( PDF ) Desenvolvimento de um método tentativo para a melhoria da acuridade de dados de um sistema de programação da produção: um estudo de caso em uma empresa do setor de alimentos cárneos

Download PDF

ads:

UNIVERSIDADE DO VALE DO RIO DOS SINOS (UNISINOS)

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE PRODUÇÃO E

SISTEMAS (PPGEPS)

NÍVEL MESTRADO

EDUARDO SCHERER RÜCKER

DESENVOLVIMENTO DE UM MÉTODO TENTATIVO PARA A MELHORIA DA

ACURACIDADE DE DADOS DE UM SISTEMA DE PROGRAMAÇÃO DA PRODUÇÃO

– UM ESTUDO DE CASO EM UMA EMPRESA DO SETOR DE ALIMENTOS

CÁRNEOS

São Leopoldo

2009

ads:

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.

EDUARDO SCHERER RÜCKER

DESENVOLVIMENTO DE UM MÉTODO TENTATIVO PARA A MELHORIA DA

ACURACIDADE DE DADOS DE UM SISTEMA DE PROGRAMAÇÃO DA PRODUÇÃO

– UM ESTUDO DE CASO EM UMA EMPRESA DO SETOR DE ALIMENTOS

CÁRNEOS

Dissertação apresentada como requisito parcial

para a obtenção do título de Mestre pelo

Programa de Pós-graduação em Engenharia de

Produção e Sistemas da Universidade do Vale

do Rio dos Sinos (UNISINOS).

Orientador: Prof. Dr. Luís Henrique Rodrigues

São Leopoldo

2009

ads:

Ficha catalográfica

Catalogação na Publicação:

Bibliotecária Carla Inês Costa dos Santos - CRB 10/973

R912d Rücker, Eduardo Scherer

Desenvolvimento de um método tentativo para a melhoria

da acuracidade de dados de um sistema de programação da

produção: um estudo de caso em uma empresa do setor de

alimentos carneos / por Eduardo Scherer Rücker. – 2009.

324 f.: il.

Dissertação (mestrado) -- Universidade do Vale do Rio dos

Sinos, Programa de Pós-Graduação em Engenharia de Produção e

Sistemas, 2009.

“Orientação: Profº. Drº. Luis Henrique Rodrigues, Ciências

Econômicas”.

1. .Produção – Sistema de programação. 2. Dados de

produção – Acuracidade. 3. .Programação da produção –

Indústria cárnea. I. Título.

FOLHA DE APROVAÇÃO

Eduardo Scherer Rücker

DESENVOLVIMENTO DE UM MÉTODO TENTATIVO PARA A MELHORIA DA

ACURACIDADE DE DADOS DE UM SISTEMA DE PROGRAMAÇÃO DA PRODUÇÃO

– UM ESTUDO DE CASO EM UMA EMPRESA DO SETOR DE ALIMENTOS

CÁRNEOS

Dissertação apresentada à Universidade do

Vale do Rio dos Sinos – Unisinos, como

requisito parcial para obtenção do título de

Mestre em Engenharia de Produção e Sistemas.

Aprovado em 27 de fevereiro de 2009.

BANCA EXAMINADORA

Prof. Dr. Guilherme Luis Roehe Vaccaro – UNISINOS

Prof. Dr. Ricardo Augusto Cassel – UNISINOS

Prof. Dr. Antônio Carlos Gastaud Maçada – UFRGS

Prof. Dr. Luís Henrique Rodrigues (Orientador)

Visto e permitida a impressão.

São Leopoldo,

Prof. Dr. Guilherme Luis Roehe Vaccaro

Coordenador Executivo PPG em

Engenharia de Produção e Sistemas

AGRADECIMENTOS

Impossível ter concebido a realização deste sonho sem o apoio dos meus pais e do

meu irmão. Muito obrigado!

Aos meus avós, que sempre rezaram por mim.

À Kelly, por ter compreendido a importância do mestrado e me apoiado. Eu te amo!

À UNISINOS, pela bolsa concedida, certamente um dos maiores incentivos, o qual

viabilizou este sonho.

Ao Professor Dr. Luís Henrique Rodrigues, meus sinceros agradecimentos pelo

incentivo para fazer o mestrado, pela confiança depositada, prestativa orientação e amizade.

Espero poder um dia retribuir todas as coisas boas que aprendi contigo durante as aulas e as

conversas sobre a dissertação.

Ao Professor Dr. Guilherme Vaccaro, pelo incentivo em fazer o mestrado, auxílio para

a disciplina de estatística, pela participação na banca e disposição para conversar sobre os

anseios de um mestrando.

Ao Professor Dr. Ricardo Cassel, pela participação na banca e por ter oportunizado a

experiência de assistir às aulas da sua disciplina de Simulação do mestrado quando eu ainda

estava na graduação. Podes ter certeza de que aquela vivência também me motivou para

cursar o mestrado.

Ao Professor Dr. Antônio Carlos Gastaud Maçada, por receber-me de braços abertos

na UFRGS para que falasse sobre a minha pesquisa, pelas contribuições ao trabalho e por ter

aceitado o convite para participar da banca de defesa da dissertação.

Ao Daniel Berlitz, Ricardo Scherer e Osmar Herzer, por terem me dado uma força na

empresa.

A todas as pessoas que participaram do projeto onde desenvolvi a dissertação. Este

trabalho é também fruto das contribuições, questionamentos ou simples conversas junto aos

membros da equipe de projeto, aos usuários-chave e a outras pessoas da empresa, além dos

consultores e analistas de sistemas da ferramenta de programação da produção pesquisada.

Meus agradecimentos a: Maria Cristina, Rafael, Dudu, Luís Afonso, Thiago, Andréa,

Christianne (Santinha), Adri, Júlio, Luciano, Cristiano e Carlos; Graciela, Rudi, Hélio,

Denise, Caetano, Paulo Ricardo, Otávio, Edenilson, Marcão, Émerson Luís, Ju, Alex Vagner

e Émerson Rodrigo; Néia, Pri, Duda, Fran, Carol, Afrânio, Xepa, Paulo Rodrigo, Maria e

Toni; LHR, Vaccaro, Diego, Felipe, Jonatas, JP, Fabian, Carlinhos e Maurício.

Ao Daniel Lacerda, Eduardo Milanez, Felipe Menezes, Flávio Kato e Lucas

Mörschbächer, pelo apoio.

A todos os professores do Programa de Pós-graduação em Engenharia de Produção e

Sistemas (PPGEPS), pelo excelente ambiente de aprendizado e pela relação fraterna com os

alunos.

Aos meus colegas da turma 2007: foi muito bom conviver com vocês!

Às meninas da secretaria da pós-graduação, muito obrigado pela atenção dispensada.

Ao José Cesar e Helena, pela receptividade na GD, e ao Kato, pelo “bate-papo

qualificado de dados”.

Ao Danilo, pelas caronas durante a época de aulas.

RESUMO

O presente estudo teve como objetivo o desenvolvimento de um método tentativo para a

melhoria da acuracidade dos dados de um sistema específico de programação da produção

para a indústria cárnea. A proposição baseou-se no projeto de implementação da referida

ferramenta na Empresa Alfa, a qual produz alimentos a base de frangos, perus e suínos. O

método de pesquisa utilizado foi um estudo de caso, por meio do qual se relatou e se analisou

a influência da acuracidade dos dados sobre as informações geradas pelo sistema durante o

projeto. O desenvolvimento do método proposto baseou-se no referencial teórico sobre

programação da produção, qualidade de dados e qualidade de informações; nas percepções do

autor acerca da participação do mesmo no projeto onde se aplicou o estudo de caso; e nas

contribuições de especialistas na temática do trabalho. A partir disso, estruturou-se o método

tentativo por meio de processos e subprocessos, hierarquização que possibilitou a execução

dos objetivos de cada processo em relação à acuracidade dos dados por etapas (subprocessos).

Ao final do trabalho, concluiu-se que a proposta ofereceu uma relevante contribuição para a

discussão da qualidade de dados na programação da produção de alimentos cárneos.

Palavras-chave: Acuracidade de dados. Qualidade de dados. Qualidade de informações.

Programação da produção. Indústria cárnea.

ABSTRACT

This study aims to develop a tentative method for improving the data accuracy of a specific

production scheduling software for the meat industry. The proposition was based on the

project phase of the implementation of a tool in Empresa Alfa, which produces food based on

chickens, turkeys and porks. The research method used was a case study, by means of which

it is reported and analyzed the influence of data accuracy on the information generated by the

system during the project. The development of the proposed method was based on the

theoretical framework on production scheduling, data quality and information quality, the

author's perceptions about the same project which was applied in the case study and the

contributions of experts in the thematic of the work. From this, the tentative method was

structured by means of processes and subprocesses, hierarchy that enabled the implementation

of the objectives of each process regarding the data accuracy in stages (subprocesses). At the

end of the study, the autor concluded that the proposal offered a significant contribution to the

discussion of data quality in the production scheduling of meat foods.

Keywords: Data accuracy. Data quality. Information quality. Production scheduling. Meat

food industry.

LISTA DE FIGURAS, QUADROS E TABELAS

FIGURA 1 – Estrutura sistêmica para uma compreensão inicial do problema da qualidade de

dados no caso pesquisado .........................................................................................................20

FIGURA 2 – Desenho esquemático sobre o conflito entre a programação manual de produção

e a gerada por um sistema, e o posicionamento do método proposto.......................................22

FIGURA 3 – Dados de saída do sistema de PPCPM (fonte: Klippel, Antunes e Pellegrin,

2005).........................................................................................................................................29

FIGURA 4 – Analogia entre a manufatura de produtos e a geração de dados (fonte: adaptado

de Wang, Storey e Firth, 1995).................................................................................................35

QUADRO 1 – Componentes da pesquisa da qualidade de dados (fonte: adaptado de TDQM,

2008).........................................................................................................................................43

FIGURA 5 – Ciclo do TDQM (fonte: adaptado de Wang, 1998). ...........................................44

QUADRO 2 – Processo de construção de teoria através de estudos de caso (fonte: adaptado de

Eisenhardt, 1989)......................................................................................................................50

FIGURA 6 – Estrutura da cadeia de frangos e perus................................................................53

FIGURA 7 – Método de trabalho .............................................................................................55

FIGURA 8 – Exemplo de estrutura de produto de um frango..................................................63

FIGURA 9 – Exemplo de estrutura de produto de um formulado. ..........................................64

FIGURA 10 – Gráfico de Gantt do projeto de implementação do sistema de seqüenciamento

da produção...............................................................................................................................65

FIGURA 11 – Exemplo de uma estrutura de um produto formulado fictício com os roteiros de

produção ...................................................................................................................................71

FIGURA 12 – Exemplo de uma estrutura de produto fictícia de um frango vivo de 1.400 g..72

FIGURA 13 – Representação do fluxo dos grupos de dados de acordo com a função dos

mesmos no sistema ...................................................................................................................73

FIGURA 14 – Representatividade de cada grupo de dados sobre o peso total das tabelas do

sistema de seqüenciamento da produção ..................................................................................74

TABELA 1 – Exemplo de uma curva de peso fictícia de um frango vivo de 1.400 g.............75

FIGURA 15 – Exemplo de parte de uma árvore de cortes de frango .......................................77

FIGURA 16 – Exemplo de uma árvore de formulação ............................................................78

FIGURA 17 – Gráfico de Gantt do período em que foram utilizados procedimentos para a

acuracidade de dados no sistema de sistema de seqüenciamento da produção ........................82

GRÁFICO 1 – Indicador de abate total global.........................................................................88

GRÁFICO 2 – Indicador de produção total global...................................................................89

GRÁFICO 3 – Indicador de resíduo total global......................................................................89

GRÁFICO 4 – Indicador de percentual de pedidos programados em relação ao total de

pedidos pendentes.....................................................................................................................91

FIGURA 18 – Resumo dos passos sugeridos para a análise dos dados na fase 4 ....................92

TABELA 2 – Exemplo da programação do produto A a partir de três árvores de cortes ........94

GRÁFICO 5 – Indicador de percentual de pedidos programados em relação ao total de

pedidos pendentes durante a fase 4...........................................................................................95

GRÁFICO 6 – Indicador de percentual de pedidos programados no prazo em relação ao total

de pedidos pendentes durante a fase 4......................................................................................96

FIGURA 19 – Estrutura simbólica do balanço de massas........................................................97

FIGURA 20 – Resumo dos passos para a análise e melhoria da programação de cortes na fase

5 ................................................................................................................................................99

FIGURA 21 – Resumo dos passos para a análise e melhoria da programação de formulados na

fase 5.........................................................................................................................................99

QUADRO 3 – Matriz de indicadores desenvolvida para a fase 5 ..........................................101

GRÁFICO 7 – Indicador de atendimento de seqüencias ME no prazo na fase 5...................102

GRÁFICO 8 – Indicador de atendimento da demanda MI na fase 5......................................102

GRÁFICO 9 – Indicador de aderência do abate empurrado na fase 5 ...................................103

GRÁFICO 10 – Indicador de variabilidade do abate puxado na fase 5 .................................104

GRÁFICO 11 – Indicador de programação de pedidos..........................................................107

GRÁFICO 12 – Indicador de atendimento de pedidos no prazo ............................................107

FIGURA 22 – O fluxo dos dados e o foco do método ...........................................................110

FIGURA 23 – Árvore de pré-requisitos de dados para a geração de uma programação

coerente...................................................................................................................................113

FIGURA 24 – Processos do método proposto........................................................................117

FIGURA 25 – Subprocessos do método proposto..................................................................118

FIGURA 26 – Hierarquia dos componentes do fluxo dos subprocessos................................120

QUADRO 4 – Legenda dos componentes dos fluxos do método ..........................................121

FIGURA 27 – Codificação padrão das atividades e testes dos subprocessos do método

proposto ..................................................................................................................................122

FIGURA 28 – Fluxograma do Subprocesso 1.1.....................................................................123

FIGURA 29 – Fluxograma do Subprocesso 1.2.....................................................................125

FIGURA 30 – Fluxograma do Subprocesso 1.3.....................................................................126

QUADRO 5 – Indicadores do método proposto.....................................................................130

FIGURA 31 – Fluxograma do Subprocesso 1.4.....................................................................131

QUADRO 6 – Parâmetros e objetivos dos subprocessos do Processo 2................................137

FIGURA 32 – Fluxograma do Subprocesso 2.1.....................................................................139

FIGURA 33 – Fluxograma do Subprocesso 2.2.....................................................................144

FIGURA 34 – Fluxograma do Subprocesso 2.3.....................................................................148

FIGURA 35 – Fluxograma do Subprocesso 2.4.....................................................................152

FIGURA 36 – Fluxograma do Subprocesso 2.5.....................................................................156

FIGURA 37 – Fluxograma do Subprocesso 2.6.....................................................................160

FIGURA 38 – Fluxograma do Subprocesso 2.7.....................................................................163

FIGURA 39 – Fluxograma do Subprocesso 2.8.....................................................................168

FIGURA 40 – Fluxograma do Subprocesso 2.9.....................................................................171

FIGURA 41 – Fluxograma do Subprocesso 2.10...................................................................175

FIGURA 42 – Fluxograma do Subprocesso 2.11...................................................................177

FIGURA 43 – Fluxograma do Subprocesso 2.12...................................................................179

FIGURA 44 – Fluxograma do Subprocesso 2.13...................................................................181

FIGURA 45 – Fluxograma do Subprocesso 2.14...................................................................184

FIGURA 46 – Fluxograma do Subprocesso 2.15...................................................................186

LISTA DE SIGLAS

ERP: sigla para Enterprise Resource Planning, refere-se aos sistemas integrados de

gestão.

ME: mercado externo.

MI: mercado interno.

P&D: Pesquisa e Desenvolvimento.

SIF: Serviço de Inspeção Federal, órgão governamental brasileiro que fiscaliza a

produção de alimentos de origem animal.

TI: Tecnologia da Informação.

SUMÁRIO

1 INTRODUÇÃO....................................................................................................................15

1.1 Justificativa .........................................................................................................................17

1.2 Questão de pesquisa............................................................................................................23

1.3 Objetivos.............................................................................................................................23

1.3.1 Objetivo geral..................................................................................................................24

1.3.2 Objetivos específicos .......................................................................................................24

1.4 Delimitações da pesquisa....................................................................................................24

1.5 Estrutura do trabalho...........................................................................................................27

2 REFERENCIAL TEÓRICO ..............................................................................................28

2.1 Programação da Produção ..................................................................................................28

2.1.1 Conceitos básicos de PCPM ............................................................................................28

2.1.2 O problema do seqüenciamento da produção..................................................................29

2.1.3 Os dados nos sistemas de seqüenciamento da produção .................................................30

2.2 Gerenciamento de dados e informações .............................................................................32

2.2.1 Dados versus informações e outros delineamentos.........................................................33

2.2.2 O estudo da qualidade de dados.......................................................................................34

2.2.3 A dimensão acuracidade no conceito de qualidade de dados ..........................................37

2.3 Métodos para a qualificação de dados ................................................................................37

2.3.1 Abordagens estatísticas....................................................................................................39

2.3.2 Abordagens tecnológicas .................................................................................................39

2.3.3 Abordagens gerenciais .....................................................................................................40

2.3.4 Abordagens mistas...........................................................................................................43

2.4 Considerações finais sobre o capítulo.................................................................................45

3 MÉTODO.............................................................................................................................47

3.1 Método de pesquisa ............................................................................................................47

3.1.1 Desenvolvimento de teorias a partir de estudos de caso..................................................49

3.2 Método de trabalho .............................................................................................................53

4 ESTUDO DE CASO............................................................................................................61

4.1 Sistemas produtivos da Empresa Alfa ................................................................................61

4.2 A implementação do sistema de programação da produção...............................................64

4.2.1 Mapeamento dos processos de atendimento de pedido ...................................................66

4.2.2 Especificação conceitual..................................................................................................66

4.2.3 Redesenho de processos ..................................................................................................67

4.2.4 Levantamento de requisitos de dados ..............................................................................67

4.2.5 Coleta de dados e desenvolvimento da ferramenta..........................................................67

4.2.6 Disponibilização para uso e testes ...................................................................................68

4.2.7 Treinamento de usuários..................................................................................................68

4.2.8 Testes dos usuários..........................................................................................................69

4.2.9 Homologação...................................................................................................................69

4.3 O sistema de programação da produção .............................................................................70

4.4 A estruturação dos dados no sistema ..................................................................................72

4.4.1 Visão geral e conceitos sobre os dados............................................................................72

4.4.2 Detalhamento dos dados do sistema ................................................................................79

4.4.2.1 Dados cadastrais ...........................................................................................................79

4.4.2.2 Dados de abates ............................................................................................................79

4.4.2.3 Dados industriais ..........................................................................................................80

4.4.2.4 Dados comerciais ..........................................................................................................80

4.4.2.5 Dados logísticos............................................................................................................80

4.5 Procedimentos utilizados para a acuracidade dos dados no estudo de caso .......................81

4.5.1 Fase 1 – População de dados...........................................................................................82

4.5.2 Fase 2 – Correção de erros triviais ..................................................................................83

4.5.3 Fase 3 – Os primeiros passos em direção a um método para a correção dos dados........86

4.5.4 Fase 4 – A intensificação de esforços junto às fábricas e a formalização de um

procedimento para a acuracidade dos dados.............................................................................92

4.5.5 Fase 5 – Extensão do projeto ...........................................................................................98

4.6 Resumo e avaliação dos procedimentos adotados ............................................................104

5 PROPOSIÇÃO DE UM MÉTODO TENTATIVO PARA A MELHORIA DA

ACURACIDADE DE DADOS EM UM SISTEMA DE PROGRAMAÇÃO DA

PRODUÇÃO PARA A INDÚSTRIA CÁRNEA................................................................109

5.1 Pressupostos e estratégias para o desenvolvimento do método e para a melhoria da

acuracidade de dados ..............................................................................................................109

5.2 Método tentativo para a melhoria da acuracidade dos dados ...........................................116

5.2.1 Processo 1 – Preparação de dados .................................................................................122

5.2.1.1 Subprocesso 1.1 – Especificação de dados.................................................................122

5.2.1.2 Subprocesso 1.2 – Estruturação de dados...................................................................123

5.2.1.3 Subprocesso 1.3 – Auto-validação de dados ..............................................................125

5.2.1.4 Subprocesso 1.4 – Testes de importação de dados .....................................................131

5.2.2 Processo 2 – População e melhoria da acuracidade de dados .......................................132

5.2.2.1 Subprocesso 2.1 – Dados cadastrais e estoques de produtos......................................138

5.2.2.2 Subprocesso 2.2 – Pedidos fictícios de formulados....................................................140

5.2.2.3 Subprocesso 2.3 – Capacidades finitas de formulados...............................................145

5.2.2.4 Subprocesso 2.4 – Suprimentos de formulados..........................................................150

5.2.2.5 Subprocesso 2.5 – Capacidades reais de estoques (teste formulados)........................154

5.2.2.6 Subprocesso 2.6 – Formulados global........................................................................157

5.2.2.7 Subprocesso 2.7 – Pedidos fictícios de cortes............................................................161

5.2.2.8 Subprocesso 2.8 – Capacidades finitas de cortes........................................................165

5.2.2.9 Subprocesso 2.9 – Suprimentos de cortes...................................................................169

5.2.2.10 Subprocesso 2.10 – Cortes global.............................................................................172

5.2.2.11 Subprocesso 2.11 – Balanceamento de cortes e formulados (sem abates) ...............175

5.2.2.12 Subprocesso 2.12 – Balanceamento de cortes e formulados (com abates)...............178

5.2.2.13 Subprocesso 2.13 – Capacidades finitas de cortes e formulados..............................180

5.2.2.14 Subprocesso 2.14 – Suprimentos de cortes e formulados.........................................182

5.2.2.15 Subprocesso 2.15 – Cortes e formulados global.......................................................184

5.3 Fatores Críticos de Sucesso para a aplicação do método tentativo ..................................187

5.4 Considerações finais do capítulo ......................................................................................191

6 CONCLUSÃO E RECOMENDAÇÕES PARA TRABALHOS FUTUROS ...............193

6.1 Conclusão .........................................................................................................................193

6.2 Recomendações para trabalhos futuros ............................................................................195

1 INTRODUÇÃO

Em um contexto de competição entre as empresas em nível mundial, a capacidade de

as organizações agirem perante um ambiente de negócios de constante mudança exige que a

tomada de decisão seja qualificada. Diante deste cenário, a informação é um dos fatores que

adquirem importância em função de representarem o insumo para o processo de escolha de

alternativas de ação. Para que se obtenha um diferencial competitivo perante esta tendência, o

investimento em sistemas de informação contribui para que a tomada de decisão seja rápida e

qualificada. Neste sentido, como forma de atender aos cada vez mais exigentes mercados

consumidores, as indústrias de manufatura dependem de informações qualificadas a respeito

da programação de produção. A operacionalização de sistemas de informação para este fim

nas organizações depende da disponibilidade de dados cuja acuracidade reflita a realidade da

empresa.

A agroindústria brasileira, especialmente as empresas produtoras de alimentos a base

de carnes (frigoríficos e fábricas de produtos industrializados), vem passando por um

momento que a credenciou para competir com os maiores players (empresas) deste mercado.

Particularmente no que tange ao mercado de carnes, o Brasil ocupa uma posição de destaque:

dentro do panorama mundial de exportações de produtos a base de frango, o País foi o maior

exportador no período de 2004 a 2007 (ABEF, 2008).

A complexidade da cadeia produtiva do ramo de carnes, tendo em vista a diversidade

dos membros da mesma, aliada à necessidade de melhor atender aos clientes, exige das

empresas a capacidade de produzirem seus produtos dentro de padrões de qualidade e dos

prazos estipulados pelos clientes. Para que esta situação seja sustentável do ponto de vista

financeiro e em longo prazo, as firmas necessitam investir nos parques fabris e adotar

estratégias que as auxiliem na alocação dos recursos materiais e humanos na área de

manufatura. Dentro deste contexto, a sincronização dos processos produtivos de frigoríficos e

de fábricas de industrializados pode ser suportada por sistemas de informação capazes de

potencializar o processo de tomada de decisão.

A implementação de sistemas de seqüenciamento da produção em empresas de

alimentos cárneos permite que as peculiaridades inerentes ao ambiente produtivo destas

firmas sejam consideradas nas decisões de aprazamento de pedidos. Em função disso, estas

características contribuem para que o sistema seja validado junto aos usuários, pois estes

compreendem que possuem uma ferramenta direcionada para a realidade que conhecem.

Independentemente da organização, estes sistemas auxiliam na geração de planos de

produção que possam ser utilizados para a programação das operações de manufatura, pois

são respeitadas as restrições das fábricas a partir de dados coletados nas linhas de produção.

Além disso, este tipo de sistema representa um avanço sobre técnicas manuais ou semi-

automatizadas de programação (quando se utilizam planilhas eletrônicas, por exemplo). Em

suma, um sistema dessa natureza é desenvolvido por meio de heurísticas que possibilitam a

geração de informações de forma ágil e independente de critérios subjetivos.

Os sistemas de seqüenciamento da produção demandam a disponibilidade de dados

sobre a empresa, especialmente aqueles relacionados à área de produção, como a capacidade

instalada, por exemplo. Para que o sistema represente a realidade da programação da

produção, o mesmo deve ser alimentado com dados de entrada coerentes com os pressupostos

utilizados pela empresa na geração dos planos de produção (cortes e industrializados).

A utilização dos dados coletados em ambientes de manufatura revela-se importante em

função dos impactos que a qualidade dos mesmos pode exercer. Caso os dados não sejam

alimentados corretamente no sistema (seja por sub ou superestimação ou então por diferirem

da natureza do dado esperado), os resultados da ferramenta (programação sugerida, por

exemplo) não estarão de acordo com a realidade da área de manufatura. Em uma fábrica, os

efeitos da utilização de planos de produção incoerentes com a realidade comprometem a

gestão da mesma, podendo acarretar problemas irreversíveis como o atraso de pedidos. Já no

âmbito da empresa como um todo, as conseqüências podem ser ainda maiores. Exemplos

disso são os problemas de fluxo de caixa em função da compra desnecessária de embalagens e

a redução do faturamento pela perda de clientes quando da ocorrência de atrasos de entrega

dos pedidos.

Após a etapa de população dos dados no sistema (inserção no banco de dados), a

qualidade destes pode influenciar na ocorrência de problemas nas informações geradas pelo

sistema, como um programa de produção que não condiga com a realidade da firma. Em

outras palavras, entende-se que a qualidade das informações geradas pelo sistema possa ser

uma conseqüência da qualidade dos dados de entrada. Diante disso, são necessárias atividades

de limpeza dos dados e de análises criteriosas sobre as causas de eventuais problemas

relacionados aos mesmos. Entretanto, não se pode atribuir à qualidade dos dados a

exclusividade pelos resultados de um sistema de informação. Os fatores que também

influenciam neste quesito são a qualidade do sistema utilizado (algoritmo) e a qualidade da

modelagem do negócio dentro do sistema.

A atividade de melhoria de dados em ambientes de manufatura possui um desafio, o

qual implica na necessidade de se qualificar um determinado volume de caracteres não

estruturados e voláteis (ou seja, dispersos, em constante mudança e inseridos de acordo com

diferentes critérios de modelagem). Dentro do escopo da qualificação de dados, este desafio

pode ser superado no momento em que se avaliarem os impactos das atividades de

refinamento de dados. Com isso, possibilita-se a avaliação das tarefas que contribuem para a

melhoria dos dados e também das tarefas cuja contribuição para o processo não seja relevante.

A partir destes pressupostos e da participação do autor do presente trabalho na

implementação de um sistema de seqüenciamento da produção em uma empresa de alimentos

cárneos, o presente estudo versou sobre a acuracidade dos dados de entrada do referido

sistema. O desenvolvimento do trabalho teve como objetivo a proposição de um método

tentativo para a melhoria da acuracidade dos dados da referida ferramenta. A estruturação da

abordagem foi delineada sob a forma de processos e subprocessos, conforme será visto no

trabalho. Já a pesquisa foi realizada sobre um estudo empírico da etapa de projeto (pré-

homologação), portanto todas as considerações, bem como o método proposto, estiveram

condicionadas a este fator. Para fins de preservação da empresa pesquisada, a referência à

mesma se deu sob o nome “Empresa Alfa”.

1.1 Justificativa

Do ponto de vista do estudo da qualidade de dados, Sheth, Wood e Kashyap (1994)

reconhecem o problema em um artigo, mencionando aspectos como a ocorrência de

inconsistências entre os dados armazenados dentro de uma mesma base; os dados duplicados

ou redundâncias (as quais são desnecessárias, pois impactam na qualidade dos resultados de

um sistema e no tempo de execução ou de reposta para o usuário); e os erros intrínsecos ao

dado (discrepâncias entre o dado armazenado e dado real). Olson (2002) e Redman (2004)

referem-se à influência da qualidade de dados sobre a tomada de decisão, e o segundo

sustenta que o armazenamento de dados pelas empresas e órgãos governamentais aumenta em

descompasso com as preocupações em torno da acuracidade.

Conforme uma pesquisa desenvolvida por Torres (1999), dentre as dificuldades

encontradas na implementação de um sistema de programação fina da produção, os problemas

relacionados à qualidade dos dados levaram à realização de trabalhos de correção e de

adequação de dados. O referido autor também ressalta que a inexatidão dos dados

comprometeu a geração dos planos detalhados de produção (TORRES, 1999). Goldratt (1991)

e Bonjour, Baptiste e Larchvèque (1997) também tratam da temática da qualidade de dados

dentro do seqüenciamento da produção. Já Loshin (2001) ressalta que as ferramentas de

qualidade de dados concentram-se na limpeza de dados de nomes e endereços.

A programação de produção cumpre uma função estratégica nas organizações em

função de traduzir para o ambiente produtivo as demandas do mercado consumidor

estabelecidas pela área de vendas. Daoud e Maçada (2005) sustentam que as atividades do

PCP impactam na produtividade das empresas, o que reflete na competitividade das

organizações. As informações geradas pela programação de produção desdobram-se para

outras áreas de uma empresa, sendo utilizadas, por exemplo, para a avaliação da necessidade

de investimentos, para a estimativa de fluxo de caixa e para o dimensionamento da logística

de transportes.

Analisando-se a cadeia de produção da indústria cárnea avícola e de suínos, a estrutura

de produção verticalizada demanda a existência de informações qualificadas, pois as decisões

da empresa focal (neste caso, de suas fábricas) podem impactar nos elos da cadeia. Ainda,

ressalta-se que este ramo da indústria lida com matéria-prima viva e alimentos para o

consumo humano, além de possuir processos produtivos convergentes e divergentes. Estes

aspectos evidenciam a importância do processo de tomada de decisão quanto à programação

de produção, sendo mais bem explorados abaixo:

• matéria-prima viva: em torno de um dia antes do abate das aves e dos suínos, os

criadores responsáveis pelos aviários e pocilgas, respectivamente, iniciam um

processo diferenciado de manejo dos animais, como a cessão no consumo de ração.

Em função desta e de outras limitações, torna-se um delicado problema alterar a

programação de abate neste período de tempo (a não ser que os animais sejam

vendidos), tendo em vista que os mesmos já estão alojados nas granjas;

• pericibilidade dos produtos: os produtos cortados e os industrializados para venda,

além daqueles utilizados para a fabricação de produtos elaborados (chamados de

matérias-primas), possuem prazo de validade para o consumo humano. Com isso, a

produção da fábrica precisa ser seqüenciada de maneira que não ocorram riscos

para a saúde dos consumidores; e

• natureza dos processos produtivos: os frigoríficos e as fábricas de produtos

elaborados são caracterizados por sistemas produtivos divergentes e convergentes,

respectivamente. Nos frigoríficos, um frango vivo abatido gera resíduos e produtos

compulsórios (penas, sangue, vísceras e miúdos, dentre outros) e ainda alguns

produtos alternativos (cortado ou inteiro, por exemplo). Esta segunda denominação

refere-se às opções de produção de um determinado produto. No caso de uma

carcaça de frango, a mesma pode ser utilizada para se produzir frango inteiro ou

produtos cortados (peito, coxa e asa). Ou seja, neste caso não existe um caráter de

compulsoriedade atrelada à “desmontagem” do animal como ocorre com os

resíduos. Já no caso dos produtos elaborados, estes devem ser “montados” com

base na disponibilidade de matérias-primas e de condimento, desde que obedeça a

um padrão de formulação (especificação das proporcionalidades de cada insumo na

composição do produto).

Os fatores elencados acima contribuem para se reconhecer o papel da função de

programação da produção para as empresas do ramo cárneo. Considerando-se que fez parte do

escopo deste trabalho um estudo empírico sobre a etapa de projeto de um sistema de

seqüenciamento da produção, uniram-se a importância do PCP e a necessidade de melhoria de

dados na ferramenta.

O impacto da qualidade de dados em sistemas de programação da produção pode ser

compreendido por meio de uma analogia com o modelo entrada-transformação-saída de

processos. Tal como em um sistema produtivo, onde as matérias-primas passam por um

processo de manufatura no qual, ao final do mesmo, adquirem forma e valor econômico,

dados são utilizados para a geração de informações. Como esta é, portanto, conseqüência do

primeiro, uma decisão será prejudicada quando se basear em informações geradas a partir de

dados errados. Portanto, o refinamento dos dados necessários para a programação da

produção vai ao encontro da qualificação da tomada de decisão, tendo em vista o impacto que

as entradas do sistema exercem sobre os dados de saída (resultados) do mesmo. A partir das

informações geradas pela ferramenta, os desdobramentos das mesmas podem conter riscos

para a organização em função da qualidade dos dados utilizados.

A pesquisa deste trabalho partiu do pressuposto de que os dados constituíram-se como

um fator cuja complexidade impactou diretamente na implementação de um sistema de

seqüenciamento da produção em uma empresa da área de alimentos cárneos. Uma explicação

para este argumento e para a motivação pelo estudo relaciona-se com as dificuldades

encontradas durante o projeto do qual o autor deste estudo participou. Concomitantemente a

isso, ressalta-se a importância da discussão da qualidade de dados nas organizações, conforme

se mencionou nos parágrafos anteriores.

Com base nos pressupostos levantados até este ponto do estudo acerca do assunto e do

caso pesquisado, desenvolveu-se uma estrutura sistêmica (Figura 1) que evidencia a

importância do tema em função do impacto que a qualidade de dados exerce sobre a tomada

de decisão. Para se interpretar a Figura 1, os sinais positivos indicam relação direta entre dois

eventos.

FIGURA 1 – Estrutura sistêmica para uma compreensão inicial do problema da qualidade de dados no caso

pesquisado

Na Figura 1, quanto menor for a qualidade dos dados, pior será a qualidade das

informações geradas pelo sistema de programação da produção. Conseqüentemente, menor

será a credibilidade da ferramenta, o que poderá levar ao desuso da mesma e à falta de

manutenção dos dados, tornando-os obsoletos (portanto inacurados). Neste caso, o enlace

reforçador dos eventos (simbolizado pela letra “R” na estrutura sistêmica) indica que o

problema tenderá ao colapso exponencial, fazendo-se com que se torne inviável a utilização

do sistema de seqüenciamento da produção. Contudo, quanto mais iniciativas houver no

sentido da melhoria da qualidade dos dados, o ciclo vicioso será alterado – quanto mais ações

de melhoria, maiores serão a qualidade dos dados, das informações e das decisões, bem como

maior também será a credibilidade do sistema. Verifica-se, com isso, que as ações para a

melhoria dos dados são um ponto de alavancagem para limitar o ciclo vicioso que levaria ao

fracasso da implementação do sistema.

A organização estudada, antes de passar pelo processo de implementação do sistema

de seqüenciamento da produção, balizava parte das suas decisões de programação em

processos manuais, geralmente feitos em planilhas eletrônicas. Ainda, os dados eram

descentralizados e utilizados com base em distintos critérios distintos, dependendo do

departamento que tratava os dados. A partir da utilização de um novo sistema de programação

da produção, os dados passaram a ser centralizados e formalizados em um banco de dados,

evitando-se, assim, dados dispersos e calculados por diferentes métodos dentro da empresa.

A situação descrita no parágrafo anterior pode ser mais bem entendida por meio da

Figura 2, onde se apresentam as discrepâncias que surgem quando empresas passam da

programação manual de produção para o uso de uma ferramenta para este fim. No método

manual de seqüenciamento, o usuário modela a realidade em computador (geralmente em

planilhas eletrônicas), utilizando critérios locais (específicos para uma fábrica, por exemplo) e

empíricos, não necessariamente alinhado com as práticas de outras unidades fabris da mesma

organização.

Por outro lado, em função do uso de um sistema, a mesma realidade passa a ser

interpretada sob a forma de uma linguagem padrão, quando os dados coletados pelos analistas

de programação da produção passaram a ser armazenados na base de dados da ferramenta. Os

mesmos dados que antes eram tratados de forma descentralizada e mantidos na memória das

pessoas passam a ser compartilhados em uma base de dados – e assim, os efeitos da

programação de produção de cada fábrica impactam no seqüenciamento das outras plantas.

A partir disso, o sistema passa a gerar programas de produção que, quando

comparados com os planos que eram elaborados no método antigo, possuíam diferenças. Esta

situação leva a um conflito entre as visões antiga e nova, como também deflagra um processo

de análise das informações geradas pelo sistema para que se entendam as causas das

inconsistências observadas. A partir dessa constatação, surge a necessidade de se detectar e

corrigir erros na base de dados do sistema para que as informações geradas pelo mesmo sejam

coerentes com a realidade.

FIGURA 2 – Desenho esquemático sobre o conflito entre a programação manual de produção e a gerada por um

sistema, e o posicionamento do método proposto

Na Figura 2 também se identifica o momento em que o método que se propõe neste

estudo deveria ser inserido no processo de qualificação dos dados do sistema de

seqüenciamento da produção. A utilização de um método desta natureza combate os

problemas gerados pelos erros existentes em uma base de dados. No que diz respeito à

dificuldade em abordar o problema da qualidade de dados em organizações, Bair et al (2004)

sentenciam:

“Enquanto que a qualidade de dados é um dos mais importantes aspectos dos

esforços de gestão sobre dados de uma empresa, pode também tornar-se um dos

mais frustrantes. Particularmente para organizações com grandes volumes de dados

ou dados extremamente complexos, pode ser difícil saber por onde começar na

correção dos erros de dados” (BAIR et al, 2004, p. 3).

O método proposto neste trabalho foi desenvolvido com o intuito de contribuir para o

refinamento dos dados que são coletados na realidade e inseridos posteriormente no banco de

dados do sistema de programação da produção. Dessa forma, cria-se um canal entre a

disponibilidade dos dados coletados na realidade e a população do banco do sistema. Esta

ligação constitui-se de uma espécie de “filtro” para que os dados sejam populados

adequadamente e com a acuracidade necessária na base da ferramenta. Já o estabelecimento

de um rigor metodológico, mesmo que se restrinja à etapa de projeto, contribui para a

economia de tempo na análise dos resultados do sistema.

A geração de teoria (método) a partir de um estudo empírico único pode ser explicada

a partir da oportunidade de vivência durante toda a etapa de projeto do sistema de

seqüenciamento da produção. Neste aspecto, a riqueza de detalhes, a qual é uma característica

de qualquer estudo de caso, conferiu ao método desenvolvido uma validade interna

importante.

1.2 Questão de pesquisa

A partir das considerações expostas anteriormente, o presente estudo procurou

responder à seguinte questão: como deveria ser a estrutura de um método para a melhoria da

acuracidade de dados de um sistema de programação da produção em uma empresa do setor

de alimentos cárneos?

1.3 Objetivos

Para responder à pergunta que se faz para esta pesquisa, foram elaborados um objetivo

geral e três objetivos específicos para que a investigação fosse desenvolvida, conforme se

apresenta nas duas próximas partes deste capítulo.

1.3.1 Objetivo geral

O objetivo geral deste estudo foi o de desenvolver um método tentativo para a

melhoria da acuracidade dos dados de entrada de um sistema específico de programação da

produção em uma empresa do setor de alimentos cárneos.

1.3.2 Objetivos específicos

• realizar um estudo de caso sobre a etapa de projeto da implementação de um

sistema de seqüenciamento da produção;

• definir e detalhar os processos e subprocessos do método proposto para a melhoria

da acuracidade dos dados; e

• identificar as questões gerenciais necessárias para a aplicação do método proposto.

1.4 Delimitações da pesquisa

O presente trabalho, no âmbito do objetivo geral de pesquisa e dos objetivos

específicos, delimitou-se, por um lado, por fatores considerados necessários ao entendimento

da situação problema e aos desdobramentos dos métodos de pesquisa e de trabalho; e, por

outro lado, por aspectos considerados fora do escopo desta dissertação. Ambas as

delimitações são delineadas nos parágrafos que seguem.

Os conceitos das terminologias “qualidade” e “qualificação” de dados são abordados

neste trabalho de uma forma conjunta em função de a qualificação representar a ação sobre a

qualidade. Wang (1995) sustenta que a qualidade de dados possui algumas dimensões, as

quais são necessárias para a compreensão, a pesquisa e desenvolvimento de métodos acerca

do assunto – dentre estas dimensões, o autor destaca a acuracidade como sendo aquela que

melhor define a qualidade de um dado. Bonjour, Baptiste e Larchvèque (1997) e Winkler

(2004) corroboram com este argumento, pois a acuracidade representa o grau de

conformidade de um dado em relação à realidade na qual está inserido. Favaretto (2007, p.

346) também compreende a qualidade de um dado sob esta ótica, afirmando que “em um

senso comum, a dimensão acuracidade é apontada como a própria qualidade do dado”. A

partir disso e do entendimento do autor deste estudo em relação ao foco da pesquisa dentro do

caso que se pesquisou, a qualidade de um dado será considerada diretamente proporcional à

acuracidade do mesmo.

O desenvolvimento da pesquisa deu-se por meio de um estudo empírico sobre a etapa

de projeto da implementação de um sistema de seqüenciamento da produção em uma indústria

de alimentos cárneos. Apesar de o termo “projeto” parecer remeter ao conceito de

Gerenciamento de Projetos, este trabalho não estará atrelado ao referido tema, o qual

contempla as decisões e os desdobramentos de escopo, prazo e custo. Complementarmente,

não se pretende discutir os critérios utilizados na definição do planejamento do projeto.

A aplicação da pesquisa, no que diz respeito à utilização de um sistema específico de

seqüenciamento da produção, não buscou comparar a qualidade das informações geradas pela

ferramenta com o método até então utilizado para a programação de produção. Apesar de

terem sido elencados alguns benefícios da utilização de sistemas de seqüenciamento da

produção neste capítulo, além da influência da qualidade do sistema sobre a qualidade das

informações geradas, as observações fazem parte das percepções do autor deste trabalho

acerca do problema de pesquisa. Logo, não será objeto deste trabalho a comprovação da

hipótese acerca das vantagens do novo sistema em relação à solução anteriormente aplicada

na programação de produção.

Com relação à utilização dos termos “seqüenciamento” e “programação” da produção,

ambos foram considerados como sinônimos. Além disso, não se mencionou no trabalho a

programação de materiais, pois se consideraram os materiais diretos do produto (embalagens

e condimentos) como partes integrantes do seqüenciamento (ou programação) da produção.

O método proposto neste trabalho, em função de ter sido validado junto a especialistas

na temática da pesquisa, poderá ser replicado para outras realidades, desde que se considere o

mesmo sistema de programação da produção e o ramo de alimentos cárneos. Em outras

palavras, o método desenvolvido não é genérico a ponto de contemplar qualquer ramo

industrial ou ferramenta de seqüenciamento da produção.

Entretanto, o estudo oferece contribuições para o problema da qualificação de dados

para a programação de produção. Dentre elas, ressalta-se a proposição de índices de controle e

de indicadores para a sinalização dos impactos da acuracidade dos dados, bem como de

técnicas de análise e solução de problemas. O uso de medições não é uma opção que se limita

a uma ou outra abordagem, e sim uma forma universal de avaliação de resultados no tempo e

no espaço. Ou seja, esta iniciativa não ficará necessariamente restrita aos limites do trabalho,

podendo as medições propostas servir como alternativa para outros estudos dentro da temática

da qualidade de dados.

A elaboração do método não poderá ser confundida com a modelagem de banco de

dados (estruturação do mesmo), dado que este contempla aspectos tecnológicos, o que está

fora do escopo deste trabalho. Ainda, o método desenvolvido não passou por uma etapa de

testes, porém a validade do mesmo foi submetida à avaliação de experts no tema deste

trabalho, cujas contribuições foram utilizadas na elaboração do método.

A partir do exposto acima, entende-se que a acuracidade dos dados é um fator que

influencia na geração de informações por um sistema computadorizado. Este estudo partiu do

pressuposto de que os dados do sistema de seqüenciamento pesquisado foram previamente

coletados de acordo com critérios que a empresa julgou importantes (amostragem estatística,

leitores óticos, entre outros). Assim, coube ao método proposto o estabelecimento de uma

abordagem capaz de qualificar os dados da realidade (sinalizando para eventuais problemas,

quando for o caso) – com isso, o método não indica o quanto o dado está impreciso, e sim se

está prejudicando os resultados do sistema.

Como já mencionado neste estudo, a qualidade das informações geradas pelo sistema

depende da qualidade da ferramenta (algoritmo

), da modelagem empregada e dos dados de

entrada. Do ponto de vista da modelagem, entende-se que uma vez desenvolvido o modelo de

uma forma que o mesmo seja coerente com a realidade da empresa, não existem perspectivas

quanto a mudanças com mais freqüência que aquelas verificadas nos dados de entrada, pois

estes são suscetíveis à dinâmica de mudanças do ambiente de manufatura. Com isso,

manutenções na base de dados tornam-se mais freqüentes que os ajustes no modelo à medida

que melhoram os resultados do sistema, os quais são influenciados pela qualidade dos dados.

Por fim, as questões políticas envolvidas na gestão sobre os dados não foram

consideradas pelo fato de desvirtuarem do objetivo deste estudo. O papel do método não

deverá ser o de identificar as causas dos problemas de dados nos espectros político e cultural

Em sistemas de informação, trata-se de um procedimento computacional composto por uma seqüência finita de

instruções que recebe um ou mais valores (entrada) e produz um ou mais valores (saída).

(em função de motivação de funcionários, dentre outros), mas auxiliar na identificação dos

problemas e na sugestão de alternativas de solução para os mesmos.

1.5 Estrutura do trabalho

O presente trabalho foi estruturado em 6 capítulos, conforme se descreve nos

próximos parágrafos.

O capítulo 1 (introdução) apresentou o tema e o problema de pesquisa, como também

os objetivos geral e específicos. A contextualização do tema e a delimitação do trabalho são

feitas sob a ótica da importância e da relevância do assunto a ser pesquisado.

O capítulo 2 (referencial teórico) foi desenvolvido com o intuito de reunir os conceitos

que o autor deste trabalho julgou necessários para o entendimento do tema. Ainda, este

capítulo serviu para que fossem analisadas as referências que poderiam ser utilizadas para a

proposição do método para a melhoria da acuracidade de dados.

O capítulo 3 versa sobre o método de pesquisa a ser utilizado neste estudo, o qual foi

necessário para nortear a coleta e a análise de dados, além de discutir elementos necessários

para a proposição do método para a melhoria da acuracidade de dados. Neste capítulo também

se expõe o método de trabalho, o qual se utilizou do método de pesquisa e dos objetivos

gerais do estudo para propor os passos para a execução da pesquisa.

No capítulo 4 descreve-se o caso pesquisado, no qual se relatou com maior precisão o

problema de pesquisa e as atividades realizadas.

No capítulo 5, a partir das constatações evidenciadas no caso pesquisado, no

conhecimento adquirido pelo pesquisador e nas contribuições de experts na temática do

estudo, propõe-se um método tentativo para a melhoria da acuracidade de dados do sistema

pesquisado.

Por fim, no capítulo 6, são feitas as conclusões do trabalho, bem como sugeridas

recomendações para pesquisas futuras.

2 REFERENCIAL TEÓRICO

As referências utilizadas para o desenvolvimento deste trabalho estão concentradas em

dois grupos temáticos, os quais estão relacionados aos conceitos de programação da produção

e de qualidade de dados e de informações. O uso da teoria disponível foi útil para que as

análises e proposições do estudo fossem balizadas por pressupostos teóricos e contribuíssem

para a validação interna da pesquisa.

2.1 Programação da Produção

Esta seção apresenta os conceitos básicos sobre Programação e Controle da Produção

e dos Materiais (PCPM), sendo que se enfatiza a programação em detrimento do controle,

pois este componente do conceito não faz parte do escopo da pesquisa. Ainda, descrevem-se

fundamentos sobre o seqüenciamento da produção.

2.1.1 Conceitos básicos de PCPM

A função de Programação e Controle da Produção e dos Materiais (PCPM)

desempenha uma das tarefas mais complexas em uma organização, mais especificamente na

gestão da produção (SLACK, CHAMBERS e JOHNSTON, 2002). Pedroso e Corrêa (1996)

sustentam que isso acontece em função do volume de variáveis necessárias para o processo de

PCPM, dentre outros aspectos.

A operacionalização do PCPM é estudada por Klippel, Antunes e Pellegrin (2005). Os

autores sugerem uma representação simbólica das etapas do processo global (Figura 3), o qual

contempla também a função de planejamento (que não faz parte do escopo do estudo). As

referidas etapas correspondem a 4 questões, cujas respostas auxiliam no desdobramento das

atividades fabris para o planejamento e o seqüenciamento das operações.

FIGURA 3 – Dados de saída do sistema de PPCPM (fonte: Klippel, Antunes e Pellegrin, 2005)

Conforme pode ser visualizado na Figura 3, o processo gera definições básicas para a

área de manufatura, tanto do ponto de vista dos planos de produção quanto da gestão de

materiais. Dentro do processo de PPCPM, existem os chamados circuitos do planejamento, da

programação e do controle, os quais orientam a tomada de decisão no médio prazo, no curto

prazo e no acompanhamento da aderência de produção, respectivamente (KLIPPEL,

ANTUNES E PELLEGRIN, 2005). A estes diferentes níveis da informação dá-se o nome de

planejamento hierárquico da produção (PEDROSO E CORRÊA, 2006).

O planejamento corresponde à definição global dos planos de produção e de compras

de matérias-primas, de forma agregada, tendo por base uma previsão de vendas e/ou os

pedidos confirmados informados pela área comercial da empresa. Para que este plano seja

desdobrado para a realidade de um sistema produtivo, o circuito de programação engloba a

sincronização da produção e a necessidade de materiais. Nesta etapa, as informações são mais

detalhadas e geradas a partir da estrutura de materiais que cada produto necessita. A partir da

realização da produção e do consumo de materiais, o controle é necessário para que seja feita

a comparação entre aquilo que se programou e a produção realizada. Com base nos dados

apontados nesta etapa, faz-se a reprogramação das operações para o próximo grão de

programação (turno ou dia, por exemplo).

2.1.2 O problema do seqüenciamento da produção

O seqüenciamento da produção, a fim de gerar programas factíveis para a área de

manufatura, deve reconhecer os recursos produtivos que restringem a capacidade de uma

fábrica. Para o entendimento desta questão, é necessário delinear os conceitos de gargalos e

recursos com restrição de capacidade (ou CCR – Constrained Capacity Resources). Gargalo é

qualquer recurso cuja capacidade seja inferior à demanda alocada no mesmo, enquanto que o

CCR, apesar de possuir uma capacidade superior à demanda, quando não seqüenciado de uma

forma adequada pode tornar-se um gargalo (Rodrigues, 1994). Estes dois tipos de restrições,

conforme Rodrigues (1994, p. 34), “são as maiores barreiras para a manufatura sincronizada”.

A geração de programas de produção baseia-se nas estruturas de produto e de roteiros.

Nas indústrias cárneas, o seqüenciamento da produção depara-se com uma característica

marcante destas empresas: as estruturas de convergência e de divergência dos produtos.

Portanto, além dos gargalos do sistema produtivo, a programação deve considerar as

alternativas de cortes (desmontagem) e de formulações (montagem) dos produtos. Já as

necessidades de materiais são calculadas com base na estrutura de produto, influenciando

sobre as decisões de seqüenciamento dependendo da disponibilidade dos suprimentos em

estoque ou das datas de recebimento confirmadas (ordens de compra).

2.1.3 Os dados nos sistemas de seqüenciamento da produção

A implementação de sistemas de seqüenciamento da produção, a fim de atender aos

requisitos definidos no escopo do projeto, necessita gerar informações confiáveis acerca do

sistema produtivo da organização. Goldratt (1991, p. 107) corrobora com esta afirmação e

ressalta a importância de sistemas de programação: “se quisermos ter respostas confiáveis às

perguntas gerenciais, temos que solucionar o problema da programação confiável.

Programação é, definitivamente, um dos blocos básicos de um sistema de informação”.

Conforme já destacado neste trabalho, a qualidade dos dados coletados em ambientes

produtivos para que os mesmos sejam utilizados em sistemas de seqüenciamento da produção

adquire importância. Do ponto de vista dos requisitos básicos para a programação de

produção, dentre os quais parte é modelada sob a forma de dados em sistemas, Rodrigues

(1994) sugere que os elementos abaixo sejam considerados:

• estrutura de banco de dados;

• horizonte de seqüenciamento;

• reprogramação;

• capacidades produtivas;

• time buckets (“baldes de tempo”); e

• sentido da programação.

A estrutura de banco de dados contém o Bill of Material (BoM, do inglês estrutura de

material), o qual possui o cadastro de clientes; o cadastro de materiais (embalagens, por

exemplo); o lead time de compra dos materiais; os componentes necessários para a

manufatura de cada produto; o cadastro de recursos produtivos; os calendários de atividades;

os roteiros de produção; os estoques em processo e os acabados; e a lista de pedidos.

Os dados de clientes, materiais e lead time de ressuprimento fazem parte dos cadastros

de um sistema. A lista dos produtos também poderia ser inserida neste agrupamento. Estes

dados cumprem fundamental função em um sistema de programação de produção, tendo em

vista que os demais dados dependem destes para serem estruturados. Um exemplo disso é a

lista dos componentes necessários para a produção de um produto. Para que este seja

produzido, existe uma relação de dependência em relação a determinados insumos, sem os

quais é impossível finalizar (ou mesmo começar a fabricar) o produto. Na indústria cárnea,

uma salsicha tem em sua estrutura carnes e condimentos (ingredientes), os quais são

misturados para que o produto final seja gerado.

Os recursos produtivos representam as restrições de produção, as quais se constituem

de fatores limitantes da capacidade de uma fábrica. No momento em que os recursos são

vinculados a um produto e se definem os tempos de processamento dos itens de produção,

além do cadastro de calendários para os recursos, estabelece-se um roteiro de produção. Os

calendários referem-se à disponibilidade de tempo dos recursos. Quando os roteiros são

atrelados à estrutura de um produto, têm-se as redes de atividades (task net).

Os estoques em processo devem ser utilizados para as decisões de programação da

produção porque necessitam de apenas parte do processamento para serem finalizados, não

sendo necessário produzir um novo produto novamente. Já os estoques de itens acabados

servem para que seja feita a programação dos pedidos, os quais constam na lista de pedidos.

O horizonte de seqüenciamento é o intervalo de tempo que será considerado para as

rodadas de programação. Rodrigues (1994) indica que a escolha do horizonte de programação

pode também afetar a qualidade da informação. Conforme se aumenta o período de tempo,

maiores serão as chances de se identificarem potenciais problemas no futuro. Um exemplo

desse tipo de situação é a identificação antecipada de falta de capacidade para o atendimento

de demandas futuras (em função de sazonalidades de mercado, por exemplo). Entretanto, o

aumento do período de tempo pode prejudicar a programação em função da probabilidade de

erros nas previsões de vendas serem maior. Com isso, deve-se fazer um trade-off (escolha em

que os benefícios compensem as desvantagens) na opção pelo tamanho do período de

seqüenciamento.

A reprogramação refere-se ao processo de geração de planos de produção atualizados,

pois os dados de entrada do sistema são novamente submetidos ao seqüenciamento. Estes

dados podem ser novos pedidos, a redução dos estoques e a redução da capacidade produtiva,

dentre outros.

Os sistemas de seqüenciamento podem considerar as capacidades finitas ou infinitas

do sistema produtivo. A primeira opção impede que os planos de produção apresentem

volumes superiores à capacidade máxima dos recursos da empresa. Já a segunda opção ignora

o limite que a primeira estabelece.

Os chamados baldes de tempo referem-se à granularidade do tempo relativa à forma

por meio da qual se pretende visualizar as informações do sistema (por turno de produção ou

por dia, por exemplo).

O processo de seqüenciamento das operações em função dos recursos produtivos pode

ser backward ou forward. A primeira abordagem (do inglês, mover-se para trás) seqüencia as

atividades a partir do prazo final dos pedidos, desdobrando a programação do último recurso

para o primeiro. A segunda abordagem (do inglês, mover-se para frente) considera ou o

primeiro dia do horizonte de programação ou a data mais próxima deste dia (desde que tenha

disponibilidade). Neste caso, as operações são seqüenciadas ao longo do tempo até que se

obtenha uma estimativa da data em que um pedido será atendido.

2.2 Gerenciamento de dados e informações

O problema da qualidade de dados em ambientes de manufatura implica inicialmente

na pesquisa sobre os conceitos relacionados ao tema, além dos estudos desenvolvidos na área.

Nesta seção, comparam-se algumas terminologias e apresenta-se o caráter de estudos sobre a

qualidade de dados.

2.2.1 Dados versus informações e outros delineamentos

A discussão sobre o conceito e a utilização de dados e de informações em ambientes

corporativos pode ser encontrada no livro “A Síndrome do Palheiro”, de Eliyahu M. Goldratt

(GOLDRATT, 1991). O autor justifica a abordagem sustentando que inexiste uma definição

de escopo amplo para os dois termos e que o tratamento inadequado de dados e de

informações oferece riscos para as organizações. Goldratt (1991, p. 3) inicia sua obra fazendo

uma afirmação que resume o eixo de discussão do livro: “estamos afogados em oceanos de

dados; todavia, parece que raramente temos informação suficiente”.

Após refletir sobre as possíveis interpretações para dados e informações, o autor

define primeiramente o dado como “qualquer gama de caracteres que descreva algo sobre

nossa realidade” (GOLDRATT, 1991, p. 74). Em outras palavras, atributos ou características

de determinadas situações ou objetos poderiam ser enquadrados como dados.

Avançando-se neste raciocínio, Goldratt sustenta que a informação seria a resposta a

uma pergunta formulada (GOLDRATT, 1991). O autor argumenta que toda informação faz

parte de um processo de tomada de decisão no qual a informação é a saída e o dado a entrada.

Neste momento, verifica-se que se oferece uma contribuição para a diferenciação entre os

conceitos de dado e de informação – a interpretação das terminologias, bem como o escopo

das mesmas, não é estático, e sim dependente do momento (tempo e espaço) e da ação de um

sujeito (busca ou necessidade de informações). Como forma de exemplificar esta situação

utiliza-se uma pergunta sugerida pelo autor (Goldratt, 1991, p. 74): “qual é o melhor caminho

para se chegar a Atlanta hoje?”. Neste caso, a indicação do número do vôo para o referido

destino seria uma informação, sendo uma resposta adequada para a pergunta feita. Se a

mesma pergunta tivesse sido respondida com uma lista de todos os vôos para Atlanta, a

necessidade de se saber o “melhor caminho” não seria atendida. Neste caso, o catálogo de

vôos seria um dado para quem fez a pergunta; no entanto, para a pessoa que buscou responder

à pergunta, o mesmo catálogo de vôos seria uma informação, tendo em vista que era

necessário conhecer as opções de vôos para então sugerir o melhor vôo.

Existem autores que reconhecem o dado como sendo um estágio anterior à

informação. A utilização dos dados é assim definida por Jack Olson: “dado é o combustível

que utilizamos para tomar decisões” (OLSON, 2003, p. 3). Já Wang, Ziad e Lee (2002)

comentam que gestores intuitivamente diferenciam ambos os conceitos definindo a

informação como um dado processado.

O esforço despendido na atividade de coleta dos dados que são utilizados em sistemas

de informação pode desvirtuar o foco do processo de tomada de decisão (GOLDRATT,

1991). No caso da captura de dados, existem dois riscos inerentes: o tempo necessário e a

imprecisão dos dados. Goldratt (1991) entende que a visão distorcida sobre os dados advém

da inexistência de critérios estruturados para o processo de decisão. Isso influencia

negativamente na geração de informações qualificadas ao final do processo de decisão. No

que diz respeito ao impacto dos dados exigidos sobre as saídas, a qualificação dos mesmos é

uma atividade fundamental.

2.2.2 O estudo da qualidade de dados

O tema da qualidade de dados possui uma estreita ligação com a qualidade da

informação, tendo em vista a já mencionada derivação das informações a partir dos dados na

seção anterior. O conceito de qualidade de dado é amplamente difundido na literatura como

adequação ao uso, ou seja, ela só faz sentido se vai ao encontro do atendimento de uma

necessidade (TAYI e BALLOU, 1998; HELFERT, 2001; LEE et al, 2006). De forma

complementar, Redman (2004, p. 2) sustenta que a qualidade de dados relaciona-se em “obter

o dado certo e correto, no lugar correto e no momento certo para realizar uma tarefa”.

Dentre os estudos nestas áreas, houve contribuições variadas. Em função disso, Wang,

Storey e Firth (1995) desenvolveram um estudo no qual se propôs um framework a partir da

literatura que explorava a pesquisa sobre a qualidade de dados. Inicialmente, os autores

propõem uma analogia entre a manufatura de produtos e a geração de dados (Figura 5).

Na Figura 5 verifica-se que o que os autores tratam como a “produção de dados”

poderia ser também compreendida como a geração de informações. Esta lógica corrobora com

aquilo que Goldratt (1991) defende: a função de um sistema de informação é a de realizar um

processo de dedução dos dados de entrada para que sejam geradas informações na saída do

processamento. A partir disso, é possível compreender o impacto da precisão dos dados

utilizados para o processo de tomada de decisão. A existência de erros na entrada do processo,

como também os problemas de integração de sistemas ou até nos bancos de dados, faz com

que as saídas do processamento não estejam de acordo com o esperado.

FIGURA 4 – Analogia entre a manufatura de produtos e a geração de dados (fonte: adaptado de Wang, Storey e

Firth, 1995).

Dentre os estudos que Wang, Storey e Firth (1995) destacam na literatura sobre a

qualidade de dados, cada qual propôs diferentes dimensões (ou categorizações), porém

similares em suas essências, neste campo de estudo. Dentre os termos utilizados, destacam-se

a acuracidade (accuracy), a completeza (completeness), a consistência (consistency) e o grau

de atualização (timeliness) dos dados, os quais são mais bem detalhados abaixo:

• acuracidade: refere-se ao nível de conformidade de um dado em relação ao seu

valor no mundo real. Um exemplo de inacuracidade seria a capacidade de uma

máquina em um banco de dados cadastrada como 1.000 peças/h, mas que, na

realidade, pode processar até 1.500 peças/h;

• completeza: refere-se à razão entre os dados existentes e os necessários. Um

exemplo disso é a tabela de estoques em um banco de dados. Se nem todas as

unidades de armazenagem aparecer na tabela, os dados estão incompletos, logo a

completeza é baixa;

• consistência: ocorre quando a representação do dado é a mesma em diferentes

fontes. Um exemplo de dados consistentes é o CEP (Código de Endereçamento

Postal) de uma correspondência referir-se ao CEP do local de destino da mesma

correspondência; e

• grau de atualização: refere-se a quanto o dado reflete o seu valor atual na fonte de

onde é coletado em relação ao momento no qual deveria ter sido atualizado. Um

exemplo de dado desatualizado é um lote de produção de um produto continuar

aparecendo no sistema de estoque, mas que, na verdade, já foi expedido para o

cliente final.

O estudo da qualidade de dados aparece sob diversos nomes na literatura, tais como

Data Cleaning ou Data Cleansing (Limpeza de Dados) e Data Quality (Qualidade de Dados),

dentre outros. Apesar disso, todas as abordagens têm em comum o foco para a melhoria dos

dados, a qual envolve, por exemplo, atividades de remoção de dados que estejam errados ou

que sejam desnecessários, bem como a correção dos mesmos. Estas atividades contribuem

para a geração de informações coerentes com a realidade e confiáveis, tornando a tomada de

decisão mais qualificada.

Maletic e Marcus (2000) ressaltam que o Data Cleansing pressupõe a utilização de

recursos computacionais para a qualificação de dados, o que torna esta técnica uma solução de

alto custo, especialmente nos casos de tratamento de grandes volumes de dados. O Data

Cleansing pode ser aplicado dentro do escopo de projetos de Data Warehousing

(armazenagem de dados), de Data Mining (mineração de dados) e de gestão da qualidade de

dados, como o Total Data Quality Management (MALETIC e MARCUS, 2000).

Nos estudos desenvolvidos por Winkler (2003) e Karr, Sanil e Banks (2006), os

autores mencionam os efeitos causados por dados errados e algumas ações no sentido de

identificar e eliminar os erros. Dentre os problemas apontados pelos autores, destacam-se os

dados duplicados, os dados faltantes e as informações inconsistentes (aquelas que não

necessariamente estão erradas, mas que, quando comparadas com um dado complementar,

tornam-se potenciais erros).

Em bancos de dados de sistemas de informação, os testes de integridade referencial

auxiliam na detecção de erros nos dados armazenados. A integridade referencial garante que o

relacionamento dos dados das tabelas que fazem parte de um banco de dados seja respeitado.

Um exemplo disso é um banco de dados que possui uma tabela para o cadastro de clientes e

outra para os pedidos. Com a integridade referencial, não será permitida a inclusão de um

pedido no banco de dados se o cliente do mesmo não estiver previamente cadastrado.

Entretanto, de acordo com Maletic e Marcus (2000, p. 4), “enquanto que a análise de

integridade de dados pode desmascarar um número de possíveis erros em uma lista de dados,

o mesmo não ocorre para o direcionamento aos erros que são mais complexos”. Neste caso,

surge a necessidade de se realizarem análises profundas sobre os dados utilizados em um

sistema de informação.

2.2.3 A dimensão acuracidade no conceito de qualidade de dados

A dimensão acuracidade acaba confundindo-se com a qualidade de dados em função

de a mesma representar o nível de conformidade do mesmo em relação ao seu valor no mundo

real. Se um dado estiver correto, será confiável para a tomada de decisão, logo a qualidade do

mesmo, que poderia ser avaliada sob outras dimensões, acaba sendo avaliada conforme a

acuracidade do dado. Olson (2002) acrescenta ao conceito de acuracidade a forma e o

conteúdo de um dado

, além de apontar algumas das causas da inacuracidade de dados:

• valores errados inseridos em um banco de dados ou em um relatório;

• erros feitos por pessoas que não dão a devida atenção ao manuseio com os dados;

• telas ou formulários confusos ou contraditórios;

• procedimentos que permitem que os dados não sejam inseridos ou não sejam

cadastrados no prazo-limite;

• procedimentos que promovam a inserção de dados errados; e

• bancos de dados mal-estruturados.

2.3 Métodos para a qualificação de dados

Conforme tratado neste capítulo, na seção que versava sobre a evolução do estudo da

qualidade de dados, metodologias foram sendo desenvolvidas ao longo do tempo em função

A forma refere-se ao formato do dado (uma data em dd/mm/aaaa, por exemplo). Já o conteúdo representa o

dado em si (a data de 31/12/2009 seria um exemplo disso, respeitando um formato pré-estabelecido).

da necessidade de se tratar os dados com o devido foco. Conforme Wang, Storey e Firth

(1995, p. 637), “é necessário que se estude a ligação existente entre a fraca qualidade de dados

e os procedimentos utilizados para se detectar e eliminar problemas”. Este argumento reforça

a necessidade da existência de métodos que auxiliem na qualificação de dados como forma de

impedir que os mesmos prejudiquem as informações geradas para o processo de tomada de

decisão. No âmbito desta discussão, vale ressaltar que os métodos podem compreender tanto

procedimentos de identificação, análise e correção de dados como também procedimentos

para mensuração dos dados – neste sentido, a proposição de indicadores contribui para a

qualificação de dados.

Nas três primeiras seções que seguem, apresentam-se estudos que possuem uma

relação direta com a temática da qualidade de dados, especialmente no que tange a métodos

que possam ser utilizados na busca pela melhoria de dados. Em função das diferentes

perspectivas de compreensão e de solução do tema, corroborando com Karr, Sanil e Banks

(2006), os estudos foram divididos em abordagens estatísticas, tecnológicas e de gestão da

qualidade de dados.

Considera-se uma abordagem como sendo estatística quando esta privilegia a

utilização de conhecimentos estatísticos para a validação, análise e controle de dados. A

abordagem tecnológica, por sua vez, congrega os métodos que fazem uso de recursos de

Tecnologia da Informação. Por fim, a perspectiva de gestão engloba atividades de cunho

estratégico para a melhoria de dados, além de premissas como as regras de negócio entre os

processos de geração e “consumo” dos dados. Na abordagem de gestão, desenvolvem-se

também indicadores e atividades de limpeza para a qualificação dos dados. É importante

ressaltar que esta divisão se constitui de uma forma de visualização do problema sob

diferentes vertentes de pesquisa. Além disso, os critérios utilizados para esta classificação

basearam-se nas características predominantes das referências pesquisadas. Portanto, admite-

se que um mesmo método pode se situar conceitualmente dentro de duas ou mais abordagens,

dependendo-se de qual característica se analisa.

Já na quarta e última seção, onde se discutem os métodos para a qualificação de dados,

a partir das pesquisas realizadas e da interpretação do autor deste trabalho, são feitas algumas

considerações onde se busca estabelecer uma síntese das referências e um paralelo entre as

abordagens propostas.

2.3.1 Abordagens estatísticas

Em um estudo desenvolvido por Maletic e Marcus (2000), dentre 4 métodos genéricos

de Data Cleansing, o método estatístico para a qualificação de dados identifica dados errados

ou faltantes através dos valores da média e do desvio padrão. Karr, Sanil e Banks (2006)

também mencionam em um artigo a aplicação de medidas de tendência central (média, moda

e mediana) ou de dispersão (desvio padrão, dentre outras).

Pinho (2001) e Pinheiro (2002) defendem o uso das técnicas de Controle Estatístico de

Processo (CEP) de forma associada a bancos de dados. No que diz respeito à qualidade de

dados, Pinheiro (2002, p. 1) sustenta que “a exploração estatística dos dados fornece um

substrato capaz de apontar possíveis erros”. O método é aplicado através do uso das chamadas

cartas de controle, dentre outras possibilidades, pelas quais se acompanha, por exemplo, o

comportamento dos dados perante o resultado de uma métrica e os níveis mínimo e máximo

aceitáveis da mesma.

2.3.2 Abordagens tecnológicas

Sheth, Wood e Kashyap (1994) propuseram em um estudo o desenvolvimento de um

protótipo de um sistema com o uso de uma linguagem de programação que contribuiria para a

validação e a limpeza dos dados. Já Maletic e Marcus (2000) sugerem dois métodos:

clustering, o qual auxilia na identificação de padrões de comportamento dos dados dentro de

grupos de dados; e pattern-based, que identifica os dados que estejam fora dos padrões

existentes em uma base de dados.

O desenvolvimento de scripts SQL (Structured Query Language ou Linguagem de

consulta estruturada) para a identificação de erros, a construção de interfaces de sistemas

adequadas para que os dados não sejam inseridos erroneamente e restrições que garantam a

integridade de um banco de dados são sugeridos por Karr, Sanil e Banks (2006). Dentro das

proposições, a última delas é também discutida por Winkler (2004), o qual propõe a

identificação de erros por meio do desenvolvimento de regras de negócio (ou restrições de

integridade). Olson (2002) também discute o emprego destas regras, sugerindo a aplicação de

validações para que se encontrem erros de dados. Um exemplo da aplicação desta técnica é a

verificação de situações nas quais a data de entrega solicitada por um cliente fosse inferior à

data da colocação (criação) de um pedido.

2.3.3 Abordagens gerenciais

Dentro do escopo da perspectiva de gestão da qualidade de dados, as questões centrais

de discussão são a medição da qualidade do dado (indicadores) e a utilização de

procedimentos de análise para a identificação de correção de erros de dados. Em outras

palavras, estas abordagens englobam a definição de estratégias ou de programas para a

qualidade dos mesmos.

As contribuições do processo de descobrimento de conhecimento em bancos de dados

(ou KDD, do inglês Knowledge Discovery in Database) são abordadas por Bortolazza (2006).

Dentro do escopo do processo de KDD, no qual se destaca o Data Mining (do inglês,

mineração de dados), a etapa de preparação de dados caracteriza-se por estruturar os dados

dentro de um formato pré-estabelecido (BORTOLAZZA, 2006).

Olson (2002) sugere a realização de comparações entre os dados armazenados no

banco de dados e a realidade. No caso de um sistema de seqüenciamento da produção, um

exemplo dessa proposta seria a comparação entre o plano sugerido pelo sistema para um

determinado período e a produção realizada ou projetada (planejada) no mesmo horizonte de

tempo.

O processo de identificação e correção de dados junto às “fontes poluidoras” é

discutido por Thomas Redman, o qual defende uma postura preventiva e integradora em

relação à qualidade de dados (REDMAN, 2004). O autor ressalta que problemas com a

qualidade de dados ocorrem em função de inexistirem integrações adequadas entre diversos

bancos de dados em determinadas situações (devido ao fato de cada usuário ser responsável

por um tipo de informação, o mesmo administra localmente os dados que utiliza). Esta

situação contribui também para a inexistência de um padrão de qualidade nos dados dos

sistemas, o que prejudica a análise de informações pelos usuários.

Redman (2008) também aborda a importância da adoção de indicadores que sinalizem

para a qualidade dos dados. O principal indicador deve relacionar o número de registros

errados em um banco de dados sobre o número total de registros. Entretanto, o indicador

proposto não contribui para uma análise sistêmica do problema, ou seja, não se avalia o

impacto da qualidade dos dados sobre as informações que são geradas a partir deles.

Segundo Redman (1996; 2008), os planos para a gestão sobre os dados deveriam

seguir os seguintes critérios:

• as ações devem ser feitas sobre os dados mais importantes para uma empresa. São

considerados importantes os dados que sejam críticos para a estratégia de negócio

de uma organização;

• os planos devem ser direcionados para que os desejos dos clientes da empresa

sejam atendidos, considerando-se tanto clientes internos quanto externos à

organização;

• os ganhos ou melhorias advindos da gestão sobre os dados devem ser sustentáveis,

ou seja, deve ser feito um trabalho de prevenção para que os problemas não

reapareçam nas mesmas fontes que já sofreram intervenções; e

• deve haver uma definição clara das responsabilidades na execução dos planos de

melhoria dos dados.

A utilização de um indicador de inacuracidade de dados é proposta por Bonjour,

Baptiste e Larchvèque (1997). Os autores entendem que se deve utilizar a medida do desvio

padrão das inacuracidades para que se verifiquem mais facilmente os problemas, pois a média

das inacuracidades pode “esconder” os defeitos. Este indicador relaciona a diferença entre o

valor real (correto) de um dado e o valor armazenado em uma base de dados em relação ao

dado armazenado.

O tratamento da qualidade de dados em ambientes de manufatura, especificamente

com relação à estrutura de materiais dos produtos (Bill of Materials), é explorado por

Clement, Coldrick e Sari (1992). A melhoria da acuracidade e da completeza dos dados

deveria ser realizada por meio de auditorias sobre a estrutura de materiais, no próprio

processo produtivo. Os autores sugerem 4 maneiras para se buscar a melhoria dos dados,

sendo que cada qual possui vantagens e desvantagens, fato que deve ser ponderado na escolha

das mesmas:

• escolher os principais produtos que estejam sendo produzidos, por meio da

aplicação do Princípio de Pareto, segundo o qual 80% dos efeitos são causado por

20% das causas. Amostras de produtos deveriam ser selecionadas para que fossem

verificados quais materiais haviam sido utilizados na produção de cada item

escolhido. A análise deveria confrontar os materiais que deveriam estar sendo

utilizados no produto, a estrutura de material definida na ficha técnica do item e os

materiais que efetivamente estivessem sendo usados na manufatura do produto;

• auditar as solicitações de materiais no chão-de-fábrica, confrontando-as com o

volume de produção e os itens programados;

• desmontar um item recém-produzido, procurando identificar falta ou excesso de

materiais e de quantidades; e

• permitir que funcionários considerados especialistas no chão-de-fábrica possam

auditar o processo em tempo real.

Como forma de priorizar as análises de dados, Bonjour, Baptiste e Larchvèque (1997)

relacionam a importância de se medir a qualidade dos recursos-gargalo, em detrimento

daqueles que não exercem influência sobre o desempenho de um sistema produtivo. Dentro

deste contexto, aborda-se a relação entre a granularidade dos dados e a tomada de decisão

sobre os mesmos.

A granularidade corresponde ao grau de detalhamento dos dados. Um exemplo disso é

o tratamento dado ao tempo total de processamento de uma máquina (o que poderia incluir

setup – preparação – e o processamento em si). Se o valor do tempo total puder ser

considerado em detrimento dos tempos parciais, sugere-se utilizar a primeira opção, pois

reduz a necessidade de manutenção dos dados (BONJOUR, BAPTISTE e LARCHEVÈQUE,

1997).

No que diz respeito ao trade-off entre a inacuracidade dos dados e o grau de

detalhamento desejado, Bonjour, Baptiste e Larchvèque (1997) defendem que dados

reconhecidamente inacurados e que, ao mesmo tempo, não exerçam impacto sobre a tomada

de decisão, sejam desconsiderados. No exemplo citado pelos autores, se o setup tiver mais de

10% de inacuracidade e corresponder a menos de 10% do tempo total de processamento de

uma máquina, o mesmo pode ser desconsiderado. Trata-se de um método para a priorização

das análises dos dados, na qual se reduz a necessidade de manutenção da base de dados a

partir de diversas fontes.

2.3.4 Abordagens mistas

A pesquisa na área da qualidade de dados motivou a criação, dentro do Massachusetts

Institute of Technology (MIT), do Total Data Quality Management (TDQM), um projeto que

partiu da necessidade da Indústria por altos índices de qualidade de dados (TDQM, 2008). O

programa foi desenvolvido com o intuito de construir fundamentos teóricos e métodos que

pudessem contribuir para a melhoria da qualidade de dados (TDQM, 2008). O escopo das

pesquisas do TDQM divide-se em três componentes, os quais são detalhados no Quadro 1.

Componente Características

Definição da qualidade

do dado

A pesquisa do tema ampara-se no estudo das dimensões do

conceito. Aspectos como a mensuração da qualidade dos dados

e o suporte de algoritmos para a identificação de erros são

estudados neste componente.

Análise do impacto da

qualidade de dados nas

organizações

As atividades envolvem a comparação entre a qualidade dos

dados e alguns parâmetros-chave identificados em uma

empresa, tais como a satisfação do consumidor.

Melhoria da qualidade

de dados

O terceiro componente compreende métodos para a melhoria

de dados, os quais se dividem em 4 categorias:

• redesenho de processos: simplificação e racionalização de

processos para que se minimizem as oportunidades de

ocorrência de erros de dados;

• motivação para a qualidade de dados: lida com recompensas

e benefícios aos colaboradores a fim de sensibilizá-los

quanto ao manuseio dos dados;

• uso de novas tecnologias: técnicas automatizadas de captura

de dados e de comunicação entre sistemas;

• tecnologias de interpretação de dados: auxiliam os

colaboradores na captura dos dados e implicam no

redesenho de processos.

QUADRO 1 – Componentes da pesquisa da qualidade de dados (fonte: adaptado de TDQM, 2008).

No Quadro 1 é possível compreender a maneira como o TDQM lida com a questão da

qualidade de dados, pois os componentes propostos direcionam para uma visão sistemática do

problema. Um aspecto a ser destacado é que uma das dimensões tratadas pelo TDQM é a

acuracidade, elemento considerado neste trabalho como fundamental para o conceito de

qualidade de dados.

A metodologia do TDQM inspira-se no Ciclo de Deming da Gestão da Qualidade

Total. De forma similar ao PDCA, em vez das conhecidas etapas de Plan, Do, Check e Act

(planejar, executar, controlar e agir, respectivamente), o ciclo do TDQM contempla as

atividades de Definir, Medir, Analisar e Melhorar. A proposta do TDQM é apresentada na

Figura 5.

FIGURA 5 – Ciclo do TDQM (fonte: adaptado de Wang, 1998).

A etapa “Definir” do ciclo do TDQM refere-se à identificação das dimensões da

qualidade de dados que serão consideradas em um projeto, bem como os requisitos de dados

para cada dimensão. Posteriormente, na fase “Medir” são desenvolvidas as métricas para a

avaliação da qualidade dos dados. A partir dos resultados dos indicadores, no componente

“Analisar” devem-se identificar as causas dos erros nos dados. Por fim, a etapa “Melhorar”

caracteriza-se pela correção dos dados errados, bem como pela melhoria de outros dados.

De forma similar ao TDQM, Larry English (1999) desenvolveu o Total Quality data

Management, ou TQdM, o qual foi inspirado nos princípios da Gestão da Qualidade Total. O

autor sustenta que o TQdM não é um programa, nem um processo de medição e limpeza de

dados – trata-se de uma metodologia que integra crenças, princípios e métodos em torno da

melhoria de processos de negócio e de desenvolvimento de sistemas com foco para dados e

informações. Assim como Clement, Coldrick e Sari (1992), English defende a mudança nos

processos de uma organização quando identificados erros de dados que sejam provocados

pela falta de processos padronizados.

A metodologia desenvolvida por English divide-se em processos, os quais

contemplam a avaliação das especificações e arquitetura de dados; a medição da qualidade

das informações (utilizando cartas de controle para a identificação de dados fora do padrão

estabelecido); e a limpeza e melhoria dos dados. Na limpeza de dados, destaca-se a utilização

das validações, as quais avaliam o nível de conformidade dos dados em relação às regras de

negócio de uma organização.

A abordagem sobre a qualidade de dados proposta por David Loshin (2001) baseia-se

em uma série de iniciativas, não havendo uma que se sobressaia perante as outras. O autor

direciona sua abordagem para os seguintes itens:

• arquitetura do banco de dados;

• uso do Controle Estatístico de Processo (CEP) para identificação de dados que

estejam fora dos limites estabelecidos;

• análise da causa-raiz dos erros de dados, a qual deve ser suportada pela utilização

do Princípio de Pareto;

• definição de validações baseadas nas regras de negócio da organização;

• uso de métricas para a avaliação da qualidade dos dados; e

• data cleaning.

2.4 Considerações finais sobre o capítulo

A partir dos estudos analisados, verificou-se que alguns possuíam um viés tecnológico

associado para a adoção de soluções acerca do problema da qualidade de dados. Mesmo nos

artigos que sugerem o uso da estatística, há uma tendência para o tratamento do processo de

identificação e correção de dados em função do desenvolvimento de tecnologias de validação

dos mesmos. Em outras referências pesquisadas, ainda que algumas não ofereçam

contribuição direta para o presente estudo, verificou-se que as mesmas contribuem para a

discussão em torno do desenvolvimento de métodos para o processo de qualificação de dados.

No que diz respeito à qualificação de dados em ambientes de manufatura e,

especificamente no caso deste trabalho, em sistemas de seqüenciamento da produção,

verificou-se que poucos dos estudos encontrados exploram de forma direta o problema sobre

estas áreas ou sistemas. Salvas as pesquisas de Bonjour, Baptiste e Larchvèque (1997) e

Favaretto (2007), o restante não direcionou o tema para a área de manufatura de forma direta.

Apesar disso, no desenvolvimento do método proposto neste trabalho, os elementos

norteadores dos estudos analisados foram utilizados de forma complementar às observações

do estudo de caso.

3 MÉTODO

O método deste trabalho foi subdividido em duas seções: o método de pesquisa e o

método de trabalho. A primeira seção versa sobre a estratégia e as técnicas de pesquisa que

foram empregadas para o delineamento do estudo. Neste momento, contextualiza-se a

estruturação da pesquisa em torno de referências que tratam sobre a geração de teoria sobre

estudos de caso. Em um segundo momento, descreve-se no capítulo a unidade-caso e o

método de trabalho, o qual se encarregou de detalhar os passos objetivos realizados para se

atingirem os objetivos deste estudo com o apoio do método de pesquisa.

3.1 Método de pesquisa

A realização deste estudo foi motivada a partir da necessidade da melhoria da

acuracidade dos dados de um sistema de seqüenciamento da produção. Este problema foi

identificado durante a participação do autor deste trabalho, juntamente de outros profissionais,

em um projeto de implementação de uma ferramenta de programação da produção.

Inicialmente, para que fosse possível definir o método de pesquisa que seria utilizado no

trabalho, analisou-se o problema do ponto de vista dos níveis de classificação de uma

pesquisa, conforme Gil (2002):

• abordagem do problema;

• objetivos do estudo; e

• procedimentos técnicos.

Dentro do escopo da abordagem do problema, Gil (2002) divide a pesquisa entre

quantitativa e qualitativa. A primeira considera que todas as características de um objeto de

estudo possam ser mensuradas, o que implica em utilizar técnicas estatísticas para a avaliação

(como média e desvio-padrão, por exemplo). Já a pesquisa qualitativa caracteriza-se por

admitir, diferentemente da quantitativa, que a subjetividade é inerente ao processo de análise

de um fenômeno. Durante o caso pesquisado, adotou-se predominantemente a abordagem

qualitativa, porém houve avaliações do ponto de vista quantitativo. A parte qualitativa esteve

relacionada, por exemplo, com a análise dos eventos que influenciaram no andamento do

projeto pesquisado (como a participação dos usuários do sistema). Já o lado quantitativo foi

desenvolvido por meio da análise dos indicadores utilizados no caso, bem como por meio da

criação de medições para os dados de entrada e os resultados da ferramenta de programação

de produção no método proposto.

Do ponto de vista dos objetivos do estudo, a pesquisa aproximou-se de um estudo

exploratório, o qual se caracteriza por possibilitar maior familiaridade do pesquisador junto ao

problema que se analisa. Neste trabalho, o fato de o autor ter participado da implementação do

sistema pesquisado, além de ter realizado entrevistas para a coleta de dados, corroborou para

que a pesquisa pudesse ser considerada de cunho exploratório.

Ao terceiro nível de classificação da pesquisa (procedimentos técnicos), agregaram as

contribuições de Yin (2005). Este autor sugere recorrer-se à análise de três condições:

a) o tipo de questão de pesquisa proposta;

b) a extensão de controle que o pesquisador tem sobre eventos comportamentais

atuais; e

c) o grau de enfoque em acontecimentos contemporâneos em oposição a

acontecimentos históricos.

De acordo com uma classificação derivada destas três condições e explorada por Yin

(Yin, 2005), o presente estudo aproxima-se, do ponto de vista da questão de pesquisa, a um

experimento, a uma pesquisa histórica e a um estudo de caso. Estes três procedimentos de

pesquisa possuem em comum o fato de questionarem “como” ou “por que” determinados

fenômenos se desenvolvem. Isso pode ser explicado pelo fato de a questão de pesquisa deste

trabalho estar atrelada à identificação da maneira pela qual se poderia estruturar um método

para a melhoria da acuracidade dos dados de um sistema. Avançando-se no conceito dos

procedimentos, os experimentos caracterizam-se pelo controle sobre os eventos (experiências)

realizados na pesquisa; ou seja, interage-se e altera-se o meio que se estuda, o que não é o

caso deste estudo. Já a pesquisa histórica focaliza fenômenos ocorridos no passado, tal como

o estudo de caso, porém não-contemporâneos, aspecto que vai de encontro ao propósito deste

trabalho.

Em função disso e da intenção de se estudar profundamente um problema em

particular, decidiu-se utilizar o método de pesquisa do estudo de caso. Ainda, cabe ressaltar

que a pesquisa baseou-se em um projeto ocorrido no passado, porém dentro de uma

problemática contemporânea e com acesso às fontes primárias de dados, ou seja, sobre o

objeto de estudo e as pessoas que nele trabalharam.

Além do estudo de caso, dos experimentos e da pesquisa histórica, outros métodos de

pesquisa foram avaliados para que se optasse por aquele que melhor se enquadrasse ao estudo.

Dentre os métodos analisados, não se optou pela Pesquisa-ação pelo fato de esta pressupor a

aplicação prática da pesquisa, onde a interação do pesquisador junto a uma equipe de trabalho

permitiria a realização de uma intervenção sobre o objeto de estudo. Já o método conhecido

por Design Research não foi escolhido porque pressupõe a criação de um artefato ao final do

estudo (novo método, produto ou serviço, dentre outras possibilidades) a partir de uma idéia

inicial de projeto. Como o presente estudo baseou-se em uma experiência do passado que não

foi desenvolvida com a finalidade de se realizar uma pesquisa a partir da concepção de um

artefato, o Design Research seria menos recomendado que o estudo de caso.

3.1.1 Desenvolvimento de teorias a partir de estudos de caso

O presente estudo, como já mencionado, buscou desenvolver um método para a

melhoria da acuracidade dos dados de entrada de um sistema de seqüenciamento da produção

a partir de um estudo empírico em uma empresa produtora de alimentos cárneos. A utilização

de estudos de caso para o desenvolvimento de teorias é discutida na literatura e, em função

dessa necessidade, foram utilizadas as contribuições dos estudos de Eisenhardt (1989), Dyer

Jr e Wilkins (1991) e Yin (2005).

Eisenhardt (1989) propõe um guia para o processo de construção de teoria por meio de

estudos de caso conforme abaixo:

Passo Atividade

Passos iniciais Definição da questão de pesquisa e dos constructos para que se

defina o foco do trabalho e se obtenha melhor conhecimento sobre as

métricas do constructo.

Seleção de casos Escolher casos relacionados ao tema da pesquisa do ponto de vista da

teoria a ser explorada, não de uma forma aleatória.

Coleta de dados A escolha de métodos múltiplos de coleta de dados fortalece os

conhecimentos básicos da teoria através da triangulação de

evidências. Neste sentido, a triangulação de pesquisadores contribui

para a existência de diferentes perspectivas de análise. Do ponto de

vista do tipo de dados a ser coletado, a combinação de dados

quantitativos e qualitativos promove uma visão sinérgica das

evidências do caso.

Pesquisa de campo O desenvolvimento simultâneo da coleta e da análise de dados

potencializa as análises e permite que se identifiquem oportunidades

de ajustes na etapa de coleta de dados. No caso de temas emergentes

e casos únicos, métodos mais flexíveis de pesquisa de campo

auxiliam o pesquisador em suas tarefas.

Análise de dados A análise de dados, quando realizada sob a ótica de um caso,

propicia familiaridade com os dados. Já a pesquisa através de dois

ou mais casos com a utilização de diversas técnicas de análise faz os

pesquisadores compreenderem o caso além das impressões iniciais e

observarem as evidências a partir de óticas múltiplas.

Definição de hipóteses O estabelecimento da relação das evidências de cada constructo

delineia a definição sobre o constructo, bem como a validade e a

possibilidade de mensurá-lo. Em pesquisas de casos múltiplos, a

replicação das hipóteses entre os casos explora o potencial da teoria

que se desenvolve.

Uso da literatura existente O estudo da literatura, tanto aquela que se aproxima ao tema da

pesquisa quanto aquela que possui pressupostos divergentes ou

opostos à primeira, auxilia na melhoria do nível teórico do estudo.

Isso contribui para a validação da pesquisa, dos constructos e do

escopo de generalização da teoria.

Consolidação final O estudo profundo dos casos aliado ao rigor metodológico em

função da teoria pesquisada deve chegar a um ponto em que as

melhorias marginais se tornam pequenas.

QUADRO 2 – Processo de construção de teoria através de estudos de caso (fonte: adaptado de Eisenhardt,

1989).

A partir do exposto no Quadro 2 e das demais idéias de Eisenhardt em seu artigo

(Eisenhardt, 1989), pode-se verificar que a autora privilegia estudos de caso baseados em

dados qualitativos em detrimento de critérios estatísticos para a seleção dos casos

(amostragens). Estes, por sua vez, devem ser auxiliados pela coleta e análise de dados a partir

de múltiplas evidências e dos constructos estabelecidos na etapa de projeto. Como forma de

desenvolver uma teoria genérica, a literatura sobre o tema da pesquisa deve ser esgotada a

ponto de as diferentes óticas acerca do assunto serem analisadas.

As proposições de Eisenhardt são analisadas e também criticadas por Dyer Jr e

Wilkins (1991). Estes autores entendem que Eisenhardt, apesar de acertadamente testar

hipóteses baseada em ricos dados qualitativos, foca em demasiado suas proposições acerca do

desenvolvimento de constructos e a possibilidade de mensuração dos mesmos. Dyer Jr e

Wilkins (1991) entendem que Eisenhardt parece relegar a um segundo plano a exploração do

contexto e a riqueza do conhecimento existente em cada caso.

Dyer e Wilkins (1991) também criticam Eisenhardt quanto ao argumento da autora em

relação ao número de estudos de caso necessários para se gerar uma teoria complexa e com

bases empíricas convincentes. De acordo com a autora, “não existe um número ideal de casos

– um número entre 4 a 10 casos normalmente funciona bem” (EISENHARDT, 1989, p. 545).

Examinando-se o artigo de Eisenhardt, verifica-se que a autora defende o perfil de

pesquisa profunda e focada do estudo de caso. Por outro lado, a menção ao uso de 4 a 10

casos para se formular teorias não necessariamente depende disso. No que diz respeito à

escolha de casos para se desenvolver uma teoria, Yin (2005) admite que se discute o potencial

da utilização do estudo de caso para se gerar teoria. O autor entende que isso advém de os

críticos compararem essa possibilidade às pesquisas realizadas com base em levantamentos

amostrais (Surveys, por exemplo), nos quais as conclusões constituem-se de generalizações

estatísticas sobre a população (ou universo) de dados. Contudo, conforme o autor, “os estudos

de caso (da mesma forma que os experimentos) baseiam-se em generalizações analíticas”

(YIN, 2005, p. 58). Nestas, o conhecimento gerado a partir das conclusões do estudo contribui

para uma dimensão teórica mais abrangente. Dyer Jr e Wilkins (1991) corroboram para este

argumento, sustentando que a geração de teoria está vinculada à capacidade de o pesquisador

compreender a dinâmica do caso escolhido de uma forma contextualizada e redigir suas

impressões de maneira inteligível para o leitor.

O método da construção de teoria a partir de estudos de caso é também analisado por

Sylvia Roesch (ROESCH, 2007). A autora entende que a combinação das evidências de um

caso possibilita a formulação de uma análise que seja desdobrada para bases teóricas mais

amplas em relação à realidade pesquisada.

Diante das contribuições expostas, parte delas foi utilizada durante o processo de

desenvolvimento do método para a melhoria da acuracidade dos dados proposto neste estudo,

conforme será detalhado nos próximos parágrafos. Inicialmente, a seleção de uma experiência

em torno da implementação de um sistema de seqüenciamento da produção e das ações de

melhoria da qualidade dos dados do mesmo marcou a definição do caso que seria pesquisado.

Do ponto de vista da teoria, a análise de uma experiência passada sobre a qualidade de dados

poderia contribuir para o referencial sobre este tema, tendo em vista que não se identificaram

na referência pesquisada situações que envolvessem a função de programação da produção. A

partir disso, a consolidação da questão de pesquisa estabeleceu o desafio da estruturação de

um método, o qual foi suportado pelo estabelecimento de um objetivo geral e de três objetivos

específicos que direcionaram o foco do estudo.

A pesquisa realizada neste estudo contemplou a análise pormenorizada da

implementação de um sistema de seqüenciamento da produção na Empresa Alfa, como

também as contribuições de especialistas na temática do estudo. Este aspecto reforça a

questão da triangulação de evidências, a qual reflete na familiaridade com os dados coletados.

A utilização de informações existentes na organização pesquisada, das impressões do autor

deste trabalho e das avaliações feitas por especialistas puderam ser confrontadas, de maneira

que se extrapolassem os limites entre as três fontes. O uso de técnicas flexíveis de coleta de

dados, como a observação participante, permitiu que a pesquisa de campo fosse moldada

conforme o estudo avançava. O descarte de determinados dados, bem como a captura de

outros que se fizeram necessários, ocorreu durante este processo.

A seleção de um caso único, objeto deste estudo, utilizou como critério a situação

oportunizada pelo projeto de implementação de um sistema. As características do mesmo o

tornaram singular, tendo em vista que não se identificaram nas referências pesquisadas

estudos empíricos profundos sobre a qualidade de dados no processo de programação da

produção, conforme já mencionado neste capítulo. Este aspecto possibilitou adotar-se para o

desenvolvimento do método proposto uma abordagem direcionada à acuracidade de dados no

sistema pesquisado.

Durante a realização do estudo de caso, ao mesmo tempo em que se relatava a

experiência, procurou-se analisar as situações vislumbradas, tais como: o impacto da

intensificação dos esforços de qualificação dos dados junto aos usuários-chave da ferramenta;

e o comportamento dos indicadores criados para a mensuração dos resultados do sistema. A

realização dessas análises concomitantemente com o relato da experiência passada

possibilitou que a familiaridade com o caso se tornasse maior, dado que se passou a

compreender problemas não explorados durante a implementação do sistema.

O uso da literatura fez parte do processo de consolidação do método proposto ao final

do estudo, tendo em vista que se agregaram elementos previamente testados e analisados. Este

fator, aliado às contribuições dos experts na temática do estudo, contribuiu para aprofundar o

rigor metodológico da proposta.

3.2 Método de trabalho

Nesta seção, aborda-se o papel da unidade-caso escolhida para a pesquisa, bem como

se explora o conteúdo de cada uma das etapas do método de trabalho. Com relação a estas

fases, o detalhamento das mesmas possibilita a compreensão da seqüência das atividades

realizadas no âmbito da pesquisa.

Conforme já mencionado no trabalho, a pesquisa foi desenvolvida em uma empresa da

área de alimentos cárneos. Esta firma abate e processa carnes de frango, peru e suíno,

exportando em torno de 80% da sua produção. A estrutura da organização é verticalizada e

contempla granjas, incubatórios, milhares de produtores integrados, fábricas de ração,

abatedouros e filiais de venda no Brasil. A empresa trabalha com linhas de produtos

temperados e in natura fabricados a partir do corte de aves e de suínos, além de produtos

industrializados (empanados e embutidos) feitos a base das carnes dos referidos animais.

A unidade-caso selecionada para o estudo foi a programação da produção. Para se

contextualizar o papel desta função na indústria cárnea, sugere-se visualizar a Figura 6, a qual

retrata a cadeia resumida de frangos e de perus. Nesta representação, não constam os suínos,

porém a cadeia do mesmo é similar a das aves (exceto pelos incubatórios), além do fato de a

programação de produção inserir-se no mesmo elo: os abatedouros e as fábricas de produtos

elaborados.

FIGURA 6 – Estrutura da cadeia de frangos e perus.

A cadeia avícola tem início com as chamadas avós, aves que passam previamente por

cruzamentos para a melhoria genética das mesmas. As avós geram as matrizes reprodutoras,

cuja função é gerar ovos que serão posteriormente incubados e de onde nascerão pintos ou

peruzinhos para corte, como são chamadas as aves utilizadas para o abate. Depois de

nascerem, os animais são levados para as granjas de produtores integrados, a partir dos quais

as aves são transportadas para o abatedouro. Das granjas de avós até os integrados, passando

pelos aviários das matrizes reprodutoras, é de fundamental importância o papel das fábricas

de ração, as quais produzem o alimento dos animais. Durante o abate das aves no frigorífico,

são gerados produtos para venda e matérias-primas para a utilização na produção de

elaborados.

No fluxo resumido da cadeia de frangos e perus apresentado na Figura 6, a

programação de produção insere-se a partir do momento em que se estima o número

necessário das aves para o abate. Para que este processo tenha início, contudo, é necessário

levantar, junto à área Comercial, os pedidos existentes, os quais deverão ser entregues aos

clientes. A partir disso, são calculadas as necessidades de produção e de abates. No momento

em que estes dados são conhecidos, parte-se para o desdobramento do plano global de

produção para as fábricas, o que depende de fatores como a capacidade instalada, a

disponibilidade de matéria-prima e a existência de embalagens e condimentos em estoque,

dentre outros. Além da verificação dos estoques, caso for necessário deverá iniciar-se um

processo de compra dos insumos faltantes, o que impactará em áreas como a de suprimentos.

Este detalhamento permite inferir sobre a influência das definições da programação da

produção sobre outras áreas de uma empresa. A partir das necessidades do mercado

consumidor, desdobram-se ações no sentido da operacionalização das demandas, o que reflete

nas atividades das demais áreas de uma organização.

A partir da seleção e detalhamento da unidade-caso, o desenvolvimento da pesquisa

foi estruturado por 7 passos objetivos, os quais constituíram o método de trabalho. Na Figura

7, apresentam-se as etapas e a ordem com que as mesmas foram executadas no estudo.

FIGURA 7 – Método de trabalho

Inicialmente, definiu-se neste trabalho a questão de pesquisa do mesmo, a qual foi

antecedida pela contextualização do problema da acuracidade de dados em um sistema de

seqüenciamento da produção. A questão de pesquisa direcionou para o foco do estudo, o qual

se relaciona com a aplicação de um método.

O segundo passo do método de trabalho caracterizou-se pelo resgate das referências

pesquisadas sobre programação da produção, conceitos sobre dados e informações, e métodos

para a qualificação de dados. Nesta etapa, dentre todas as fontes pesquisadas, procurou-se

selecionar e discutir aquelas que oferecessem contribuição para o desenvolvimento da

pesquisa. Dentre os temas selecionados para a elaboração do método ao final deste trabalho,

buscaram-se questões relacionadas à Engenharia de Produção e à Gestão de dados e de

informações. No primeiro, destacam-se os conceitos inerentes aos processos produtivos, os

quais são fundamentais para a programação de produção, tais como os gargalos e os CCRs, os

roteiros, os tempos de processo e as estruturas de produto, dentre outros. Já com relação à

gestão de dados e de informações, verificou-se a importância da adoção de métodos para a

qualificação de dados, os quais contemplam medições e técnicas de identificação e de

correção de erros, dentre outros aspectos.

Após a revisão bibliográfica, a aplicação do estudo de caso concentrou-se na busca de

informações sobre o projeto de implementação do sistema de programação da produção, bem

como pelo posterior relato das atividades realizadas. Os dados coletados para a pesquisa

foram obtidos sobre as fontes primárias, pois o autor deste estudo participou da equipe de

implementação da ferramenta de seqüenciamento da produção estudada.

A coleta de dados foi auxiliada por uma pesquisa qualitativa em torno das atividades

de qualificação de dados realizadas na empresa pesquisada. Dentro dessa análise, foi

evidenciada a utilização de indicadores para a mensuração dos resultados do sistema, os quais

foram influenciados pela acuracidade dos dados. Com isso, conferiu-se à pesquisa um teor

quantitativo devido à medição das informações.

A partir das fontes de evidência sugeridas por Yin (2005) e das intenções do

pesquisador em torno do estudo, definiram-se as seguintes fontes para a coleta dos dados:

observação participante, documentos e diários. O primeiro dos instrumentos de coleta foi

viabilizado com o acompanhamento presencial do autor da pesquisa junto aos membros da

equipe de projeto do sistema de programação da produção. O caráter das observações foi

aberto, pois o pesquisador possuía permissão para a realização da pesquisa no ambiente da

Empresa Alfa, além do fato de a mesma ter sido do conhecimento dos colaboradores. Dentre

os membros da equipe de projeto, pelo lado da Empresa Alfa havia gestores, profissionais das

áreas industrial, comercial e de Tecnologia da Informação, além dos usuários-chave da

ferramenta de seqüenciamento da produção. Na equipe de projeto, contou-se também com

consultores de negócio e analistas de sistemas da empresa que desenvolveu o sistema de

programação da produção.

A segunda fonte de evidência utilizada (documentos) necessitou ser empregada para

que fossem resgatadas informações que estavam armazenadas em meios impressos ou

eletrônicos. São exemplos desta fonte as mensagens eletrônicas (emails), as atas de reuniões,

os relatórios da empresa que desenvolveu o sistema, os manuais da ferramenta (interface e

operacionalização) e os manuais dos procedimentos de identificação e solução de problemas

de dados elaborado pela equipe de projeto.

Outro instrumento de coleta de dados utilizado durante a aplicação do estudo de caso

foi o resgate de diários do projeto. Com eles, foi possível analisar o histórico da

implementação do sistema, o que possibilitou identificar, por exemplo, os eventos que

influenciaram no comportamento dos indicadores criados para as informações geradas pela

ferramenta.

De posse dos dados coletados, o relato do caso contemplou os seguintes passos, na

ordem em que aparecem:

• a contextualização dos sistemas produtivos da Empresa Alfa, do processo de

decisão pelo investimento em um sistema de seqüenciamento da produção e das

etapas da implementação da ferramenta;

• as características da ferramenta pesquisada;

• a estruturação dos dados de entrada do sistema no mesmo, bem como conceitos

específicos utilizados na ferramenta para designar determinados dados ou estruturas

de dados; e

• os procedimentos adotados para a identificação e correção de erros de dados

durante a etapa de testes do sistema.

O quarto passo do método de trabalho caracterizou-se pela análise do método

empregado no caso para a melhoria da acuracidade dos dados inseridos no sistema de

seqüenciamento da produção. A análise de evidências foi amparada pelos dados coletados na

pesquisa e pelas percepções do autor sobre a realidade da Empresa Alfa. Esta atividade

sucedeu o relato dos procedimentos utilizados no método e responsabilizou-se por uma

análise crítica que possibilitou identificar pontos de alavancagem para a qualificação dos

dados.

As ponderações feitas durante o trabalho foram categorizadas em tabelas, quadros ou

gráficos para que os atributos dos dados fossem melhor compreendidos.

Com base na experiência adquirida durante o caso e no referencial pesquisado sobre

qualidade de dados e de informações, elaborou-se na quinta etapa uma versão inicial do

método tentativo. Nela, contemplou-se a definição dos pressupostos e das estratégias de

desenvolvimento do método; o detalhamento dos processos e subprocessos do mesmo; e o

estabelecimento dos Fatores Críticos de Sucesso para a aplicação do método.

Neste estágio, a proposta não possuía validade, pois não havia sido submetida a

qualquer tipo de teste ou avaliação. Tratava-se, tão somente, de uma iniciativa que buscava

propor uma abordagem estruturada para a melhoria da acuracidade dos dados em um sistema

de programação da produção. Para que esta proposição inicial fosse validada, submeteu-se a

mesma, na sexta etapa do método de trabalho, à avaliação de especialistas na temática da

pesquisa. Desse modo, sugestões de melhorias foram agregadas à proposta, o que contribuiu

para a validação da mesma. É importante ressaltar que as contribuições dos especialistas não

foram consideradas como parte da etapa de coleta de dados da pesquisa, tendo em vista que a

validação do método corresponde à análise do estudo de caso.

Consideraram-se como experts pessoas que possuíssem reconhecido conhecimento

prático ou titulação acadêmica nas áreas de PCP (especialmente da indústria cárnea), de

qualidade de dados e de informações, e de processos de negócios. A seguir, apresentam-se

breves currículos dos 6 especialistas que participaram da validação do método proposto:

• Expert 1: Bacharel em Marketing pela Universidade Anhembi Morumbi e Pós-

graduado em Governança de TI pelo Instituto Mauá de Tecnologia. Experiência

como consultor e em cargos de gerência e diretoria em empresas de TI. Atualmente

é Diretor de Produtos de Qualidade de Dados de uma empresa brasileira que

desenvolve sistemas para este fim;

• Expert 2: Bacharel em Administração de Empresas pela Universidade de Caxias do

Sul e experiência de 9 anos nas áreas de PCP de duas empresas do ramo cárneo,

tendo ocupado o cargo de gerência corporativa em ambas. Coordenou a

implementação de um sistema de planejamento agregado e otimizado de produção e

vendas e de uma ferramenta de programação da produção, ambos para a indústria

cárnea;

• Expert 3: Bacharel em Engenharia de Produção pela Universidade do Vale do Rio

dos Sinos (UNISINOS) e mestrando do Programa de Pós-graduação em Engenharia

de Produção e Sistemas, na mesma instituição. Atua desde o ano de 2003 na área de

programação de produção e vendas da área de carnes, tendo trabalhado em três

empresas do ramo no Brasil. Durante este período, participou da implementação de

um sistema de planejamento agregado e otimizado de produção e vendas e

atualmente coordena a equipe de gestão de demanda de uma empresa brasileira da

área de alimentos cárneos. Nesta função, utiliza um sistema de planejamento de

produção e vendas;

• Expert 4: Bacharel em Engenharia de Produção Mecânica pela Universidade do

Vale do Rio dos Sinos (UNISINOS) e Mestre em Engenharia de Produção e

Sistemas pela mesma instituição. Professor dos cursos de Administração de

Empresas, Ciências Contábeis, Gestão da Produção e Pós-graduação na Feevale.

Professor do curso de graduação tecnológica em Logística na Unisinos. Experiência

empresarial e de consultoria em Gestão de Sistemas Produtivos e da Qualidade,

implantação de Sistemas de Planejamento e Programação da Produção e em

projetos de Modelagem, Otimização e Pensamento Sistêmico em empresas dos

ramos avícola, metal-mecânico, petrolífero e automotivo;

• Expert 5: Bacharel em Engenharia Mecânica-Aeronáutica pelo ITA e Mestre em

Engenharia Elétrica pela UNICAMP. Tem 15 anos de experiência no

desenvolvimento de sistemas de apoio à decisão para a otimização de processos

decisórios de Cadeias de Fornecimento (Supply Chain Management). É sócio-

quotista de uma empresa de referência no Brasil no desenvolvimento e implantação

de sistemas de programação da produção para a indústria cárnea; e

• Expert 6: Bacharel em Administração de Empresas pela Instituição Educacional

São Judas Tadeu e Mestre em Administração pela Universidade do Vale do Rio dos

Sinos (UNISINOS). Atualmente cursa o Doutorado em Engenharia de Produção

pela COPPE/UFRJ. Tem experiência na área de Administração, com ênfase em

Administração da Produção, atuando principalmente nos seguintes temas:

Engenharia de Processos de Negócios, Teoria das Restrições, Custos, Estratégia.

Possui publicações em periódicos e congressos científicos além de capítulos de

livro.

Depois de selecionados os especialistas, foram agendadas reuniões de validação do

método proposto com cada um. Antes da realização dos encontros, porém, enviou-se para os

experts os pressupostos, as estratégias, os Fatores Críticos de Sucesso e os fluxogramas das

etapas do método. Desta forma, adiantou-se o assunto das reuniões, possibilitando aos

profissionais a análise da proposta e a elaboração de uma lista prévia de dúvidas, críticas e

sugestões. Por conta disso, a coleta dos dados durante os encontros deu-se por meio da

realização de entrevistas focadas e semi-estruturadas. Isso significa que os encontros

caracterizaram-se pela espontaneidade e informalidade, por terem sido objetivos quanto ao

período de tempo dispensado e pelo caráter aberto dos tópicos colocados. Durante as reuniões,

trataram-se 4 temas:

• a abordagem do método: solicitou-se para que os experts avaliassem a proposta sob

um ponto de vista macro (viabilidade e importância da mesma), bem como os

fatores que o método deveria levar em consideração;

• a forma pela qual o método foi estruturado (processos e subprocessos), bem como o

formato dos fluxogramas;

• a consistência do método quanto aos testes sugeridos, índices de controle,

indicadores, validações e processos de análise; e

• os dados considerados: solicitou-se para que os especialistas comentassem sobre os

dados necessários para a programação da produção para a indústria cárnea, e se

estavam contemplados no método.

Por fim, a sétima etapa do método de trabalho contemplou o refinamento do método

proposto a partir das contribuições dos experts, gerando-se o documento final da proposta.

4 ESTUDO DE CASO

Neste capítulo, explora-se o desenvolvimento e análise do estudo de caso sobre a etapa

de projeto da implementação de um sistema de seqüenciamento da produção na Empresa

Alfa. A estruturação do capítulo permite que seja compreendido o contexto no qual se

desenvolveu o projeto do sistema, passando pelas especificações e atributos do mesmo, além

da estruturação dos dados coletados na ferramenta. Ainda, direcionam-se neste capítulo o

relato e as análises dos procedimentos utilizados para o problema da acuracidade dos dados

no sistema.

Inicialmente, abordam-se neste capítulo as características da Empresa Alfa,

principalmente no que tange aos sistemas produtivos e à estrutura de produto característicos

de indústrias de alimentos cárneos. Na seção 2, resgata-se o fator que levou a Empresa Alfa a

investir em um sistema de seqüenciamento da produção, como também se relata o histórico do

caso, o qual contempla as atividades de cada etapa do projeto para a implementação do

sistema.

Na terceira seção do capítulo, são abordadas as características do sistema, as quais

foram implementadas considerando-se os requisitos mínimos de um sistema de

seqüenciamento da produção e as características do negócio da Empresa Alfa. Já a quarta

seção traz conceitos utilizados no sistema relacionados à estrutura de dados, bem como os

fluxos e o relacionamento de dados.

A quinta e a sexta seções do capítulo dedicam-se, respectivamente, ao detalhamento

do método empregado para a acuracidade dos dados no sistema e à análise das atividades

desenvolvidas em torno da falta de qualidade dos dados no caso pesquisado. Por fim, a sétima

seção resgata de forma sucinta os assuntos abordados no capítulo.

4.1 Sistemas produtivos da Empresa Alfa

A empresa pesquisada possuía dois tipos de sistemas produtivos nas suas fábricas: um

era caracterizado pela divergência dos processos produtivos (plantas do tipo “V”), enquanto

que o outro pela convergência das operações de manufatura (plantas do tipo “A”)

, conforme

mencionado no capítulo 1. A estrutura de produto dos sistemas divergentes de fabricação em

um abatedouro é simbolicamente apresentada na Figura 8. Um frango, ao ser abatido, gera

compulsoriamente uma série de itens em função da “desmontagem” da ave – são retirados da

ave as penas, o sangue e as vísceras (os quais são enviados para a fábrica de subprodutos, que

produz óleo e farinha animais); a cabeça (também enviada para subprodutos); os pés (que

podem ir para subprodutos ou serem vendidos); e a carcaça com miúdos, também chamada de

broiler (carcaça com fígado, moela e coração).

Uma observação pertinente em relação à estrutura representada na Figura 8 diz

respeito aos itens compulsórios e alternativos das partes do frango: há produtos que sempre

serão produzidos a partir desta ave (como os pés, por exemplo), logo existe um percentual do

peso do frango (chamado de rendimento) que será destinado para a produção de um corte. Por

outro lado, de uma carcaça com miúdos é possível vendê-la como broiler ou então retirar os

miúdos para que sejam vendidos separadamente os seguintes itens: carcaça sem miúdos

(também chamada de griller), fígado, coração e moela. Esta situação apresenta o conceito de

cortes alternativos – em outras palavras, existe uma decisão a ser feita (e não uma

compulsoriedade) entre produzir um ou outro (ou um pouco de cada). Logo, o conceito de

rendimento não é aplicado nos produtos alternativos.

O suíno e o peru possuem uma estrutura de desmembramento praticamente igual à do

frango, à exceção dos tipos de cortes, miúdos e rendimentos. Porém, em sua essência, a

estrutura é a mesma. De uma ave ou suíno vivo, retiram-se as partes do mesmo a cada estágio

do processo de maneira que sejam obtidos os cortes desejados.

Já os produtos cárneos elaborados (Figura 9) são “montados” com base em uma

formulação definida pela área de P&D, a qual estabelece as quantidades e os percentuais de

cada componente da fórmula em relação a uma batelada

padrão do produto final. O conceito

de itens compulsórios e alternativos é também aplicado nos produtos elaborados. Para se

produzir um formulado cárneo, é necessário que se utilizem compulsoriamente carnes e

condimentos, ou seja, não se pode fazer um produto que contenha um ou outro item.

O primeiro sistema (divergente) é encontrado nos frigoríficos (também chamados de abatedouros), no qual as

aves ou suínos vivos são “desmontados” do início para o final do processo. Ou seja, os animais são

transformados em um montante de produtos acabados (prontos para serem comercializados) ou então destinados

para o consumo interno nas fábricas de industrializados. Estas plantas, por sua vez, são enquadradas nos sistemas

produtivos de montagem (processos convergentes), pois as matérias-primas (carnes) e os condimentos

convergem para um único ponto – em outras palavras, ambos os grupos de componentes são utilizados para a

fabricação do produto final (também conhecido como elaborado ou formulado).

FIGURA 8 – Exemplo de estrutura de produto de um frango.

A Figura 9 apresenta um exemplo de uma lingüiça. Na estrutura do produto, é possível

verificar que a matéria-prima “Recorte de coxa de frango”, apesar de ser compulsória, possui

dois produtos alternativos – ou seja, são oferecidas opções para que a condição de se utilizar a

referida MP seja atendida.

A contextualização dos sistemas produtivos da Empresa Alfa nesta seção permitiu que

se explorasse a dinâmica envolvida na programação da produção de cortes e de formulados. A

complexidade resultante das atividades do PCP desta organização, bem como a necessidade

Quantidade de um ou mais insumos utilizada em um ciclo de processamento.

de melhoria do seqüenciamento da produção, corroborou para que empresa investisse na

compra de um sistema. A elaboração manual dos planos de produção estava suscetível a

critérios empíricos e localizados, sem uma visão global das inter-relações (e respectivos

impactos) das decisões sobre os planos de produção.

FIGURA 9 – Exemplo de estrutura de produto de um formulado.

4.2 A implementação do sistema de programação da produção

A Empresa Alfa desenvolveu um projeto de redesenho de processos no qual se

identificaram alguns processos críticos para a organização, dentre os quais o de atendimento

de pedidos. Os objetivos de desempenho para este macro-processo foram assim definidos:

voltar a empresa para o mercado (produção puxada); melhorar a capacidade de entrega dos

pedidos aos clientes conforme o acordado; e reduzir o “custo de atendimento” dos pedidos.

Diante desses objetivos, a Empresa Alfa decidiu investir em um sistema de

seqüenciamento da produção, onde o mesmo deveria auxiliar a organização a atender os

pedidos no prazo acordado com os clientes. Para tanto, o sistema sincronizaria a produção da

empresa, alocando os volumes para cada uma das fábricas, considerando restrições produtivas

e de suprimentos, por exemplo. Esta sincronização possibilitaria à empresa obter uma visão

futura da alocação de pedidos como forma de se antever possíveis atrasos na entrega. A partir

da definição desses requisitos, uma empresa de consultoria foi contratada para que fosse feito

o desenvolvimento do sistema de seqüenciamento da produção para a Empresa Alfa.

A implementação do sistema de seqüenciamento da produção contemplou uma série

de etapas, cujas atividades foram coordenadas por uma equipe de projeto composta por dois

grupos: o dos profissionais da Empresa Alfa e o dos consultores da empresa responsável pelo

desenvolvimento do sistema. Até o momento em que os usuários do sistema foram

incorporados ao projeto (treinamento), o primeiro grupo era composto por 9 pessoas, dentre as

quais havia o gerente e o champion do projeto, analistas de negócio da área de Tecnologia da

Informação e analistas de processo industrial. Com o início dos treinamentos dos usuários e

dos testes destes colaboradores no sistema, a equipe passou a ser composta por 25 pessoas. Já

o segundo grupo (empresa de consultoria) possuía 9 pessoas, dentre as quais havia o quality

assurance, o gerente de projeto, consultores de negócio e analistas de sistema. Ambas as

equipes reuniam-se presencialmente ao menos uma vez por semana, além de manterem

contato telefônico e por e-mail diariamente.

A fim de se compreender o escopo do projeto, são detalhadas nesta seção as etapas do

projeto. Antes, apresenta-se o cronograma do projeto em um Gráfico de Gantt (Figura 10).

Meses

Etapas 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Mapeamento

Especificação conceitual

Redesenho de processos

Requisitos de dados

Coleta de dados e desenvolvimento

da ferramenta

Disponibilização para uso e testes

Treinamento de usuários

Testes dos usuários

Homologação

FIGURA 10 – Gráfico de Gantt do projeto de implementação do sistema de seqüenciamento da produção

4.2.1 Mapeamento dos processos de atendimento de pedido

A primeira etapa do projeto teve como objetivos o estudo e a formalização dos

processos de alocação de pedidos e previsões de demanda e de programação e controle da

produção empregados pela Empresa Alfa, colhidos a partir das percepções dos profissionais

da organização. Dessa forma, foi possível identificar as interações desses processos por meio

das seguintes áreas da empresa: Comercial, P&D, Logística, PCP corporativo (situado na

matriz da empresa), PCPs das fábricas, Fomento e Suprimentos.

4.2.2 Especificação conceitual

A etapa de especificação conceitual caracterizou-se pela definição e detalhamento do

escopo e das atribuições do sistema de seqüenciamento da produção a partir das informações

obtidas por meio do mapeamento de processos de programação e controle da produção

realizado na primeira etapa do projeto. Em outras palavras, buscou-se identificar as

expectativas em relação à ferramenta pela Empresa Alfa, definindo aquilo que o sistema

deveria e aquilo que o mesmo não precisaria contemplar, como também avaliar riscos e

benefícios da utilização do sistema.

A partir das discussões em torno dos objetivos da etapa de especificação conceitual,

foram feitas definições a respeito dos requisitos do sistema: conceitos gerais e pressupostos

(função e delimitações do escopo do sistema); indicadores de priorização (lógica adotada pelo

sistema para seqüenciar os pedidos); horizonte e grão de seqüenciamento (período de

programação e nível de detalhamento da programação, respectivamente), dados necessários

(estruturas de produto, calendários, roteiros de produção, transportes e suprimentos, dentre

outros); relatórios; interação com o usuário (definição dos principais “grupos” de usuários e

suas responsabilidades).

4.2.3 Redesenho de processos

A etapa de redesenho de processos foi realizada para que as rotinas de programação de

produção identificadas na primeira etapa do projeto (mapeamento dos processos de

programação realizados pela Empresa Alfa) fossem analisadas do ponto de vista da

operacionalização do sistema de seqüenciamento da produção. Dessa forma, foram definidos

os processos globais, a integração entre os mesmos, as atividades necessárias durante o uso da

ferramenta e os responsáveis pela manutenção dos dados em cada atividade.

4.2.4 Levantamento de requisitos de dados

A quarta etapa do projeto do sistema de seqüenciamento da produção caracterizou-se

pelo detalhamento dos dados que seriam necessários para o pleno funcionamento da

ferramenta, bem como pela análise dos fluxos de dados entre sistemas da Empresa Alfa e o

sistema de PCP. Os dados poderiam ser ora importados para a ferramenta ora inseridos

manualmente na interface do sistema. Na primeira situação, a importação seria feita por meio

de templates

(sendo o processo iniciado por intervenção humana) ou a partir da integração

com outros sistemas da Empresa Alfa.

4.2.5 Coleta de dados e desenvolvimento da ferramenta

As etapas de coleta de dados e de desenvolvimento da ferramenta ocorreram

simultaneamente. Enquanto que uma equipe da Empresa Alfa dedicou-se à coleta dos dados

necessários para o sistema (dados industriais e transportes, dentre outros), a empresa de

consultoria desenvolveu o algoritmo de seqüenciamento e a interface da ferramenta.

O processo de captura dos dados no ambiente da Empresa Alfa também contemplou o

preenchimento de templates de parte dos dados coletados (em planilhas eletrônicas) e a

avaliação dos sistemas corporativos da organização para obtenção da outra parte dos dados.

Templates são modelos de documento (arquivo) nos quais se preenchem dados.

Esta avaliação foi feita para que fosse possível exportar os dados automática e regularmente

para o sistema de programação da produção.

4.2.6 Disponibilização para uso e testes

Ao final da quinta etapa do projeto, disponibilizou-se para a equipe de projeto da

Empresa Alfa a primeira versão do sistema de seqüenciamento da produção. Inicialmente,

houve uma maior atuação da área de TI para a instalação da ferramenta e teste da estrutura de

hardware (servidor, rede, memória RAM dos computadores, dentre outros). Finalizadas as

verificações, iniciou-se a carga de dados (população) no banco de dados do sistema, a qual foi

feita mediante a utilização de templates e por meio da integração com outros sistemas da

Empresa Alfa (a qual foi suportada por um processo automático).

Após a população dos dados no sistema de seqüenciamento da produção, os membros

da equipe de projeto iniciaram um período de testes da ferramenta. Neste período, realizaram-

se atividades de limpeza e de correção de dados no sistema, cujos problemas foram

diagnosticados por meio de duas situações: as validações de dados do sistema e a comparação

dos programas de produção gerados pelo sistema com a realidade da empresa. Ainda, houve

situações nas quais foi necessário solicitar melhorias do algoritmo do sistema.

Esta etapa e as duas precedentes (requisitos e coleta de dados) representam o

verdadeiro foco deste estudo, tendo em vista a especificação, o manuseio e a correção dos

dados necessários para o sistema de programação da produção. Conforme será detalhado no

relato do estudo de caso, a acuracidade dos dados exerceu um impacto na qualidade das

informações geradas pelo sistema pesquisado. A partir disso, tornou-se necessário

desenvolver ações no sentido de identificar e corrigir os erros de dados.

4.2.7 Treinamento de usuários

O projeto de implantação do sistema de seqüenciamento da produção passou por um

momento no qual a equipe de projeto não conseguia avançar satisfatoriamente na qualificação

de dados e na análise das informações geradas pelo sistema. O grupo de profissionais não

possuía sensibilidade nas avaliações nem certeza da acurácia dos dados, apesar de os mesmos

terem sido coletados junto aos mantenedores (fornecedores) dos dados.

A partir desta constatação, decidiu-se envolver os futuros usuários do sistema no

projeto, principalmente aqueles que seriam os principais usuários da ferramenta: os

profissionais das áreas de PCP corporativo e do PCP das fábricas. Esse processo por realizado

por meio de treinamentos nos quais se procurou qualificar mais pessoas para trabalharem nos

testes da ferramenta para que ela fosse validada e posteriormente implantada.

4.2.8 Testes dos usuários

O período de testes (ou validações) dos PCPs concentrou-se na qualificação dos dados

no sistema de seqüenciamento da produção. Esta etapa foi similar na sua essência com a sexta

etapa do projeto (testes na equipe de projeto), porém com a diferença que as correções,

limpezas e análises de dados foram mais intensivas e profundas por parte dos principais

usuários da ferramenta.

4.2.9 Homologação

Ao final do período de testes dos principais usuários da ferramenta, situação na qual a

acurácia dos dados permitia uma maior confiabilidade sobre as informações geradas pelo

sistema, havia condições para que a ferramenta fosse implantada. Paralelamente a esta

definição, outros usuários foram sendo integrados ao projeto de maneira que os processos

estabelecidos na etapa de redesenho de processos fossem respeitados. Garantidas essas

questões, implementou-se o sistema.

4.3 O sistema de programação da produção

O sistema implementado na Empresa Alfa foi dotado de uma heurística própria de

seqüenciamento (não otimizante), a qual foi definida junto aos representantes da área de PCP

na equipe de projeto. O objetivo estabelecido para o sistema foi o de que deveria haver uma

prioridade para a programação de pedidos para o mercado externo, tendo em vista que a

Empresa Alfa exportava em torno de 80% da sua produção. Esta prioridade seria uma

ponderação de fatores como a data solicitada pelo cliente, um índice de priorização (definido

pela área de PCP em função de acordos comerciais, dentre outros), o valor financeiro do

pedido, o número de dias de atraso do mesmo e o volume dos produtos do pedido em atraso.

A estruturação do sistema do ponto de vista das necessidades de informação do

mesmo contemplou o desenvolvimento de três módulos: programação, acompanhamento de

pedidos e aprazamento. O módulo de programação englobava os planos de produção por

fábrica, as necessidades de matérias-primas, as sugestões de compra e de consumo de

suprimentos, as transferências entre unidades e a ocupação dos recursos produtivos.

O módulo de acompanhamento de pedidos consistia na visualização do status dos

mesmos conforme a etapa na qual se encontravam (aprovado ou não pela área de PCP

corporativo, por exemplo); dos pedidos atrasados; e das aderências (data de entrega solicitada

pelo cliente em comparação com a data de expedição do pedido). Por fim, o módulo de

aprazamento caracterizava-se por permitir a visualização das cotações de entrega das

consultas feitas pelos clientes. Este processo era realizado antes da confirmação (ou não) do

pedido, pois a data sugerida pelo sistema era submetida à avaliação da área de PCP

corporativo e do cliente.

Na Figura 11, apresenta-se a tela de estrutura de produtos formulados desenvolvida no

sistema de programação da produção (as chamadas árvores de formulação). Nesta figura,

verifica-se que os conceitos apresentados na seção 4.1 em relação aos sistemas produtivos da

Empresa Alfa são aplicados para uma salsicha resfriada. O produto final (código 2009) é feito

a partir da mistura dos componentes S1002 (matérias-primas para salsicha resfriada) e S1005

(ingredientes para salsicha resfriada), sendo que cada um destes possui um percentual de

formulação – o primeiro equivale a 90% do produto final, enquanto que o segundo, 10%.

Além disso, os roteiros foram desenvolvidos como redes de atividades integradas à estrutura

de produto, sendo possível cadastrar os recursos produtivos no ponto onde os mesmos são

consumidos. No exemplo da Figura 11, os recursos “Estufa” e “Embalagem final” são

utilizados na geração do produto em processo S1001 (massa de salsicha), sendo que, no

roteiro, o segundo sucede o primeiro, conforme se visualiza na coluna “Ordem”. Já as

capacidades dos recursos também podem ser visualizadas na Figura 11. No caso da “Estufa”,

a mesma tem capacidade de processamento de 2 bateladas/hora e lotes mínimos e máximos de

batelada de 500 e 1.000 kg, respectivamente.

FIGURA 11 – Exemplo de uma estrutura de um produto formulado fictício com os roteiros de produção

Já na Figura 12 apresenta-se outra tela do sistema de seqüenciamento da produção, a

qual contempla a estrutura de produto de desmontagem (chamada de árvore de cortes). No

exemplo apresentado, visualizam-se as partes compulsórias de um frango vivo de 1.400

gramas.

FIGURA 12 – Exemplo de uma estrutura de produto fictícia de um frango vivo de 1.400 g

4.4 A estruturação dos dados no sistema

Os objetivos desta seção são os de estabelecer uma visão global e integrada dos dados

utilizados para o funcionamento do sistema de seqüenciamento da produção (sob uma ótica

agregada a partir função dos mesmos), bem como descrever conceitos importantes dentro do

escopo do sistema.

4.4.1 Visão geral e conceitos sobre os dados

Conforme mencionado na introdução da seção 4.4, o objetivo desta parte do estudo é

apresentar os dados sob um ponto de vista agregado. Ou seja, não será detalhado cada dado

necessário para o sistema, mas se abordarão os chamados grupos de dados. Com isso,

possibilita-se compreender de uma forma global a função dos dados na ferramenta de

programação da produção. Além disso, esta seção dedica-se a explorar conceitos que são

empregados no sistema e inerentes à indústria cárnea.

A Figura 13 apresenta uma visão global dos grupos de dados que são coletados para

serem atualizados no banco de dados da ferramenta. Dentre os 5 grupos de dados

estabelecidos, os cadastrais, além de serem inseridos na base do sistema, possuem um

relacionamento com os demais grupos de dados, tendo em vista que a inserção destes no

banco depende da existência daqueles. Uma vez que todos estes dados estejam populados na

base, o sistema os utiliza no processo de rodada, o qual gera informações para a tomada de

decisão.

FIGURA 13 – Representação do fluxo dos grupos de dados de acordo com a função dos mesmos no sistema

Em termos gerais, para se ter uma idéia da quantidade de variáveis e de dados de

entrada, como também do volume das tabelas na base do sistema de programação da

produção, elaboraram-se uma lista e uma figura, respectivamente, para a visualização de

ambas as estatísticas. Abaixo se apresentam algumas variáveis e outros dados de entrada:

• número de unidades produtivas modeladas: 13;

• número de árvores de cortes (faixas de peso): 49;

• número de produtos do tipo corte (finais e matérias-primas): 1.023;

• número de árvores de formulação: 287; e

• número de produtos finais formulados: 211.

Do ponto de vista do volume de dados nas tabelas do banco do sistema de

seqüenciamento da produção, na Figura 14 é possível visualizar a representatividade de cada

grupo de dados sobre o tamanho total, em megabytes (MB), das tabelas do banco de dados. É

importante ressaltar que não estão computados os pesos das tabelas de resultado do sistema, e

sim apenas das tabelas que recebem dados importados por templates ou integração de

sistemas.

FIGURA 14 – Representatividade de cada grupo de dados sobre o peso total das tabelas do sistema de

seqüenciamento da produção

Algumas observações se fazem necessárias em relação a determinados termos

utilizados no sistema para as estruturas de dados, pois serão recorrentemente mencionados a

partir desta seção. Estas terminologias são as escalas de abates, as curvas de peso, as árvores

de cortes e as árvores de formulação, as quais são detalhadas nos próximos parágrafos.

As escalas de abates são os dados referentes ao número de aves ou de suínos, por

gramatura (peso) do animal vivo, que se pretende abater em um abatedouro e em uma

determinada data e turno de trabalho. Os abates são os dados de entrada para o processo de

“desmontagem” de uma ave ou suíno para que o sistema possa programar os produtos finais

para venda ou então as matérias-primas para produtos elaborados. É importante ressaltar que

as escalas de abates são detalhadas por faixas de peso vivo, tendo em vista as seguintes

peculiaridades:

• existem produtos que podem ser produzidos somente a partir de algumas

gramaturas de vivo. Por exemplo, uma asa de frango de 25 gramas não poderá ser

produzida a partir do abate de frangos vivos com peso superior a 1.200 gramas; e

• dependendo-se da faixa de peso vivo, os rendimentos das partes da ave e do suíno

podem ser diferentes entre uma gramatura e outra.

Dentro do grupo de dados de abates, as curvas de peso (ou distribuições de abate)

representam a distribuição estatística do peso médio de um animal vivo. Quando se

programam as escalas de abates, os produtos finais e as matérias-primas, estima-se o volume,

em kg, necessário do animal desejado. A partir disso, dependendo-se da capacidade das

fábricas e da disponibilidade de animais nas granjas (peso médio unitário e número de

animais), solicita-se a coleta daqueles que terão o peso médio no dia do abate conforme a

necessidade. No entanto, pelo fato de a indústria cárnea lidar com matéria-prima viva, não se

pode considerar que todos os animais chegarão ao dia do abate com o mesmo peso vivo; no

caso de uma granja cujo peso médio do frango vivo seja de 1.400 g, por exemplo, pode haver

frangos de 900 g até 1.900 g. Logo, a partir do cálculo do peso médio projetado dos animais,

projetam-se os volumes conforme a curva de peso, a qual é calculada por amostragem nas

granjas. A Tabela 1 auxilia no entendimento do conceito de curva de peso.

TABELA 1 – Exemplo de uma curva de peso fictícia de um frango vivo de 1.400 g

Animal

Peso

médio

Faixas da

curva de

peso

% das faixas

sobre o peso

médio

Frango 1.400 g 900 g 0,52%

Frango 1.400 g 1.000 g 1,73%

Frango 1.400 g 1.100 g 5,21%

Frango 1.400 g 1.200 g 11,70%

Frango 1.400 g 1.300 g 16,22%

Frango 1.400 g 1.400 g 22,98%

Frango 1.400 g 1.500 g 16,02%

Frango 1.400 g 1.600 g 11,50%

Frango 1.400 g 1.700 g 7,86%

Frango 1.400 g 1.800 g 4,40%

Frango 1.400 g 1.900 g 1,86%

Total 100,00%

Fonte: autor.

As outras terminologias existentes no sistema de seqüenciamento da produção

relacionam-se com a estrutura de produto – a “desmontagem” das aves e suínos e a

“montagem” das carnes e componentes para a produção de elaborados são denominadas

árvores de cortes e árvores de formulação, respectivamente. As chamadas árvores de cortes

são uma representação gráfica da estrutura em que uma ave ou suíno são desmembrados até

chegar aos produtos finais ou matérias-primas, o que é similar à Figura 8, na primeira seção

deste capítulo. Já as árvores de formulação são análogas às árvores de cortes, com a diferença

que tratam as estruturas referentes aos produtos elaborados e possuem o percentual da

formulação na árvore.

Conforme mencionado, ambas as estruturas possuem componentes em comum. Dentre

estes, são detalhados abaixo os significados e funções dos rendimentos, dos produtos-pai, dos

produtos-filho, dos produtos intermediários, dos roteiros de produção e dos percentuais de

formulação de um produto elaborado:

• os rendimentos são utilizados nas árvores de cortes para determinar o percentual de

um corte compulsório de uma ave ou de um suíno. Já nos produtos formulados, os

rendimentos são utilizados tanto em itens alternativos quanto em produtos

compulsórios – o objetivo é representar as perdas ou ganhos de peso de um produto

durante o processo, tendo em vista que um elaborado pode passar por processos de

fritura e cozimento, por exemplo;

• os conceitos de “pai” e “filho” são aplicados nas árvores de cortes e de formulações

para facilitar a referência a uma parte da estrutura de produto. Exemplo: uma

carcaça de frango sem miúdos que será utilizada para gerar cortes pode ser

considerada “mãe” do peito, da coxa, da asa e do resíduo de dorso. Estes, por sua

vez, são considerados “filhos” da carcaça sem miúdos, como também podem ser

considerados “pais” dos produtos que originam (o peito pode ser considerado “pai”

do peito sem osso e do peito com osso);

• os produtos intermediários são aqueles que foram criados especificamente em

função da construção das árvores – ou seja, fazem parte da modelagem utilizada no

sistema de seqüenciamento da produção. Logo, estes produtos não são vendidos

nem utilizados como matérias-primas – eles servem apenas para facilitar a

modelagem das árvores. Na Figura 15, o nodo “Carcaça para griller ou corte” é um

produto intermediário. Já na Figura 16, o nodo “Carnes” é igualmente um produto

intermediário;

• no sistema de seqüenciamento da produção, os recursos foram modelados dentro

das árvores, de maneira que a seqüência das operações respeitasse o ponto onde os

mesmos são utilizados no processo produtivo (e conseqüentemente na estrutura do

produto); e

• os percentuais de uma formulação são utilizados para definir as proporções de cada

componente da fórmula em relação a uma batelada do produto final. Vale ressaltar

que o percentual da formulação não pode ser confundido com o rendimento de uma

formulação.

Para que os conceitos acima sejam mais bem assimilados, apresentam-se nas Figuras

15 e 16 dois exemplos: um de árvore de corte de frango e outro de árvore de formulação de

uma lingüiça.

FIGURA 15 – Exemplo de parte de uma árvore de cortes de frango

A aplicação dos rendimentos nas árvores de cortes e de formulação, conforme já

mencionado, tem o mesmo princípio: destinação da “massa cárnea” nos nodos compulsórios.

A única diferença é que os rendimentos servem para “desmontar” as árvores de cortes,

enquanto que, nas árvores de formulações, os mesmos servem para sinalizar a existência de

perda ou ganho de massa no nodo. No caso da Figura 16, o recorte resfriado de coxa de

frango tem rendimento de 80%. Isso significa que, do total da carne utilizada no início do

processo (entrada na máquina moedora), 80% da massa é utilizada – ou seja, existe perda de

20%.

FIGURA 16 – Exemplo de uma árvore de formulação

O rendimento nas árvores de cortes e o percentual da formulação nas árvores de

produtos elaborados devem ser calculados em relação ao produto pai, logo se utiliza uma base

100% em cada nodo (nível ou ramo) das árvores. Na árvore de cortes apresentada na Figura

15, a soma dos rendimentos dos miúdos e da carcaça para corte ou griller é igual a 100%. Em

um nível abaixo, os componentes da carcaça para corte também somam 100%. A mesma

situação ocorre na árvore de formulação da Figura 16 – em cada nível no qual existem filhos

compulsórios, a soma dos percentuais dos mesmos em relação ao produto pai é igual a 100%.

4.4.2 Detalhamento dos dados do sistema

Após descrever o volume dos dados inseridos na base do sistema e os conceitos

utilizados na ferramenta, retoma-se nas próximas seções o detalhamento dos grupos de dados.

4.4.2.1 Dados cadastrais

Os dados cadastrais agregam todos os dados que são utilizados para a estruturação ou

modelagem de outros grupos de dados. Em outras palavras, são considerados básicos para o

funcionamento do sistema. Abaixo são elencados exemplos de situações nas quais os dados

cadastrais são utilizados por outros grupos de dados:

• um pedido pode ser composto pelos dados de país, cliente e produto desejado; e

• uma árvore de formulação é composta por produtos intermediários, matérias-

primas, produtos finais e ingredientes.

4.4.2.2 Dados de abates

O grupo de abates é composto pelos dados relacionados aos animais que serão

utilizados para a geração dos produtos finais ou matérias-primas por meio das árvores de

cortes. Dentre esses dados, as escalas de abate e as curvas de peso já foram previamente

detalhadas neste capítulo. O terceiro elemento do grupo (limites de abates) é utilizado

somente no período do horizonte de programação não coberto pela escala de abate, no qual os

volumes de abate são sugeridos pelo sistema. Os limites de abates são definidos por meio de

volumes mínimos e máximos (em unidades), por fábrica e faixa de peso vivo, dentro dos

quais a empresa deseja que o sistema programe o abate dos animais. Esta definição pode ser

necessária para que se respeite o plano de alojamentos de animais nas granjas definido pela

organização.

4.4.2.3 Dados industriais

O grupo dos dados industriais representa os dados que são coletados na área produtiva

da empresa e que estejam relacionados aos produtos e matérias-primas. Com isso, dados de

árvores de cortes e de formulação, recursos produtivos e calendários (dentre outros) fazem

parte do grupo.

4.4.2.4 Dados comerciais

O grupo de dados comerciais engloba os dados relacionados aos volumes de pedidos

confirmados e à previsão de demanda, por mercado e produto. A função destes dados é a de

direcionar as decisões do sistema de PCP para a programação dos produtos finais nas fábricas,

bem como das matérias-primas, pois estas são demandadas conforme a necessidade de

produção de formulados.

No caso dos pedidos confirmados, devem ser atendidas as datas de entrega acordadas

para os mesmos junto aos clientes. As previsões de demanda possuem menor prioridade em

relação aos pedidos, pois representam uma tendência de venda, servindo apenas para

direcionar as decisões do sistema nos casos em que não houver pedidos para um produto ou

quando os pedidos já tiverem sido alocados no horizonte de programação. Ou seja, se “sobrar

massa” dos abates dos animais após atender aos pedidos, a mesma deverá ser alocada para os

produtos que possuam previsão de demanda.

4.4.2.5 Dados logísticos

Os dados logísticos são compostos pelo cadastro dos dados que estejam relacionados

ao transporte de produtos e à armazenagem de suprimentos e produtos. No caso dos

transportes, são considerados os tempos e permissões de transferência de produtos entre

fábricas, unidades de armazenagem e pontos de embarque (porto seco, porto marítimo,

aeroporto, dentre outros). Já os dados relacionados à armazenagem contemplam os estoques

de produtos e de suprimentos nas fábricas, bem como as capacidades de estocagem dos

produtos.

4.5 Procedimentos utilizados para a acuracidade dos dados no estudo de caso

Esta seção detalha os passos dados no sentido de melhorar a acuracidade dos dados no

sistema de seqüenciamento da produção. Antes, porém, é feito um breve relato das atividades

desenvolvidas durante o período compreendido entre a sexta etapa do projeto de

implementação da ferramenta (relatada na seção 4.2.6) e a pré-implementação do sistema.

Esta fase final do projeto consumiu em torno de 75% do mesmo, aspecto que reforça a

necessidade de se discutir os procedimentos adotados para a acuracidade dos dados.

O início do manuseio do sistema iniciou com a população dos dados no sistema, sendo

que alguns já haviam sido coletados na empresa, enquanto que outros seriam importados para

a base em um momento mais adequado. Com os dados devidamente populados na base de

dados, prosseguiu-se para a análise das chamadas validações, mecanismo implementado na

ferramenta para que fosse possível identificar erros de dados.

As atividades realizadas em torno da análise das validações permitiram que erros

triviais pudessem ser corrigidos, porém chegou-se em um momento onde a complexidade dos

problemas exigia uma análise mais estruturada e profunda dos mesmos. Em função disso,

elaborou-se um procedimento padrão para a identificação dos erros de dados.

A iniciativa de desenvolver um procedimento contribuiu para a melhoria da

acuracidade dos dados, bem como facilitou as atividades da equipe de projeto. Porém, tal

como ocorreu na fase final da análise dos erros de validação, verificou-se que eram

necessárias ações efetivas no processo de identificação e correção de dados no sistema.

Decidiu-se, a partir disso, treinar os usuários-chave da ferramenta para que houvesse

multiplicação do conhecimento sobre a ferramenta e, conseqüentemente, maiores avanços na

acuracidade dos dados.

A sinergia de esforços entre a equipe de projeto e os principais usuários do sistema

permitiu que fossem obtidos progressos na melhoria dos dados. O procedimento para a

acuracidade dos dados foi sendo aprimorado, enquanto que profissionais da Empresa Alfa

passaram a “apropriar-se” da ferramenta, até que se decidiu implementar o sistema de

seqüenciamento da produção.

O relato sobre as atividades do período em que se adotaram procedimentos para a

acuracidade dos dados no sistema de seqüenciamento da produção foi dividido em 5 etapas, as

quais são detalhadas nas próximas seções. Na Figura 17, apresenta-se um Gráfico de Gantt

por meio do qual é possível visualizar a duração de cada fase.

Semanas

Etapas

Fase 1 - População de dados

Fase 2 - Correção de erros triviais

Fase 3 - Os primeiros passos em direção a

um método para a acuracidade dos dados

Fase 4 -

A intensificação de esforços junto às

fábricas

Fase 5 - Extensão do projeto

9 10 18 201913 14 15 16 1711 126 7 81 2 3 4 5

FIGURA 17 – Gráfico de Gantt do período em que foram utilizados procedimentos para a acuracidade de dados

no sistema de sistema de seqüenciamento da produção

4.5.1 Fase 1 – População de dados

Após a disponibilização da ferramenta para que a mesma fosse testada pela equipe de

projeto da Empresa Alfa, iniciou-se a população do banco de dados do sistema com os dados

coletados na organização. Nesta etapa, por ter sido a carga inicial da ferramenta, houve a

importação de todos os dados de entrada. É importante destacar que, ao final deste processo,

as importações subseqüentes de dados não seria tão elevada quanto a carga inicial, pois as

alterações necessárias seriam atualizadas por meio da integração com outros sistemas da

Empresa Alfa; pela importação de templates com novos dados ou para atualização dos já

existentes; ou ainda pela edição manual na interface da ferramenta de seqüenciamento da

produção.

Inicialmente, a empresa de consultoria responsável pelo desenvolvimento do sistema

passou orientações a respeito do processo de população de dados para a equipe de projeto:

• como importar dados para as tabelas do sistema;

• quais tabelas deveriam ser populadas em função de serem pré-requisito para a

ferramenta rodar;

• quais tabelas não precisavam ser populadas (pelo fato de receberem resultados do

sistema); e

• quais eram as precedências entre as tabelas, de maneira que o processo de

importação de dados para a base considerasse estes pré-requisitos.

Diante destas orientações e, como forma de adiantar os trabalhos em torno dos testes

da ferramenta, não se esperou pela disponibilização de todos os dados necessários para o

sistema – aqueles que não eram pré-requisito para o funcionamento do sistema, mas que

influenciariam nos resultados do mesmo, seriam atualizados em um segundo momento.

No processo de população da base, houve dificuldades para importar os dados, tendo

em vista os seguintes problemas:

• interpretações erradas por parte da equipe de projeto a respeito dos templates das

tabelas; e

• dificuldade de preenchimento dos templates, dado o volume de dados coletados e a

necessidade de respeitarem-se os relacionamentos entre as tabelas.

Conforme relatado nesta seção, a fase de população de dados caracterizou-se pelo

manuseio dos mesmos para que fosse feita a carga inicial da base do sistema. Ocorreram

dificuldades durante o processo, as quais foram sendo sanadas até que se iniciaram as

validações de dados e as respectivas correções.

4.5.2 Fase 2 – Correção de erros triviais

A segunda fase do período de identificação e correção dos erros de dados caracterizou-

se predominantemente pela análise de erros triviais. Houve também a descoberta de falhas nas

cargas de dados de suprimentos e de produtos para a ferramenta de PCP e a geração de

pedidos fictícios como forma expor-se outros erros.

Os erros triviais foram assim denominados porque os problemas relacionados tinham

uma complexidade de solução considerada baixa. Ou seja, uma vez identificados os

problemas, não foram encontradas dificuldades para solucioná-los. É importante mencionar,

neste caso, o papel das validações. O sistema de seqüenciamento da produção foi dotado de

um mecanismo de validação dos dados, por meio do qual era possível identificar

determinados tipos de erros. Dependendo-se da característica do problema diagnosticado, não

era possível prosseguir no processo de testes de rodadas do sistema (geração dos programas

de produção). Logo, os diferentes tipos de erros identificados nas validações impediam

quaisquer tentativas de análises preliminares das informações que a ferramenta poderia gerar.

Abaixo se listam três situações e respectivos exemplos de erros triviais:

• produto cadastrado em árvore possuía atributo de origem diferente da origem da

árvore: um produto de origem frango (coração, por exemplo) estava cadastrado em

uma árvore de cortes de suínos;

• produto intermediário sem filho: em uma árvore de cortes, a massa proveniente do

abate de um animal não possuía destino, dado que um produto intermediário não

possuía filhos (produto final ou matéria-prima); e

• produto intermediário não habilitado na permissão de produção: esta situação

impedia que a massa abatida fosse empurrada na direção dos produtos finais ou

MPs.

A geração de pedidos fictícios foi uma idéia que surgiu a partir da redução dos erros

triviais conforme estes foram sendo corrigidos. O objetivo desta ação foi o de forçar a

ocorrência de erros de dados, expondo-os de forma a serem mais facilmente identificados e

corrigidos. O meio utilizado para operacionalizar esta idéia foi gerar pedidos com quantidade

igual a 1 kg (um quilo) para todos os produtos de todas as árvores de cortes e de formulações

de todas as fábricas. Com isso, foi possível identificar outros erros triviais, além de problemas

um pouco mais difíceis de serem encontrados nas estruturas de produto.

A partir da análise das validações do sistema, os problemas relacionados à acuracidade

dos dados foram resumidos conforme a lista abaixo:

• árvores: houve casos nos quais a árvore não estava relacionada a uma fábrica, além

de situações nas quais havia rendimentos não preenchidos;

• atributos de produto: havia itens com dados incompletos

;

• atributos de uma unidade produtiva: havia erros de permissão de estocagem, nos

quais uma unidade que possuía estoque tinha o atributo de permissão desabilitado; e

• recursos: houve casos de recursos com batelada mínima maior que a máxima, por

exemplo

A lista acima apresenta dois tipos de erros: dados faltantes e dados incoerentes.

Consideram-se dados faltantes aqueles que deveriam estar cadastrados mas não estavam, seja

pela necessidade do caractere em si ou por uma questão de relacionamento de dados. Um

exemplo disso é uma árvore de cortes não habilitada. Neste caso, o sistema não irá considerá-

la para programar a produção e, até aqui, não existem problemas (não é necessário que o dado

de “permissão de produção” da árvore de cortes esteja preenchido). Porém, se existir um

produto que tenha pedido e esteja cadastrado somente nesta árvore, as validações sinalizarão

para a ocorrência de erros de dados. Logo, a falta deste dado caracteriza um erro. Já os dados

incoerentes são aqueles em que o dado está preenchido, porém não respeita um dos três itens a

seguir:

• formato: se o formato de um campo que contém datas no banco de dados for

“aaaa/mm/dd” (ano/mês/dia) e a base for atualizada com o formato “dd/mm/aaaa”

(dia/mês/ano), o dado é incoerente;

• natureza: um recurso produtivo está cadastrado como do tipo “unitário”, porém os

campos atualizados na base são referentes a um recurso “batelada”; e

• caractere: quando o dado correto deveria ser 20 e está 13000.

Conforme mencionado no início desta seção, verificou-se também nesta fase a

existência de problemas nas cargas de suprimentos e de produtos (integração de sistemas da

Empresa Alfa com a ferramenta de PCP). Os dados de estoques de embalagens, condimentos,

matérias-primas e produtos finais não representavam a realidade da empresa – por um lado,

faltavam itens, e, por outro, apareciam códigos com saldo positivo que, na verdade, não

Foram identificados casos em que um produto que era exportado possuía atributo “vendável” no sistema,

porém os demais atributos não estavam preenchidos, como “transferível” e “estocável”.

Uma batelada refere-se a um lote de produção no qual, por exemplo, um determinado volume de uma massa

composta por carnes e ingredientes é submetido a um ciclo de processamento. Um exemplo de um recurso do

tipo batelada é uma estufa, que é onde as salsichas são cozidas. No sistema de programação da produção

pesquisado, havia a possibilidade de determinar as bateladas mínimas e máximas desejadas (dado de entrada),

sendo que a ferramenta deveria seqüenciar a produção dentro destes dois limites. Logo, no erro constatado

(mínimo de batelada maior que o máximo), havia uma incoerência, pois esta situação não existe.

estavam no estoque contábil nem no estoque físico. Este tipo de erro não pôde ser

diagnosticado por meio de validações, tendo em vista que não existe uma regra que consiga

detectar esta situação. A única solução teria sido comparar os estoques conforme constavam

nos sistemas da Empresa Alfa com os dados de estoque na ferramenta de seqüenciamento da

produção.

Analisando-se as atividades desenvolvidas na fase 2, verifica-se que houve avanços na

identificação e correção de erros de dados; no entanto, havia outros problemas cujo

diagnóstico parecia ser impossível. Além disso, por mais que tenham sido encontradas

oportunidades de melhoria e ações estivessem sendo tomadas neste sentido, a visão era de que

a programação gerada pelo sistema não era satisfatória.

Ao final da fase 2, portanto, as iniciativas para a melhoria da acuracidade dos dados no

sistema de PCP não surtiam efeito, dada a complexidade dos problemas. Os erros já não eram

mais triviais nem se identificavam outros pontos de alavancagem para o problema. Com isso,

a equipe de projeto atuava permanentemente no monitoramento das validações do sistema e

na busca por outras técnicas para a identificação e correção dos erros. Em outras palavras,

havia dúvidas sobre onde estavam os problemas.

4.5.3 Fase 3 – Os primeiros passos em direção a um método para a correção dos dados

Após a realização de reuniões acerca das atividades da equipe de projeto quanto aos

rumos do mesmo, chegou-se à conclusão de que deveriam ser criados procedimentos de

análise, identificação e correção de erros de dados. Esta alternativa contribuiria para uma

padronização nas análises (rigor metodológico) e daria maior segurança aos membros da

equipe de projeto. Havia um consenso de que as idéias e atividades desenvolvidas na fase 2,

apesar de terem avançado na questão da correção de erros dados, estavam sendo avaliadas

com base em critérios subjetivos – não se tinha uma noção real e objetiva do status do projeto

(qual tinha sido a evolução e quão próximo do final estava o mesmo).

Uma iniciativa que contribuiu neste sentido foi a criação de métricas para informações

geradas pelo sistema, as quais eram consideradas básicas para o negócio da empresa: volumes

de abates, de produção e de pedidos. A equipe de projeto passou a acompanhar os indicadores

criados e, a partir das constatações perante a evolução dos mesmos, direcionou as ações de

melhoria nos dados.

Os gráficos 1, 2 e 3 apresentam, respectivamente, a evolução dos indicadores de

abates, de produção total e de resíduos por meio de gráficos. O indicador de resíduos foi

desenvolvido a partir dos testes preliminares das métricas de abates e de produção total, nos

quais se verificou que havia produtos sendo programados que não eram estocáveis nem

vendáveis – ou seja, não tinham um destino. Nestes gráficos (e nos demais que serão

apresentados nas fases 4 e 5), ressaltam-se pontos que podem representar dois tipos de

situações: primeira, os eventos a partir dos quais se identificou uma melhoria no resultado de

um indicador (os quais foram sucedidos por ações de correção de erros de dados e de bugs

sistema); e, segunda, os eventos que foram marcados pela tendência de piora no desempenho

de um indicador.

O significado dos indicadores apresentados nos Gráficos 1, 2 e 3, bem como o método

de cálculo dos mesmos são detalhados a seguir:

• abate total: considera o volume total, em kg, das quantidades programadas

sugeridas pelo sistema de cada ave e suíno vezes o peso unitário dos animais;

• produção total: considera o volume total, em kg, dos produtos que são gerados por

meio das árvores de cortes e de formulados; e

• resíduo total: considera o volume total, em kg, dos produtos programados que não

são estocáveis. Os resíduos indicam a existência de erros de dados neste atributo

dos produtos.

Os indicadores criados consideravam todo o horizonte de programação (três meses),

ou seja, não foi feito um acompanhamento em granularidades menores (semana ou dia). Da

mesma forma, não se criaram os indicadores separados por fábrica. A idéia, inicialmente, foi

visualizar o comportamento das métricas em uma dimensão global.

Erro no funcionamento de um sistema.

GRÁFICO 1 – Indicador de abate total global

No indicador de abate total global (Gráfico 1), escolheram-se três inflexões no

comportamento da medição para se fazer a análise do mesmo. No ponto 1, identificou-se que

havia recursos produtivos saturados ou próximos deste nível (com ocupação de 95 a 100%). A

ação tomada sobre esta situação foi identificar, primeiramente, quais recursos estavam

saturados. Em um segundo momento, analisou-se a disponibilidade de cada recurso (tempo,

em horas, que o mesmo possuía para programar a produção). Neste ponto, foram encontrados

erros nos calendários dos recursos (horários de início e fim de turno, tempos de parada

programada e quantidade do recurso), os quais foram corrigidos.

No ponto 2, verificou-se que havia erros nas árvores de cortes em que a soma dos

rendimentos dos filhos compulsórios de um nodo eram diferentes de 100%. Isso fazia com

que a necessidade de abate calculada pelo sistema fosse subestimada. Além disso,

encontraram-se casos nos quais os produtos intermediários de uma árvore de cortes não

estavam habilitados para programação, fazendo-se com que a massa não “percorresse” as

árvores. As ações feitas sobre estes casos foram, primeiro, identificar em quais animais a

programação de abates estava aquém da meta. Em um segundo momento, escolheram-se as

árvores das aves e suínos que possuíam problemas para que fossem corrigidos os erros.

O ponto 3 caracterizou-se pelo início da existência de erros nos percentuais de

formulação, os quais ocorreram a partir da realização de atividades de revisão das árvores.

Diante da redução no resultado do indicador, verificou-se ao longo das análises feitas que a

composição de ingredientes nas formulações estava superestimada (acima de 100%),

enquanto que o total de matéria-prima subestimado (inferior a 100%). Com isso, a

necessidade de carnes reduzia, o que limitava a programação de abates.

GRÁFICO 2 – Indicador de produção total global

No indicador de produção total global (Gráfico 2), o comportamento do mesmo

refletiu os resultados alcançados na medição da programação de abates (Gráfico 1). Por conta

disso, as causas dos problemas verificados neste indicador foram as mesmas no de produção,

com a diferença de também terem sido encontrados erros na habilitação de produtos

intermediários de árvores de formulação.

GRÁFICO 3 – Indicador de resíduo total global

Já o indicador de resíduos (Gráfico 3) teve a meta alcançada no terceiro dia da

medição do mesmo. No ponto 1, verificou-se que havia produtos que estavam sendo

programados corretamente, porém não eram estocáveis. Com isso, não havia destinação para

os itens, o que fazia com que o os mesmos se tornassem resíduos no sistema. A ação tomada

sobre este caso foi analisar cada produto que se enquadrava no conceito de resíduo,

procedendo-se para a correção dos dados.

Paralelamente aos três indicadores criados, foi feita uma análise conjunta dos abates e

da produção total em relação à programação de pedidos. Isso foi necessário porque se

verificou que a complexidade dos problemas exigia processos de solução de problemas que

considerassem mais de um fator concomitantemente. Neste caso, a análise contribuiria para a

melhoria dos dados das estruturas de produto e de roteiros, e vice-versa.

Para que o acompanhamento do indicador de pedidos pudesse ser feito, foi necessário

iniciar o processo de carga, a cada rodada do sistema de seqüenciamento da produção, dos

volumes pendentes dos pedidos “reais” da Empresa Alfa na ferramenta (consideraram-se

apenas os saldos dos pedidos para evitar que o sistema programasse desnecessariamente

produtos ou quantidades já entregues ao cliente). É importante ressaltar que, até então,

testava-se o sistema de seqüenciamento da produção sem os pedidos “reais” da Empresa Alfa

porque se procurou isolar esta variável para que o processo de análise e identificação de erros

se tornasse mais fácil.

O Gráfico 4 apresenta a evolução do primeiro indicador relacionado à programação de

pedidos, o qual considerava o percentual de pedidos programados sobre o total de pedidos

pendentes. O indicador era calculado mediante a divisão da quantidade total, em kg, de massa

destinada para pedidos sobre a massa total de pedidos, também em kg. É válido ressaltar que

o denominador considerava todos os pedidos pendentes e outros pedidos desde que tivessem a

data de embarque acordada com o cliente menor ou igual à última data do horizonte de

programação. Ou seja, como o sistema considerava três meses “rolantes” de horizonte (“hoje”

mais 90 dias), pedidos cuja data de embarque não estivesse compreendida neste período não

eram considerados no cálculo. Esta decisão foi tomada, também, porque os pedidos da

Empresa Alfa possuíam uma média de atraso de 30 dias, logo o sistema de seqüenciamento da

produção priorizava estes pedidos em detrimento de outros que pudessem ser antecipados.

GRÁFICO 4 – Indicador de percentual de pedidos programados em relação ao total de pedidos pendentes

Nos pontos 1 e 2 do indicador de pedidos, os eventos que caracterizaram as situações

foram a existência de erros nos calendários dos recursos (afetando a disponibilidade dos

mesmos), de recursos sem calendário e erros nos rendimentos das árvores de cortes e de

formulação. Além disso, identificaram-se pedidos que já haviam sido entregues ao cliente,

mas que não tinham sido encerrados no sistema corporativo da Empresa Alfa. Logo, a

ferramenta de seqüenciamento da produção programava produções desnecessárias, ocupando

espaço de outros pedidos. Já no ponto 3 identificou-se um bug no sistema que estava

impedindo a alocação da programação de produção para uma parcela dos pedidos.

O acompanhamento do indicador de pedido possibilitou o direcionamento das

correções de erros de dados, predominantemente, para as árvores de cortes e de formulações,

os calendários dos recursos e os pedidos. Como os pedidos “reais” estavam sendo carregados

para o sistema, sabia-se que produtos não estavam sendo programados adequadamente. Neste

processo de melhoria, as validações do sistema de seqüenciamento da produção também

contribuíram para a identificação de erros de dados. Os problemas encontrados resumiram-se

conforme as situações abaixo descritas:

• pedido cujo país de destino não aceitava o registro de Serviço de Inspeção Federal

de qualquer uma das fábricas da Empresa Alfa;

• pedido com quantidade negativa;

• produto pai com filhos alternativos e compulsórios;

• produto constava em um pedido, porém tinha atributo informando que era não-

vendável; e

• formatos inválidos de dados no banco: data de entrega de pedidos e data do lote de

produção no estoque e estoque em trânsito.

4.5.4 Fase 4 – A intensificação de esforços junto às fábricas e a formalização de um

procedimento para a acuracidade dos dados

A utilização de procedimentos durante a fase 3 contribuiu para a melhoria da

acuracidade dos dados no sistema, porém chegou-se em um ponto onde as dificuldades

voltaram a aparecer – ou seja, os procedimentos criados já não conseguiam ter um efeito tão

satisfatório quanto no início da aplicação dos mesmos. A partir disso, decidiu-se aprimorar os

procedimentos existentes e intensificar os esforços por meio da multiplicação do

conhecimento acerca da ferramenta. Isso motivou a realização do primeiro treinamento para

aqueles que seriam os principais usuários do mesmo quando implementado (profissionais das

áreas de PCP corporativo e PCP de cada fábrica). Nesta oportunidade, os usuários foram

conscientizados sobre a importância da participação deles na intensificação da análise e

melhoria dos dados no sistema. Ainda, foram avisados de que seriam cobrados pela evolução

dos indicadores e pelo engajamento no processo de análises de dados.

Durante o treinamento, repassou-se para os usuários o procedimento que deveria ser

seguido durante as análises de dados no sistema para que os indicadores propostos evoluíssem

no sentido das metas estabelecidas. A Figura 18 apresenta os passos sugeridos:

FIGURA 18 – Resumo dos passos sugeridos para a análise dos dados na fase 4

Os passos apresentados na Figura 18 foram estruturados de maneira que as

inconsistências verificadas na programação sugerida pelo sistema fossem endereçadas para a

melhoria das árvores de cortes e de formulação. Decidiu-se direcionar os esforços neste

sentido por dois motivos: primeiro, as estruturas de “montagem” e de “desmontagem” dos

produtos representam o canal no qual os dados de pedidos e de abates (entrada) são

processados para que sejam gerados planos de produção (saída). Existem outros dados que

influenciam na programação de produção, como os logísticos e cadastrais; porém, é a

estrutura de produto, aliada aos recursos, que regula a conversão dos insumos em produto

final. Segundo, a intensificação da análise de dados pelos PCPs das fábricas contribuiria para

que se avançasse na correção dos erros, pois estes profissionais conheciam detalhadamente os

dados e as especificidades de cada planta industrial.

O passo 1 sugeria que o processo de análise se iniciasse pela comparação entre a

programação sugerida pelo sistema e a produção realizada (ou projetada) em um mesmo

horizonte (por exemplo, a programação total de 5 dias úteis). Diante de todos os produtos

analisados, no passo 2 deveriam ser identificados aqueles que fossem representativos para a

empresa, como forma de priorizar a análise. Os critérios utilizados poderiam ser os seguintes,

dentre outros:

• volume programado diferente do realizado ou projetado;

• produto faz parte dos itens mais importantes para a empresa; e

• produto é compulsório de diversos outros produtos.

A partir da escolha do produto a ser analisado, no passo 3 sugeria-se que fossem

identificadas as árvores a partir das quais o produto estivesse sendo programado ou aquelas

nas quais o produto estivesse cadastrado (caso o item não estivesse sendo programado). No

primeiro caso, dever-se-ia verificar de quais árvores o produto era programado. A Tabela 2

apresenta um exemplo desta situação para o produto A, o qual está sendo programado em três

árvores de cortes distintas.

A partir da Tabela 2, verifica-se que 75% da programação do produto A está sendo

feita por meio da árvore de cortes do frango vivo de 1.600 g na fábrica 2. De posse desta

informação, o usuário priorizaria a análise do referido produto nesta árvore no passo 4 do

procedimento sugerido. Ainda no passo 3, caso um produto não estivesse sendo programado

pelo sistema, deveriam ser identificadas as árvores que possuíssem o item cadastrado. Neste

momento, uma vez identificadas as árvores nas quais o produto estivesse inserido, proceder-

se-ia para a escolha das mesmas (passo 4). No caso do produto que não estivesse sendo

programado, a escolha recairia sobre a árvore cujo peso vivo do animal fosse compatível com

o histórico ou projeção de produção do produto em questão.

TABELA 2 – Exemplo da programação do produto A a partir de três árvores de cortes

Produto

Fábrica

Árvore de

cortes

Programação

do produto

(kg)

% sobre o

total

1 Frango 1.400 g 5.000 15,63

2 Frango 1.600 g 24.000 75,00

1 Frango 2.000 g 3.000 9,38

Total 32.000 100,00

Fonte: autor.

Uma vez escolhidas a fábrica e uma árvore da mesma, deveriam ser analisadas, caso o

produto não estivesse sendo programado, as habilitações do mesmo em relação à fábrica e à

árvore. Depois de realizada esta verificação e a correção (ou não) dos dados, seria feita uma

análise detalhada da situação, conforme a ordem que segue:

1. programação de abate da árvore em análise: analisar a coerência com o histórico ou

projeção;

2. rendimentos e formulações: verificar os percentuais cadastrados do início da árvore

até o ponto no qual se encontra o produto que se deseja analisar;

3. ocupação de recursos: identificar aqueles que estejam saturados (ocupação igual a

100%) ou próximos deste nível (principalmente para os recursos do tipo batelada);

4. calendário do recurso: analisar os dados de horas disponíveis (início e fim do turno

para cada dia, horas extras por dia e turno e tempo de paradas programadas) e de

quantidade do recurso;

5. programação do recurso: verificar que produtos estão consumindo o recurso. Dentre

esses, aqueles que não passam pelo recurso devem ser corrigidos.

Dentro do escopo do procedimento sugerido, contemplavam-se também os indicadores

de pedidos. Já as métricas de abate e de produção, que foram utilizadas na fase 3 dos

procedimentos de análise e correção de dados, deixaram de ser utilizadas na fase 4. Esta

decisão foi tomada porque se entendeu que, por meio da análise dos pedidos, os dados de

abate e de produção seriam naturalmente explorados.

No início da fase 4, propôs-se uma mudança na mensuração dos indicadores de pedido

– em vez de considerar massa (kg), passou-se a medir o indicador com base no número de

seqüências, tendo em vista que esta era a métrica utilizada pela Empresa Alfa. Um pedido

poderia possuir uma ou mais seqüências, que correspondiam ao fracionamento do pedido

total. Dessa forma, conforme a produção finalizava lotes do pedido, as seqüências eram

carregadas para o cliente. Os Gráficos 5 e 6 apresentam gráficos referentes à programação de

pedidos (indicador que já havia sido utilizado na fase 3) e à alocação de pedidos no prazo,

respectivamente.

O indicador apresentado no Gráfico 5 é o mesmo que foi utilizado durante a fase 3 do

procedimento de análise e correção de dados. Verifica-se pelo gráfico a evolução do

indicador, o qual considerava o percentual de pedidos programados sobre o total de pedidos

pendentes (lembrando que o denominador considerava somente os pedidos cobertos pelo

horizonte “rolante” de programação do sistema, o qual passou de três para cinco meses na

fase 4). Na fase 3, este indicador teve uma evolução de 18 para 60%. Já na fase 4, o mesmo

iniciou com uma queda para 50% (fruto da mudança do indicador – de kg para número de

seqüências), porém aumentou até o final desta fase para 96%, que era um índice próximo da

meta de 100%.

GRÁFICO 5 – Indicador de percentual de pedidos programados em relação ao total de pedidos pendentes

durante a fase 4

No ponto 1 do indicador de pedidos programados, foram novamente encontrados erros

nas formulações, tal como na fase 3. Isso ocorreu porque a revisão das árvores de produtos

elaborados iniciada na etapa anterior prosseguiu na fase 4. Especificamente em relação ao

ponto 1, os eventos que marcaram a redução no desempenho do indicador foram os seguintes:

• havia matérias-primas que estavam cadastradas em árvores de formulação, mas que

não constavam em árvores de cortes; e

• havia nodos compulsórios em árvores de cortes e de formulação que, na realidade,

deveriam ser alternativos, e vice-versa.

No ponto 2, verificou-se que havia calendários que não contemplavam as horas extras

de um recurso. Além deste evento, havia recursos cadastrados erroneamente em roteiros de

produção. Com isso, o recurso saturava, sendo que os produtos que o consumiam não

poderiam estar cadastrados para o mesmo.

Já no ponto 3 identificaram-se dois problemas, os quais são listados abaixo:

• havia produtos com baixos tempos de processo em relação ao valor real, o que fazia

com que a programação desses produtos saturasse os recursos de forma incoerente

com a realidade; e

• havia produtos que constavam em pedidos, mas que não estavam cadastrados em

todas as árvores necessárias. Com isso, reduziam-se as chances de o sistema

programar os produtos.

GRÁFICO 6 – Indicador de percentual de pedidos programados no prazo em relação ao total de pedidos

pendentes durante a fase 4

No Gráfico 6, visualiza-se o indicador criado na fase 4, o qual era similar ao

representado no Gráfico 5, com a diferença que representava as seqüências atendidas no

prazo. O índice era calculado mediante a divisão da quantidade total, em número de

seqüências, que o sistema programou no prazo sobre o número total de seqüências. Os

eventos que marcaram os pontos assinalados no Gráfico 6 também foram impactados pelos

erros identificados no indicador apresentado no Gráfico 5, tendo em vista que o atendimento

de seqüências no prazo é uma conseqüência da programação de pedidos.

Durante a fase 4, uma atividade que contribuiu para a busca pela melhoria das

informações geradas pelo sistema foi a análise da programação de produção do ponto de vista

das famílias de produtos. Esta tarefa não estava contemplada no método proposto no início da

fase 4, porém foi útil para a obtenção de uma visão ampla dos volumes sugeridos pela

ferramenta em comparação com a análise de um produto isoladamente.

Outra atividade desempenhada na fase 4 foi o desenvolvimento e a análise do

chamado balanço de massas, o qual se fundamenta no princípio de conservação de massa. Na

aplicação deste conceito para a análise das informações do PCP de uma indústria cárnea, as

entradas devem igualar-se às saídas, ambas em massa cárnea. A Figura 19 apresenta uma

estruturação simbólica do balanço de massas, o qual foi desenvolvido considerando-se todo o

horizonte de seqüenciamento, a fim de que fosse possível obter uma visão ampla da alocação

dos produtos.

ENTRADAS SAÍDAS

- Estoque inicial

- Estoque em trânsito

- Compras

- Programação

- Apontamento de

produção

- Alocação para pedidos

- Alocação para previsão

de demanda

- Alocação para formulação

- Estoque final

- Estoque em trânsito

- Resíduos

FIGURA 19 – Estrutura simbólica do balanço de massas

As atividades desenvolvidas durante a fase 4, apesar de a meta do indicador de

pedidos no prazo não ter sido atingida, permitiram concluir que os avanços foram

satisfatórios. A adoção de um procedimento estruturado para a identificação de erros de dados

(o qual foi também suportado por indicadores) e a intensificação da análise pelos usuários

contribuíram para que se chegasse a um melhor nível das informações geradas pelo sistema.

4.5.5 Fase 5 – Extensão do projeto

Os avanços verificados na fase 4 estiveram relacionados à melhoria da informação

gerada pelo sistema de seqüenciamento da produção sob o ponto de vista global da Empresa

Alfa (volumes totais do horizonte de programação, independentemente da fábrica). Por outro

lado, as informações relativas a grãos menores de programação (turno, dia ou mês), aos

planos de produção por fábrica e à programação de formulados ainda não eram satisfatórias.

Em outras palavras, era necessário que se trabalhasse sobre refinamentos no mix de produção

gerado pelo sistema. A partir disso, foram tomadas três ações:

• aprimoramento dos passos para a identificação e a correção de dados estabelecidos

na fase 4;

• direcionamento das análises para a realidade de cada fábrica;

• intensificação das análises ainda maior em comparação com a fase 4. Na fase 5,

cerca de 50% dos usuários passou a dedicar-se em tempo integral para o projeto, ao

passo que os outros tinham uma agenda semanal de trabalho no sistema a ser

cumprida; e

• criação de outros indicadores (atendimento de demanda MI e programação de

abates).

O aprimoramento dos passos desenvolvidos na fase 4 contemplou dois aspectos: (1) os

passos foram divididos em dois fluxos – um para produtos do tipo corte e outro para análise

de produtos formulados; e (2) não era necessário iniciar a análise a partir dos produtos cuja

programação fosse incoerente com a realidade, como na fase 4. Como a acuracidade das

estruturas de produto foi melhorada ao longo das três primeiras etapas, a programação de

abates permitia que o mix de produção fosse avaliado a partir da massa dos animais vivos.

As Figuras 20 e 21 apresentam o resumo dos passos para a análise da programação e

melhoria da acuracidade de dados para cortes e formulados.

FIGURA 20 – Resumo dos passos para a análise e melhoria da programação de cortes na fase 5

A visualização das Figuras 20 e 21 permite concluir que os passos sugeridos para

cortes e formulados diferem apenas no início dos mesmos – enquanto que, para cortes,

sugere-se analisar a programação de abates, nos formulados deve-se comparar a necessidade

de matéria-prima (em função dos pedidos e da estrutura de produto) com a alocação de MP. O

detalhamento desses passos no sentido de identificar erros de dados está nos Apêndices A e B,

sendo o primeiro para cortes e o segundo para formulados.

FIGURA 21 – Resumo dos passos para a análise e melhoria da programação de formulados na fase 5

Nos passos 1 e 2 do fluxo de cortes, a análise de abates era feita para o grão turno e o

grão semana. O primeiro termo refere-se ao período do horizonte no qual o abate é empurrado

pela escala de abate (10 dias úteis); em outras palavras, é o número de animais por peso,

fábrica, data e turno que a empresa projetou para abater. Neste caso, as informações de saída

100

do sistema são igualmente detalhadas por peso do animal, fábrica, data e turno (considerando

10 dias úteis). Já o grão semana referia-se ao período no qual o sistema de seqüenciamento da

produção sugeria tanto a programação de abates quanto a de produtos finais e matérias-primas

– ou seja, o abate não era empurrado, e sim puxado pelos pedidos e necessidades de MP. Este

período contemplava 95 dias úteis e gerava planos de produção consolidados por semana,

portanto não havia o mesmo grau de detalhamento do grão turno.

O passo 1 do fluxo de formulados, por sua vez, sugeria a comparação entre as

necessidades e a alocação de MP para produtos formulados. As necessidades eram calculadas

com base nos pedidos e previsão de demanda dos produtos elaborados, como também na

estrutura das árvores de formulação, que possuíam os percentuais necessários de cada MP e os

ganhos e perdas de massa decorrentes do processo produtivo (rendimentos). Já a alocação

refere-se à utilização da programação de matéria-prima para a geração dos planos de produção

de produtos formulados.

O restante dos passos para cortes e formulados era essencialmente o mesmo. Depois

de avaliados os abates ou as necessidades versus a alocação de matéria-prima, procedia-se

para a análise da regularidade da programação. Este passo visava verificar se os volumes

totais de programação por fábrica, data e turno estivessem sendo gerados. A conferência

deveria ser feita mais no sentido de verificar se havia informações, pois foram encontrados

casos nos quais não havia programação em determinados turnos de algumas fábricas.

No penúltimo passo, sugeria-se a análise da programação de produção por família de

produto, pois desta forma seria possível identificar possíveis erros relacionados a um grupo de

itens. Apenas depois de realizado este passo, seguia-se para a última etapa da análise das

informações: o mix de produção. Nesta etapa, deveria ser feito um processo fino de análise e

identificação de erros para produtos específicos.

Além da definição dos passos descritos nos últimos parágrafos, criou-se uma matriz de

indicadores (Quadro 3), a qual possuía métricas anteriormente empregadas na fase 4, bem

como outros índices criados especificamente para a fase 5. A referida matriz foi concebida

para gerir os indicadores globais e locais (por fábrica) da Empresa Alfa. O quadro foi

separado entre dois grupos de indicadores: primeiro, os de atendimento de pedidos ME

(mercado externo) e de atendimento de demanda; e, segundo, os de aderência de abates.

101

Grupo

indicadores

N° Indicador Cálculo Horizonte

Atendimento de

seqüências ME

no prazo

Número de seqüências

programadas no prazo dividido pelo

número total de seqüências dentro

do horizonte para produtos do

mercado externo.

5 meses

Atendimento

de pedidos

ME e

atendimento

demanda

Atendimento da

demanda MI

Desvio padrão das aderências entre

o programado pelo sistema e

histórico de produção por família de

produtos do mercado interno.

1 mês

Aderência do

abate no grão

turno (abate

empurrado)

Número de animais programado

pelo sistema dividido pelo número

de animais programado na

realidade.

10 dias

úteis

Aderência

de abates

Variabilidade do

abate

programado no

grão semana

(abate puxado)

Desvio padrão do número de

cabeças programado pelo sistema.

95 dias

úteis

QUADRO 3 – Matriz de indicadores desenvolvida para a fase 5

Os resultados globais obtidos nos indicadores apresentados no Quadro 3 podem ser

visualizados nos Gráficos 7, 8, 9 e 10. Nos próximos parágrafos, também se analisam os

resultados alcançados em cada indicador.

O indicador 1A iniciou a fase 5 com 20% das seqüências programadas no prazo.

Houve uma evolução durante esta fase que o fez chegar a 38% ao final da mesma, índice,

porém, inferior à meta de 60%. No ponto 1 sinalizado no Gráfico 7, identificaram-se erros de

validades de produção – havia pedidos com zero meses de validade, o que significava que o

sistema poderia utilizar apenas os lotes de produção do mês “atual” para programar um

pedido. A partir disso, realizou-se um trabalho de correção dos dados, o que surtiu efeito com

a melhoria do indicador no dia 92 da fase 5.

No ponto 1, também houve a correção de um bug no sistema, o qual afetava a

programação de abates. No ponto 2 do indicador 1A, verificou-se que os problemas com os

saldos pendentes de seqüências já carregadas persistiam. Este evento marcou a queda no

indicador para o patamar verificado no dia 97. Já no ponto 3, a identificação e gradual

correção dos erros nos roteiros de produção permitiram que o indicador evoluísse

positivamente até o dia 106 da fase 5.

102

GRÁFICO 7 – Indicador de atendimento de seqüencias ME no prazo na fase 5

O indicador 1B, apresentado no Gráfico 8, manteve-se a maior parte do tempo

constante e próximo da meta de 34%. No ponto 1, houve um evento que marcou a melhoria

do indicador: identificou-se um bug no sistema, o qual não alocava a produção para a

demanda conforme o esperado. Já no ponto 2 duas situações resultaram na queda do

indicador: (1) os dados de demanda do mercado interno estavam errados; e (2) a modelagem

das árvores de formulação das fábricas de empanados não refletia a realidade.

GRÁFICO 8 – Indicador de atendimento da demanda MI na fase 5

No Gráfico 9, verifica-se que o indicador 2A manteve-se em 77% do período com um

índice médio de 95%, o que demonstrou a estabilidade e a proximidade do mesmo em relação

à meta (100%) durante a fase 5. No ponto 1, identificou-se uma necessidade de customização

do sistema para que o mesmo considerasse particularidades da programação de produção duas

unidades produtivas. Ainda, havia duas unidades com erros nos calendários de recursos, e

103

outras duas fábricas com erros nos dados de escala de abate. No ponto 2, verificou-se que

havia erros nos tempos de processo da maior fábrica da Empresa Alfa (em termos de volume

de produção). Já no ponto 3 identificaram-se erros em rendimentos de árvores de cortes.

GRÁFICO 9 – Indicador de aderência do abate empurrado na fase 5

O indicador 2B, conforme se visualiza no Gráfico 10, iniciou a fase 5 com um índice

de 9%, o que era praticamente a meta estabelecida (8%). Durante esta etapa, houve oscilações

e, no final, o indicador ficou em 25%, aquém da meta desejada. No ponto 1, verificou-se que

a programação de abates de um frigorífico em especial estava sendo responsável pelo

aumento da variabilidade, o que foi corrigido mediante uma customização do sistema no dia

87. No ponto 2, os erros mencionados na análise do indicador 2A também influenciaram

(erros nos tempos de processo da maior fábrica da Empresa Alfa). Nos pontos 3 e 4, a

existência de erros no cadastro dos limites de abates três frigoríficos (estavam

superestimados) culminou no aumento da programação de abates e, conseqüentemente, no

aumento da variabilidade.

104

GRÁFICO 10 – Indicador de variabilidade do abate puxado na fase 5

Durante as atividades realizadas na fase 5, houve dificuldades na análise e

identificação de erros de dados dos produtos formulados. Contudo, diagnosticou-se que uma

das causas do problema referia-se à programação de matéria-prima nas fábricas fornecedoras

deste insumo. A partir disso, analisaram-se as árvores de cortes e de formulação, além dos

estoques iniciais que eram carregados para o sistema de seqüenciamento da produção. Nestes,

verificou-se que havia estoque físico nas fábricas, porém o mesmo não aparecia na carga de

estoques para a ferramenta de seqüenciamento da produção. Após investigar, descobriu-se que

os estoques estavam sendo registrados em uma tela do sistema de controle de estoques da

Empresa Alfa de onde o sistema de programação da produção não importava dados.

Ao final da fase 5, realizou-se pela primeira vez no projeto a análise dos pedidos e

seqüências do ponto de vista das datas programadas pelo sistema de seqüenciamento da

produção. Esta atividade foi feita pela área de PCP corporativo, na qual foi possível comparar

as seqüências programadas pelo método “manual” com as seqüências programadas pelo

sistema.

A fase 5 caracterizou-se por ajustes finos nos dados do sistema de seqüenciamento da

produção, bem como pela intensiva participação dos usuários de todas as fábricas. Apesar

deste esforço, nenhum dos indicadores alcançou a meta desejada, apesar de o 1B, o 2A e o 2B

terem sido considerados satisfatórios. Por outro lado, como essas métricas foram criadas

somente na fase 5, não havia condições de avaliar a evolução das mesmas em relação a outras

etapas do projeto. Em função da necessidade de utilização do sistema pela Empresa Alfa,

além do fato de o projeto ter atrasado (o que fez aumentarem as pressões por parte da diretoria

da organização), decidiu-se homologar o sistema ao final da fase 5.

4.6 Resumo e avaliação dos procedimentos adotados

Apesar de não ter sido utilizado um procedimento propriamente dito durante as

primeiras fases em que se identificaram e corrigiram erros de dados, houve uma seqüência de

atividades que, mesmo não estruturadas, buscaram melhorar os dados do sistema de

105

seqüenciamento da produção. De uma forma geral, as fontes dos erros de dados encontrados

estavam relacionadas a dois grupos de problemas, conforme abaixo:

• integração de sistemas: a importação de dados de outros sistemas da Empresa Alfa

não havia sido mapeada adequadamente. Com isso, determinados dados não

refletiam a realidade quando atualizados no sistema de seqüenciamento da

produção; e

• influência humana: os dados eram impactados direta ou indiretamente no sistema

de seqüenciamento da produção pelos erros dos usuários. A relação direta se dava

quando os dados eram inseridos na interface do sistema ou importados por meio de

templates com erros. Já a relação indireta ocorria por meio de erros em outras

ferramentas da Empresa Alfa, as quais exportavam dados para o sistema de PCP.

Um exemplo deste segundo fator foi a inacuracidade de estoques de produtos ou de

suprimentos identificada durante o caso.

Neste sentido, com o advento da utilização de um sistema, a necessidade de dados

acurados expôs uma situação até então inexistente na Empresa Alfa. Havia dados que jamais

haviam sido levantados pela área de PCP. Já a acuracidade dos mesmos não era exigida pelo

fato de que, com a programação manual e descentralizada, os erros de uma fábrica não

influenciavam em outras. A partir do sistema de PCP, os erros de dados de uma fábrica

passaram a impactar em outras.

Outro fator relacionado à acuracidade dos dados diz respeito às diferentes visões

criadas sobre os cálculos de rendimentos e de percentuais de formulação em uma árvore – a

estrutura de produto do sistema era diferente da maneira como as fábricas tratavam estes

dados. Além disso, houve dificuldades na interpretação da função dos calendários para os

recursos, bem como na compreensão de quais dados inserir no sistema. Este segundo aspecto

diz respeito à diferença entre os dados reais e os objetivos (metas). O correto seria que

somente os dados reais (tempo de processo real de uma máquina, por exemplo) fossem

inseridos no sistema. Porém, havia usuários que, devido à cultura de cobrança de metas pelas

chefias, imaginavam que os dados utilizados no sistema deveriam ser as metas estabelecidas

para as fábricas.

A adoção de procedimentos para a melhoria da acuracidade de dados contribuiu para a

estruturação das atividades dos usuários e da equipe de projeto, bem como direcionou as

ações para a correção de erros. Na fase 2, quando ainda não havia um procedimento

106

estabelecido, as ações limitaram-se a corrigir erros triviais. Além disso, após a correção destes

erros, não se sabia o que fazer para melhorar a acuracidade dos dados.

Já a fase 3 caracterizou-se pelo embrião daquele que se transformaria, na fase 4, no

procedimento estruturado de análise e correção de dados. Na fase 3, a equipe de projeto teve o

mérito de criar indicadores e uma lista de verificação dos dados do sistema. No que diz

respeito às métricas criadas, as informações geradas pelo sistema passaram a ser avaliadas

conforme as atividades de melhoria da acuracidade dos dados eram realizadas. Outro aspecto

importante na fase 3 foi a carga dos pedidos reais da Empresa Alfa, o que aproximou as

informações geradas pelo sistema à realidade da organização, como também facilitou o

processo de análise dos dados.

A multiplicação do conhecimento sobre a ferramenta de seqüenciamento da produção

possibilitada na fase 4 foi uma iniciativa tão importante quanto o aprimoramento do

procedimento de melhoria da acuracidade dos dados. A intensificação de esforços

potencializou o processo de análise, o que contribuiu para a melhoria dos indicadores criados.

A fase 5 não apresentou uma evolução tão significativa quanto a fase 4. Ainda,

identificou-se um problema na carga dos dados de estoques, e o PCP corporativo analisou a

programação de pedidos. Esta segunda atividade deveria ter ocorrido no momento que a carga

de pedidos “reais” foi feita (fase 3), pois a validação destes dados contribuiria para a correção

de erros nos pedidos. Por outro lado, a criação de outros indicadores, como também os

desdobramentos dos mesmos para as fábricas, foi importante para analisar as informações sob

outra ótica e oportunizar aos usuários a avaliação dos resultados das plantas nas quais

trabalhavam. Ao final da fase 5, é possível fazer uma análise dos indicadores de programação

de pedidos e de atendimento de seqüencias no prazo em função da importância dos mesmos e

do fato de terem sido aplicados durante duas ou mais fases. Os Gráficos 11 e 12 apresentam

estes indicadores.

No gráfico do indicador de programação de pedidos, os pontos assinalados dizem

respeito aos seguintes eventos:

• ponto 1: identificação de erros de calendários, recursos cadastrados em árvores sem

calendário associado, erros nos rendimentos de árvores de cortes e de formulação, e

pedidos carregados e não encerrados pela área Comercial;

• ponto 2: bug no sistema de programação da produção;

107

GRÁFICO 11 – Indicador de programação de pedidos

• ponto 3: erros de rendimento e percentual de formulação nas árvores de produtos

elaborados, matérias-primas cadastradas em estruturas de produtos formulados

ausentes em árvores de cortes, e produtos que deveriam ser alternativos cadastrados

como compulsórios (e vice-versa);

• ponto 4: ausência de horas extras em calendários e recursos cadastrados em roteiros

nos quais não poderiam estar presentes; e

• ponto 5: recursos com baixos tempos de processo em relação à realidade e produtos

que não constavam em todas as árvores possíveis.

Já no indicador de atendimento de pedidos no prazo (Gráfico 12), foram sinalizados 5

pontos no gráfico do mesmo, sendo que os dois primeiros dizem respeito aos eventos 4 e 5,

respectivamente, identificados na análise da programação de pedidos (Gráfico 11).

GRÁFICO 12 – Indicador de atendimento de pedidos no prazo

108

Abaixo se elencam os eventos dos três últimos pontos do Gráfico 12:

• ponto 3: validades máximas de produção aceitas pelo cliente zeradas e bug no

sistema de seqüenciamento da produção;

• ponto 4: recorrência do problema dos pedidos carregados e não encerrados pela

área Comercial; e

• ponto 5: erros nos roteiros de produção.

Com relação à efetividade das ações realizadas em todas as fases para a correção dos

erros de dados, entende-se que houve 4 pontos de alavancagem para a melhoria da

acuracidade dos mesmos, os quais são listados abaixo:

• validação e refinamento da estrutura de produto e roteiros;

• validação e refinamento dos calendários dos recursos;

• multiplicação do conhecimento sobre a ferramenta e intensificação de esforços

junto aos usuários; e

• criação de indicadores para as informações geradas pelo sistema.

5 PROPOSIÇÃO DE UM MÉTODO TENTATIVO PARA A MELHORIA DA

ACURACIDADE DE DADOS EM UM SISTEMA DE PROGRAMAÇÃO DA

PRODUÇÃO PARA A INDÚSTRIA CÁRNEA

Neste capítulo, propõe-se um método tentativo que estabelece um roteiro para o

tratamento da acuracidade dos dados de um sistema de seqüenciamento da produção

desenvolvido para a indústria cárnea. Por método tentativo entende-se como uma proposta

que busca definir uma abordagem estruturada para a análise de um objeto. O desenvolvimento

do método contemplou os seguintes aspectos: conceitos inerentes ao objetivo do estudo

(programação da produção aplicada à indústria cárnea, além de qualidade de dados e de

informações); elementos identificados por meio da experiência relatada no estudo de caso na

Empresa Alfa; e as contribuições de experts na temática da pesquisa, conforme detalhado no

Capítulo 3 e no Apêndice C.

Inicialmente, identificam-se neste capítulo os pressupostos para o desenvolvimento do

método e as estratégias utilizadas para a elaboração do mesmo no sentido da atuação sobre a

melhoria da acuracidade de dados. Na segunda seção, foram detalhados os passos do método

tentativo, aos quais foram incorporadas as sugestões dos experts consultados. A terceira parte

do capítulo apresenta os Fatores Críticos de Sucesso (FCS) para a aplicação do método

proposto, os quais possuem uma abordagem do ponto de vista gerencial e da estrutura

necessária. Por fim, resgatam-se de forma sucinta na quarta seção os assuntos tratados no

capítulo.

5.1 Pressupostos e estratégias para o desenvolvimento do método e para a melhoria da

acuracidade de dados

O desenvolvimento do método proposto para a melhoria da acuracidade dos dados

passou pela definição de pressupostos e de estratégias para o mesmo. Os pressupostos

referem-se ao escopo do método em função das características do negócio da indústria cárnea

e ao papel dos dados no sistema de seqüenciamento da produção. Já as estratégias constituem-

110

se das ações no sentido da efetivação dos pressupostos, ou seja, dos elementos utilizados para

o desenvolvimento do método.

A Figura 22 apresenta o problema dos dados no caso pesquisado, no qual se visualiza

o fluxo de dados entre a realidade da empresa, as fontes primárias de armazenamento de

dados e o sistema de seqüenciamento da produção. Além disso, a figura delineia os pontos

onde o método proposto se insere.

FIGURA 22 – O fluxo dos dados e o foco do método

Na Figura 22, é possível verificar que os dados coletados na realidade da empresa são

inseridos em bases de dados e em templates, os quais, por sua vez, servem como um elo entre

a realidade o banco de dados do sistema. O método desenvolvido parte do pressuposto de que

os caminhos intermediários entre os locais onde os dados são originalmente gerados ou

coletados e os templates ou bases de dados corporativas não possuem problemas de

integração. Por isso, os templates e os sistemas corporativos serão considerados como as

próprias fontes primárias – logo, a identificação de erros dos dados importados para a base do

sistema de seqüenciamento da produção deverá basear-se nestas duas fontes.

111

No momento em que os dados de entrada necessários para a ferramenta de

programação da produção são inseridos nas bases corporativas ou nos templates, a transição

dos dados para o sistema é feita por meio de um processo de integração (importação). Neste

ponto, por mais que os dados estejam acurados, se houver problemas no referido processo o

banco do sistema de programação da produção não refletirá a realidade.

Entre os meios digitais nos quais os dados são armazenados (fontes primárias) e a

inserção dos mesmos no banco do sistema, reside o foco do método proposto neste estudo: a

acuracidade dos dados. Estes são importados para a base do sistema de programação da

produção, a partir do qual o seqüenciador gera planos de produção. Entre a realidade da

empresa e as informações geradas pelo sistema, pode existir uma discrepância, pois os planos

sugeridos talvez não sejam coerentes com a realidade. A partir disso, a acuracidade dos dados

é um dos pontos nos quais se podem realizar melhorias que tornarão a programação do

sistema mais próxima do mundo real – os outros seriam a integração de sistemas (do ponto de

vista do desenvolvimento das mesmas) e o algoritmo do seqüenciador, os quais não são

tratados neste trabalho.

As proposições feitas para o método foram desenvolvidas independentemente do

esforço tecnológico necessário para a implementação das mesmas. Em outras palavras, o

método não possui um viés tecnológico, pois o objetivo foi o de elaborar uma abordagem

estruturada para a acuracidade dos dados, sem detalhar a maneira pela qual as inteligências de

busca de erros de dados seriam construídas. Por outro lado, dentre os pressupostos

tecnológicos, parte-se do princípio de que os erros de importação dos dados para o sistema

possam ocorrer por apenas um motivo: erro no template (nos dados ou no nome do arquivo).

Quanto ao mecanismo de importação do sistema de seqüenciamento da produção, assume-se o

mesmo estaria livre de erros.

Outro pressuposto tecnológico diz respeito à existência de mecanismos de

identificação de erros de dados após a importação dos mesmos para o sistema (os chamados

logs). Estes se referem a mecanismos automáticos de verificação de erros de importação em

relação à estrutura do banco de dados. Baseado neste critério, os logs devem contemplar as

seguintes situações:

• nome do template não consta no schema banco de dados: a ação sugerida é verificar

se o arquivo do template foi nomeado corretamente;

112

• formato do arquivo do template incompatível com o banco. Exemplo: o template

foi importado em formato “.xls”, porém o banco de dados aceita somente “.csv”;

• formato dos dados incompatível com a base de dados: ocorre quando o formato de

um dado preenchido em um template diferir do formato especificado no banco de

dados para o referido atributo; e

• integridade referencial: contempla tanto o não preenchimento de um dado em um

campo obrigatório (chave) quanto erros no relacionamento entre entidades

Uma premissa inerente ao método é de que os dados errados, quando identificados,

sempre serão corrigidos adequadamente, não sendo possível que os mesmos percam a sua

acuracidade. Esta afirmação não possui relação com novos dados que forem inseridos ao

longo dos testes do método (um novo produto, por exemplo). Caso estes estiverem errados e

forem identificados, entrarão normalmente no fluxo, sendo também submetidos às validações

(checagens automáticas de identificação de erros e potenciais erros de dados).

Em todas as fases do método proposto, as validações serão sempre cumulativas,

sucedidas por testes de verificação da existência de erros. Se confirmados, os dados deverão

ser corrigidos na fonte primária, e uma nova carga do template que continha os erros deverá

ser feita.

No que diz respeito ao tratamento dos erros de dados, o foco do estudo estará atrelado,

na verdade, aos defeitos dos mesmos. Fazendo-se uma analogia com os conceitos de erro e de

defeito do Controle da Qualidade Zero Defeito (CQZD) proposto por Shingo (1996), defeito é

uma conseqüência do erro, o qual é a real causa geradora de problemas no processo produtivo.

Outra analogia possível entre erro e defeito é entre processo e produto, respectivamente.

Enquanto que o primeiro deve ser melhorado para que se previnam futuros problemas, o

segundo, caso não seja produzido adequadamente, gerará uma perda, não valendo à pena,

portanto, atuar corretivamente no processo. Portanto, o termo “erro” utilizado neste estudo

deverá ser considerado como defeito, dado que a melhoria da acuracidade dos dados não se

dará nos processos que os geram, de forma preventiva.

A ordem com que os dados devem ser tratados para que o sistema seja capaz de gerar

planos de produção coerentes com a realidade pode ser adotada por meio da consideração da

inter-relação entre os dados do sistema. A Figura 26 apresenta uma árvore de pré-requisitos de

Na linguagem de bancos de dados, entidades referem-se às tabelas que armazenam informações.

113

dados, a qual estabelece os relacionamentos entre os principais dados do sistema (aqueles que

mais influenciam na programação da produção).

A árvore apresentada na Figura 23 foi desenvolvida para se interpretar a necessidade

de o sistema de seqüenciamento da produção gerar uma programação coerente com a

realidade. Para que isso seja possível, 5 pré-requisitos devem ser atendidos: os pedidos devem

ser programados, e os estoques de produtos finais, as limitações de estocagens, as restrições

de produção e as necessidades de embalagens necessitam estar adequadamente populados na

base de dados. Independentemente das últimas 4 condições mencionadas, a programação de

pedidos pode ser gerada, desde que exista uma programação de abates. Neste ponto, a massa

gerada a partir da “desmontagem” dos animais é empurrada no sentido da geração dos

produtos finais e das matérias-primas (que serão utilizadas para a programação de

formulados), atendendo desta forma aos pedidos. Portanto, os abates são “puxados” pela

existência de pedidos e depois “empurrados” no sentido da programação dos produtos.

FIGURA 23 – Árvore de pré-requisitos de dados para a geração de uma programação coerente

114

A geração da programação de abates depende da existência concomitante dos

cadastros de estruturas de produto dos cortes (cada raiz representando uma faixa de peso

vivo), de curvas de peso e dos pedidos ou previsão de demanda. Os abates não

necessariamente dependem das árvores de formulação, pois a massa que é destinada para a

programação de matérias-primas pode ser utilizada para a produção de cortes vendáveis.

Logo, a programação de matérias-primas e as estruturas de produtos formulados não são pré-

requisitos para a programação de abates. Por outro lado, para que os pedidos sejam

programados, é necessário que estas condições estejam preenchidas.

Os pressupostos definidos nos parágrafos anteriores serviram de base para o

desenvolvimento da estratégia do método proposto, a qual é composta por 7 elementos:

• prevenção;

• parcimônia;

• nível de complexidade da modelagem dos dados;

• exposição dos dados;

• validações;

• medições (índices de controle e indicadores); e

• priorização das análises.

A prevenção refere-se ao estabelecimento dos requisitos dos dados que devem ser

populados na base do sistema, para que o preenchimento de templates e a integração de dados

com outros sistemas não contenham erros. Além disso, o desenvolvimento de logs que

indiquem a ocorrência de erros de importação de dados para a base do sistema de PCP

contribui para que a mesma não tenha dados faltantes.

O Princípio da Parcimônia, o qual sugere a simplicidade como critério para o estudo e

ação sobre um fenômeno, contribuiu para o desenvolvimento do método em relação à

seqüência de atividades do mesmo. Nas atividades de população da base de dados, deve-se

iniciar pelo processo de importação, validação e de correção de erros dos dados básicos para o

sistema (aqueles que são pré-requisito para os demais cadastros). Ao final disso, adota-se este

mesmo procedimento para os demais dados necessários para o sistema, obedecendo-se a

critérios de precedência e aos resultados verificados nas métricas. Esta estratégia facilita o

115

processo de identificação de erros, tendo em vista que os grupos de dados serão tratados aos

poucos, de forma incremental (inclusive testando-se fábrica por fábrica). Dentro do escopo da

parcimônia, ressalta-se a possibilidade de os testes do método serem realizados de forma

paralela, somente nos casos em que os passos de um subprocesso forem aplicados da mesma

maneira para diferentes fábricas. Apesar de, no fluxo, o início dos testes de uma unidade

depender da finalização de uma fábrica predecessora, nada impede que o paralelismo seja

adotado nestes casos.

O nível de complexidade (detalhamento) da modelagem de dados influencia no

volume necessário dos mesmos e também na manutenção dos dados. O método deve

corroborar para que se adote a simplicidade na modelagem das estruturas de produto e de

roteiros (redes de atividades), pois quanto mais detalhada for a modelagem, maiores serão as

chances de existirem dados errados (ou de os resultados não alcançarem as metas desejadas).

Outro aspecto relacionado ao nível de detalhamento da modelagem diz respeito à real

necessidade disso – talvez nem seja preciso construir estruturas volumosas, considerando-se o

trade-off benefício versus esforço de modelagem.

Os incrementos de modelagem, caso

necessário, devem ser feitos ao longo da aplicação do método, de forma que sejam alcançados

os resultados desejados.

A exposição dos dados possibilita simular situações anormais para que se forcem os

erros de dados, ou seja, para que os mesmos venham à tona mais facilmente. A população de

estoques fictícios de matérias-primas para que seja possível realizar rodadas no sistema com

produtos formulados é um exemplo desta estratégia.

Existem erros de dados cujo padrão de comportamento é passível de ser identificado

por meio de regras, as quais são as chamadas validações. Estes mecanismos de identificação

automática de erros devem ser rodados regularmente e sempre antes das rodadas do sistema,

pois desta forma se garante que os tipos de erros mapeados estarão corrigidos antes de o

sistema gerar os resultados. Com relação às validações, existe uma delimitação importante:

parte-se do pressuposto de que não serão criadas novas validações durante as atividades de

identificação e de correção de erros, pois as sugeridas deverão contemplar todas as situações

de erro.

A modelagem de recursos que não sejam gargalo ou CCRs é um exemplo desta estratégia, pois o esforço

necessário para coletar e manter estes dados no sistema não trará benefícios do ponto de vista dos resultados.

Outro exemplo é a modelagem dos produtos cujos volumes não são considerados no processo de PCP, que,

portanto, não precisam ser detalhados (pulmão e sangue, dentre outros).

116

As métricas são utilizadas para avaliar a acuracidade dos dados inseridos no sistema,

bem como os resultados das rodadas do seqüenciador. Em outras palavras, a existência de um

mecanismo de controle permite que se analise a qualidade das informações geradas pelo

sistema. Dois exemplos de itens de controle podem ser utilizados para uma melhor

compreensão do papel dos mesmos: um feito antes das rodadas e outro feito depois. O

primeiro exemplo refere-se à variabilidade dos tempos de processo dos recursos produtivos, a

qual é calculada utilizando-se o desvio-padrão. Neste caso, possibilita-se encontrar tempos

sub ou superestimados. O segundo exemplo diz respeito à programação de pedidos no prazo:

dependendo-se da acuracidade dos cadastros de estrutura de produto, o volume destinado para

o atendimento de pedidos (programado pelo sistema) poderá ficar abaixo da meta existente na

empresa.

Por fim, a sétima estratégia estabelece uma noção de priorização (Princípio de Pareto)

na análise dos índices de controle e dos indicadores – no caso de as metas não terem sido

atingidas, é necessário realizar um processo de verificação, no qual é possível identificar erros

de dados. Nesta avaliação, é necessário priorizar a análise, primeiramente, sobre os piores

resultados; em um segundo momento, devem ser analisadas as causas potenciais dos

problemas, sendo que as mais prováveis deverão ser testadas antes das menos prováveis. Esta

lógica contribuirá para a agilidade na busca pela melhoria dos resultados do sistema,

aproximando-o da realidade da empresa.

5.2 Método tentativo para a melhoria da acuracidade dos dados

Nesta seção, apresenta-se o método proposto para a melhoria da acuracidade de dados

de um sistema de seqüenciamento da produção desenvolvido para a indústria cárnea. Antes de

esta versão ter sido consolidada, uma proposta inicial (original) do método foi submetida à

avaliação de especialistas na temática do estudo. A partir da etapa de validação, parte das

críticas e contribuições feitas pelos experts à proposta foi incorporada à mesma, o que

resultou na elaboração da versão revisada do método. Os temas tratados na entrevista semi-

estruturada realizada junto aos especialistas constam no capítulo 3 (método). Já os

comentários dos mesmos quanto à proposta inicial constam no Apêndice C.

117

O método proposto foi estruturado por meio de processos e subprocessos, pois desta

maneira foi possível ordenar as atividades do mesmo de forma seqüencial (seguindo o

Princípio da Parcimônia). Considerou-se como processo um agrupamento de tarefas que,

juntas, representassem um marco para a aplicação do método. No caso do método proposto,

definiu-se que deveria existir três marcos: o da preparação dos dados, o da população e

melhoria da acuracidade dos dados e outro de homologação (Figura 24), os quais são

detalhados em seções distintas ao longo deste capítulo.

Um processo pode ser constituído por um conjunto de subprocessos, os quais

dependem da seguinte condição para existirem: entregar um “produto” ao final da execução

do subprocesso (exemplo: árvores de cortes validadas). Já o critério utilizado para a definição

do número de subprocessos considerou a existência de atividades cujas finalidades eram

similares (no caso do Processo 1), enquanto que, para o Processo 2, o critério foi o número de

variáveis que se desejava testar em etapas separadas (parcimônia).

Um subprocesso é constituído por atividades ou testes, as quais detalham os fluxos no

sentido da operacionalização dos subprocessos aos quais estejam vinculados. Esta

hierarquização da estrutura do método possibilitou que o nível de detalhamento do mesmo se

tornasse menos complexo, sendo possível o cumprimento dos objetivos de cada processo e

subprocesso por etapas.

FIGURA 24 – Processos do método proposto

O Processo de Homologação do sistema, apesar de fazer parte do método, não é

detalhado neste trabalho, tendo em vista que a proposta contempla apenas a etapa de projeto

da implementação do sistema de programação da produção pesquisado. Este processo está

definido dentro do escopo do método para que fosse possível compreender em que momento

o mesmo finalizava. Utiliza-se o termo homologação do sistema porque, dado que se parte do

pressuposto de que a qualidade do algoritmo fosse adequada, a homologação dos dados seria

concomitante com a do sistema.

118

Diante da apresentação dos processos do método e da explicação sobre a função dos

subprocessos, apresenta-se na Figura 25 uma visão geral da proposta e mais ampla em relação

à Figura 24. Verifica-se na Figura 25 que o Processo 1 possui 4 subprocessos, sendo que,

apenas ao final da execução do último, inicia-se o primeiro subprocesso do Processo 2.

FIGURA 25 – Subprocessos do método proposto

Os passos de cada subprocesso podem ser compostos por atividades e testes. Uma

atividade pode possuir três elementos distintos, sendo que cada qual possui uma função. São

eles: tarefas, validações e medições. As tarefas referem-se à descrição detalhada de uma

atividade, tais como a função da atividade e as ações que devem ser tomadas na mesma.

As validações são verificações feitas sobre os dados populados no banco do sistema de

programação da produção, nas quais se compara cada caso com as regras de negócio da

empresa. Caso uma situação não esteja de acordo com essas regras (ou possa representar um

problema, dependendo da situação), será gerada uma mensagem informando que o dado

verificado pode possuir problemas. É importante ressaltar que, no método proposto, parte-se

do pressuposto de que todas as validações são automáticas, ou seja, geradas pelo próprio

sistema de seqüenciamento da produção.

Uma validação pode ser classificada como erro ou alerta – o primeiro refere a uma

situação que vai de encontro às regras de negócio, sendo prejudicial para a qualidade das

119

informações que serão geradas pelo sistema. Já o segundo termo indica uma situação de risco

potencial, ou seja, não sem tem certeza se configura um erro, porém deve ser analisada para

que se confirme (ou não) um problema.

A terceira função possível de uma atividade (medições) divide-se em índices de

controle (ICs) e indicadores. O primeiro é utilizado para mensurar os dados de entrada

independentemente da realização de uma rodada do sistema. Os ICs podem ser calculados,

por exemplo, por meio de medidas tendência central (média) ou de dispersão (desvio-padrão),

sendo possível acompanhar a evolução dos mesmos (e das situações de erro) com o apoio de

gráficos de controle. Os ICs podem indicar erros e também contribuir para a identificação de

oportunidades de melhorias nos dados. Um exemplo disso é o cálculo do desvio padrão dos

tempos de processo, em kg/h, de um recurso. Se o desvio for maior que o limite máximo

aceitável, deverá ser verificado se existem erros. Caso um problema seja confirmado, a

análise do mesmo em uma estrutura de produto poderá contribuir para a melhoria de outros

dados da árvore.

O segundo tipo de medição proposto no método (indicadores) caracteriza-se pela

mensuração das informações geradas pelo sistema de programação da produção após as

rodadas do mesmo. Em outras palavras, os indicadores atuam sobre os resultados do sistema,

e não diretamente nos dados de entrada. A vantagem é que erros na informação gerada pelo

sistema poderão indicar problemas nos dados de entrada. De forma similar às validações e aos

ICs, quando as metas dos indicadores não forem atingidas, deverá ser feito um processo de

análise. Após isso, os dados errados deverão ser corrigidos, e as oportunidades de melhoria

identificadas deverão ser implementadas, ambos na fonte primária dos dados. Finaliza esta

etapa, as tabelas onde os dados foram editados devem ser novamente importadas para o

sistema.

Ambas as medições propostas (índices de controle e indicadores) deverão possuir uma

meta para que seja possível avaliar os resultados das mesmas. As metas poderão derivar-se de

resultados do histórico da empresa, ou então da realidade da organização (no caso em que a

medição tenha uma correspondente na realidade).

Após detalhar as três funções que uma atividade possui, retoma-se o outro elemento

que, ao lado das atividades, materializa os passos de cada subprocesso. Os testes possuem

uma função auxiliar, pois representam os nodos de decisão no fluxo, sendo graficamente

representados por losangos. Para fins de entendimento dos componentes do detalhamento dos

120

subprocessos dentro de uma hierarquia, sugere-se a visualização da Figura 26, na qual se

apresentam todos os elementos apresentados neste e nos parágrafos anteriores.

FIGURA 26 – Hierarquia dos componentes do fluxo dos subprocessos

Depois de contextualizados os componentes dos subprocessos, apresentam-se os

símbolos utilizados no desenvolvimento dos fluxos do método, cuja legenda pode ser

visualizada no Quadro 4.

Símbolo Nome Aplicação

Conector de

atividade ou

teste

Interliga todos os símbolos no processo, exceto

na ligação das fontes externas ao fluxo (bases

de dados e documentos), a qual é simbolizada

por uma seta tracejada.

Conector

interno

Possui a mesma função de um conector de

atividade ou teste, com a diferença que serve

para interligar atividades cuja distância entre

as mesmas faça com que o conector de

atividade ou teste não seja recomendável. O

interior do conector é preenchido apenas por

letras, sendo que as mesmas não se repetem

para duas ou mais referências.

Conector de

processo

É utilizado para simbolizar a conexão entre dois

subprocessos. Quando um conector de

atividade ou teste sair de um conector de

processo, significa que este representa um

subprocesso anterior. Por outro lado, quando

um conector de atividade ou teste chegar a

um conector de processo, este representa o

próximo subprocesso.

121

Atividade É utilizado para designar as atividades do fluxo.

Teste É utilizado para designar os testes do fluxo.

Conector de

página

É utilizado para sinalizar a continuação de um

subprocesso em outra página. A numeração

utilizada será a da página deste estudo na

qual o subprocesso tem continuidade.

Conector de

fontes

externas

É utilizado para a ligação das fontes externas

(bases de dados ou documentos) às atividades

ou testes.

'DGRV

Base de

dados

Refere-se a bancos de dados ou meios

impressos de onde são importados ou

coletados, respectivamente, os dados

utilizados nos testes.

Documento

Refere-se a qualquer informação impressa em

formato de texto ou um relatório proveniente

do sistema de programação da produção.

Obs.: os meios impressos que possuírem dados

que serão coletados para o sistema de

programação da produção não fazem parte

desta definição.

Ferramenta

de sistema

Refere-se a qualquer mecanismo ou

ferramenta desenvolvida com recursos de

tecnologia da informação.

QUADRO 4 – Legenda dos componentes dos fluxos do método

Como pôde ser visualizado no Quadro 4, foram atribuídos para as atividades e testes

códigos identificadores, os quais serão úteis na descrição dos subprocessos. A referida

identificação utiliza uma codificação padrão, a qual é dividida em 6 caracteres, conforme

visualiza-se na Figura AA.

122

FIGURA 27 – Codificação padrão das atividades e testes dos subprocessos do método proposto

A partir da compreensão de todas as informações relatadas até o momento nesta seção,

faz-se necessário abordar a estrutura e o conteúdo dos subprocessos. Nas próximas seções do

capítulo, detalham-se os fluxos e descrevem-se brevemente as atividades e testes dos mesmos.

O detalhamento fino dos componentes dos subprocessos é apresentado do Apêndice D1 até o

Apêndice D19.

5.2.1 Processo 1 – Preparação de dados

No Processo 1, predominam atividades e testes preparatórios para a utilização dos

dados no sistema de programação da produção. Nesta fase, definem-se inicialmente o modelo

conceitual e os requisitos dos dados. Posteriormente, no Subprocesso 1.2, verifica-se a

disponibilidade e coletam-se os dados necessários para o sistema no ambiente da empresa e

estruturam-se as integrações entre sistemas e os templates. No Subprocesso 1.3, são definidas

as auto-validações que deverão ser geradas automaticamente pelo sistema. Ao final, no

Subprocesso 1.4, detalham-se os testes de integração de sistemas e de importação de dados.

5.2.1.1 Subprocesso 1.1 – Especificação de dados

O objetivo do Subprocesso 1.1 é especificar os dados necessários para o sistema de

programação da produção. Na Figura 28, visualiza-se o fluxograma desta fase do método

proposto. A primeira atividade refere-se à definição do modelo conceitual para os dados

123

(P1S1A1), a qual trata de aspectos como o nível de detalhamento desejado dos dados, tanto do

ponto de vista do horizonte de programação quanto da modelagem de estruturas de produto.

Posteriormente, a outra atividade do Subprocesso (P1S1A2) identifica os dados necessários

para o sistema, bem como as condições para a utilização dos mesmos, como formato e

freqüência de atualizações (de hora em hora, diária, dentre outras).

FIGURA 28 – Fluxograma do Subprocesso 1.1

5.2.1.2 Subprocesso 1.2 – Estruturação de dados

O Subprocesso 1.2 caracteriza-se pelo mapeamento e seleção dos dados necessários no

ambiente corporativo, bem como pela preparação dos mesmos para as integrações entre

sistemas ou nos templates. A partir da definição dos requisitos de dados realizada na fase

anterior, o Subprocesso 1.2 inicia-se, conforme a Figura 29, pela verificação se todos os dados

necessários para o sistema existem na empresa (teste P1S2T1), seja em meio digital ou

impresso. Se a resposta for “Sim”, deve-se verificar se os dados estão disponíveis em bases de

dados corporativas (P1S2T3). Considera-se como tal um banco que atenda às seguintes

condições:

• o dado requerido é armazenado de forma centralizada, ou seja, não existem outros

sistemas paralelos;

• o banco deve fazer parte da estrutura de Sistemas de Gerenciamento de Bancos de

Dados (SGBD) da empresa

• o banco deve ser regularmente atualizado; e

124

• o banco possibilita a exportação de cargas de dados para o sistema de PCP, sem a

necessidade de prepará-los manualmente antes de importá-los.

Com base nestes critérios, portanto, não são consideradas como bases de dados

corporativas quaisquer aplicações independentes e descentralizadas (também chamadas de

sistemas com banco de dados embarcado). Os bancos de dados desenvolvidos para usuários

domésticos são exemplos das referidas bases.

Caso os dados necessários estejam disponíveis em bases de dados corporativas, os

mesmos devem ser ajustados nos arquivos das cargas que serão importadas diretamente para o

sistema de programação da produção (P1S2A4). Nesta atividade, verificam-se questões

relacionadas ao formato dos dados e a unidades de medida (número, texto, quilo, tonelada,

dentre outros). Com isso, verifica-se a necessidade de se fazer uma conversão dos dados antes

de os mesmos serem importados para a base do sistema. Se, no teste anterior à atividade

P1S2A4, os dados existirem na empresa, porém não estiverem disponíveis em bases de dados

corporativas, deve-se verificar a possibilidade de os dados serem cadastrados em algum

sistema (P1S2T4). Se isso for possível, os dados deverão ser cadastrados (P1S2A5) e

posteriormente ajustados nos arquivos de integração com o sistema de programação da

produção (P1S2A4). Caso contrário, deverão ser preenchidos templates com os dados

disponíveis (P1S2A3).

Retornando-se ao teste P1S2T1, se houver dados que inexistam na empresa, deve-se

verificar se será possível obtê-los (teste P1S2T2). Caso isso não puder ser feito, será

necessário providenciar alterações no escopo do sistema (P1S2A1), o que refletirá na

reavaliação dos requisitos de dados. Por outro lado, caso seja possível obter os dados

faltantes, deverá ser feito um processo de coleta de dados (P1S2A2). Após esta atividade,

deve-se verificar se existe a possibilidade de os dados serem armazenados em sistemas

corporativos. Se a resposta for “Sim”, deverá ser feito um processo de cadastro dos dados em

uma base (P1S2A5), o qual será sucedido pelo ajuste dos dados nos arquivos de integração de

sistemas (P1S2A4). Caso contrário, deverão ser preenchidos templates com os dados

coletados (P1S2A3).

Uma observação se faz necessária em relação ao terceiro teste do Subprocesso 1.2

(P1S2T3) caso a resposta ao mesmo seja “Sim”. O método proposto não entrará no mérito dos

critérios de escolha de uma fonte de dados caso existirem mais de duas para um mesmo

atributo.

125

FIGURA 29 – Fluxograma do Subprocesso 1.2

5.2.1.3 Subprocesso 1.3 – Auto-validação de dados

No Subprocesso 1.3, após o mapeamento, seleção e obtenção dos dados necessários

para o sistema de programação da produção, especificam-se as rotinas automáticas de

validação dos dados, as quais contemplam os seguintes itens:

• mecanismos de identificação de erros na importação dos dados para o sistema;

• validações dos dados quanto às regras de negócio da empresa; e

• índices de controle e indicadores para a mensuração dos dados de entrada e dos

resultados do sistema, respectivamente.

126

FIGURA 30 – Fluxograma do Subprocesso 1.3

Os três componentes do Subprocesso 1.3 estão representados em atividades distintas

no fluxograma do mesmo, conforme a Figura 30. Além disso, cada atividade gera um

“produto” ao final da execução da mesma, o qual será utilizado como entrada para a execução

de atividades no Subprocesso 1.4 e no decorrer das etapas do Processo 2. Devido à

importância dos indicadores como sinalizadores dos resultados do sistema de programação da

produção, apresenta-se no Quadro 5 a relação destas medições.

127

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Programação de

pedidos fictícios (global)

Permite verificar se os dados populados até

esta etapa possuem uma acuracidade que

garanta a programação dos pedidos.

Soma dos pedidos programados,

em kg, dividida pelo total de

pedidos, em kg.

Sugere-se

acompanhar a

evolução do

indicador a cada

rodada por meio

de um gráfico.

Programação de

pedidos (global)

Permite verificar se os dados populados até

esta etapa possuem uma acuracidade que

garanta a programação dos pedidos.

Soma de pedidos programados,

em kg, dividida pelo total de

pedidos residuais

, em kg.

Referem-

se aos pedidos cuja data

de embarque seja menor ou igual

à última data do horizonte de

programação do sistema.

Sugere-se

acompanhar a

evolução do

indicador a cada

rodada por meio

de um gráfico.

Programação de

demanda líquida

(global)

Refere-se à soma das

diferenças entre a

demanda total e os

pedidos, em kg, de cada

produto.

Permite verificar se os dados populados até

esta etapa possuem uma acuracidade que

garanta a programação da demanda

líquida. A análise decorrente deste indicador

possibilita uma análise por produto, já que o

indicador nº 2 mensura a programação de

pedidos.

Soma da alocação para

demanda, em kg, dividida pelo

total de demanda líquida, em kg.

Idem ao indicador

nº 2.

Aderência da

programação (global

por fábrica)

Contribui para a comparação dos volumes

programados pelo sistema em relação à

projeção de produção. A partir dos

resultados, é possível também avaliar a

acuracidade dos dados de pedidos e de

previsão de demanda.

[1 - (soma dos desvios absolutos do

programado pelo sistema em

relação à projeção de produção,

em kg)] dividido pelo total

projetado, em kg, por fábrica.

Idem ao indicador

nº 2.

Aderência da

programação (por

fábrica e família de

produto)

Idem ao indicador nº 4, com a diferença que

permite visualizar a aderência para cada

família de produto, facilitando o processo de

identificação de erros de dados.

Idem ao indicador nº 4, porém

discriminado por família de

produto.

Idem ao indicador

nº 2.

128

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Projeção de

consumo versus

necessidade de MPs

Este indicador permite

identificar 2 tipos de

problemas: (1) erros nos

pedidos ou demandas; e

(2) erros nas árvores.

[1 - (Soma dos desvios absolutos entre o volume total de

consumo projetado, em kg, de cada MP e o volume total

necessário

da MP, em kg) dividida pelo total do consumo

projetado].

É o percentual da MP sobre o produto final vezes o total

de pedidos e demanda líquida do produto final.

Idem ao indicador

nº 2.

Projeção de

consumo versus

necessidade de

suprimentos

A quantidade necessária

de suprimentos influencia

nas compras e projeções

de consumo dos

mesmos,

bem como no

aprazamento de

pedidos.

[1 - (Soma dos desvios absolutos entre a projeção de

consumo de cada suprimento e a necessidade

material) dividida pelo total do consumo projetado].

É o percentual do ingrediente sobre o produto final vezes

a programação do produto que utiliza o condimento mais

a quantidade de embalagem na estrutura vezes a

programação do produto utiliza este material.

Sugere-se

acompanhar a

evolução do

indicador a cada

rodada por meio

de um gráfico.

Ocupação média de

estoques

As limitações de estoques

influenciam na

programação da

produção.

Média da programação de estoques, em número de

pallets

, dividida pela capacidade real de estoque, em

número de pallets.

Programação de estoques de cada produto, em kg,

dividida pelo peso do pallet de cada produto.

Sugere-se

acompanhar a

evolução do

indicador a cada

rodada por meio

de um gráfico.

Pedidos

programados no

prazo

Permite verificar se os

dados populados até

esta etapa possuem uma

acuracidade que

garanta a programação

dos pedidos no prazo.

Soma de pedidos programados no prazo, em kg, dividida

pelo total de pedidos residuais

, em kg.

Referem-se aos pedidos cuja data de embarque seja

menor ou igual à última data do horizonte de

programação do sistema.

Sugere-se

acompanhar a

evolução do

indicador a cada

rodada por meio

de um gráfico.

129

Aderência de abates

por tipo de animal

(global, abate

empurrado e

puxado)

Avaliar a coerência do

volume programado de

abate.

Volume total programado de abates, em kg, dividido pelo

volume projetado de abates, em kg, por tipo de animal

(frango, peru, suíno, dentre outros).

Sugere-se

acompanhar a

evolução do

indicador a cada

rodada por meio

de um gráfico. O

indicador deve ser

analisado

conjuntamente

com o de nº 11.

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Rendimento de

cortes por tipo de

animal (global)

Avaliar a coerência do volume

programado de cortes em relação

ao volume abatido.

Volume total programado de cortes, em kg,

dividido pelo volume programado de abates, em

kg, por tipo de animal (frango, peru, suíno, dentre

outros).

Sugere-se

acompanhar a

evolução a cada

rodada por meio

de um gráfico.

Volume de resíduos

(global)

rodutos finais que

não são estocáveis

Possibilita a identificação de erros no

atributo de estocagem de um

produto. O resultado deve ser

sempre zero, salvo se o produto for

realmente um resíduo.

Volume total programado de cortes, em kg,

menos o total programado de produtos

estocáveis, em kg.

Sugere-se

acompanhar a

evolução do

indicador a cada

rodada por meio

de um gráfico.

Aderência de

abate empurrado

(global, por tipo de

animal)

Permite avaliar a programação da

escala de abate global, a qual

influencia na programação no início

do horizonte.

Número de animais programados no período do

abate empurrado dividido pelo número de

animais da escala de abate, por tipo de animal.

Idem ao indicador

12.

Aderência de

abate empurrado

(por fábrica e tipo

de animal)

Idem ao indicador 13, porém permite

avaliar a programação para cada

fábrica.

Idem ao indicador 13, porém por fábrica e tipo de

animal.

Idem ao indicador

12.

130

Aderência de

abate puxado

(global, por tipo de

animal)

Permite avaliar a programação de

abate sugerida pelo sistema, a qual

influencia na programação do final

do período do abate empurrado até

o último dia do horizonte.

Número de animais programados no período do

abate puxado dividido pelo número de animais

da projetados para o mesmo período, por tipo de

animal.

Idem ao indicador

12.

Aderência de

abate puxado (por

fábrica e tipo de

animal)

Idem ao indicador 15, porém permite

avaliar a programação para cada

fábrica.

Idem ao indicador 15, porém por fábrica e tipo de

animal.

Idem ao indicador

12.

Alocação versus

necessidade de

MPs

Este indicador permite identificar 2

tipos de problemas: (1) erros nos

pedidos ou demandas; e (2) erros

nas árvores.

[1 - (Soma dos desvios absolutos entre o volume

total, em kg, de cada MP consumida em

formulação e o volume total necessário

da MP,

em kg) dividido pelo total consumido]

É o percentual da MP sobre o produto final vezes

o total de pedidos e demanda líquida do produto

final.

Sugere-se

acompanhar o

indicador a cada

rodada e

juntamente com o

indicador nº 7.

Aderência da

programação de

produção (global)

Permite avaliar a programação de

produção global.

[1 - (Soma dos desvios absolutos do programado

pelo sistema em relação à projeção de

produção, em kg) dividida pelo total projetado,

em kg]

Sugere-se o

acompanhamento

do indicador a

cada rodada.

QUADRO 5 – Indicadores do método proposto

131

5.2.1.4 Subprocesso 1.4 – Testes de importação de dados

A última etapa do Processo 1 caracteriza-se pela realização de testes de importação

dos dados preenchidos em templates ou dos ajustados nas cargas automáticas de integração

entre sistemas. Na Figura 31, verifica-se que a atividade P1S4A1 é marcada pelo teste de

integração, sendo apoiada pelos logs de erros de importação criados no Subprocesso 1.3.

FIGURA 31 – Fluxograma do Subprocesso 1.4

Posteriormente, realiza-se o teste P1S4T1, o qual verifica se houve problemas no

processo. Se houver, as correções necessárias deverão ser feitas, retornando-se novamente ao

teste inicial. Caso contrário, excluem-se todos os dados do sistema (P1S4A6) para que se

132

encaminhe ao Subprocesso 2.1, desde que os testes com os templates também tenham sido

realizados satisfatoriamente.

Nos testes de importação dos templates, são realizadas atividades similares e feitos os

mesmos testes em relação à integração de sistemas. Caso ocorram problemas neste processo,

o que é verificado no teste P1S4T2, deve-se corrigir o problema. Senão, encaminha-se para a

exclusão dos dados da base do sistema, a fim de que se possa iniciar o Subprocesso 2.1.

5.2.2 Processo 2 – População e melhoria da acuracidade de dados

Ao final do primeiro processo, o Processo 2 estabelece os passos para a carga e a

melhoria da acuracidade dos dados no sistema de programação da produção. O objetivo desta

etapa é o de efetivar os elementos definidos no Processo 1 para que as informações geradas

pelo sistema de PCP reflitam a realidade da empresa, o que será avaliado com o apoio de

medições.

Adotou-se para o desenvolvimento dos passos do Processo 2 o Princípio da

Parcimônia, o qual sugere a simplicidade como critério para o estudo e a ação sobre um

fenômeno. O desdobramento deste princípio na estruturação dos subprocessos foi efetivado

por meio do estabelecimento de uma seqüencia de testes ao longo dos quais são

incrementados novos dados e realizadas novas verificações. Isso contribui para a redução da

complexidade das análises caso todos os dados fossem populados de uma vez só no sistema.

Com isso, expõem-se possíveis erros e possibilita-se mais facilidade na identificação e

solução de problemas, a qual é também apoiada pelos logs, validações e métricas automáticos

definidos no Processo 1.

A maioria dos subprocessos, conforme será possível verificar no detalhamento, utiliza

os mesmos passos para que o objetivo do Processo 2 seja atingido. A ordem em que essas

etapas são aplicadas no método, bem como a descrição das mesmas, é elencada abaixo:

• preenchimento de templates: os dados populados em cada subprocesso são

importados mediante a utilização de templates;

• importações dos dados para o sistema: no fluxo do método, a ordem em que o

preenchimento dos templates aparece (da esquerda para a direita) deve ser seguida,

133

pois se obedece a critérios de precedência entre os dados. Dessa forma, previne-se

parte dos erros de integridade referencial;

• verificação de erros na importação (teste) e correção dos mesmos, caso forem

identificados: após a importação dos templates, devem-se gerar os mecanismos de

identificação de erros (logs) especificados no Processo 1;

• validação dos dados inseridos no banco do sistema: em todos os subprocessos, a

validação possui o mesmo nome para a atividade (“Validar os dados do banco”),

pois não se trata de atividades diferentes – todas as validações das regras de

negócio são aplicadas do início ao final do método;

• verificação de erros de validação (teste) e correção dos mesmos, caso forem

identificados: após a geração das validações, deve-se verificar se existem situações

de erros de dados, as quais deverão ser automaticamente comunicadas por meio de

mensagens de erro ou alerta;

• geração de índices de controle: em todos os subprocessos, a validação possui o

mesmo nome para a atividade (“Gerar os índices de controle”). Diferentemente das

validações, nem todos os ICs deverão ser gerados em todos os subprocessos. A

indicação de quais índices deverão ser utilizados está detalhada do Apêndice D5 ao

D19;

• verificação da conformidade dos resultados dos ICs em relação às metas (teste) e

correção dos mesmos, caso necessário: após gerar os índices de controle, deve-se

verificar se as metas foram alcançadas. Se não foram, deve-se identificar e corrigir

os erros de dados;

• rodada do sistema: corresponde ao processo de geração de resultados pela

ferramenta de programação de produção;

• geração dos indicadores: idem aos índices de controle, com a diferença que são

gerados sempre após as rodadas do sistema; e

• verificação da conformidade dos resultados dos indicadores em relação às metas

(teste) e correção dos mesmos, caso necessário: idem aos índices de controle.

Dentre os pontos dos fluxos nos quais será possível identificar erros, existem 4 que

contribuem para isso e são comuns à maioria dos subprocessos: a verificação dos erros de

importação, a validação dos dados e a geração de índices de controle e de indicadores.

134

Existem ainda outros testes específicos para determinados subprocessos, como o cálculo da

disponibilidade dos recursos.

O Quadro 5 apresenta os subprocessos do Processo 2, por meio do qual se visualiza a

utilização dos principais parâmetros ao longo dos subprocessos, além dos objetivos de cada

etapa. Verifica-se que, no referido quadro, existem 7 parâmetros para os testes dos

subprocessos. O primeiro deles (árvores) diz respeito à escolha, dentre os dois tipos de

produtos cárneos (cortes e formulados), da estrutura que será submetida ao método. Já o

termo “Fábricas” refere-se à opção de testar as fábricas separadamente ou todas juntas. O

parâmetro “Abates” engloba as escalas, as curvas de peso e os limites mínimos e máximos de

abates. Os roteiros contemplam a inclusão de recursos, calendários e tempos de processo nos

testes. Os suprimentos contemplam o uso dos lead times e lotes mínimos de ressuprimento, as

compras de embalagens e ingredientes, os estoques iniciais e as estruturas de embalagens

(necessidades por produto). Os estoques iniciais englobam a consideração de todos os

produtos da empresa que estejam armazenados, seja nas fábricas ou em poder de terceiros.

Por fim, os limites de estocagens dizem respeito ao uso das capacidades reais de estoques nos

testes.

No Quadro 5 é também possível verificar que, após o tratamento dos dados cadastrais,

inicia-se uma seqüência de testes com produtos formulados, apenas. Em um segundo

momento, são testados somente os cortes e, ao final, ambas as estruturas de produto são

submetidas simultaneamente a validações, métricas, testes e análises. A opção pela realização

dos testes das árvores de formulados antes dos cortes não é uma condição necessária – os

cortes poderiam ser testados primeiramente. Outra observação se faz necessária: nada impede

que os subprocessos nos quais os testes são feitos por fábrica (separadamente), todas sejam

testadas simultaneamente, desde que exista uma estrutura apropriada para tanto (sistemas e

pessoas dedicadas para cada fábrica).

135

Nº Nome do Subprocesso

Árvore

Fábricas

Abates

Pedidos

Roteiros

Supri-

mentos

Estoques

iniciais

Limites de

estocagens

Objetivos

2.1

Dados cadastrais e

estoques

- - - - - - - -

Garantir que os dados considerados

básicos para a estruturação dos demais

dados no sistema estejam populados e

livres de erros.

2.2

Pedidos fictícios de

formulados

Formu-

lações

Por

fábrica

- Fictícios

Não Não Não Não

Verificar se as estruturas dos produtos de

cada fábrica testada possuem uma

acuracidade mínima que possibilite a

programação de pelo menos um volume

irrisório de produção.

2.3

Capacidades finitas

de formulados

Formu-

lações

Por

fábrica

- Reais Sim Não Sim Não

Verificar se os roteiros de cada fábrica

testada possuem uma acuracidade que

possibilite a programação dos pedidos e

demandas reais.

2.4

Suprimentos de

formulados

Formu-

lações

Por

fábrica

- Reais Sim Sim Sim Não

Verificar se os suprimentos de cada fábrica

testada possuem uma acuracidade que

possibilite a programação dos pedidos e

demandas reais.

2.5

Capacidades reais de

estoques (teste

formulados)

Formu-

lações

Por

fábrica

- Reais Sim Sim Sim Sim

Verificar o impacto da inclusão das

capacidades reais de estoques na

programação da produção e na projeção

de estoques futuros, validando também os

dados de transportes entre unidades.

2.6 Formulados global

Formu-

lações

Todas

juntas

- Reais Sim Sim Sim Sim

Verificar a programação de produtos que

possam ser produzidos em mais de uma

fábrica.

2.7

Pedidos fictícios de

cortes

Cortes

Por

fábrica

Não Fictícios

Não Não Não Não

Verificar se as estruturas dos produtos de

cada fábrica testada possuem uma

acuracidade mínima que possibilite a

programação de pelo menos um volume

irrisório de produção.

2.8

Capacidades finitas

de cortes

Cortes

Por

fábrica

Sim Reais Sim Não Sim Não

Verificar se os roteiros de cada fábrica

testada possuem uma acuracidade que

possibilite a programação dos pedidos e

136

demandas reais.

2.9 Suprimentos de cortes Cortes

Por

fábrica

Sim Reais Sim Sim Sim Não

Verificar se os suprimentos de cada fábrica

testada possuem uma acuracidade que

possibilite a programação dos pedidos e

demandas reais.

2.10

Cortes global Cortes

Todas

juntas

Sim Reais Sim Sim Sim Não

Verificar a programação de produtos que

possam ser produzidos em mais de uma

fábrica.

Nº

Nome do

Subprocesso

Árvore

Fábricas

Abates

Pedidos

Roteiros

Supri-

mentos

Estoques

iniciais

Limites de

estocagens

Objetivos

2.11

Balanceamento

entre cortes e

formulados (sem

abates)

Ambas

Todas

juntas

Não Reais Não Não Sim Não

Avaliar a programação de cortes

concomitantemente com a de

formulados, sem qualquer

restrição, e verificar o

balanceamento entre as

necessidades de carne para

produto final e para MP.

2.12

Balanceamento

entre cortes e

formulados (com

abates)

Ambas

Todas

juntas

Sim Reais Não Não Sim Não

Avaliar a programação de cortes

concomitantemente com a de

formulados, com a introdução dos

abates, e verificar o

balanceamento entre as

necessidades de carne para

produto final e para MP.

2.13

Capacidades finitas

de cortes e

formulados

Ambas

Todas

juntas

Sim Reais Sim Não Sim Não

Avaliar a programação de cortes

concomitantemente com a de

formulados, com a introdução dos

roteiros, e verificar o

balanceamento entre as

necessidades de carne para

produto final e para MP.

137

2.14

Suprimentos de

cortes e formulados

Ambas

Todas

juntas

Sim Reais Sim Sim Sim Não

Avaliar a programação de cortes

concomitantemente com a de

formulados, com a introdução dos

suprimentos, e verificar o

balanceamento entre as

necessidades de carne para

produto final e para MP.

2.15

Cortes e formulados

global

Ambas

Todas

juntas

Sim Reais Sim Sim Sim Sim

Avaliar a programação de cortes

concomitantemente com a de

formulados, com a introdução das

capacidades reais de estoques, e

verificar o balanceamento entre

as necessidades de carne para

produto final e para MP.

QUADRO 6 – Parâmetros e objetivos dos subprocessos do Processo 2

138

5.2.2.1 Subprocesso 2.1 – Dados cadastrais e estoques de produtos

O Subprocesso 2.1 caracteriza-se pela primeira população de dados no sistema. Os

dados cadastrais são aqueles utilizados para a modelagem de estruturas de produto, por

exemplo. Ou seja, são básicos para o sistema, sendo que parte deles independe de outros

dados para que sejam populados. São exemplos destes dados as seguintes entidades: países

(código e descrição), produtos (código, descrição e atributos), clientes (código e descrição),

permissão de produção de um produto para as fábricas (código do produto e código da

fábrica) e permissão dos SIFs para os países (código do SIF e código do país).

O objetivo do Subprocesso 2.1 é o de garantir que os dados considerados básicos para

a estruturação dos demais dados no sistema estejam populados e livres de erros. Na Figura 32,

verifica-se que as atividades do Subprocesso 2.1 têm início somente após a conclusão do

subprocesso anterior (1.5). Logo após, importam-se as cargas de dados (atividades P2S1A1,

P2S1A2 e P2S1A3). Posteriormente, realiza-se o primeiro teste (P2S1T1), o qual verifica a

existência de erros na importação dos dados e apóia-se na geração automática de logs caso

existam inconsistências. Abaixo são relacionados exemplos de mensagens de erro para cada

tipo de problema que pode ser identificado neste passo:

• nome do template não consta no banco de dados: o nome do template do cadastro

de países foi preenchido de forma errada;

• formato do arquivo do template incompatível com o banco: o template das

habilitações de SIF por país foi importado em formato “.xls”, porém o banco de

dados aceita somente “.csv”;

• formato dos dados incompatível com a base de dados: a coluna “tempo” do

template de tempos de transferências entre unidades foi preenchida por números

decimais, porém o banco não reconhece este tipo de formato para o referido campo;

• integridade referencial: na carga das permissões de transferência entre unidades,

havia uma unidade inexistente no cadastro de unidades.

139

6XESURFHVVR

,PSRUWDURV

GDGRVFDGDVWUDLV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

9DOLGDURVGDGRVGREDQFR

3 6 $

&RUULJLURVGDGRV

3 6 $

*HUDURVtQGLFHVGHFRQWUROH

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

+RXYHHUURVQDV

LPSRUWDo}HV"

3 6 7

([LVWHPHUURV

GHGDGRV "

6XESURFHVVR

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

([FOXLURVHVWRTXHV

GHSURGXWRV

3 6 $

,PSRUWDURVHVWRTXHV

GHSURGXWRV

3 6 $

,PSRUWDUDVFDSDFLGDGHV

UHDLVGHHVWRTXHV

3 6 $

([FOXLUDVFDSDFLGDGHV

UHDLVGHHVWRTXHV

3 6 $

'DGRV

/RJVGH

HUURV

9DOLGDo}HV

,&V

FIGURA 32 – Fluxograma do Subprocesso 2.1

Se houver erros neste ponto do subprocesso, é necessário que se corrijam os dados na

fonte primária (P2S1A4) e se faça uma nova carga dos templates que continham os erros; caso

140

contrário, prossegue-se para a validação dos dados (P2S1A5), cuja finalidade é submeter os

dados populados na base às regras de negócio da empresa. Abaixo são listados dois exemplos

de validações características desta etapa:

• produto apresenta prazo de validade zerado: esta situação representa um erro, pois

todo produto cárneo é perecível; e

• fábrica não possui permissão de transferência de produtos: toda fábrica deve

transferir produtos para outras unidades, armazéns ou pontos de embarque.

O teste P2S1T2 verifica, após a rodada das validações, a existência de dados que não

estejam de acordo com as regras de negócio. Se houver erros, os mesmos deverão ser

corrigidos na fonte primária (P2S1A6), sendo necessária uma nova importação do template

que armazena o dado. Caso contrário, prossegue-se para a geração dos índices de controle

(P2S1A7). Os ICs do Subprocesso 2.1 mensuram o número médio e a variabilidade dos

prazos de validade por tipo de produto (MPs resfriadas e congeladas, e produtos finais

resfriados e congelados), a consistência entre os pesos dos pallets e o estoque de produtos, e

os limites mínimos e máximos dos tempos de transferência entre unidades. No caso das MPs,

o número de dias de validade impacta na programação de produtos formulados, enquanto que,

no caso dos produtos finais, este dado influencia na entrega dos pedidos, tendo em vista que

os clientes podem exigir produtos com determinado tempo de vida útil transcorrido.

Após a comparação dos resultados das métricas em relação às metas estabelecidas

(P2S1T3), caso estas não sejam atendidas, devem-se identificar os erros e corrigi-los na fonte

primária (P2S1A8). Por outro lado, se as metas forem atingidas, devem-se excluir os dados de

estoques e capacidades reais de estoques de produtos (P2S1A9 e P2S1A10, respectivamente)

e prosseguir-se para o Subprocesso 2.2.

5.2.2.2 Subprocesso 2.2 – Pedidos fictícios de formulados

Após finalizar o Subprocesso 2.1, iniciam-se os testes com as estruturas de produtos

formulados sem os roteiros produtivos, submetendo uma fábrica de cada vez. Nesta etapa, não

são consideradas as limitações de suprimentos nem a capacidade de estocagem e a

disponibilidade de MP. Além disso, Subprocesso 2.2 tem como premissa a geração de pedidos

fictícios (de 1 kg) para todos os produtos que possuam árvore de formulação cadastrada na

fábrica onde o teste será realizado. A opção pela utilização de pedidos fictícios partiu da

141

necessidade de se testar todos os produtos de uma unidade produtiva, já que, se fossem

colocados os pedidos e previsões de demanda “reais” desde o início, não seria possível testar

todos os produtos (considerando-se que talvez nem todos os produtos da fábrica possuam

pedidos ou previsão na realidade).

O objetivo do Subprocesso 2.2 é verificar se as estruturas dos produtos de cada fábrica

testada possuem uma acuracidade mínima que possibilite a programação de pelo menos um

volume irrisório de produção. Com isso, garante-se que os “caminhos” das árvores estão

corretamente cadastrados e também habilitados na fábrica em análise.

Para que a programação dos pedidos fictícios seja forçadamente feita em cada fábrica,

o estoque inicial de produtos não é carregado, caso contrário o sistema utilizaria o mesmo

para o atendimento dos pedidos. Outro aspecto importante neste subprocesso, como também

nos demais que testam fábrica por fábrica, é que se isolam as unidades produtivas, evitando-se

que, caso o teste fosse feito com todas as plantas simultaneamente, uma fábrica programasse o

produto do pedido e acabasse escondendo erros de dados de outras.

A importação dos estoques fictícios de MPs contribui para que a disponibilidade de

matérias-primas não seja um fator limitante para a programação dos produtos formulados.

Esta estratégia foi adotada porque as árvores de cortes e as compras de MPs de terceiros, que

são as fontes fornecedoras de MP no mundo real, não foram populadas neste subprocesso. De

forma parecida com os estoques fictícios de MPs, o cadastro de capacidades elevadas de

armazenagem e dos lead times e lotes mínimos de ressuprimento zerados objetivam fazer com

que estes fatores não limitem a programação de produção. No caso dos suprimentos, mesmo

que as necessidades de embalagens para cada quilo de produto não tenham sido importadas,

os ingredientes estão presentes nas árvores, por fazerem parte da massa do produto final.

Logo, para que os mesmos não impossibilitassem a programação dos pedidos, zeraram-se os

tempos e lotes de ressuprimento.

A Figura 33 apresenta o fluxograma do Subprocesso 2.2, o qual se inicia pelo

preenchimento dos 5 templates dos dados mencionados nos parágrafos anteriores, além dos

dados cadastrais (atividades P2S2A1 até P2S2A6). É importante ressaltar que os dados

cadastrais deverão ser importados em todos os subprocessos do Processo 2, pois assim

garante-se que atualizações de cadastros sejam consideradas (evitando-se que os dados se

tornem obsoletos). Após esta etapa, importam-se as cargas de dados (P2S2A7) para o sistema,

ao final da qual se sucede o teste de verificação de erros na importação dos templates

142

(P2S2T1). Abaixo são relacionados exemplos de mensagens de erro para cada tipo de

problema que pode ser identificado neste passo:

• nome do template não consta no banco de dados: o nome do template dos estoques

fictícios foi preenchido de forma errada;

• formato do arquivo do template incompatível com o banco: o template dos pedidos

fictícios foi importado em formato “.xls”, porém o banco de dados aceita somente

“.csv”;

• formato dos dados incompatível com a base de dados: a coluna “percentual de

formulação” do template de árvores de formulação foi preenchida por números

negativos, porém o banco não reconhece este tipo de formato para o referido

campo; e

• integridade referencial: na carga das capacidades elevadas de estoques, havia um

produto cujo código inexistia no cadastro de produtos.

Se forem identificados erros nesta etapa, é necessário que se corrijam os dados na

fonte primária (P2S2A8); caso contrário, prossegue-se para a validação dos dados (P2S2A9),

a qual verifica a ocorrência de situações em que os dados não respeitem as regras de negócio

da empresa. Em relação ao subprocesso anterior (dados cadastrais e estoques de produtos),

outros tipos de erros são mapeados pelas validações, já que, no Subprocesso 2.2, populam-se

5 cargas de dados que inexistiam no antecessor. Abaixo são listados dois exemplos de

validações características desta etapa:

• produto pai possui filhos alternativos e compulsórios: uma árvore jamais poderá ter

filhos alternativos e compulsórios do mesmo pai, pois a situação é conflitante no

conceito destes termos – enquanto os alternativos não possuem rendimento em uma

árvore de cortes ou percentual de formulação em uma árvore de formulação, os

compulsórios são exatamente o contrário; e

• o SIF da fábrica não está habilitado para o país do pedido, porém pelo menos um

dos produtos do pedido está cadastrado em alguma árvore da fábrica: esta validação

é do tipo alerta, pois não necessariamente existem erros neste caso. Se o SIF da

fábrica não estiver habilitado para o país destino do pedido (no mundo real), não há

erros. Por outro lado, pode estar faltando a habilitação do SIF da fábrica para o país

de destino do pedido, o que configuraria um erro.

143

144

FIGURA 33 – Fluxograma do Subprocesso 2.2

Caso existirem erros de validação, os quais são verificados no teste P2S2T2, os

mesmos deverão ser corrigidos na fonte primária (P2S2A10), e uma nova importação dos

templates que continham os dados errados deverá ser feita (voltando-se à atividade P2S2A7).

Quando verificar-se que inexistem erros de validação no teste P2S2T2, prossegue-se no fluxo

para que sejam gerados os índices de controle (P2S2A11). Nesta etapa, não há novos ICs,

porém deverão ser gerados todos os índices criados até este subprocesso. A partir disso, os

resultados dos ICs devem ser confrontados com as metas estipuladas para cada um,

verificando se todas foram atingidas (P2S2T3).

Se nem todos os ICs alcançaram a meta, deve-se identificar e corrigir os erros de

dados na fonte primária (P2S2A12). Caso as metas tenham sido atingidas, prossegue-se no

fluxo para que seja feita a rodada do sistema (P2S2A13). Ao final desta, os resultados da

ferramenta devem ser submetidos aos indicadores (P2S2A14), sendo que a única métrica

deste subprocesso tem como foco a programação dos pedidos fictícios. A partir dos resultados

apresentados no indicador, deve-se fazer a checagem do teste P2S2T4.

Caso a meta em relação à programação dos pedidos não tenha sido alcançada, se

existirem problemas nos dados, os mesmos deverão ser corrigidos na fonte primária

(P2S2A15). Um exemplo de um erro seria o caminho da árvore até o produto final possuir

itens que não estivessem habilitados para a fábrica em análise. A ação sobre o problema

deveria ser a correção do dado na fonte primária (dados cadastrais). Outro exemplo seria a

145

identificação de produtos finais formulados que não serão mais produzidos na fábrica em

análise. Neste caso, a árvore do produto poderia ser excluída da fonte primária.

A partir da correção dos erros, os templates cujos dados foram editados devem ser

reimportados para o sistema (P2S2A7), voltando-se ao fluxo já mencionado nesta seção. Por

outro lado, se as metas forem atingidas, devem ser excluídos os pedidos fictícios e as árvores

de formulação da fábrica testada (atividades P2S2A16 e P2S2A17). Executadas as exclusões

dos dados, deve-se partir para o teste P2S2T5, o qual verifica se todas as fábricas já foram

testadas. Caso negativo, deve-se voltar para as atividades iniciais do fluxo (preenchimento dos

templates), fazendo-se os mesmos procedimentos que os utilizados para a última fábrica. No

caso de todas as unidades produtivas já terem sido testadas, finaliza-se o Subprocesso 2.2,

prosseguindo-se para o Subprocesso 2.3.

5.2.2.3 Subprocesso 2.3 – Capacidades finitas de formulados

Após a realização dos testes sobre os produtos de todas as fábricas de formulados com

o apoio de pedidos fictícios, o Subprocesso 2.3 utiliza os dados corrigidos até o final da etapa

anterior, com a diferença da adição de novos dados e a substituição de outros. Os roteiros

produtivos, os estoques iniciais de produtos e as compras de produtos finais são agregados ao

subprocesso, enquanto que os pedidos fictícios são substituídos pelos pedidos e previsões de

demanda reais de formulados.

Nesta etapa, os roteiros passam a ser considerados porque uma condição foi atendida

no subprocesso anterior: a garantia de que todas as árvores de formulação estão livres de erros

que possam impedir a programação da produção. Além disso, o fato de os roteiros serem

limitantes da produção faz direcionar o método no sentido da visualização da programação de

produção em bases próximas da realidade, o que será mensurado por meio dos ICs. Os

estoques iniciais de produtos e as compras de produtos finais também contribuem para esta

visualização. O objetivo do Subprocesso 2.3, portanto, é o de verificar se as estruturas de

produto de cada fábrica, agora complementadas pela população dos roteiros na base do

sistema, são capazes de programar todos os pedidos e previsões de demanda dentro do

horizonte de seqüenciamento.

No Subprocesso 2.3, mantém-se a estratégia dos estoques fictícios de MPs, das

capacidades elevadas de estoques e dos lead times e lotes mínimos de suprimentos zerados,

146

pois desta forma estas variáveis não influenciarão nos resultados, sendo possível testar os

roteiros produtivos. A realização dos testes por fábrica (uma de cada vez) também é mantida

porque, caso o teste fosse feito para todas as fábricas de formulados juntas, o sistema

escolheria uma delas para atender um pedido, por exemplo, e não se saberia se esta escolha

teria sido feita por causa de erros nos roteiros de uma fábrica.

A importação dos pedidos reais para o sistema deve possuir somente pedidos cujos

saldos pendentes de embarque sejam maiores que zero. Ou seja, somente os pedidos que ainda

não foram completamente entregues aos clientes deverão ser populados na base de dados. Já

as previsões de demanda devem ser importadas porque são responsáveis por "cobrir" os

pedidos na falta destes (nem todos os produtos possuem pedidos para todo o horizonte de

programação).

No Subprocesso 2.3, não se mede nos indicadores o índice de atendimento de pedidos

no prazo. Isso é explicado pelo fato de os testes serem feitos por fábrica, separadamente.

Neste caso, como no mundo real os pedidos não são necessariamente atendidos somente por

uma fábrica, os testes não comportariam a utilização deste indicador de aderência.

A partir desta introdução acerca das características e dos objetivos do Subprocesso 2.3,

apresenta-se o fluxograma desta etapa, o qual é pode ser visualizado na Figura 34. Após a

conclusão do Subprocesso 2.2, inicia-se a preparação dos dados cadastrais e o preenchimento

dos templates de árvores de formulação com os roteiros de produção de uma fábrica, dos

pedidos e demandas reais que possuem produtos da mesma unidade, dos estoques iniciais de

produtos formulados e das compras de produtos finais (respectivamente, as atividades

P2S3A1, P2S3A2, P2S3A3, P2S3A4 e P2S3A5).

Os templates são importados (P2S3A6) e posteriormente submetidos ao teste referente

à importação (P2S3T1). Abaixo são relacionados exemplos de mensagens de erro para cada

tipo de problema que pode ser identificado neste passo:

• nome do template não consta no banco de dados: o nome do template das compras

de produtos finais foi preenchido de forma errada;

• formato do arquivo do template incompatível com o banco: o template dos estoques

iniciais foi importado em formato “.xls”, porém o banco de dados aceita somente

“.csv”;

147

148

FIGURA 34 – Fluxograma do Subprocesso 2.3

• formato dos dados incompatível com a base de dados: a coluna “quantidade” do

template dos pedidos e demandas reais foi preenchida por números negativos,

porém o banco não reconhece este tipo de formato para o referido campo; e

• integridade referencial: na carga das árvores de formulação com os roteiros, havia

um recurso cujo código inexistia no cadastro de recursos.

Caso existirem erros na importação, os mesmos devem ser corrigidos na fonte

primária (P2S3A7); senão, inicia-se o processo de validação dos dados do banco (P2S3A8), a

partir dos quais também será possível verificar se existem problemas nos dados. Abaixo são

listados dois exemplos de validações características desta etapa:

• recurso possui quantidade por hora igual a zero em um produto de uma árvore de

formulação: o tempo de processo zerado de um recurso faria com que o sistema

ignorasse a utilização do mesmo na programação da produção; e

• produto consta em pedido e nenhuma das árvores nas quais está cadastrado está

habilitada: mesmo que o produto esteja cadastrado em alguma árvore, esta deve

149

estar habilitada em pelo menos uma fábrica, caso contrário o produto não será

programado.

O segundo teste do subprocesso avalia a ocorrência de erros de dados nas validações

(P2S3T2), os quais deverão ser corrigidos (se existirem erros). Caso contrário, geram-se os

índices de controle na atividade P2S3A10, sendo que, nesta etapa, não existem novos ICs. No

entanto, devido ao caráter cumulativo de parte das métricas ao longo dos subprocessos,

deverão ser gerados todos os ICs criados em etapas anteriores. Da mesma forma que nos

subprocessos já explorados, os resultados dos índices de controle são confrontados com as

metas estabelecidas para os mesmos (P2S3T3). Se existirem problemas nos dados, os mesmos

deverão ser corrigidos (P2S3A11).

Uma atividade foi criada especificamente para os subprocessos nos quais se os roteiros

produtivos fazem parte dos testes, pois, mesmo com as validações criadas para os calendários,

nada impede que a disponibilidade de um recurso seja sub ou superestimada. Na atividade

P2S3A12, deve ser medido de forma automática pelo sistema o número de horas, por dia e

turno de trabalho de um período semanal, que está cadastrado para um recurso. Assim,

evitam-se futuros problemas com um recurso que seja gargalo e possibilite a programação de

certos produtos além de um nível que seja factível na realidade, por exemplo. Uma

observação deve ser feita em relação ao cálculo das disponibilidades: existe um pressuposto

de que, ao final da correção das mesmas, não seja necessário continuar medindo-as enquanto

estiverem sendo testadas as estruturas de formulações. Ou seja, uma vez corrigidas, as

disponibilidades de recursos de árvores de formulados não serão novamente validadas em

etapas subseqüentes, a não ser quando se iniciarem os testes com as árvores de cortes.

Após a geração do tempo disponível dos recursos, o teste P2S3T4 verifica se as

disponibilidades calculadas para cada recurso da fábrica em análise estão corretas. Caso não

estiverem, os calendários deverão ser corrigidos (P2S3A13), sendo necessária uma nova

importação da tabela que contenha estes dados. Se não houver problemas nas

disponibilidades, prossegue-se no fluxo para a rodada do sistema (P2S3A14).

Após a esta atividade, devem ser gerados os indicadores (P2S3A15), os quais

mensuram a programação dos pedidos e da previsão de demanda líquida

, a necessidade de

A demanda líquida refere-se à diferença entre a demanda total e os pedidos, em kg, de um produto, desde que

ela seja maior que o volume de pedidos. É importante que a demanda reflita a real previsão de vendas da

empresa, caso contrário o sistema programará produtos desnecessariamente.

150

MPs

e a aderência da programação

. Caso as metas não sejam atendidas, inicia-se um

processo de identificação e de correção de erros (P2S3A16). Um exemplo de erro neste caso

seria a demanda de um produto estar cadastrada com volumes acima da real previsão de

venda. Com isso, o sistema programará desnecessariamente a produção. A correção sobre este

erro deve ser feita na fonte primária, sendo necessário reimportar o template para o sistema.

Se as metas forem atingidas, prossegue-se para os passos finais do Subprocesso 2.3, o

qual contempla a exclusão dos dados de árvores e roteiros, pedidos e demandas, e os estoques

iniciais de produtos e as compras de produtos finais (atividades P2S3A17, P2S3A18,

P2S3A19 e P2S3A20, respectivamente). Executadas estas ações, verifica-se no teste P2S3T6

se todas as fábricas já foram testadas. Caso negativo, uma nova fábrica deverá ser testada,

voltando-se ao início do Subprocesso 2.3 (atividades P2S3A1 até a P2S3A5). Se todas as

unidades já tiverem sido testadas, finaliza-se o subprocesso e inicia-se o seguinte.

Uma observação se faz necessária em relação aos dados de estoques de produtos e de

compras de produtos finais: os mesmos poderiam ser mantidos na base do sistema, pois serão

utilizados no próximo subprocesso. No entanto, os dados podem ter se tornado obsoletos até o

final do Subprocesso 2.3, por isso uma nova e atualizada carga destes dados deverá ser feita

no Subprocesso 2.4. Esta lógica será mantida para todos os subprocessos, portanto esta

observação não será feita nos demais.

5.2.2.4 Subprocesso 2.4 – Suprimentos de formulados

No Subprocesso 2.4, são mantidos os dados utilizados na etapa anterior e as definições

sobre os mesmos, com a diferença que são incorporados a estrutura de embalagens de cada

produto formulado e os estoques e restrições de suprimentos (lead time e lote mínimo de

ressuprimento). A estrutura de ingredientes não é importada porque a mesma já se encontra

nas árvores formulação, tendo em vista que os condimentos fazem parte da massa dos

produtos formulados.

A necessidade de matérias-primas é calculada a partir da aplicação dos rendimentos e percentuais de

formulação sobre o volume de pedidos e demandas. A acuracidade deste cálculo é medida por meio de um

comparativo com a quantidade planejada de MPs pela empresa, em um mesmo horizonte (1 mês, por exemplo).

Assim, será possível verificar se os percentuais das MPs nas árvores de formulação estão corretos. Conforme

mencionado no detalhamento do Subprocesso 2.3, os cálculos de aderência de produção não são feitos porque os

testes ainda não são multi-fábrica. No caso do indicador de necessidade de MPs, no entanto, sugere-se ponderar

a análise do mesmo perante o volume programado dos produtos finais que utilizam cada MP que será analisada.

A aderência da programação compara os volumes programados pelo sistema em relação à projeção

(planejamento) da empresa por família de produto.

151

6XESURFHVVR

3UHHQFKHUR

WHPSODWHGDV

iUYRUHVGH

IRUPXODomRGH

XPDIiEULFD

FRPRVURWHLURV

3 6 $

3UHHQFKHUR

WHPSODWHGRV

SHGLGRVH

GHPDQGDVUHDLV

GRVIRUPXODGRVGD

IiEULFDHVFROKLGD

3 6 $

,PSRUWDURVWHPSODWHV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

9DOLGDURVGDGRVGREDQFR

3 6 $

&RUULJLURVGDGRV

3 6 $

3 6 7

+RXYHHUURVQDV

LPSRUWDo}HV"

3 6 7

([LVWHPHUURV

GHGDGRV"

5RGDURVLVWHPD

3 6 $

*HUDURVLQGLFDGRUHV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

3UHHQFKHUR

WHPSODWHGDV

HVWUXWXUDVGH

HPEDODJHQV

GDIiEULFD

HVFROKLGD

3 6 $

3UHHQFKHUR

WHPSODWHGRV

OHDG WLPHVH

ORWHVPtQLPRV

UHDLVGH

VXSULPHQWRV

3 6 $

3UHHQFKHUR

WHPSODWHGRV

HVWRTXHVLQLFLDLV

GHVXSULPHQWRV

GDIiEULFD

HVFROKLGD

3 6 $

3UHHQFKHUR

WHPSODWHGRV

HVWRTXHV

LQLFLDLVGH

SURGXWRV

IRUPXODGRV

3 6 $

3UHHQFKHUR

GDV

FRPSUDVGH

SURGXWRV

ILQDLV

3 6 $

3iJ

*HUDURVtQGLFHVGHFRQWUROH

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

(

3UHHQFKHU

WHPSODWH

GDV

FRPSUDVGH

VXSULPHQ

WRV

3 6 $

3UHSDUDU

DFDUJDGH

GDGRV

FDGDVWUDLV

3 6 $

'DGRV 'DGRV

/RJVGH

HUURV

9DOLGDo}HV

,&V

,QGLFDGRUHV

5HODWyULRV

GRVLVWHPD

152

FIGURA 35 – Fluxograma do Subprocesso 2.4

Estes dados são populados somente nesta etapa porque a utilização de suprimentos é

definida para cada quilograma de produto. Logo, caso as árvores de formulação não

estivessem validadas, não seria possível realizar um teste adequado para os suprimentos.

Além disso, o fato de a programação do sistema já contemplar antes mesmo do Subprocesso 4

as limitações dos roteiros produtivos permite que os suprimentos sejam testados em bases

próximas da realidade.

Conforme mencionado, mantêm-se a nesta etapa a mesma estratégia utilizada no

Subprocesso 2.3, como o acompanhamento da programação dos pedidos (independentemente

se atendidos no prazo) e a opção por testar fábrica por fábrica, por exemplo. Na Figura 35,

apresenta-se o fluxograma do Subprocesso 2.4. Após o término do Subprocesso 2.3,

preenchem-se os mesmos templates utilizados nesta etapa (atividades P2S4A1 a P2S4A3,

P2S4A7 e P2S4A9), com a diferença que outros três são utilizados (P2S4A4 a P2S4A6).

Os templates são importados para o sistema de programação da produção, sendo que

após este processo se realiza o primeiro teste do Subprocesso 2.4, o qual verifica a ocorrência

de erros na importação (P2S4T1). Abaixo são relacionados exemplos de mensagens de erro

para cada tipo de problema que pode ser identificado neste passo:

153

• nome do template não consta no banco de dados: o nome do template das estruturas

de embalagens foi preenchido de forma errada;

• formato do arquivo do template incompatível com o banco: o template das compras

de suprimentos foi importado em formato “.xls”, porém o banco de dados aceita

somente “.csv”;

• formato dos dados incompatível com a base de dados: a coluna “código de

suprimento” do template das árvores de formulação foi preenchida por códigos

alfanuméricos, porém o banco não reconhece este tipo de formato para o referido

campo; e

• integridade referencial: na carga dos estoques iniciais de suprimentos, havia um

código de ingrediente inexistente no cadastro de suprimentos.

Caso existirem erros de importação, os mesmos deverão ser corrigidos na fonte

primária (P2S4A11), e uma nova importação dos dados será necessária, voltando-se aos

passos iniciais do fluxo. Depois deste passo, da mesma forma que no Subprocesso 2.3, os

dados inseridos no banco do sistema de programação da produção são submetidos às

validações das regras de negócio da empresa (P2S4A12). Abaixo são listados dois exemplos

de validações características desta etapa:

• produto possui suprimento com quantidade zerada na estrutura de embalagens: se

uma embalagem tiver quantidade igual a zero na estrutura de um produto, a mesma

não será considerada na programação da produção; e

• suprimento cadastrado na lista de compras tem data de entrega estimada no

passado: esta situação não representa necessariamente um erro (é um alerta), pois a

entrega do material pode estar atrasada. No entanto, a compra não será utilizada

pelo sistema na programação da produção, o que refletirá na qualidade das

informações geradas pelo mesmo.

Caso existam erros nos dados após a geração das validações, os mesmos devem ser

corrigidos na fonte primária (P2S4A13); senão, os índices de controle deverão ser gerados.

Igualmente às validações, verifica-se o atendimento das metas (P2S4T3). Existindo

problemas, os mesmos deverão ser corrigidos (P2S4A15). Um exemplo de um erro

diagnosticado por meio da análise de um IC seria uma embalagem possuir uma quantidade

necessária errada e elevada. Isso faria com que o sistema calculasse, durante a rodada de

154

programação, embalagens além do necessário considerando-se os pedidos e previsões de

demanda.

Na inexistência de erros quando as metas dos ICs não foram alcançadas, prossegue-se

para a rodada do sistema, ao final da qual se geram os indicadores (P2S4A16). Neste

subprocesso, não foram criadas novas métricas, porém deve-se continuar utilizando todos os

indicadores criados nos subprocessos anteriores. O que poderia ser avaliado em termos de

métricas após a rodada seria o comparativo entre o consumo necessário de suprimentos

calculado pelo sistema e a projeção de consumo da empresa. Porém, assim como explicado no

Subprocesso 2.3 em relação ao índice de aderência da programação do sistema, o fato de o

teste ser realizado para cada fábrica separadamente impede que o indicador contribua para a

análise das estruturas de suprimentos. Esta questão somente poderá ser verificada no

Subprocesso 2.6, o qual testa todas as fábricas de formulados juntas.

Caso as metas dos indicadores não forem atingidas, deverá ser feito um processo de

identificação e de correção de erros (P2S4A18). Se as metas forem atingidas, deve-se

proceder para a exclusão dos dados utilizados no Subprocesso 2.4 (atividades P2S4A19 a

P2S4A26) e posteriormente para a checagem final se todas as fábricas já foram testadas

(P2S4T5). Se a resposta for “Não”, deve-se voltar para o início do subprocesso

(preenchimento dos templates); caso contrário, as capacidades elevadas de estoques devem

ser excluídas, pois o Subprocesso 2.5 dedica-se ao teste com as capacidades reais de estoques.

5.2.2.5 Subprocesso 2.5 – Capacidades reais de estoques (teste formulados)

Após a realização dos testes das estruturas de formulados submetidas às estruturas de

embalagens e à habilitação dos lead times e lotes mínimos de ressuprimento, realizam-se no

Subprocesso 2.5 os testes referentes às limitações de estocagens. O objetivo desta etapa é

verificar o impacto da inclusão das capacidades reais de estoques na programação da

produção e na projeção de estoques futuros, validando também os dados de transportes entre

unidades. Este último item deve ser analisado porque, na falta de capacidade de estoque de

uma fábrica, por exemplo, os produtos poderiam ser enviados para entrepostos de

armazenagem. Na Figura 36, visualiza-se o fluxograma do Subprocesso 2.5, o qual é

praticamente igual ao Subprocesso 2.4, com a diferença da consideração das limitações de

estoques.

155

156

FIGURA 36 – Fluxograma do Subprocesso 2.5

O subprocesso inicia pelo preenchimento dos templates (atividades P2S5A1 até

P2S5A10), passando posteriormente pela importação dos dados e teste de erros neste

procedimento (P2S5T1). Abaixo são relacionados exemplos de mensagens de erro para cada

tipo de problema que pode ser identificado neste passo:

• nome do template não consta no banco de dados: o nome do template das

capacidades reais de estoques foi preenchido de forma errada;

• formato do arquivo do template incompatível com o banco: o template dos pedidos

e demandas reais foi importado em formato “.xls”, porém o banco de dados aceita

somente “.csv”;

• formato dos dados incompatível com a base de dados: a coluna “data de embarque”

do template dos pedidos foi preenchida por datas no formato DDMMAAAA (dia-

mês-ano), porém o banco reconhece apenas o formato AAAAMMDD (ano-mês-

dia) para o referido campo; e

• integridade referencial: na carga dos roteiros, havia um código de turno inexistente

no cadastro de turnos de trabalho.

157

Confirmada a inexistência de problemas nas importações, prossegue-se para a

validação dos dados com base nas regras de negócio da empresa (P2S5A13). No Subprocesso

2.5, não existem validações que sejam características desta etapa, porém pode-se utilizar um

exemplo das validações de roteiros: recurso sem calendário associado está cadastrado em uma

árvore. Um recurso não é obrigado a possuir um calendário vinculado. Porém, no momento

em que é cadastrado em uma árvore, deve possuir um calendário, caso contrário o sistema não

considerará o recurso na programação da produção.

Após esta atividade, novamente se realiza um teste (P2S5T2), porém desta vez para a

verificação de erros de dados no banco do sistema. Quando não houver mais erros na base,

geram-se os índices de controle (P2S5A15). Neste subprocesso, não existem novos ICs,

porém devem-se utilizar todos os outros que foram criados até as etapas anteriores.

Confirmada a inexistência de erros, o sistema deverá ser rodado (P2S5A17). A partir disso,

poderão ser avaliados os resultados do sistema por meio dos indicadores (P2S5A18), dentre

os quais serão utilizadas métricas criadas em outros subprocessos, além do indicador para a

ocupação de estoques.

Após a geração dos indicadores, verifica-se se as metas foram atingidas (P2S5T4). Se

a resposta for “Não”, será necessário realizar um processo de identificação e de correção de

erros (P2S5A19). Um exemplo de um erro neste subprocesso seria no cadastro de permissão

de transferências de produtos entre unidades e pontos de embarque. Caso isso não estiver

habilitado, o estoque disponível na unidade não será utilizado para atender determinados

pedidos, fazendo com que o estoque aumente e impeça que o sistema programe a produção a

partir de um ponto, pois a produção não poderá ser armazenada.

Se as metas dos indicadores forem atingidas, deve-se proceder para a exclusão dos

dados utilizados no Subprocesso 2.5 (atividades P2S5A20 a P2S5A28). Após esta ação, deve-

se verificar se todas as fábricas foram testadas. Caso nem todas as unidades tenham sido

submetidas, será necessário reiniciar o fluxo com uma nova fábrica. Se não, procede-se para o

Subprocesso 2.6.

5.2.2.6 Subprocesso 2.6 – Formulados global

No Subprocesso 2.6, são feitos testes com todas as fábricas de formulados ao mesmo

tempo e todos os dados importados para o sistema até o subprocesso anterior. Nesta etapa,

158

contemplam-se situações ainda mais próximas da realidade, nas quais, por exemplo, produtos

que sejam produzidos em mais de uma fábrica possam ser programados pelo sistema

considerando-se esta possibilidade. Em função disso e também da população dos dados

necessários para a geração de uma programação próxima do mundo real, viabiliza-se nesta

fase a avaliação de indicadores que até então não estavam sendo gerados:

• atendimento de pedidos no prazo;

• acuracidade da necessidade de matérias-primas; e

• acuracidade da necessidade de suprimentos.

Na Figura 37, apresenta-se o fluxograma do Subprocesso 2.6, o qual tem início com o

preenchimento dos templates. Igualmente aos subprocessos anteriores, procede-se para a

realização de testes de importação, validação da base de dados, geração de índices de controle

e de indicadores, além das correções de erros ou melhorias nos dados.

Após o preenchimento dos templates, é realizada a importação dos dados (P2S6A11),

a qual é posteriormente submetida ao teste de verificação de problemas (P2S6T1). Abaixo são

relacionados exemplos de mensagens de erro para cada tipo de problema que pode ser

identificado neste passo:

• nome do template não consta no banco de dados: o nome do template das compras

de suprimentos foi preenchido de forma errada;

• formato do arquivo do template incompatível com o banco: o template das compras

de produtos finais foi importado em formato “.xls”, porém o banco de dados aceita

somente “.csv”;

• formato dos dados incompatível com a base de dados: a coluna “data inicial da

demanda” do template das demandas foi preenchida por datas no formato

AAAAAMMDD (ano-mês-dia, porém com 5 dígitos no ano), sendo que o banco

reconhece o formato AAAAMMDD (ano-mês-dia) para o referido campo; e

• integridade referencial: na carga das árvores de formulação, havia um código de

produto pai inexistente no cadastro de produtos.

159

6XESURFHVVR

,PSRUWDURVWHPSODWHV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

9DOLGDURVGDGRVGREDQFR

3 6 $

&RUULJLURVGDGRV

3 6 $

3 6 7

+RXYHHUURVQDV

LPSRUWDo}HV"

3 6 7

([LVWHPHUURV

GHGDGRV "

5RGDURVLVWHPD

3 6 $

*HUDURVLQGLFDGRUHV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

3UHHQFKHUR

WHPSODWHGDV

FDSDFLGDGHV

UHDLVGH

HVWRTXHVGH

WRGDVDV

IiEULFDVGH

IRUPXODGRV

3 6 $

3UHHQFKHUR

WHPSODWH

GDViUYRUHV

GH

IRUPXODomR

GHWRGDVDV

IiEULFDVFRP

RVURWHLURV

3 6 $

3UHHQFKHU

RWHPSODWH

GRV

SHGLGRVH

GHPDQGDV

UHDLVGH

WRGRVRV

IRUPXODGRV

3 6 $

3UHHQFKHUR

WHPSODWHGDV

HVWUXWXUDVGH

HPEDODJHQV

GHWRGDVDV

IiEULFDVGH

IRUPXODGRV

3 6 $

3UHHQFKHUR

WHPSODWHGRV

OHDG WLPHVH

ORWHV

PtQLPRV

UHDLVGH

VXSULPHQWRV

3 6 $

3UHHQFKHUR

WHPSODWHGRV

HVWRTXHV

LQLFLDLVGH

VXSULPHQWRVGH

WRGDVDV

IiEULFDVGH

IRUPXODGRV

3 6 $

3UHHQFKHUR

WHPSODWH

GRV

HVWRTXHV

LQLFLDLVGH

SURGXWRV

IRUPXODGRV

3 6 $

3UHHQFKHU

R

GDV

FRPSUDV

GH

SURGXWRV

ILQDLV

3 6 $

3iJ

*HUDURVtQGLFHVGHFRQWUROH

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

3UHHQFKHU

WHPSODWH

GDV

FRPSUDV

GHVXSUL

PHQWRV

3 6 $

3UHSDUDUD

FDUJDGH

GDGRV

FDGDVWUDLV

3 6 $

'DGRV

/RJVGH

HUURV

9DOLGDo}HV

,&V

,QGLFDGRUHV

5HODWyULRV

GRVLVWHPD

160

FIGURA 37 – Fluxograma do Subprocesso 2.6

Caso sejam identificados erros, realizam-se a correção dos mesmos, sendo necessário

reimportar os templates. Por outro lado, se não forem encontrados erros após a importação

dos dados, inicia-se a validação do banco de dados (P2S6A13), a qual também é submetida a

um teste para verificar se existem erros de dados (P2S6T2). Neste ponto do fluxo, não existem

novas validações, porém, devido ao caráter cumulativo das mesmas, deve-se verificar a

existência de situações que não respeitem as regras de negócio estabelecidas.

Verificada a inexistência de erros, procede-se para a geração dos índices de controle

(P2S6A15). Neste ponto, são apenas mantidos os mesmos ICs de subprocessos anteriores. Se

for confirmada a inexistência de erros, deve-se executar uma rodada do sistema (P2S6A17), a

qual será sucedida pela geração dos indicadores.

Os resultados deverão ser comparados com a meta de cada métrica (P2S6T4) – se for

confirmada a existência de erros, deve-se analisar cada situação e corrigir os erros (P2S6A19).

Quando todas as metas forem alcançadas, aproxima-se do final do Subprocesso 2.6, faltando

apenas a exclusão de todos os dados que foram populados na base do sistema para a

realização dos testes (atividades P2S6A20 a P2S6A29). No momento em que estas ações

forem executadas, finalizam-se todos os testes nos quais foram tratados apenas produtos

formulados e encaminha-se para o início dos subprocessos dos cortes.

161

5.2.2.7 Subprocesso 2.7 – Pedidos fictícios de cortes

Finalizado o teste com todas as fábricas de produtos formulados juntas, o Subprocesso

2.7 marca o início dos testes para cortes. Em termos da estruturação dos fluxos, dos dados

utilizados e dos objetivos propostos, esta etapa é análoga ao Subprocesso 2.2, portanto

existem pontos em comum entre ambos. O Subprocesso 2.7 também tem como premissa a

geração de pedidos fictícios (de 1 kg) para todos os produtos que estejam cadastrados nas

árvores de cortes de cada fábrica que for testada. Dessa forma, possibilita-se testar todos os

produtos de uma unidade produtiva, independentemente se, no mundo real, os mesmos

possuam pedidos ou previsões de demanda.

O objetivo do Subprocesso 2.7 é verificar se as árvores de cortes de cada fábrica

testada são capazes de possibilitar ao menos a programação de um volume irrisório de

produção. Com isso, garante-se que os “caminhos” das árvores estarão corretamente

cadastrados e também habilitados na fábrica em análise.

As escalas e os limites mínimos e máximos de abates não são testados no Subprocesso

2.7 porque os pedidos reais ainda não estão sendo utilizados, logo não é necessário utilizar os

abates reais para a programação dos pedidos fictícios. Com isso, ficará a cargo do sistema a

sugestão do abate que será necessária para atender às necessidades de 1 kg para cada produto.

Já os estoques iniciais também não fazem parte desta etapa, pois, assim como no Subprocesso

2.2, poderia correr-se o risco de os pedidos serem atendidos pelos estoques, o que

inviabilizaria o teste forçado de todos os cortes.

A Figura 38 apresenta o fluxograma do Subprocesso 2.7. Esta etapa do método inicia-

se com o preenchimento dos templates das árvores de cortes sem os roteiros de produção, das

curvas de peso, dos pedidos fictícios para todos os produtos habilitados nas árvores e das

capacidades elevadas de estoques (atividades P2S7A1 até P2S7A5). Em um segundo

momento, os dados são importados para o sistema (P2S7A6), e ao finalizar a importação o

sistema gera os logs que fazem a verificação automática de erros neste processo. Abaixo são

relacionados exemplos de mensagens de erro para cada tipo de problema que pode ser

identificado neste passo:

• nome do template não consta no banco de dados: o nome do template das curvas de

peso foi preenchido de forma errada;

162

163

FIGURA 38 – Fluxograma do Subprocesso 2.7

• formato do arquivo do template incompatível com o banco: o template das

capacidades elevadas de estoques foi importado em formato “.xls”, porém o banco

de dados aceita somente “.csv”;

• formato dos dados incompatível com a base de dados: a coluna “percentual da

curva” do template das curvas de peso foi preenchida por números com formato

americano (vírgulas no lugar de ponto, e vice-versa), sendo que o banco reconhece

apenas o formato brasileiro para o referido campo; e

• integridade referencial: na carga das árvores de cortes, havia um código de raiz de

corte inexistente no cadastro de produtos.

Caso ocorram erros neste processo, o que é verificado no teste P2S7T1, devem-se

identificar e corrigir os problemas na fonte primária (P2S7A7), além de reimportar os

templates para a ferramenta, realizando-se novamente as atividades a partir deste ponto. Caso

inexistirem erros na importação dos templates, devem-se gerar as validações dos dados da

base do sistema (P2S7A8). Abaixo são listados dois exemplos de validações características

desta etapa:

• classe do produto diferente da classe da raiz de cortes na qual o mesmo está

cadastrado: esta situação representa um erro, tendo em vista que, em uma árvore de

cortes, não podem coexistir produtos de classes diferentes (cortes e formulados); e

• produto presente em uma árvore de cortes possui filhos cuja soma dos rendimentos

é diferente de 100: esta situação é classificada como um alerta, pois pode ser um

164

erro ou uma situação normal, dependendo-se de cada caso verificado. Se a soma

dos rendimentos for menor que 100%, dependendo-se da modelagem da estrutura

de produto, a diferença talvez represente um resíduo que não será utilizado no

processo produtivo nem vendido, logo o mesmo nem deve ser cadastrado na árvore.

No caso de a soma ser maior que 100%, é possível que alguns produtos adquiram

massa durante o processo.

Se identificar-se que existem erros de dados após serem rodadas as validações (teste

P2S7T2), os mesmos deverão ser corrigidos na fonte primária (P2S7A9), sendo necessário

que os templates sejam novamente importados para o sistema. Caso inexistirem problemas

nos dados, devem ser gerados os índices de controle (P2S7A10). Dentre os ICs, um deles

calcula a média dos pesos das raízes que fazem parte de uma curva de peso, comparando-se

estes dados com o peso da “raiz-mãe” da curva. Erros nestes dados fazem com que a

programação de abates e, conseqüentemente, a de produção sejam prejudicadas.

No teste P2S7T3, verifica-se se as metas foram alcançadas. Se a resposta for “Não”,

será necessário realizar um processo de identificação e de correção de erros (P2S7A11). Caso

as metas tenham sido alcançadas, o sistema deverá ser rodado e, ao final do processo, os

indicadores deverão ser gerados (P2S7A13) para que os resultados dos mesmos sejam

confrontados com as metas estipuladas (P2S7T4). Se nem todas as métricas alcançarem as

metas, deverá ser feito um processo de identificação e de correção de erros (P2S7A14). Um

exemplo de um erro neste ponto seria a ausência de um ou mais produtos intermediários de

uma árvore de cortes, o que faz com que o sistema não consiga “empurrar” a massa no sentido

da geração dos produtos que possuem pedidos. A correção deste erro deve ser feita no

cadastro de permissão de produção, no qual os códigos com problemas devem estar

vinculados à fábrica da raiz de corte em análise.

Caso todas as metas estabelecidas para os indicadores forem atendidas, aproxima-se

do final do Subprocesso 2.7, faltando apenas excluir as árvores de cortes e os pedidos fictícios

da fábrica testada (P2S7A15 e P2S7A16) e verificar se todas as unidades produtivas de cortes

já foram submetidas ao subprocesso (P2S7T5). Se a resposta for “Não”, uma nova fábrica

deverá ser testada, iniciando-se novamente o subprocesso para que outra unidade produtiva

seja submetida ao mesmo. Caso todas as fábricas tenham passado pelo fluxo, encerra-se o

Subprocesso 2.7 e inicia-se o Subprocesso 2.8.

165

5.2.2.8 Subprocesso 2.8 – Capacidades finitas de cortes

O Subprocesso 2.8 caracteriza-se principalmente pela população dos pedidos e

previsões de demanda reais, dos roteiros de produção e de novo um elemento, até então não

utilizado nas etapas anteriores: os abates (escalas, curvas de peso e limites mínimos e

máximos). Logo, em sua essência, este subprocesso é análogo ao Subprocesso 2.3

(capacidades finitas de formulados), existindo apenas duas diferenças entre ambos: nas

matérias-primas e nos abates – no primeiro caso, as árvores de cortes não dependem das MPs

para a geração dos produtos finais de cortes, portanto não serão utilizados estoques fictícios

de MPs nos testes que envolvam os cortes. Com relação aos abates, a utilização dos dados

referentes a escalas, curvas de peso e limites possibilita, juntamente dos roteiros e pedidos e

previsões de demanda reais, que se direcione a programação do sistema para bases similares

ao mundo real. Além destes argumentos, as considerações feitas na introdução do

Subprocesso 2.3 são aplicáveis nesta etapa do método, inclusive para a utilização dos dados

de compras de produtos finais e de estoques de cortes, além da capacidade elevada de

estoques.

Na Figura 39, visualiza-se o fluxograma definido para a execução do Subprocesso 2.8.

Inicialmente, preenchem os templates de árvores de cortes, curvas de peso, escalas de abate e

pedidos e demandas reais de cortes dos produtos da fábrica escolhida, além dos estoques

iniciais de produtos e as compras de cortes finais (atividades P2S8A1 até P2S8A7).

Posteriormente, os dados são importados para o sistema de programação da produção. Ao

final da importação, realiza-se o primeiro teste do fluxo: a verificação de erros durante o

referido procedimento (P2S8T1). Abaixo são relacionados exemplos de mensagens de erro

para cada tipo de problema que pode ser identificado neste passo:

• nome do template não consta no banco de dados: o nome do template das árvores

de cortes foi preenchido de forma errada;

• formato do arquivo do template incompatível com o banco: o template das escalas

de abate foi importado em formato “.xls”, porém o banco de dados aceita somente

“.csv”;

• formato dos dados incompatível com a base de dados: a coluna “quantidade” do

template de estoques foi preenchida por números com pontos como separadores de

dígitos, porém o banco não reconhece este tipo de formato para o referido campo; e

166

• integridade referencial: na carga de pedidos, havia um pedido cujo país de destino

não constava no cadastro de países.

Caso tenham sido encontrados erros na importação dos dados, a correção dos mesmos

deverá ser feita na fonte primária dos dados (P2S8A9) e uma nova importação do template

que possui erros será necessária. Após confirmar a inexistência de erros de importação,

prossegue-se para a validação das regras de negócio na atividade P2S8A10. Abaixo são

listados três exemplos de validações características desta etapa:

• o SIF da fábrica está habilitado para o cliente do pedido, porém não está habilitado

para o país do cliente. Esta validação abrange duas situações: (1) o SIF da fábrica

talvez não possa fabricar produtos para o cliente, logo existiria um erro neste

cadastro; (2) a não habilitação do SIF da fábrica para o país destino do pedido pode

estar errada;

• recurso possui horários sobrepostos entre dois ou mais turnos de trabalho em um

mesmo dia: os horários de término de um turno e de início do turno subseqüente

não podem estar sobrepostos. Exemplo: o horário de término do turno 1 não pode

ser maior que o horário de início do turno 2, em um mesmo dia; e

• raiz de corte possui escala de abate cadastrada, porém não possui conteúdo

(detalhamento da árvore): se uma raiz de corte possui escala de abate, é

imprescindível que possua uma estrutura por meio da qual consiga gerar a massa

necessária para atender pedidos, demandas e MPs. Neste caso, é importante avaliar

se a raiz é abatida na realidade, pois a escala de abate cadastrada pode estar errada.

Se forem diagnosticados erros de dados após a geração das validações, devem-se

corrigir os mesmos na fonte primária (P2S8A11) e realizar uma nova importação do template

que contenha os dados com problema. No momento em que não houver erros de validação, os

índices de controle devem ser gerados (P2S8A12). Neste ponto do fluxo, não existem novos

ICs, porém, devido ao caráter cumulativo dos mesmos, deve-se verificar se as metas foram

atingidas (teste P2S8T3). Se as metas não forem alcançadas, deve-se iniciar um processo de

identificação e de correção de erros (P2S8A13).

O fato de a inclusão dos roteiros produtivos ser feita no Subprocesso 2.8 implica na

necessidade de se medirem as disponibilidades dos recursos (P2S8A14), atividade que, assim

como no Subprocesso 2.3, será feita apenas uma vez para cada tipo de produto (cortes e

formulados).

167

168

FIGURA 39 – Fluxograma do Subprocesso 2.8

O teste P2S8T4 sugere a verificação da acuracidade das disponibilidades calculadas;

caso existam erros, os calendários deverão ser corrigidos na fonte primária (P2S8A15), e uma

nova carga do template que contém estes dados será necessária. Se as disponibilidades

estiverem corretas, procede-se para a rodada do sistema, cujos resultados poderão ser

avaliados por meio dos indicadores ao final da mesma (P2S8A17).

No Subprocesso 2.8, agregam-se os indicadores de abates, de volume de produção de

cortes e de resíduos. Nos abates, mensura-se aderência global (apenas separada por tipo de

animal). Quanto aos volumes de cortes, este indicador refere-se ao volume programado de

produtos e MPs, cuja meta deverá ser coerente com a meta definida para os abates, tendo em

vista que os cortes são decorrentes dos abates.

Quanto aos volumes de cortes, este indicador refere-se ao volume programado de

produtos e MPs, cuja meta deverá ser coerente com a definida para os abates, tendo em vista

que os cortes são decorrentes daqueles. Já o indicador de resíduos deverá apresentar o volume

programado de produtos que não possam ser estocáveis, o que constitui um erro.

169

Após comparar os resultados com as metas estabelecidas (P2S8T5), caso as mesmas

não tenham sido alcançadas, assim como nos ICs, deve-se realizar um processo de

identificação e de correção de erros (P2S8A18). Quando todas as metas forem atingidas,

devem-se excluir da base todos os dados populados no início do subprocesso e verificar se

todas as fábricas foram testadas (P2S8T6). Caso existirem fábricas pendentes, será necessário

escolher outra unidade produtiva e reiniciar o Subprocesso 2.8. Se não houver mais fábricas

para serem testadas, finaliza-se o referido subprocesso.

5.2.2.9 Subprocesso 2.9 – Suprimentos de cortes

Finalizados os testes em torno da inclusão dos roteiros produtivos nas árvores de

cortes de cada fábrica separadamente, o Subprocesso 2.9 caracteriza-se pelo incremento dos

suprimentos de cortes, mantendo-se os outros dados populados até o subprocesso anterior.

Esta etapa é análoga ao Subprocesso 2.4, no qual se realizou o mesmo teste, porém para as

árvores de formulação de cada fábrica. Além disso, este subprocesso adota os mesmos

objetivos e pressupostos que o 2.4. O teste com suprimentos no Subprocesso 2.9 agrega os

seguintes dados: estruturas de embalagens dos produtos (não entram aqui condimentos, dado

que apenas um produto formulado possui este tipo de material), lead time e lotes mínimos

reais de ressuprimento, estoques iniciais de embalagens de cada fábrica e as compras de

suprimentos (recebimentos futuros dos materiais).

Na Figura 40, apresenta-se o fluxograma do Subprocesso 2.9, o qual inicia pela carga

de uma série de templates (atividades P2S9A1 a P2S9A11). Posteriormente, os dados são

importados para o sistema de programação da produção, procedimento que é sucedido pelo

primeiro teste do fluxo, o qual verifica se houve problemas nas importações (P2S9T1) com o

apoio de logs que devem ser gerados automaticamente pela ferramenta. Abaixo são

relacionados exemplos de mensagens de erro para cada tipo de problema que pode ser

identificado neste passo:

• nome do template não consta no banco de dados: o nome do template das curvas de

peso foi preenchido de forma errada;

• formato do arquivo do template incompatível com o banco: o template dos estoques

iniciais de suprimentos foi importado em formato “.xls”, porém o banco de dados

aceita somente “.csv”;

170

6XESURFHVVR

,PSRUWDURVWHPSODWHV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

9DOLGDURVGDGRVGREDQFR

3 6 $

&RUULJLURVGDGRV

3 6 $

3 6 7

+RXYHHUURVQDV

LPSRUWDo}HV"

3 6 7

([LVWHPHUURV

GHGDGRV "

5RGDURVLVWHPD

3 6 $

*HUDURVtQGLFHVGHFRQWUROH

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

*HUDURVLQGLFDGRUHV

3 6 $

3UHHQFKHUR

WHPSODWH

GDV

HVWUXWXUDV

GH

HPEDODJHQV

GDIiEULFD

HVFROKLGD

3 6 $

3UHHQFKHUR

WHPSODWH

GRVOHDG

WLPHVHORWHV

PtQLPRV

UHDLVGH

VXSULPHQ

WRV

3 6 $

3UHHQFKHUR

WHPSODWHGDV

iUYRUHVGH

FRUWHVGHXPD

IiEULFDFRPRV

URWHLURVGH

SURGXomR

3 6 $

3UHHQFKHUR

WHPSODWHGRV

SHGLGRVH

GHPDQGDV

UHDLVGH

FRUWHVGD

IiEULFD

HVFROKLGD

3 6 $

3UHHQFKHU

WHPSODWH

GRV

HVWRTXHV

LQLFLDLVGH

FRUWHV

3 6 $

3UHHQFKHU

WHPSODWH

GDV

FRPSUDV

GHFRUWHV

ILQDLV

3 6 $

3UHHQFKHU

WHPSODWH

GDVFXUYDV

GHSHVR

GDIiEULFD

HVFROKLGD

3 6 $

3UHHQFKHU

RWHPSODWH

GDVHVFDODV

HOLPLWHVGH

DEDWHVGD

IiEULFD

HVFROKLGD

3 6 $

3UHHQFKHUR

WHPSODWH

GRV

HVWRTXHV

LQLFLDLVGH

VXSULPHQWRV

GDIiEULFD

HVFROKLGD

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

3iJ

3UHHQFKHU

WHPSODWH

GDV

FRPSUDV

GH

VXSULPHQ

WRV

3 6 $

3UHSDUDU

DFDUJDGH

GDGRV

FDGDVWUDLV

3 6 $

'DGRV

/RJVGH

HUURV

9DOLGDo}HV

,&V

,QGLFDGRUHV

5HODWyULRV

GRVLVWHPD

171

FIGURA 40 – Fluxograma do Subprocesso 2.9

• formato dos dados incompatível com a base de dados: a coluna “data do

recebimento do material” do template das compras de suprimentos foi preenchida

por datas no formato AAAAMMMDD (ano-mês-dia, porém com 3 dígitos no mês),

sendo que o banco reconhece somente o formato AAAAMMDD (ano-mês-dia, com

2 dígitos no mês) para o referido campo; e

• integridade referencial: na carga das estruturas de suprimentos, havia um código de

embalagem que não constava no cadastro de suprimentos.

Caso forem identificados erros neste passo, devem-se identificar e corrigir os

problemas na fonte primária (P2S9A13), sendo também necessário reimportar os templates

para a ferramenta. Se não houver erros na importação dos templates, devem-se gerar as

validações dos dados (P2S9A14). As duas únicas validações características desta etapa foram

desdobradas no Subprocesso 2.4, as quais contemplam situações em que um produto possui

embalagem com quantidade zerada em sua estrutura, como também suprimentos na lista de

compras com de entrega no passado.

Após a geração das validações, o teste P2S9T2 verifica a ocorrência de situações que

não respeitem as regras de negócio estabelecidas. Caso forem encontrados erros, os dados

devem ser corrigidos na fonte primária, além de ser necessária uma nova importação dos

templates após a correção. Por outro lado, se inexistirem problemas, os índices de controle

172

devem ser gerados (P2S9A16). Neste ponto do Subprocesso 2.9, não existem novos ICs que

mensurem questões específicas desta etapa. Porém, devido ao caráter cumulativo dos

mesmos, os ICs utilizados em todos os subprocessos anteriores devem ser aplicados para que

se teste a acuracidade dos dados. Posteriormente, o teste P2S9T3 verifica se as metas

definidas para os ICs foram atingidas. Se a resposta for “Não”, será necessário realizar um

processo de identificação e de correção de erros (P2S9A17).

Após a confirmação da inexistência de erros de importação e de validação, além de as

metas dos ICs terem sido atingidas, o sistema deve ser rodado (P2S9A18). As informações

geradas pelo sistema quanto à programação de pedidos, de produção e de necessidade de

suprimentos devem ser acompanhadas por meio dos indicadores (P2S9A19) e comparadas

com as metas (P2S9T4). Caso estas não tenham sido atingidas, novamente realiza-se um

processo de identificação e de correção de erros de dados (P2S9A20). Quando todas as metas

dos indicadores forem alcançadas, procede-se para a exclusão de todos os dados inseridos no

banco do sistema neste subprocesso (atividades P2S9A21 a P2S9A30). Desse modo, outras

fábricas poderão ser testadas ou, caso todas tenham sido submetidas ao Subprocesso 2.9,

encaminha-se para o teste com todas as fábricas de cortes juntas (Subprocesso 2.10).

5.2.2.10 Subprocesso 2.10 – Cortes global

No Subprocesso 2.10, é feito o mesmo teste da etapa anterior (suprimentos de cortes),

com a diferença que, nesta, são testadas todas as fábricas de cortes finais e MPs juntas.

Diferentemente dos subprocessos de produtos formulados (2.2 ao 2.6), não se aplicaram, antes

do teste global, as capacidades reais de estoques. Isso é explicado pelo fato de as MPs não

terem um “destino” – a massa empurrada pelos abates fará com que pedidos e previsões de

demanda sejam atendidos, porém o excedente (que seria utilizado para a programação de

matérias-primas) ficará no estoque, não tendo um destino.

Considerando-se a utilização de todos os dados de cortes populados e corrigidos até o

subprocesso anterior e o teste de todas as fábricas juntas, contemplam-se situações ainda mais

próximas da realidade nesta etapa. Da mesma forma que no Subprocesso 2.6, produtos que

sejam produzidos em mais de uma fábrica podem ser programados pelo sistema

considerando-se esta possibilidade. Com isso, viabiliza-se nesta fase o acompanhamento do

indicador de atendimento de pedidos no prazo.

173

O fluxograma do Subprocesso 2.10 é detalhado na Figura 41. Como este subprocesso

é idêntico ao anterior, com a diferença do tratamento de todas as fábricas de cortes ao mesmo

tempo, as atividades e testes são similares. Verifica-se que, primeiramente, preenchem-se os

templates dos dados que serão submetidos aos testes desta etapa (atividades P2S10A1 a

P2S10A11).

Em um segundo momento, importam-se as cargas de dados para o sistema, passo que é

sucedido pela verificação de erros de importação (teste P2S10T1). Os mesmos exemplos de

mensagens de erro relatados no Subprocesso 2.9 aplicam-se neste passo: nome do template

preenchido de forma errada, formato do arquivo e dos dados importados incompatíveis com o

banco, e problemas de integridade referencial. Caso identificarem-se erros neste processo, os

mesmos deverão ser corrigidos na fonte primária (P2S10A13), e uma nova importação dos

templates que continham os problemas será necessária. Se não houver erros, procede-se para a

execução das validações dos dados do banco (atividade P2S10A14). Neste momento, as

situações que não estiverem de acordo com as regras de negócio da empresa deverão ter o

mesmo tratamento dado aos erros de importação.

Na atividade P2S10A16, após confirmar-se a inexistência de erros de validação,

geram-se os índices de controle. Da mesma forma que no Subprocesso 2.9, apesar de não

existirem novos índices na fase dos cortes globais, deve-se manter o controle sobre os ICs

criados em subprocessos anteriores. Se as metas dos ICs não forem atingidas (teste P2S10T3),

deverá verificar-se a existência de erros de dados, bem como ser deflagrado um processo de

correção dos mesmos (P2S10A17). Após a correção dos dados e a confirmação de que

inexistem erros, deve-se rodar o sistema (P2S10A18), atividade que é sucedida pela geração

dos indicadores. O resultado dos mesmos deve ser comparado com as metas estipuladas para

cada um (P2S10T4), sendo que, caso nem todas as metas sejam atendidas, deve-se identificar

e corrigir os erros de dados; senão, prossegue-se no fluxo para a exclusão de todos os dados

populados no Subprocesso 2.10, para que se encaminhe à próxima fase do processo 2.

174

6XESURFHVVR

,PSRUWDURVWHPSODWHV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

9DOLGDURVGDGRVGREDQFR

3 6 $

&RUULJLURVGDGRV

3 6 $

3 6 7

+RXYHHUURVQDV

LPSRUWDo}HV"

3 6 7

([LVWHPHUURV

GHGDGRV"

5RGDURVLVWHPD

3 6 $

*HUDURVtQGLFHVGHFRQWUROH

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

*HUDURVLQGLFDGRUHV

3 6 $

3UHHQFKHUR

WHPSODWHGDV

HVWUXWXUDVGH

HPEDODJHQV

GHWRGDVDV

IiEULFDV

3 6 $

3UHHQFKHUR

WHPSODWH

GRVOHDG

WLPHVH

ORWHV

PtQLPRV

UHDLVGH

VXSULPHQWRV

3 6 $

3UHHQFKHUR

WHPSODWH

GDViUYRUHV

GHFRUWHV

FRPRV

URWHLURVGH

WRGDVDV

IiEULFDV

3 6 $

3UHHQFKHUR

WHPSODWHGH

WRGRVRV

SHGLGRVH

GHPDQGDV

UHDLVGH

FRUWHV

3 6 $

3UHHQFKHU

RWHPSODWH

GRV

HVWRTXHV

LQLFLDLVGH

FRUWHV

3 6 $

3UHHQFKHU

WHPSODWH

GDV

FRPSUDV

GHFRUWHV

ILQDLV

3 6 $

3UHHQFKHU

RWHPSODWH

GDVFXUYDV

GHSHVRGH

WRGDVDV

IiEULFDV

3 6 $

3UHHQFKHU

RWHPSODWH

GDVHVFDODV

HRVOLPLWHV

GHDEDWHV

GHWRGDVDV

IiEULFDV

3 6 $

3UHHQFKHUR

WHPSODWH

GRV

HVWRTXHV

LQLFLDLVGH

VXSULPHQWRV

GHWRGDVDV

IiEULFDV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

3iJ

3UHHQFKHU

WHPSODWH

GDV

FRPSUDV

GH

VXSULPHQ

WRV

3 6 $

3UHSDUDU

DFDUJDGH

GDGRV

FDGDVWUDLV

3 6 $

'DGRV 'DGRV

/RJVGH

HUURV

9DOLGDo}HV

,&V

,QGLFDGRUHV

5HODWyULRV

GRVLVWHPD

175

FIGURA 41 – Fluxograma do Subprocesso 2.10

5.2.2.11 Subprocesso 2.11 – Balanceamento de cortes e formulados (sem abates)

O Subprocesso 2.11 marca o início de um novo grupo de testes, os quais consideram

os dados de todas as fábricas e dos dois tipos de produtos (cortes e formulados) ao mesmo

tempo. A partir desta etapa, portanto, possibilita-se avaliar a programação de pedidos que

possuam produtos cortes e formulados, podendo estes ser programados em mais de uma

fábrica. Com isso, os indicadores de atendimento de pedidos no prazo e de aderência da

programação de produção e de suprimentos poderão ser acompanhados, bem como poderá ser

avaliado o balanceamento entre matérias-primas e produtos finais de cortes, já que as

restrições de MP passam a ser consideradas.

Nesta etapa do método, são considerados os pedidos e previsões de demanda reais,

além dos estoques iniciais de produtos finais e em processo. Os demais (abates, roteiros,

suprimentos e limitações de estoques) serão gradativamente inseridos nos próximos

subprocessos. Uma observação se faz necessária especificamente em relação aos abates: como

um dos objetivos desta etapa é analisar o balanceamento entre a programação de cortes para

pedido e matéria-prima, não se utilizarão as escalas nem os limites mínimos e máximos de

abate, para que o próprio sistema decida o volume necessário que consiga atender à

programação. Desta forma, isolam-se apenas os pedidos e previsões de demanda nos testes

deste subprocesso.

Um esclarecimento se faz necessário também em relação ao indicador de necessidade

versus programação e alocação de matéria-prima (balanceamento): no caso de uma MP

176

possuir irmãs alternativas em árvores de formulação, o cálculo de necessidade acaba ficando

duplicado para determinados produtos, pois, no exemplo citado, qualquer uma das duas MPs

poderia atender à necessidade de programação do produto final formulado. Logo, a análise

das matérias-primas por código deve ser feita de forma ponderada, pois o indicador pode,

inclusive, mascarar problemas. Uma forma para reduzir o efeito disso é analisar a métrica por

meio das famílias de matérias-primas.

Após esta introdução a respeito das características e dos objetivos do Subprocesso

2.11, apresenta-se na Figura 42 o fluxograma do referido subprocesso. Inicialmente,

preenchem-se os templates de dados cadastrais, das árvores de cortes sem os roteiros, das

curvas de peso, dos pedidos e previsões de demanda reais e dos estoques iniciais e compras de

produtos (atividades P2S11A1 a P2S11A6).

Posteriormente, os dados são importados para o sistema, atividade que é sucedida pelo

teste de verificação de erros de importação (P2S11T1). Deste subprocesso até o último (2.15),

não serão listados os exemplos de erros de importação, dado que todos os templates

preenchidos a partir desta fase já foram explorados em subprocessos anteriores.

Caso verificar-se no teste P2S11T1 que existem erros de importação, deve-se proceder

para a correção dos mesmos; se não houver problemas, prossegue-se para a atividade de

validação dos dados (P2S11A9). No Subprocesso 2.11, em função do teste conjunto de

árvores de cortes e de formulação, são aplicáveis novas validações. Abaixo são listados dois

exemplos de validações características desta etapa:

• matéria-prima usada em formulação não está cadastrada em uma árvore de cortes:

esta validação é um alerta, pois uma MP que esteja cadastrada em uma formulação

não necessariamente estará sempre sendo produzida. Por outro lado, é importante

que se verifique cada situação apontada pela validação para que se identifiquem e

corrijam erros de dados;

• matéria-prima usada em formulação não possui habilitação de consumo em uma

fábrica que produza formulados: esta validação também é um alerta e poderia ser

explicada pela mesma razão do primeiro exemplo citado.

177

6XESURFHVVR

,PSRUWDURVWHPSODWHV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

9DOLGDURVGDGRVGREDQFR

3 6 $

&RUULJLURVGDGRV

3 6 $

3 6 7

+RXYHHUURVQDV

LPSRUWDo}HV"

3 6 7

([LVWHPHUURV

GHGDGRV"

5RGDURVLVWHPD

3 6 $

*HUDURVtQGLFHVGHFRQWUROH

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

*HUDURVLQGLFDGRUHV

3 6 $

3UHHQFKHURWHPSODWHGDV

iUYRUHVGHFRUWHVHGH

IRUPXODomRGHWRGDVDVIiEULFDV

VHPRVURWHLURVGHSURGXomR

3 6 $

3UHHQFKHURWHPSODWHGH

WRGRVRVSHGLGRVH

GHPDQGDVUHDLVGHFRUWHV

HGHIRUPXODGRV

3 6 $

3UHHQFKHURWHPSODWH

GRVHVWRTXHVLQLFLDLV

GHWRGRVRVSURGXWRV

H03V

3 6 $

3UHHQFKHUR

WHPSODWHGDV

FRPSUDVGHWRGRV

RVSURGXWRVH03V

3 6 $

3UHHQFKHUR

WHPSODWHGDV

FXUYDVGHSHVRGH

WRGDVDVIiEULFDV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

6XESURFHVVR

([FOXLUWRGRVRVSHGLGRVH

GHPDQGDVUHDLVGHFRUWHV

HGHIRUPXODGRV

3 6 $

([FOXLURVHVWRTXHV

LQLFLDLVGHWRGRVRV

SURGXWRVH03V

3 6 $

([FOXLUDVFRPSUDV

GHWRGRVRV

SURGXWRVH03V

3 6 $

([FOXLUDVFXUYDV

GHSHVRGHWRGDV

DVIiEULFDV

3 6 $

([FOXLUDViUYRUHVGH

FRUWHVHGHIRUPXODomR

GHWRGDVDVIiEULFDV

3 6 $

3UHSDUDUD

FDUJDGH

GDGRV

FDGDVWUDLV

3 6 $

'DGRV

/RJVGH

HUURV

9DOLGDo}HV

,&V

,QGLFDGRUHV

5HODWyULRV

GRVLVWHPD

FIGURA 42 – Fluxograma do Subprocesso 2.11

178

Após a geração das validações, o teste P2S11T2 verifica se existem situações que não

estejam de acordo com as regras de negócio definidas. Caso houver erros, os mesmos deverão

ser corrigidos (P2S11A10); se não existirem problemas nos dados, deve ser feita a geração

dos índices de controle (P2S11A11). No subprocesso 2.11, não existem novos ICs que

mensurem questões específicas desta etapa. Por outro lado, todos os ICs criados em

subprocessos anteriores continuam sendo gerados e acompanhados. O teste P2S11T3 verifica

a conformidade das medições com as metas estabelecidas. Caso as mesmas não forem

atingidas, devem-se identificar e corrigir os erros; caso contrário, o sistema deverá ser rodado

(P2S11A13). Os resultados deste processo devem ser avaliados com o apoio de indicadores.

Nesta etapa do método, medições de outros subprocessos são utilizadas, além de um novo

indicador – o de alocação versus necessidade de matérias-primas. Com isso, possibilita

verificar se todo o volume necessário de todas as MPs para a programação de pedidos e

previsões de demanda de formulados está sendo alocado a estes produtos.

Caso as metas dos indicadores gerados não alcancem as metas desejadas (P2S11T4),

realiza-se um processo de identificação e de correção de erros nos dados; senão, encaminha-se

para o final do Subprocesso 2.11, no qual se realizam as exclusões de todos os dados

utilizados nos testes da referida etapa (atividades P2S11A16 a P2S11A20).

5.2.2.12 Subprocesso 2.12 – Balanceamento de cortes e formulados (com abates)

Após a realização dos primeiros testes com árvores de cortes e de formulação de todas

as fábricas de forma simultânea, o Subprocesso 2.12 dá continuidade a isso, tendo como

principal objetivo a avaliação dos indicadores após a importação das escalas e limites de

abates. Com isso, deseja-se verificar a influência do abate empurrado (no caso das escalas e

dos limites mínimos) sobre a programação de pedidos, a aderência de produção e o

balanceamento de produtos finais e matérias-primas.

Na Figura 43, visualiza-se o fluxograma do Subprocesso 2.12, no qual se utilizam os

mesmos dados da etapa anterior, com a diferença do preenchimento e importação dos

templates de abates e das curvas de peso (atividades P2S12A1 a P2S12A7). No teste

P2S12T1, verifica-se a ocorrência de erros de importação, os quais, se confirmados, devem

ser corrigidos; caso contrário, prossegue-se no fluxo para a geração das validações das regras

de negócio (P2S12A10).

179

6XESURFHVVR

,PSRUWDURVWHPSODWHV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

9DOLGDURVGDGRVGREDQFR

3 6 $

&RUULJLURVGDGRV

3 6 $

3 6 7

+RXYHHUURVQDV

LPSRUWDo}HV"

3 6 7

([LVWHPHUURV

GHGDGRV"

5RGDURVLVWHPD

3 6 $

*HUDURVtQGLFHVGHFRQWUROH

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

*HUDURVLQGLFDGRUHV

3 6 $

3UHHQFKHUR

WHPSODWHGHWRGRVRV

SHGLGRVHGHPDQGDV

UHDLVGHFRUWHVHGH

IRUPXODGRV

3 6 $

3UHHQFKHUR

WHPSODWHGRV

HVWRTXHVLQLFLDLV

GHWRGRVRV

SURGXWRVH03V

3 6 $

3UHHQFKHUR

WHPSODWHGDV

FRPSUDVGH

WRGRVRV

SURGXWRVH03V

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

3UHHQFKHUR

WHPSODWHGDV

HVFDODVHOLPLWHV

GHDEDWHVGH

WRGDVDVIiEULFDV

3 6 $

3UHHQFKHURWHPSODWH

GDViUYRUHVGHFRUWHVH

GHIRUPXODomRGHWRGDV

DVIiEULFDV VHPRV

URWHLURVGHSURGXomR

3 6 $

3UHHQFKHUR

WHPSODWHGDV

FXUYDVGH

SHVRGHWRGDV

DVIiEULFDV

3 6 $

6XESURFHVVR

([FOXLUDViUYRUHVGH

FRUWHVHGHIRUPXODomR

GHWRGDVDVIiEULFDV

3 6 $

([FOXLUWRGRVRVSHGLGRV

HGHPDQGDVUHDLVGH

FRUWHVHGHIRUPXODGRV

3 6 $

([FOXLURVHVWRTXHV

LQLFLDLVGHWRGRVRV

SURGXWRVH03V

3 6 $

([FOXLUDVFRPSUDV

GHWRGRVRV

SURGXWRVH03V

3 6 $

([FOXLUDVHVFDODVH

RVOLPLWHVGHDEDWHV

GHWRGDVDVIiEULFDV

3 6 $

([FOXLUDVFXUYDV

GHSHVRGHWRGDV

DVIiEULFDV

3 6 $

3UHSDUDUD

FDUJDGH

GDGRV

FDGDVWUDLV

3 6 $

'DGRV

/RJVGH

HUURV

9DOLGDo}HV

,&V

,QGLFDGRUHV

5HODWyULRV

GRVLVWHPD

FIGURA 43 – Fluxograma do Subprocesso 2.12

180

Neste ponto do método, existe uma validação do tipo alerta que é útil para a

identificação de erros no cadastro de matérias-primas quando são feitos testes com as escalas

de abates. A mensagem gerada pela validação informa se existem MPs que estejam

cadastradas em árvores de formulação, porém as árvores de cortes onde estão habilitadas não

possuem escala de abate. Assim, permite-se que situações de erros na escala de abate ou

mesmo nas árvores possam ser identificadas.

O teste P2S12T2 avalia se existem erros de validação. Caso isso for confirmado, os

dados devem ser corrigidos na fonte primária; senão, geram-se os índices de controle

(P2S12A12). Neste ponto do Subprocesso 2.12, inexistem novos ICs, porém todos os outros

criados nos demais subprocessos devem ser utilizados. Se nem todas as metas dos ICs forem

atingidas, o que é checado no teste P2S12T3, deve-se analisar cada caso para que se

identifiquem e se corrijam erros de dados. Caso contrário, o sistema deverá ser rodado

(P2S12A14), e os resultados gerados pelo mesmo submetidos aos indicadores propostos.

Da mesma forma que na avaliação dos ICs, se houver metas não alcançadas, devem-se

identificar os erros de dados e corrigi-los (P2S12A16). Caso contrário, o Subprocesso 2.12

chega ao seu final, faltando apenas a exclusão de todos os dados populados nesta fase do

método (atividades P2S12A17 a P2S12A22).

5.2.2.13 Subprocesso 2.13 – Capacidades finitas de cortes e formulados

No Subprocesso 2.13, a fim de manter-se o propósito de testar os dados de forma

incremental, são adicionados os roteiros produtivos (recursos, calendários e tempos de

processo). Nesta fase do método, é possível medir o atendimento de pedidos no prazo, dado

que os roteiros estabelecem limites para a programação da produção. Assim como nos

subprocessos 2.3 e 2.8, nos quais se realizam testes com as capacidades finitas de formulados

e cortes, respectivamente, os roteiros são agregados neste momento pelo seguinte motivo: nos

Subprocessos 2.11 e 2.12, testou-se a destinação da massa cárnea proveniente dos abates e das

compras de MPs para a programação de formulados e cortes. Logo, garantiu-se para esta

etapa a acuracidade dos dados de árvores de cortes e de formulação.

A Figura 44 apresenta o fluxograma do Subprocesso 2.13. Inicialmente, preenchem-se

os templates dos dados que serão considerados nos testes (atividades P2S13A1 a P2S13A7),

etapa que será sucedida pela importação dos arquivos para o banco.

181

FIGURA 44 – Fluxograma do Subprocesso 2.13

182

O teste P2S13T1 verifica a ocorrência de erros neste processo – caso houver

problemas, os mesmos devem ser corrigidos, sendo necessária uma nova importação dos

templates que continham os dados errados. Senão, prossegue-se no fluxo para a geração das

validações (P2S13A10). Se forem encontrados erros de dados, deve-se corrigi-los na fonte

primária. Caso contrário, submete-se a base de dados aos índices de controle (P2S13A12).

Neste ponto do Subprocesso 2.13, não existem novos ICs, sendo necessário, no entanto,

manter-se o acompanhamento dos já existentes. Após esta atividade, o teste P2S13T3 verifica

a conformidade dos dados em relação às metas estabelecidas. Caso nem todas as metas sejam

alcançadas, devem-se identificar os erros de dados e corrigi-los. Senão, o sistema deve ser

rodado (P2S13A14).

Após a rodada, os resultados gerados pelo sistema são submetidos aos indicadores

criados com a finalidade de mensurar a adequação das informações às metas estabelecidas

(P2S13T4).

Caso as metas não tenham sido atingidas, realiza-se um processo de análise e de

correção de erros de dados (P2S13A16). No momento em que todas as metas forem atingidas,

prossegue-se para o final do Subprocesso 2.13, o qual contempla a exclusão de todos os dados

utilizados (P2S13A17 a P2S13A22).

5.2.2.14 Subprocesso 2.14 – Suprimentos de cortes e formulados

O penúltimo subprocesso do método proposto caracteriza-se pela habilitação das

restrições dos suprimentos utilizados no cortes e formulados. Nesta etapa, aplicam-se os

mesmos índices de controle e indicadores da etapa anterior, porém com a introdução de dados

que aproximam a programação gerada pelo sistema à realidade da produção. Estes dados

referem-se aos estoques iniciais, às compras e à habilitação dos lead times e lotes mínimos

reais de suprimentos, bem como às necessidades de embalagens por produto.

Na Figura 45, apresenta-se o fluxograma do Subprocesso 2.14, o qual tem início com

o preenchimento dos templates dos dados que devem ser utilizados nos testes (atividades

P2S14A1 a P2S14A11). Posteriormente, importam-se os arquivos para o sistema de

programação da produção e verifica-se a ocorrência de erros neste processo (teste P2S14T1).

Caso houver problemas, deve-se proceder para a identificação e correção dos erros de dados.

Senão, geram-se as validações do banco (P2S14A14).

183

6XESURFHVVR

,PSRUWDURVWHPSODWHV

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

9DOLGDURVGDGRVGREDQFR

3 6 $

&RUULJLURVGDGRV

3 6 $

3 6 7

+RXYHHUURVQDV

LPSRUWDo}HV"

3 6 7

([LVWHPHUURV

GHGDGRV"

5RGDURVLVWHPD

3 6 $

*HUDURVtQGLFHVGHFRQWUROH

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

*HUDURVLQGLFDGRUHV

3 6 $

3UHHQFKHUR

WHPSODWHGH

WRGRVRV

SHGLGRVH

GHPDQGDV

UHDLVGH

FRUWHVHGH

IRUPXODGRV

3 6 $

3UHHQFKHU

WHPSODWH

GRV

HVWRTXHV

LQLFLDLVGH

WRGRVRV

SURGXWRV

H03V

3 6 $

3UHHQFKHU

WHPSODWH

GDV

FRPSUDV

GHWRGRV

RV

SURGXWRV

H03V

3 6 $

,GHQWLILFDUH

FRUULJLURVHUURV

3 6 $

3 6 7

$VPHWDVIRUDP

DWLQJLGDV"

3UHHQFKHU

RWHPSODWH

GDVHVFDODV

HOLPLWHVGH

DEDWHVGH

WRGDVDV

IiEULFDV

3 6 $

3UHHQFKHU

RWHPSODWH

GDViUYRUHV

GHWRGDVDV

IiEULFDV

FRPRV

URWHLURVGH

SURGXomR

3 6 $

3UHHQFKHU

WHPSODWH

GDVFXUYDV

GHSHVR

GHWRGDV

DVIiEULFDV

3 6 $

3UHHQFKHU

RWHPSODWH

GRV

HVWRTXHV

LQLFLDLVGH

VXSULPHQ

WRV

3 6 $

3UHHQFKHU

WHPSODWH

GDV

HVWUXWXUDV

GHHPEDOD

JHQVGH

WRGRVRV

SURGXWRV

3 6 $

3UHHQFKHU

WHPSODWH

GRVOHDG

WLPHVHORWHV

PtQLPRV

UHDLVGH

VXSULPHQ

WRV

3 6 $

3UHHQFKHU

WHPSODWH

GDV

FRPSUDV

GH

VXSULPHQ

WRV

3 6 $

3iJ

3UHSDUDU

DFDUJDGH

GDGRV

FDGDVWUDLV

3 6 $

'DGRV

/RJVGH

HUURV

9DOLGDo}HV

,&V

,QGLFDGRUHV

5HODWyULRV

GRVLVWHPD

184

6XESURFHVVR

([FOXLUDV

iUYRUHVH

URWHLURV

GHWRGDV

DV

IiEULFDV

3 6 $

([FOXLUWRGRV

RVSHGLGRVH

GHPDQGDV

UHDLVGH

FRUWHVHGH

IRUPXODGRV

3 6 $

([FOXLURV

HVWRTXHV

LQLFLDLVGH

WRGRVRV

SURGXWRV

H03V

3 6 $

([FOXLUDV

FRPSUDV

GHWRGRV

RV

SURGXWRV

H03V

3 6 $

([FOXLUDV

HVFDODVH

OLPLWHV

GHDEDWHV

GHWRGDV

DVIiEULFDV

3 6 $

([FOXLUDV

FXUYDV

GHSHVR

GHWRGDV

DV

IiEULFDV

3 6 $

3iJ

([FOXLURV

HVWRTXHV

LQLFLDLVGH

VXSULPHQ

WRV

3 6 $

([FOXLUDV

HVWUXWXUDV

GHHPEDOD

JHQVGH

WRGRVRV

SURGXWRV

3 6 $

([FOXLURV

OHDG WLPHV

HORWHV

PtQLPRV

GHVXSUL

PHQWRV

3 6 $

([FOXLUDV

FRPSUDV

GHVXSUL

PHQWRV

3 6

([FOXLUDV

FDSDFL

GDGHV

HOHYDGDV

GH

HVWRTXHV

3 6 $

FIGURA 45 – Fluxograma do Subprocesso 2.14

Após esta atividade, verifica-se no teste P2S14T2 se existem situações que não

estejam de acordo com as regras de negócio estabelecidas. Se forem encontrados erros nos

dados, os mesmos deverão ser corrigidos na fonte primária. Caso contrário, prossegue-se no

fluxo para a geração dos índices de controle (P2S14A16), os quais, conforme mencionado na

introdução desta seção, não possuem novidades. Apesar disso, os resultados dos ICs criados

em subprocessos anteriores devem ser avaliados (P2S14T3) para que se identifiquem e

corrijam erros (se os mesmos existirem).

No momento em que as metas dos ICs forem alcançadas, o sistema deve ser rodado

(P2S14A18). Após esta atividade, geram-se os indicadores de resultado da ferramenta de

programação da produção (P2S14A19), os quais devem ser confrontados com as metas

definidas. Caso nem todos os indicadores atingirem as suas metas, deverá ser feito um

processo de identificação e de correção de erros de dados (P2S14A20). Senão, prossegue-se

para o final do Subprocesso 2.14, no qual são excluídos todos os dados utilizados nos testes

desta fase (P2S14A21 a P2S14A31), inclusive as capacidades elevadas de estoques, tendo em

vista que no próximo subprocesso são testadas as limitações de estocagem.

5.2.2.15 Subprocesso 2.15 – Cortes e formulados global

O último subprocesso do método proposto para a melhoria da acuracidade dos dados

de um sistema de programação da produção caracteriza-se por testar todos os parâmetros

utilizados nos demais subprocessos de forma simultânea. Além disso, introduzem-se no

Subprocesso 2.15 as capacidades reais de estoques. A consideração destes dados auxiliará na

185

avaliação do balanceamento entre pedidos e demandas, bem como da própria programação de

estoques, sendo que o principal indicador deste subprocesso será a ocupação de estocagem.

O fluxograma das atividades e testes do Subprocesso 2.15 é apresentado na Figura 46.

Como em todas as outras fases do Processo 2, preenchem-se os templates dos dados que serão

submetidos às validações e aos índices de controle e indicadores (P2S15A1 a P2S15A12).

Após estas atividades, realiza-se a importação dos dados para o banco do sistema, a qual é

sucedida pelo teste P2S15T1, o qual verifica se houve erros no procedimento. Se houver

problemas, os mesmos deverão ser solucionados. Caso contrário, as validações do sistema

deverão ser rodadas (P2S15A15) para que se identifiquem situações que não estejam de

acordo com as regras de negócio estabelecidas. Se houver casos que se enquadrarem nesta

condição, os dados deverão ser corrigidos; caso contrário, prossegue-se no fluxo para a

geração dos índices de controle (P2S15A17).

Caso as metas dos ICs não forem atingidas, o que é verificado pelo teste P2S15T3,

procede-se para a identificação e correção de erros os dados (P2S15A18). Já no caso de as

metas de todos os ICs terem sido alcançadas, deve-se rodar o sistema (P2S15A19), cujos

resultados devem medidos por meio de indicadores. Estes, por sua vez, são comparados no

teste P2S15T4 com as metas estabelecidas para cada um. Caso nem todas as metas forem

atingidas, realiza-se um processo de análise no qual se identifiquem e corrijam os erros de

dados (P2S15A21). Por outro lado, no momento em que as metas de todos os indicadores

forem alcançadas, homologa-se o sistema de programação da produção.

186

FIGURA 46 – Fluxograma do Subprocesso 2.15

187

5.3 Fatores Críticos de Sucesso para a aplicação do método tentativo

Após a definição dos pressupostos e das estratégias para o desenvolvimento do método

tentativo, bem como o detalhamento das etapas da proposta, são relacionados nesta seção os

Fatores Críticos de Sucesso (FCS) para a aplicação do método. O delineamento destes

elementos estabelece as condições gerenciais necessárias e de estrutura de sistemas para a

utilização do método em processos de implementação da ferramenta de programação da

produção pesquisada. Portanto, os FCS não contemplam as atividades pós-homologação do

sistema, as quais englobam a manutenção dos dados. A seguir, detalham-se todos os Fatores

Críticos de Sucesso elencados, os quais foram abordados em ordem de importância, sendo os

primeiros aqueles que deveriam ter maior atenção em projetos de implementação do sistema

pesquisado.

A função do gerente de projeto é de fundamental importância para o sucesso da

aplicação do método. Dele devem partir iniciativas que busquem assegurar o rigor

metodológico da proposta, caso contrário as demais ações e FCS não surtirão efeito. Portanto,

considera-se a figura e a pró-atividade do gerente de projeto, senão a mais importante, uma

das que mais influenciam no sucesso da aplicação do método. Existem três questões que

resumem as atribuições deste profissional: garantir o apoio do patrocinador do projeto, a

gestão de uma equipe de projeto e a governança sobre os dados. Nestas atribuições,

englobam-se as seguintes tarefas:

• alinhamento das atividades junto ao patrocinador do projeto;

• planejamento da execução do método;

• estruturação e motivação de uma equipe de projeto;

• conscientização dos futuros usuários-chave do sistema quanto à necessidade de os

dados serem acurados;

• a mudança de processos de negócio para que os mesmos atendam ao fluxo de dados

necessário para o sistema; e

• realização de reuniões regulares com a equipe de projeto e os usuários-chave para

acompanhar o status das atividades desenvolvidas e os resultados dos indicadores

propostos no método.

188

O apoio do patrocinador do projeto deve ser garantido para que os profissionais que

participam da implementação do sistema compreendam as expectativas da empresa, a

importância das atividades e se motivem para o sucesso da ferramenta. Neste sentido, é

importante que o gerente de projeto alinhe junto ao patrocinador o status das tarefas

executadas e os resultados alcançados. Em outras palavras, o profissional deve possuir um

canal de comunicação com o patrocinador para que se promovam as mudanças necessárias

com o apoio dos colaboradores que compõem a equipe de projeto.

Dentre as incumbências do gerente de projeto, ressalta-se a necessidade de os

subprocessos sugeridos pelo método possuírem um planejamento que garanta a alocação dos

recursos materiais e humanos necessários. Assim, evita-se a perda de tempo na transição entre

os subprocessos ou mesmo durante a execução dos mesmos.

No que diz respeito à formação de uma equipe de projeto, é necessária a participação

de pessoas capacitadas, que possuam reconhecido conhecimento sobre a programação de

produção da empresa. Além disso, estes profissionais devem dedicar-se ao projeto conforme o

acordado antes de os mesmos entrarem na equipe. Este acordo é importante para que se

garanta a alocação das pessoas às atividades. Neste sentido, as chefias dos membros que

forem “emprestados” para o projeto devem ser sensibilizadas para que os profissionais

possam se dedicar exclusivamente ao projeto.

Já o ambiente de projeto no qual as atividades da equipe serão desenvolvidas deve ser

provido de uma estrutura na qual seja possível realizar os testes no sistema de forma

adequada. Essa estrutura deve contemplar tanto um local adequado quanto a disponibilidade

de ferramentas de sistema e de equipamentos de informática dotados da tecnologia necessária

para o pleno andamento das atividades. Este fator revela-se importante na medida em que

pode agilizar os testes no sistema de programação da produção, reduzindo o tempo de

execução das tarefas.

Dentre as principais incumbências do gerente de projeto, resta delinear o

estabelecimento de uma governança sobre os dados. O escopo desta iniciativa deve

contemplar um conjunto de ações em torno da conscientização de usuários do sistema, da

mudança de processos de negócio, da gestão de indicadores e da realização de reuniões para

acompanhamento do status do projeto.

A conscientização dos futuros usuários-chave do sistema em relação à necessidade

da manutenção de uma base de dados acurada deve ser feita a partir do momento em que estes

189

profissionais passarem a fazer parte da equipe de projeto. De forma complementar, as pessoas

deverão conhecer os impactos que a acuracidade dos dados pode ter sobre a qualidade das

informações geradas pelo sistema de seqüenciamento da produção. Dentre estes impactos,

poderão ser ressaltados os de menor escala (como a alteração do mix de uma família produto

cujo volume seja irrisório no dia-a-dia) até aqueles que influenciarão nas decisões de outras

áreas que dependerão das informações do sistema. Exemplos dessa situação são a compra

desnecessária de embalagens, o atraso na entrega de pedidos e a alteração na programação de

produção de outras fábricas quando houver erros nas formulações de produtos cujas matérias-

primas sejam produzidas nas referidas unidades.

A partir do envolvimento dos usuários no projeto, é necessário que se definam as

responsabilidades de cada um. Estas funções deverão estar relacionadas ao compromisso

com a manutenção dos dados inseridos no sistema durante a etapa de projeto, bem como com

a identificação e solução de problemas. Paralelamente a esta definição, deve-se criar o papel

do guardião dos dados, ou administrador da qualidade de dados, conforme denominam Wang,

Kon e Madnick (1993). Os pré-requisitos para esta função deveria ser o reconhecido

conhecimento sobre o sistema (para que possa prestar suporte aos usuários) e a capacidade de

identificar pontos de alavancagem para a melhoria dos dados do sistema. Este profissional

cumpriria uma função de auditoria dos dados, conforme sugerem Dasu e Johnson (2003),

além de acompanhar os índices de controle e os resultados dos indicadores propostos pelo

método. Em vez de preocupar-se com a rotina de manutenção dos dados do sistema e a

programação gerada pelo mesmo, este profissional deveria aprimorar os dados e treinar os

usuários.

No escopo da governança sobre os dados, deve constar a liderança (negociação) do

gerente de projeto em torno da mudança de processos de negócio junto a áreas da empresa

que sejam responsáveis pelos dados que serão utilizados no sistema de PCP. Ambas as partes

(gerente e áreas) deverão agir no sentido da discussão das mudanças e na padronização das

rotinas no momento em que forem efetivadas as alterações.

O terceiro e o quarto itens da governança sobre os dados referem-se à garantia da

aplicação dos indicadores propostos no método, bem como a realização de reuniões para

verificar o status das atividades realizadas e os resultados dos indicadores em relação às

metas. Com relação às medições, é necessário que o gerente de projeto divulgue claramente as

metas para todos os usuários, atribuindo responsáveis e prazos de execução para os casos em

que os indicadores não atingirem as metas.

190

Durante as reuniões, devem ser compartilhados os erros de dados encontrados pelos

usuários e as respectivas ações tomadas para a correção dos mesmos. Dessa forma, gera-se

aprendizagem de modo que se forneçam subsídios para a identificação de futuras

oportunidades de melhoria nos dados. A formalização das discussões deve ser feita por meio

do estabelecimento de planos de ação, os quais deverão ser cobrados pelo gerente de projeto

junto aos responsáveis no prazo estipulado.

Após tratar sobre as atribuições relacionadas ao gerente de projeto, são relacionados a

partir deste ponto outros Fatores Críticos de Sucesso. Parte dos FCS a serem discutidos

também depende da gestão do gerente de projeto, porém em menor grau em relação aos

aspectos mencionados nos parágrafos anteriores.

A multiplicação do conhecimento sobre o sistema igualmente contribui para a

aplicação do método, relacionando-se intrinsecamente à capacitação dos usuários e ao

incentivo para que os colaboradores desenvolvam atividades na ferramenta. O fator

conhecimento pode ser desenvolvido por meio da realização de treinamentos e da

disponibilização de material de apoio (manuais), enquanto que o fator incentivo pode ser

explorado por meio da motivação dos usuários (e não somente vindo do gerente de projeto,

como também dos gestores cujas áreas serão afetadas pelo sistema). Esta mobilização permite

a criação de um ambiente de aprendizagem no qual possa haver troca de experiências e o

estabelecimento de uma visão compartilhada sobre o sistema. Neste contexto, deve-se

ressaltar a importância da acuracidade dos dados para a ferramenta.

Do ponto de vista da aplicação do método nos casos em que houver a possibilidade de

realizar atividades por mais de um grupo de usuários (como nos subprocessos que testam

fábrica por fábrica, por exemplo), o paralelismo é válido para agilizar a execução dos testes.

Dessa forma, reduz-se o tempo despendido na execução do método.

A infra-estrutura de Tecnologia da Informação influencia na fidedignidade dos

dados em função das integrações entre bases de dados corporativas (ERP, por exemplo) e o

sistema de seqüenciamento da produção. Os dados populados na base devem estar de acordo

com a fonte de onde são importados, bem como estar no local e no momento corretos

(conforme a especificação). Neste ínterim, o desenvolvimento de mensagens automáticas que

informem a ocorrência de falhas nas cargas de dados (os chamados logs) auxilia na detecção

de erros no processo de população da base de dados do sistema de PCP.

191

Por fim, outro fator crítico de sucesso diz respeito à disponibilidade, na ferramenta de

seqüenciamento da produção, de uma inteligência de identificação de erros de dados na

base. Existem erros cujo padrão de comportamento é passível de ser filtrado por meio deste

tipo de mecanismo, o que facilita o processo de identificação de problemas pelo usuário.

5.4 Considerações finais do capítulo

O capítulo 5 caracterizou-se pelo delineamento do método proposto para a melhoria da

acuracidade dos dados do sistema de seqüenciamento da produção pesquisado. Dentre os

tópicos abordados no capítulo, contemplaram-se a definição dos pressupostos e das estratégias

para o desenvolvimento da proposta, a apresentação do método tentativo e o estabelecimento

dos Fatores Críticos de Sucesso para a implementação do mesmo.

A definição dos pressupostos possibilitou que se elencassem as delimitações do

método e as premissas inerentes ao desenvolvimento do mesmo. A partir disso, apresentaram-

se as 7 estratégias utilizadas para a efetivação dos pressupostos (prevenção, parcimônia, nível

de complexidade da modelagem dos dados, exposição dos dados, validações, medições e a

lógica de priorização das análises).

Depois de definidos os pressupostos e estratégias, apresentou-se o método proposto, o

qual foi estruturado sob a forma de processos e subprocessos, hierarquização que possibilitou

a divisão dos agrupamentos de atividades testes em torno de rotinas de identificação e de

correção de erros dos dados. As contribuições obtidas por meio das entrevistas realizadas com

experts na temática do estudo foram incorporadas ao método, sendo que as sugestões feitas

são detalhadas no Apêndice C. Do ponto de vista da aplicação dos conceitos explorados no

referencial teórico, foram selecionados para o desenvolvimento do método aqueles referentes

• estruturas de dados necessária para um sistema de programação da produção;

• escolha do nível de detalhamento da modelagem dos dados;

• medidas estatísticas de dispersão;

• definição das regras de negócio;

192

• identificação das fontes dos erros, utilizando o Princípio de Pareto;

• indicadores de resultado; e

• abordagem metodológica por processos.

Por fim, os Fatores Críticos de Sucesso estabeleceram os requisitos necessários para a

aplicação bem sucedida do método proposto, os quais possuíam questões gerenciais e de

estrutura física e de sistemas. Dentre os aspectos gerenciais, destacaram-se a função do

gerente de projeto e a estruturação de um processo de governança sobre os dados. Já a

estrutura evidenciou a importância do apoio da área de Tecnologia da Informação e da

existência de um local adequado para as atividades da equipe de projeto.

6 CONCLUSÃO E RECOMENDAÇÕES PARA TRABALHOS FUTUROS

Neste capitulo, encaminham-se a conclusão e as recomendações para futuras pesquisas

deste estudo. A primeira é composta por inferências do autor a respeito dos resultados do

trabalho. Já as recomendações constituem-se de idéias que não fizeram parte do escopo da

pesquisa ou que surgiram durante o desenvolvimento do estudo.

6.1 Conclusão

A discussão acerca da temática da qualidade de dados oportunizada por este estudo

expôs a importância do tratamento de erros de dados, como também o impacto deste tipo de

problema nas informações necessárias para a tomada de decisão sobre a programação de

produção. O caso relatado da Empresa Alfa possibilitou que se analisasse uma experiência

real da implementação de um sistema que foi impactada pela qualidade dos dados inseridos na

ferramenta. O efeito deste problema materializou-se através do atraso do projeto do sistema

de programação de produção. Além disso, a inexistência de um rigor metodológico nas fases

iniciais dos testes da ferramenta fez com que se perdesse tempo tentando-se identificar os

erros sem um foco definido. Ao passo que os resultados gerados pelo sistema não eram

confiáveis, a credibilidade do mesmo era questionada, o que prejudicava a sustentabilidade do

projeto. Este encadeamento de eventos reforçadores partiu dos erros nos dados de entrada da

ferramenta, o que demonstra o risco a que se submeteu a implementação do projeto.

Diante da percepção do comportamento destes eventos, procurou-se neste trabalho

fortalecer a importância da etapa de projeto para o tratamento dos erros de dados. Os

problemas decorrentes das inacuracidades impossibilitaram a utilização do sistema no prazo

planejado, logo devem-se direcionar os esforços para que ações sejam tomadas de forma

adequada sobre os erros.

A partir da constatação do problema da acuracidade dos dados e, principalmente, da

magnitude do mesmo, acredita-se que o método proposto seja uma forma de adotar-se um

posicionamento metodológico perante os dados. Antes mesmo da coleta dos dados, as

194

atividades de definição do modelo conceitual e de requisitos de dados contribuem para a

prevenção de futuros erros, tais como templates preenchidos de forma errada. Posteriormente,

a estruturação dos dados, a definição dos mecanismos de auto-validação e os testes de

importação de dados valorizam o processo de preparação dos dados.

O trabalhou não se limitou ao desenvolvimento do método em si, como também

contemplou o detalhamento dos pressupostos e das estratégias do mesmo, além dos Fatores

Críticos de Sucesso. Enquanto que os primeiros aspectos referiram-se a uma etapa anterior ao

desenvolvimento do método, os FCS possibilitaram que se estabelecessem os requisitos

necessários para a aplicação do mesmo. Desta forma, forneceu-se ao método uma consistência

para que possa ser testado em outros casos que envolvam a implementação do mesmo sistema

utilizado nesta pesquisa.

Apesar de reconhecer-se que todos os itens relatados anteriormente são importantes às

conclusões do estudo, entende-se que as maiores contribuições deste trabalho residem nas

seguintes questões:

• a adoção do Princípio da Parcimônia na estruturação do método;

• a criação de medições específicas para os dados de entrada e os de saída do sistema,

sendo que estes remetiam para a qualidade dos dados de entrada; e

• o direcionamento da discussão da acuracidade de dados para o ambiente de

manufatura, mais especificamente a programação da produção.

O emprego do Princípio da Parcimônia durante o processo de população e melhoria da

acuracidade dos dados permitiu que se tratassem paulatinamente, e em uma seqüência lógica,

os dados necessários para o sistema. Dentre as referências pesquisadas na área da qualidade

de dados e de informações, não se identificaram casos em que este princípio foi aplicado. A

vantagem da parcimônia no método proposto é a possibilidade de se isolarem determinados

fatores durante a execução dos subprocessos. Assim, torna-se menos complexa a busca por

erros de dados.

A segunda contribuição do estudo diz respeito ao desenvolvimento de medições para

os dados de entrada do sistema (índices de controle) e também para os resultados gerados pela

ferramenta (indicadores). Apesar de terem sido identificadas referências que discutissem a

utilização de medições, o método tem como mérito a utilização uma lógica de priorização das

análises apoiando as medições. Isso possibilita que os ICs ou indicadores cujas metas não

sejam atingidas passem por uma análise que auxilia na identificação dos erros de dados. De

195

forma complementar, o uso associado das medições e da análise das mesmas evita que se

procure melhorar a acuracidade de todos os dados do sistema até que os resultados sejam

satisfatórios, tendo em vista as prioridades que se sugerem adotar durante o processo de

análise.

Por fim, o terceiro mérito do trabalho relaciona-se com a estruturação de uma

abordagem voltada especificamente para a programação de produção de alimentos cárneos.

Dentre todas as referências pesquisadas, não se identificou um método propriamente dito que

direcionasse a temática da qualidade de dados para a área de manufatura. Este argumento

corrobora com a opinião de David Loshin (2001), o qual entende que as ferramentas de

qualidade de dados possuem uma tendência de tratar a limpeza de erros nos dados de nomes e

endereços.

6.2 Recomendações para trabalhos futuros

Nesta seção do último capítulo do trabalho, são elencadas sugestões de pesquisas que

poderão ser realizadas a partir de questões não exploradas por estarem fora do escopo ou por

terem sido identificadas ao longo do estudo. As recomendações para trabalhos futuros

compreendem testes do método proposto, o desenvolvimento de abordagens similares em

múltiplos casos, o tratamento dos dados após a homologação do sistema, a aplicação de

fundamentos tecnológicos e a avaliação dos dados de programação da produção sob outras

dimensões da qualidade de dados.

A realização de testes com o método proposto em outras organizações do ramo de

alimentos cárneos, desde que se utilizando do mesmo sistema de programação da produção,

contribuiria para uma validação ainda maior do método. Em uma situação desse tipo, seria

verificada a consistência da proposta metodológica, o que poderia refletir na melhoria do

método.

Uma alternativa parecida para a recomendação feita no parágrafo anterior seria a

aplicação de estudos de casos múltiplos em empresas do mesmo setor (indústria cárnea).

Nesta opção, a utilização do mesmo sistema de seqüenciamento utilizado neste trabalho não

seria um pré-requisito. Dessa forma, com as contribuições das diferentes experiências de

196

empresas cárneas e dos diferentes sistemas considerados, poderia ser desenvolvido um

modelo de referência para a melhoria da acuracidade dos dados de programação da produção

da indústria cárnea, independentemente da ferramenta.

Diferentemente do foco deste estudo, o qual contemplou apenas a etapa de projeto da

implementação de um sistema de seqüenciamento da produção, poderia ser criado um método

que considerasse o período pós-homologação da ferramenta. Ou seja, o foco de uma proposta

desse tipo sairia do ambiente de projeto e entraria para o processo de manutenção dos dados

no dia-a-dia. Neste caso, seriam considerados os dados de realização de pedidos (aquilo que

foi entregue ao cliente) e os de produção realizada, por exemplo, os quais servem para que o

sistema recalcule as programações futuras em função de inaderências ao plano.

Uma abordagem que traria benefícios para a prevenção dos erros de dados seria a

atuação sobre os processos que geram os dados, tratando-se, portanto, o erro, e não o defeito.

Esta possibilidade contribuiria para tornar os processos confiáveis e sustentáveis do ponto de

vista da qualidade dos dados. Um estudo desse porte poderia contemplar questões como as

fontes geradoras dos dados (critérios de coleta e de geração dos dados) e os fluxos de dados

entre a armazenagem, a transmissão e a recepção dos mesmos pelo sistema de programação

da produção.

O desenvolvimento de abordagens tecnológicas que visassem a construção de

inteligências de identificação de erros contribuiria para a melhoria da acuracidade dos dados,

como também possivelmente para a redução do tempo necessário em relação ao método

proposto, por exemplo. Neste caso, deveria ser avaliado o trade-off entre os custos

decorrentes deste tipo de customização e os benefícios do mesmo.

Por fim, outra possibilidade de pesquisa seria a avaliação das demais dimensões da

qualidade de dados (além da acuracidade), conforme classificação do TDQM. Um trabalho

deste porte poderia desenvolver um indicador que representasse todas as dimensões, ou seja,

que fosse capaz de mensurar a verdadeira qualidade de um dado.

REFERÊNCIAS

ABEF. Exportação mundial de carne de frango – principais países (2000-2007).

Disponível em: <http://www.abef.com.br/noticias_portal/exibenoticia.php?notcodigo=74>.

Acesso em: 23 fev. 2008.

BAIR, John; SHAH, Faisal; KRIGELMAN, Ken; SANDLER, Eric; HOSS, Dorinne (2004).

A practical approach do data quality. Disponível em:

<www.geocities.com/ohakano/dss/dw/dataquality.pdf> Acesso em: 3 ago 2008.

BONJOUR, Eric; BAPTISTE, Pr. Pierre; LARCHEVÈQUE, David. Data quality and

flowshop scheduling results. Proceeding of the 6

IEEE International Conference on

Emerging Technologies and Factory Automation. Los Angeles, 1997.

BORTOLAZZA, Rodrigo Cremonesi. Contribuições para a coleta e análise de dados de

PCP em empresas de construção. Dissertação (Mestrado em Engenharia Civil).

PPGEC/UFRGS, 2006.

CLEMENT, Jerry; COLDRICK, Andy; SARI, John. Manufacturing data structures:

building foundations for excellence with bill of materials and process information. New

York: Wiley, 1992.

DAOUD, Marcel Amaral; MAÇADA, Antonio Carlos Gastaud. Análise e proposta de um

modelo de planejamento e controle da produção para as indústrias de beneficiamento de

arroz da região sul do RS. In: XXV ENCONTRO NACIONAL DE ENGENHARIA DE

PRODUÇÃO, 2005, Porto Alegre. XXV Encontro Nacional de Engenharia de Produção.

2005. v. 1, p. 1-8.

DASU, Tamraparni; JOHNSON, Theodore. Exploratory data mining and data cleaning.

Hoboken: Wiley, 2003.

198

DYER JR, W. Gibb; WILKINS, Alan L. Better stories, not better constructs, to generate

better theory: a rejoinder to Eisenhardt. Academy of Management Review, v. 16, nº 3, p.

613-619, 1991.

ENGLISH, Larry P. Improving data warehouse and business information quality:

methods for reducing costs and increasing profits. New York: Wiley, 1999.

EISENHARDT, Kathleen. Building theories from case study research. Academy of

Management Review, v. 14, nº 4, p. 532-550, 1989.

FAVARETTO, Fábio. Melhoria da qualidade da informação no controle da produção:

estudo exploratório utilizando Data Warehouse. Revista Produção, v. 17, nº 2, p. 343-353,

maio/agosto 2007.

GIL, Antônio Carlos. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002.

GOLDRATT, Eliyahu M. A síndrome do palheiro: garimpando informações num oceano

de dados. São Paulo: IMAM, 1991.

HELFERT, Markus. Managing and measuring data quality in data warehousing.

Proceedings of the World Multiconference on Systemics, Cybernetics and Informatics, 2001.

KARR, Alan F.; SANIL, Ashish P.; BANKS, David L. Data quality: a statistical

perspective. Statistical Methodology, v. 3, p. 137-173, 2006.

KLIPPEL, Marcelo; ANTUNES JR, José Antônio Vale; DE PELLEGRIN, Ivan. Os circuitos

do planejamento, programação e controle da produção e dos materiais para indústrias

do tipo engineering-to-order – pedidos contra projetos de engenharia. XXV ENEGEP,

Porto Alegre, 2005.

LEE, Yang W.; PIPINO, Leo L.; FUNK, James D.; WANG, Richard Y. Journey to data

quality. Boston: MIT Press, 2006.

LOSHIN, David. Enterprise knowledge management: the data quality approach. San

Diego: Morgan Kaufmann, 2001.

MALETIC, Jonathan I.; MARCUS, Andrian. Data Cleansing: beyond integrity analysis. In:

Proceedings of the Conference on Information Quality (IQ2000), p. 200-209, Boston, October

2000.

199

OLSON, Jack. Data accuracy: the challenge. DM Review Magazine (2002). Disponível em:

<http://www.dmreview.com/dmdirect/20021108/6019-1.html> Acesso em: 20 mai 2008.

____________. Data quality: the accuracy dimension. San Francisco: Morgan Kaufmann,

2003.

PEDROSO, M. C.; CORRÊA, H. L. Sistemas de programação da produção com

capacidade finita: uma decisão estratégica? Revista de Administração de Empresas, v. 36,

n. 4, 2006.

PINHEIRO, Flávio de Brito. Controle de qualidade em banco de dados. Dissertação de

Mestrado. PESC-COPPE/UFRJ, Rio de Janeiro, 2002.

PINHO, Selma Foligne Crespio. Avaliação da qualidade de dados pela não-conformidade.

Dissertação de Mestrado. PESC-COPPE/UFRJ, Rio de Janeiro, 2001.

REDMAN, Thomas C. Data: an unfolding quality disaster. DM Review Magazine (2004).

Disponível em: <http://www.dmreview.com/issues/20040801/1007211-1.html> Acesso em:

20 mai 2008.

__________________. Data quality for the information age. Norwood: Artec House, 1996.

__________________. Data warehouses and quality: not just for IT anymore. Navesink

Consulting Group (2008). Disponível em:

<http://www.dataqualitysolutions.com/Data_Warehouses_and_Quality.pdf> Acesso em: 20

mai 2008.

RODRIGUES, Luís Henrique. Developing an approach to help companies synchronize

manufacturing. Tese de Doutorado. Department of Management Sciences. University of

Lancaster. Lancaster, 1994.

ROESCH, Sylvia Maria Azevedo. Projetos de estágio e de pesquisa em administração:

guia para estágios, trabalhos de conclusão, dissertações e estudos de caso. 3. ed. São

Paulo: Atlas, 2007.

SHETH, Amit; WOOD, Christopher; KASHYAP, Vipul. Q-data: using deductive database

technology to improve data quality. In: Applications of Deductive Databases. R.

Ramakrishnan (org), Kluwer Academic Press, 1994, p. 23-56.

200

SHINGO, Shigeo. O Sistema Toyota de Produção do ponto de vista da Engenharia de

Produção. 2. ed. Porto Alegre: Artes Médicas, 1996.

SLACK, Nigel; CHAMBERS, Stuart; JOHNSTON, Robert. Administração da Produção. 2.

ed. São Paulo: Atlas, 2002.

TAYI, Giri Kumar; BALLOU, Donald P. Examining Data Quality. Communications of the

ACM, v. 41, n. 2, p. 54-57, February 1998.

TDQM. What is TDQM. Disponível em: <http://web.mit.edu/tdqm/www/about.shtml>.

Acesso em: 12 abr 2008.

TORRES, Márcio. Proposta de um método para a implantação de um sistema de

planejamento fino de produção baseado na Teoria das Restrições. Dissertação de

Mestrado. PPGEP/UFRGS, Porto Alegre, 1999.

WANG, Richard Y; KON e MADNICK, Data Quality Requirements Analysis and Modeling.

9th International Conference on Data Engineering, Vienna, Austria, Abril 1993.

________________; STOREY, Veda C.; FIRTH, Christopher P. A framework for analysis

of data quality research. IEEE Transactions on Knowledge and Data Engineering, v. 7, nº 4,

p. 623-640, 1995.

________________; ZIAD, Mostapha; LEE, Yang W. Data quality. New York: Kluwer,

2002.

________________. A product perspective on Total Data Quality Management.

Communications of the ACM, v. 41, n. 2, p. 58-65, February 1998.

WINKLER, William E. Methods for evaluating and creating data quality. Information

Systems, vol. 29, p. 531-550, 2004.

YIN, Robert. Estudo de caso: planejamento e métodos. 3. ed. Porto Alegre: Bookman,

2005.

APÊNDICE A – Detalhamento do método de análise para identificação de erros de

dados para cortes na fase 5 do estudo de caso

202

1. Análise da programação de abates

1.1 Análise do grão turno

• Abrir o relatório de programação de abates empurrados.

• Se não houver programação de abates em nenhum dos dias do grão turno:

o Existe um produto intermediário sem filho em todas as árvores?

o Um recurso que está cadastrado em todas as árvores não tem calendário?

• Se o abate programado for igual à escala de abate, deve-se partir para o item 1.2 ou

para o item 2.

• Se o abate programado for maior que a escala de abate, há algum problema no

software.

• Se não houver escala nem programação de abate (ou seja, não existem dados em um

determinado dia), provavelmente não foram importados adequadamente os dados de

escala de abate. As possíveis causas para este problema são listadas abaixo:

o Planilha onde os dados são digitados.

o Houve algum erro no arquivo gerador do template de abate.

o A raiz (tipo de animal) não está habilitada no arquivo gerador do template de

abate.

o A raiz (tipo de animal) não está cadastrada no Cadastro de Produtos.

• Se a escala de abate estiver errada, as possíveis causas são as seguintes:

o Os dados não foram atualizados na planilha.

o Os dados não foram atualizados no sistema de programação da produção.

o Houve algum erro no arquivo (macro) gerador do template de abate.

• Se o abate programado for menor que a escala de abate, deve-se escolher o dia e

turno em que ocorreu o problema e partir para a análise das potenciais causas

conforme quadro abaixo:

Nº

Causa potencial O que e como analisar

1 Peso cadastrado para

a raiz

§ Tela de Cadastro de Produtos.

§ Verificar se o peso cadastrado para a raiz está correto.

2 Ocupação global de

recursos

§ Abrir o relatório de ocupação de recursos.

§ Verificar se existem recursos com Ocupação Total >= 99% no

dia em que se constatou o problema e no dia posterior. O dia

posterior deve ser analisado nos casos das unidades em que

existem recursos que não são ocupados no mesmo dia do

abate.

§ Se houver recursos com ocupação total >= 99%, devem-se

identificar o(s) recurso(s), o(s) dia(s) e o(s) turno(s).

§ Verificar se as horas disponíveis no turno estão corretas

(ocupadas + ociosas). Se não estiverem, analisar os

calendários.

§ O recurso 100% tem calendário para o número de turnos que

203

trabalha? Ou seja, se o recurso trabalha no 1° e no 2° T, há

calendários cadastrados para ambos os turnos?

§ Sábados de abate ou de produção estão cadastrados nas

exceções de calendário?

§ Se o problema não for este, analisar o relatório da

programação dos produtos que passam por um recurso – ver

instruções na causa nº 3.

§ Se mesmo após analisar-se este relatório não for identificado

o problema, sugere-se fazer uma tabela comparativa entre

escala e capacidade de abate (ver exemplo mais abaixo).

3 Produtos que passam

por um recurso

§ Abrir o relatório de ocupação de recursos.

§ Se um ou poucos produtos ocupam boa parte do recurso

(80%, por exemplo), pode ser que a capacidade destes

produtos esteja mal dimensionada nas árvores de cortes.

§ O contrário também é verdadeiro: se um produto que é

bastante produzido e ocupa muito pouco do recurso, é sinal de

que a capacidade está mal dimensionada.

§ Nesta análise, podem também ser identificados produtos que

estão passando pelo recurso 100%, mas que, na realidade, não

utilizam o recurso. Isso não pode acontecer.

• Se não houver abate programado (ou seja, se há apenas a escala preenchida), as

causas podem ser as seguintes:

o O código da raiz não está na tela Uso das Árvores de Cortes.

o A validade da raiz expirou no dia programado em que se constatou o problema

(ver na tela Uso das Árvores de Cortes).

o Existe um produto intermediário sem filho em algumas árvores (nodo órfão).

o Um recurso que está cadastrado em algumas árvores não tem calendário.

• Se houver abate programado sem existir escala de abate: não pode acontecer. É erro

do software.

• Em último caso, sugere-se comparar os dados de escala de abate, capacidade de

abate, capacidade de corte, etc conforme abaixo:

o No exemplo acima, se as horas necessárias forem menores que as horas

disponíveis, o problema não está na ocupação do recurso Abate, e sim em outros

recursos.

Turno Ave Peso Escala Kg total Rdto kg/h hs neces hs disp

1 Peru macho 14,50 6.475 93.888 88,00% 16.588 4,98

1 Peru macho 16,00 1.612 25.792 88,00% 19.448 1,17

6,15 8,80

204

1.2 Análise do grão semana

• Regularidade na programação:

o Abrir o relatório de programação sugerida de abates

o Verificar se há abate programado para todas as semanas.

o Verificar se há muita variabilidade entre os abates programados semana a

semana.

2. Analisar a regularidade da programação de produtos finais e MPs

• Utilizar a planilha “Programação aberta por código”.

• Programação diária por turno coerente com a realidade E o abate programado? Se não

estiver, provavelmente se trata de um problema de rendimentos e recursos.

• Programação todos os dias úteis do grão turno (inclusive sábados, quando houver)? Se

isso não ocorrer devem ser analisados os calendários, a escala de abate (já analisada no

passo 1)

• No grão turno, há programação em dias de fim de semana que não possuem abate

programado ou disponibilidade de recursos para produção de cortes ou inteiros? Se isso

ocorrer, verificar calendários.

3. Analisar a programação de produtos finais e MPs por subclasse França

• Utilizar a planilha “Programação unidade-grupo-classe-subclasse”.

• Comparar com a realidade E o abate programado.

• Caso não estiver coerente, verificar a ocupação de recursos, calendários e os

rendimentos nas árvores (o passo 4 detalha melhor estes itens).

4. Analisar o mix programado (lista de todos os códigos finais e MPs)

• Abrir o relatório de programação da produção por produto.

4.1 Quando um produto específico NÃO está sendo programado

• O produto está habilitado no Cadastro de Produtos?

• O produto consta em alguma árvore de cortes? Ir em Produtos e Processos, Estrutura de

produtos e roteiros, Uso das árvores de cortes e utilizar a Pesquisa Avançada.

• A raiz de abate de onde sai o produto está sendo programada? Para mais detalhes, ir para

o item 4.2.

• O produto está habilitado para ser produzido na fábrica em análise? Ir em

Relacionamentos e Permissões, Permissão de Produção.

• O produto tem pedido ME? Caso afirmativo:

ü O SIF da fábrica está habilitado para o país do pedido? Ir em Relacionamentos e

Permissões, SIFs aceitos por país.

ü Existe alguma restrição de clientes ao SIF da fábrica? Ir em Relacionamentos e

Permissões, SIFs aceitos / negados por cliente.

205

• O produto tem demanda? Ir em Relatórios e abrir o relatório de previsão de demanda

por mercado.

• Todos os recursos da fábrica (e não somente os recursos do produto em análise) têm

calendário em todos os turnos nos quais a fábrica trabalha? Deve-se acessar a tela

“Calendários das fábricas” para analisar. É necessária também uma análise mais

profunda nestes casos, pois pode acontecer de a descrição dos calendários ser de 1° e de

2° T, porém as respectivas faixas de horário não o são.

• Existe algum problema no “caminho” até o produto dentro da árvore? O problema pode

estar relacionado à habilitação do produto intermediário, ao recurso ou ao calendário

deste e à existência de nodos órfãos (pais intermediários sem filhos).

4.2 Quando a quantidade programada de MUITOS produtos estiver ABAIXO do

normal

• Pode ser problema de rendimentos nas árvores – verificar o relatório de programação da

“desmontagem” dos animais. Ali é possível verificar se há rendimentos errados. Outra

possibilidade é acessar diretamente a árvore.

• Pode ser problema de recursos. Neste caso, sugerem-se os passos abaixo:

• Abrir o relatório de ocupação de recursos.

• Filtrar o campo “Ocupação total %” (é última coluna do relatório) onde o número seja

igual a 100. Com isso, serão identificados quais recursos estão com a capacidade máxima

atingida, ou seja, são gargalos em uma determinada data e turno.

• A partir dos recursos 100%, abrir o relatório de programação de produção por recurso.

• Analisar que produtos estão passando pelos recursos 100%. Algumas análises

interessantes podem ser feitas:

ü Se um ou poucos produtos ocupam boa parte do recurso (80%, por exemplo), pode

ser que a capacidade destes produtos esteja mal dimensionada nas árvores de cortes.

ü O contrário também é verdadeiro: se um produto que é bastante produzido e ocupa

muito pouco do recurso, é sinal de que a capacidade está mal dimensionada.

ü Nesta análise, podem também ser identificados produtos que estão passando pelo

recurso 100%, mas que, na realidade, não utilizam o recurso. Isso não pode

acontecer.

ü Todos os recursos têm calendário?

ü Todos os recursos 100% têm calendário para o número de turnos que trabalham? Ou

seja, se o recurso trabalha no 1° e no 2° T, há calendários cadastrados para ambos os

turnos?

ü Sábados de abate ou de produção estão cadastrados nas exceções de calendário?

• A vantagem desta análise é que ela é mais global, então muitos problemas podem acabar

sendo resolvidos de uma vez só.

4.3 Quando a quantidade programada DE UM PRODUTO for ABAIXO do normal

Alternativa 1:

• Abrir o relatório de ocupação de recursos.

206

• Filtrar o campo “Ocupação total %” (é última coluna do relatório) onde o número seja

igual a 100. Com isso, serão identificados quais recursos estão com a capacidade máxima

atingida, ou seja, são gargalos em uma determinada data e turno.

• A partir dos recursos 100%, abrir o relatório dos recursos que são consumidos por um

produto.

• Filtrar o produto que se deseja analisar.

• Verificar se algum dos recursos por onde o produto passa está 100% no relatório 14 no

dia e turno que se está analisando.

• A partir da identificação dos recursos 100%, as mesmas análises interessantes expostas

acima podem ser feitas.

Alternativa 2:

• Abrir o relatório “Atividades da árvore de cortes”, que consta nos Relatórios de Dados

Cadastrais.

• Filtrar o produto que se deseja.

• Verificar se as capacidades vinculadas ao produto estão corretas ou se falta algum

recurso que pode vir a ser gargalo de produção.

Alternativa 3:

• Verificar em quais árvores o produto passa.

• Verificar nestas árvores se as capacidades vinculadas ao produto estão corretas.

• Verificar se os recursos que podem vir a ser gargalo estão vinculados ao produto. Ou

seja, falta alguma coisa?

4.4 Quando a quantidade programada de um produto for ACIMA do normal

• Abrir o relatório “Atividades da árvore de cortes”, que consta nos Relatórios de Dados

Cadastrais.

• Filtrar o produto que se deseja.

• Verificar se as capacidades vinculadas ao produto estão superdimensionadas.

5. Analisar a programação de transferências de MPs e de produtos finais

• Abrir o relatório de programação de transferências entre unidades.

• Analisar as transferências de e para a unidade que se analisa.

• Caso forem encontradas transferências incoerentes, devem-se verificar as permissões de

transferência de produtos entre unidades.

APÊNDICE B – Detalhamento do método de análise para identificação de erros de

dados para formulados na fase 5 do estudo de caso

208

1. Analisar necessidade X programação X média realizada

Esta análise permite comparar a necessidade de MPs a partir de pedidos e demandas versus

a programação sugerida pelo Schedulare versus a média realizada pela empresa. Trata-se de

uma análise global das MPs.

a) Unidade origem pode não estar abatendo o volume normalmente feito.

b) Demanda pode estar errada (necessidade muito elevada ou baixa em relação à

realidade).

c) Caso necessário, verificar lista dos produtos finais que utilizam a referida MP e as

quantidades de demanda e pedido de cada um.

d) Erro nos mínimos e máximos da formulação.

e) Rendimentos na árvore origem. Isso pode ser confirmado analisando-se a programação

dos "grupos" de MPs (recorte de peito, etc).

f) Uma maneira de confirmar se os rendimentos das MPs estão baixos é verificar se os

irmãos alternativos ou compulsórios da MP estão tendo os pedidos atendidos.

g) Ocupação de recursos na árvore origem.

h) Ocupação de recursos na árvore destino.

2. Analisar a regularidade da programação de produtos finais e MPs

a) Utilizar a planilha “Programação aberta por código”.

b) Programação diária por turno coerente c/ a realidade E os itens do passo 1?

c) Programação todos os dias úteis do grão turno (inclusive sábados, quando houver)? Se

isso não ocorrer devem ser analisados os calendários ou as transferências da unidade

origem.

d) No grão turno, há programação em dias de fim de semana que não possuem

disponibilidade de recursos para produção? Isso não pode ocorrer.

3. Analisar a programação por subclasse França

a) Utilizar planilha “Programação unidade-grupo-classe-subclasse”.

b) Caso não estiver coerente, verificar a ocupação de recursos, calendários e os

rendimentos nas árvores (o passo 4 detalha melhor estes itens).

4. Analisar o mix programado (lista de todos os códigos finais)

Abrir os relatórios de programação da produção de produtos finais e por pai-filho.

4.5 Quando um produto específico NÃO está sendo programado

a) O produto está habilitado no Cadastro de Produtos?

b) O produto consta em alguma árvore de formulações? Ir em Produtos e Processos,

Estrutura de produtos e roteiros, Uso das árvores de formulações e utilizar a Pesquisa

Avançada.

209

c) A raiz de abate de onde sai a MP está sendo programada? Para mais detalhes, ir para o

item 4.2.

d) O produto formulado está habilitado para ser produzido na fábrica em análise? Ir em

Relacionamentos e Permissões, Permissão de Produção.

e) As MPs estão habilitadas para serem programadas na fábrica origem?

f) As MPs estão habilitadas para serem transferidas da fábrica origem para a fábrica

destino?

g) O produto tem pedido ME? Caso afirmativo:

ü O SIF da fábrica está habilitado para o país do pedido? Ir em Relacionamentos e

Permissões, SIFs aceitos por país.

ü Existe alguma restrição de clientes ao SIF da fábrica? Ir em Relacionamentos e

Permissões, SIFs aceitos / negados por cliente.

h) O produto formulado tem demanda? Ir em Relatórios e abrir o relatório de previsão de

demanda por mercado.

i) Todos os recursos da fábrica (e não somente os recursos do produto em análise) têm

calendário em todos os turnos nos quais a fábrica trabalha? Deve-se acessar a tela

“Calendários das fábricas” para analisar. É necessária também uma análise mais

profunda nestes casos, pois pode acontecer de a descrição dos calendários ser de 1° e

de 2° T, porém as respectivas faixas de horário não o são.

j) Existe algum problema no “caminho” até o produto dentro da árvore? O problema

pode estar relacionado à habilitação do produto intermediário, ao recurso ou ao

calendário deste e à existência de nodos órfãos (pais intermediários sem filhos).

4.6 Quando a quantidade programada de MUITOS produtos estiver ABAIXO do

normal

a) Pode ser problema de rendimentos nas árvores – verificar o relatório de programação

que mostra a “montagem” dos produtos formulados. Ali é possível verificar se há

rendimentos errados. Outra possibilidade é acessar diretamente a árvore.

b) Pode ser problema de recursos. Neste caso, sugerem-se os passos abaixo:

c) Abrir o relatório de ocupação de recursos.

d) Filtrar o campo “Ocupação total %” (é última coluna do relatório) onde o número seja

igual a 100. Com isso, serão identificados quais recursos estão com a capacidade

máxima atingida, ou seja, são gargalos em uma determinada data e turno.

e) A partir dos recursos 100%, abrir o relatório de programação da produção por recurso.

f) Analisar que produtos estão passando pelos recursos 100%. Algumas análises

interessantes podem ser feitas:

ü Se um ou poucos produtos ocupam boa parte do recurso (80%, por exemplo), pode

ser que a capacidade destes produtos esteja mal dimensionada nas árvores.

ü O contrário também é verdadeiro: se um produto que é bastante produzido e ocupa

muito pouco do recurso, é sinal de que a capacidade está mal dimensionada.

ü Nesta análise, podem também ser identificados produtos que estão passando pelo

recurso 100%, mas que, na realidade, não utilizam o recurso. Isso não pode

acontecer.

ü Todos os recursos têm calendário?

ü Todos os recursos 100% têm calendário para o número de turnos que trabalham? Ou

seja, se o recurso trabalha no 1° e no 2° T, há calendários cadastrados para ambos os

turnos?

210

ü Sábados de produção estão cadastrados nas exceções de calendário?

g) A vantagem desta análise é que ela é mais global, então muitos problemas podem

acabar sendo resolvidos de uma vez só.

4.7 Quando a quantidade programada DE UM PRODUTO for ABAIXO do normal

Alternativa 1:

a) Abrir o relatório de ocupação de recursos.

b) Filtrar o campo “Ocupação total %” (é última coluna do relatório) onde o número seja

igual a 100. Com isso, serão identificados quais recursos estão com a capacidade

máxima atingida, ou seja, são gargalos em uma determinada data e turno.

c) A partir dos recursos 100%, abrir o relatório da programação dos produtos que

consomem um recurso.

d) Filtrar o produto que se deseja analisar.

e) Verificar se algum dos recursos por onde o produto passa está 100% no relatório 14 no

dia e turno que se está analisando.

f) A partir da identificação dos recursos 100%, as mesmas análises interessantes expostas

acima podem ser feitas.

Alternativa 2:

a) Abrir o relatório “Atividades da árvore de formulações”, que consta nos Relatórios de

Dados Cadastrais.

b) Filtrar o produto que se deseja.

c) Verificar se as capacidades vinculadas ao produto estão corretas ou se falta algum

recurso que pode vir a ser gargalo de produção.

Alternativa 3:

a) Verificar em quais árvores o produto passa.

b) Verificar nestas árvores se as capacidades vinculadas ao produto estão corretas.

c) Verificar se os recursos que podem vir a ser gargalo estão vinculados ao produto. Ou

seja, falta alguma coisa?

4.8 Quando a quantidade programada de um produto for ACIMA do normal

a) Abrir o relatório “Atividades da árvore de formulações”, que consta nos Relatórios de

Dados Cadastrais.

b) Filtrar o produto que se deseja.

c) Verificar se as capacidades vinculadas ao produto estão superdimensionadas.

5. Programação de transferência dos produtos finais

a) Abrir o relatório de programação de transferências entre unidades.

211

b) Caso forem encontradas transferências incoerentes, devem-se verificar as permissões

de transferência de produtos entre unidades.

APÊNDICE C – Resumo das observações feitas pelos experts durante as reuniões de

validação da proposta inicial do método

213

Nos parágrafos que seguem, é feito um resgate das discussões feitas junto aos experts

entrevistados, as quais foram agregadas ao método tentativo para a melhoria da acuracidade

dos dados de um sistema de programação da produção. Neste detalhamento, não é feita

distinção entre os respondentes, o que possibilitou agregar as observações em comum em

torno dos temas tratados.

A abordagem do método foi considerada por todos os especialistas como uma forma

de estabelecer um rigor metodológico passível de ser aplicado. Durante a discussão sobre a

abordagem geral do método, surgiram duas questões: quais foram os critérios utilizados para a

criação dos subprocessos e como se garantiria que os processos geradores dos dados eram

confiáveis. Na primeira questão, concordou-se com os especialistas em relação à crítica feita.

De fato, não estavam claros quais haviam sido os critérios usados para a definição dos

subprocessos. A partir disso, gerou-se uma contribuição ao trabalho, a qual foi efetivada.

A segunda questão levantada com relação à abordagem do método foi com relação à

sustentabilidade dos processos de geração dos dados. Como o método dedicava-se a

identificar e corrigir os dados errados na fonte primária, levantou-se a hipótese de que, caso o

processo gerador possuísse erros, o problema poderia voltar a ocorrer. A partir disso,

argumentou-se que a melhoria de processos de negócio (a qual envolve as transformações do

dado no chamado ciclo de vida do dado), estava fora do escopo do método.

No que diz respeito ao formato do método, sugeriu-se que fossem padronizadas as

partes integrantes dos fluxogramas, bem como fazer uma legenda para as mesmas. Além

disso, sugeriu-se a colocação de uma figura que possibilitasse obter uma visão geral sobre os

processos e subprocessos. Ambas as colocações feitas pelos experts foram acatadas e

implementadas no método.

No Processo de Preparação de Dados, comentou-se que deveria haver atividades de

definição das regras de negócio, as quais seriam utilizadas para a estruturação das validações.

Ainda, sugeriu-se estruturar o Processo 1 por subprocessos, já que, além das validações,

deveriam ser feitas a estruturação dos dados, a definição dos índices de controle e dos

indicadores e o desenvolvimento dos logs de identificação automática de erros de dados. No

caso da estruturação dos dados, uma sugestão foi colocada em relação aos dados faltantes –

poderia ser incluído no fluxograma um teste que verificasse se estes dados, se fossem ser

coletados, pudessem ser cadastrados em algum sistema corporativo. Assim, os dados não

214

precisariam ser preenchidos em templates, e sim importados por meio da integração de

sistemas.

No Processo 2, críticas foram feitas pelo fato de os termos “índice de controle” e

“indicador”, além de não terem sido especificados quanto à função de cada um, estavam

sendo usados como sinônimos. Sugeriu-se, a partir disso, que se considerasse como índice de

controle as medições dos dados de entrada do sistema, enquanto que os resultados da

ferramenta (dados de saída) deveriam ser considerados como “indicadores”. Ainda, sugeriu-se

que as metas de ambas as medições deveriam ser definidas juntamente com a definição de

quais seriam os ICs e indicadores utilizados (Processo 1).

Quanto aos dados necessários para a programação de produção de uma empresa de

alimentos cárneos, todos os experts que conheciam este ramo de negócios concordaram que

todos os dados considerados estavam contemplados no método.

APÊNDICE D1 – Detalhamento fino das atividades e testes do Subprocesso 1.1

216

P1S1A1

Definir o modelo conceitual para os dados

• Nível de detalhamento dos dados necessários: devem-se definir quais dados serão considerados. Exemplo: todas as fábricas da empresa

serão cadastradas no sistema? No caso dos recursos produtivos, sugere-se cadastrar apenas aqueles que sejam gargalos ou CCRs

produtivos, evitando-se a coleta e manutenção de dados desnecessários.

• Produtos a serem modelados: nem todos os produtos da empresa deverão ser ter suas estruturas de produto cadastradas no sistema.

Sugere-se fazer um levantamento do histórico de produção que contemple todas as sazonalidades da empresa (1 ano, por exemplo). A

partir desta lista, deverão ser selecionados os produtos que serão modelados no sistema de programação da produção.

• Modelagem de árvores de cortes e de formulação e das curvas de peso: avaliar o custo x benefício do detalhamento destes dados

(Princípio da parcimônia). Quanto mais detalhados forem, maior será a necessidade de manutenção dos dados, além de dificultar o

processo de identificação de erros. Sugere-se iniciar os testes na ferramenta com um número reduzido de raízes de cortes em relação à

realidade, desde que seja utilizada uma amostra significativa das faixas de peso vivo abatidas na empresa. Outra sugestão diz respeito às

árvores: no início dos testes, elas devem simples. A partir dos resultados dos índices de controle propostos, outras raízes poderão ser

adicionadas, bem como a modelagem poderá ser incrementada.

• Horizonte e grão de programação: deve-se definir o período de tempo que deverá estar coberto pelo sistema, bem como o nível de

detalhamento desejado para as informações do sistema. Esta definição influencia, por exemplo, no detalhamento dos dados de pedidos,

de árvores e de recursos.

P1S1A2

Estabelecer os requisitos de dados para o sistema

• Identificar todos os dados necessários para o sistema. Exemplo: dentre os dados da entidade estoques, poderão ser necessários os

atributos de código da unidade de armazenagem e do registro do lote de produção, dentre outros.

• Definir os requisitos de qualidade para os atributos: formato, freqüência necessária das atualizações, dentre outros.

APÊNDICE D2 – Detalhamento fino das atividades e testes do Subprocesso 1.2

218

P1S2T1

Os dados necessários existem na empresa?

1. Uma vez definidos os requisitos dos dados necessários para o funcionamento do sistema, deve-se verificar se todos os dados mapeados

estão disponíveis em algum meio eletrônico ou impresso.

2. Se a resposta for “Sim”, deve-se identificar a origem dos dados (local onde os mesmos estão armazenados). Caso a resposta for “Não”,

deve-se verificar se é possível obter os dados faltantes.

P1S2T3

Os dados estão disponíveis em bases de dados corporativas?

1. Uma vez identificada a origem dos dados, deve-se verificar se os mesmos estão armazenados em alguma base de dados corporativa.

Obs.: considera-se como base de dados corporativa qualquer banco de dados que armazene o dado requerido, que faça parte da

estrutura de Sistemas de Gerenciamento de Bancos de Dados (SGBD) da empresa, que seja regularmente atualizado e que possibilite a

exportação de cargas de dados para o sistema de PCP, sem a necessidade de prepará-los manualmente antes de importá-los.

2. Deve-se verificar se todos os dados de uma entidade estão disponíveis. Exemplo: uma vez definido que a carga de estoques deve possuir

os atributos de código da unidade de armazenagem e de registro do lote de produção, deve-se verificar se todos os dados de ambos

encontram-se nas bases de dados (todas as unidades de armazenagem e todos os lotes de produção).

3. Caso a resposta à atividade for “Sim”, deve-se ajustar os dados nos arquivos de integração com o sistema. Se a resposta for “Não”, os

dados deverão ser coletados para que seja feita a importação manual dos mesmos por meio de templates.

P1S2A4

Ajustar os dados nos arquivos de integração com o sistema

Formato dos dados e unidades de medida (número, texto, quilo, tonelada, dentre outros): verificar se será necessário fazer algum tipo de

conversão dos dados antes de os mesmos serem importados para a base do sistema.

P1S2T2

É possível obter os dados faltantes?

1. Caso nem todos os dados necessários para o sistema estejam disponíveis em algum meio eletrônico ou impresso, deve-se verificar se será

possível coletá-los.

2. Se a resposta for “Sim”, deve-se iniciar a coleta dos dados faltantes. Caso a resposta seja “Não”, deverá ser feita uma reavaliação do

escopo do sistema, tendo em vista que não será possível obter todos os dados especificados na atividade de requisitos de dados.

P1S2A2

Coletar os dados

A coleta de dados resume-se em capturar no ambiente da empresa os dados que foram especificados na atividade de requisitos de dados

e que não existem em um meio eletrônico ou impresso ou que jamais foram utilizados na organização.

P1S2T4

Os dados serão cadastrados em sistemas corporativos?

219

Caso os dados necessários não estiverem disponíveis em bases de dados corporativas ou forem coletados os dados após verificar que é

possível obter os dados faltantes, deve-se verificar a possibilidade de os dados serem inseridos em algum sistema corporativo. Desta forma,

independe-se do preenchimento dos templates, atividade que pode levar a erros de preenchimento dos dado

s. Além disso, uma vantagem

de armazenar os dados em um sistema corporativo é a possibilidade de desenvolver um processo de integração automática, sem

intervenção humana, entre este sistema e a ferramenta de programação da produção.

P1S2A5

Cadastrar os dados em um sistema corporativo

Caso decidir-se cadastrar em um sistema corporativo os dados faltantes ou aqueles que não estão disponíveis em bases de dados

corporativas, deve-se efetivar o cadastro dos dados em um sistema corporativo.

P1S2A1

Providenciar alterações no escopo do sistema

Caso não seja possível obter os dados faltantes, será necessário suprimir os mesmos da especificação do sistema, ou então procurar por

alternativas em relação aos dados que possam gerar os resultados desejados no sistema.

P1S2A3

Preencher os templates

Reunir os dados coletados e preencher os templates de acordo com as definições da atividade de especificação de dados.

APÊNDICE D3 – Detalhamento fino das atividades e testes do Subprocesso 1.3

221

P1S3A1

Desenvolver mecanismo automático de identificação de erros de importação de dados para o sistema

O desenvolvimento do mecanismo de identificação de erros deverá contemplar a geração de logs que informem onde foi o erro, conforme

as possíveis situações abaixo:

• nome do template não consta no banco de dados;

• formato do arquivo do template incompatível com o banco;

• formato dos dados incompatível com a base de dados; e

• integridade referencial.

Além disso, mesmo que os erros acima não ocorram, os logs deverão gerar outras informações, como o número de registros importados.

Desta forma, será possível identificar situações nas quais possa ter havido falha na geração dos arquivos de importação ou no

preenchimento dos templates. Um exemplo disso seria um número esperado de registros da carga de estoques entre 2.000 e 2.500 linhas,

enquanto que, na realidade, o arquivo possuía 300 linhas.

Outras funcionalidades dos logs deverão ser as de auxiliar no controle da freqüência e do horário das cargas de dados. A freqüência diz

respeito ao número de vezes por dia (por exemplo) que uma atualização dos dados é feita, sendo que isso deverá ser comparado com o

que foi especificado na atividade de Requisitos de Dados (Subprocesso 1.1). Nesta mesma lógica, o horário das cargas deverá ser

comparado com o especificado.

P1S3A2

Definir as regras de negócio

As regras de negócios são particularidades específicas da empresa, compreendendo condições que devem ser cumpridas.

Neste caso, deverão ser mapeadas apenas as regras cujo padrão de comportamento seja passível de ser validado por regras dentro do

sistema de programação da produção. Exemplo: um produto que possua pedidos deve obrigatoriamente ser vendável. Esta regra é válida

para todos os produtos, não existindo exceções.

Além disso, a importância das regras de negócio deverá ser avaliada pela empresa (deve-se fazer um trade-off entre o tempo e/ou

orçamento disponível e a necessidade de acuracidade de dados).

P1S3A3

Desenvolver validações automáticas dos dados com base nas regras de negócio

A partir da definição das regras de negócio que deverão ser testadas pelo sistema de programação da produção, inicia-se o

desenvolvimento de mecanismos automáticos de validação das mesmas.

P1S3A4

Definir índices de controle e indicadores para a avaliação dos dados

Paralelamente à definição das regras de negócio, desenvolvimento de validações e dos logs, devem-se definir quais índices de controle e

indicadores deverão ser aplicados durante o processo de implementação do sistema até a homologação do mesmo, bem como as metas

dos mesmos.

222

Os ICs são utilizados para mensurar os dados de entrada independentemente da realização de uma rodada do sistema. Os índices de

controle podem ser calculados, por exemplo, por meio de medidas tendência central (média) ou de dispersão (desvio-padrão), sendo

possível acompanhar a evolução dos mesmos (e das situações de erro) com o apoio de gráficos de controle. Os ICs podem indicar erros e

também contribuir para a identificação de oportunidades de melhorias nos dados. Um exemplo disso é o cálculo do desvio padrão dos

tempos de processo, em kg/h, de um recurso. Se o desvio for maior que o limite máximo aceitável, deverá ser verificado se existem erros.

Caso um problema seja confirmado, a análise do mesmo em uma estrutura de produto poderá contribuir para a melhoria de outros dados

da árvore.

Os indicadores caracterizam-se pela mensuração das informações geradas pelo sistema de programação da produção após as rodadas

do mesmo. Em outras palavras, os indica

dores atuam sobre os resultados do sistema, e não diretamente nos dados de entrada. A vantagem

é que erros na informação gerada pelo sistema poderão indicar problemas nos dados de entrada.

APÊNDICE D4 – Detalhamento fino das atividades e testes do Subprocesso 1.4

224

P1S4A1

Realizar testes de integração entre sistemas e do mecanismo de identificação de erros importação

1. Importar todos os dados que serão inseridos no banco por meio da integração de sistemas.

2. Verificar se a concatenação / ordenação de cargas de dados está sendo respeitada. Este aspecto refere-se ao relacionamento

(precedência) entre as tabelas da base de dados do sistema. Exemplo: os dados de clientes devem ser importados antes dos pedidos.

3. Verificar os logs gerados após a importação.

P1S4T1

Os testes foram bem sucedidos? (após a realização dos testes de integração entre sistemas)

Após a realização dos testes de integração entre sistemas, deve-se verificar se houve problemas. Caso a resposta à atividade for “Sim”,

deve-se partir para a atividade P1S4A2. Se a resposta for “Não”, devem-se excluir todos os dados do banco, desde que o teste P1S4T2

tenha

sido bem sucedido

P1S4A2

Identificar a causa do problema e corrigi-lo

1. Ao constatar-se que houve erros de importação para o sistema de seqüenciamento da produção, deve-se primeiramente identificar qual

carga teve problemas.

2. Identificada a carga, deve-se verificar se existem erros na geração da mesma. Se este tipo de erro não estiver ocorrendo, o mecanismo

de integração de sistemas deve ser avaliado. Caso contrário, deve-se identificar o erro e corrigir a fonte primária.

P1S4A3

Importar os templates para o sistema

Os templates preenchidos no subprocesso anterior deverão ser importados para que se realizem os testes de importação (geração dos

logs).

P1S4A4

Testar os mecanismos identificação de erros de importação

1. Importar todos os dados que serão inseridos no banco por meio de templates.

2. Verificar se a concatenação / ordenação de cargas de dados está sendo respeitada. Este aspecto refere-se ao relacionamento

(precedência) entre as tabelas da base de dados do sistema. Exemplo: os dados de clientes devem ser importados antes dos pedidos.

3. Verificar os logs gerados após a importação.

P1S4T2

Os testes foram bem sucedidos? (após testar o mecanismo de importação de dados)

Após a realização dos testes de importação dos templates, deve-se verificar se houve problemas. Caso a resposta à atividade for “Sim”,

deve-se partir para a atividade P1S4A5. Se a resposta for “Não”, devem-se excluir todos os dados do banco, desde que o teste P1S4T

1 tenha

sido bem sucedido.

P1S4A5

Identificar a causa do problema e corrigi-lo

225

1. Ao constatar-se que houve erros de importação para o sistema de seqüenciamento da produção, deve-se primeiramente identificar qual

template teve problemas.

2. Identificado o template, deve-se verificar se existem erros no mesmo. Se este tipo de erro não estiver ocorrendo, o mecanismo de

integração de sistemas deve ser avaliado. Caso contrário, deve-se identificar o erro e corrigir a fonte primária (template).

P1S4A6

Excluir todos os dados da base do sistema

Após a realização, com sucesso, dos testes de importação de dados para o sistema, o conteúdo de todas as tabelas do mesmo deve ser

deletado para que se inicie o Subprocesso 2.1.

APÊNDICE D5 – Detalhamento fino das atividades e testes do Subprocesso 2.1

227

P2S1A1

Importar os dados cadastrais

Importar os dados de cadastro de fábricas, unidades de armazenagem, clientes, países, SIFs, produtos, suprimentos, meios de transporte,

pontos de embarque, mercados, habilitações de SIFs por país, habilitações de SIFs por cliente, permissões de produtos nas fábricas,

permissões e tempos de transporte entre fábricas, permissões e tempos de transporte entre fábricas e unidades de armazenagem,

permissões e tempos de transporte entre fábricas e pontos de embarque, e permissões e tempos de transporte entre unidades de

armazenagem e pontos de embarque.

P2S1A2

Importar os estoques de produtos

Importar os estoques iniciais de produtos para que sejam avaliados os dados de volume em estoque e do peso do pallet na atividade

P2S1A7.

P2S1A3

Importar as capacidades reais de estoques

Importar as capacidades reais de estoques de produtos para que sejam avaliados os dados de volume em estoque e do peso do pallet na

atividade P2S1A7.

P2S1T1

Houve erros nas importações?

Após a importação dos dados, devem-se analisar as mensagens geradas pelos logs criados no Processo de Preparação de Dados.

Se forem

constatados erros no processo de importação, devem-se identificar e corrigir os problemas. Caso a resposta à atividade for “Não”, deve-se

partir para a validação dos dados do banco.

P2S1A4

Identificar e corrigir os erros

1. Ao constatar-se que houve erros de importação para o sistema de seqüenciamento da produção, deve-se primeiramente identificar qual

template ou carga teve problemas.

2. Identificado o template ou carga de dados, deve-se identificar o erro e corrigir a fonte primária.

P2S1A5

Validar os dados do banco

Nº Tipo Descrição da validação Função / Importância

1 Erro

Produto é vendável e não é

estocável

Todo produto vendável, ao ser finalizado, é estocado para que seja posteriormente entregue

ao cliente.

2 Erro

Produto é transferível e não é

estocável

Todo produto, ao ser transportado de um local para outro, deverá ser armazenado.

3 Erro

Produto é estocável e não é

transferível

Todo produto que for estocável necessita ser transferido entre fábricas, armazéns e pontos de

embarque.

4 Erro

Produto apresenta prazo de

validade zerado

Todo produto cárneo é perecível, logo deve possuir um prazo de validade.

228

5 Erro

Fábrica não possui permissão de

transferência de produtos

Toda fábrica deve transferir produtos para outras unidades ou armazéns ou pontos de

embarque.

6 Erro

Fábrica possui permissão de

transferência, porém não consta

no cadastro de transportes entre

unidades

Idem à validação 5.

7 Erro

Produto sem permissão de

transferência está habilitado em

fábrica não estocadora

Se a fábrica não pode estocar produtos, os produtos produzidos na mesma deverão ser

transportados para outro lugar. Neste caso, deve haver permissão de transferência para o

produto.

8 Erro

Produto sem habilitação de

transferência consta no cadastro

de permissões de transferências

entre fábricas

Esta validação abrange duas situações:

1) Se o produto não pode ser transportado, a presença do mesmo nas permissões de

transferências entre unidades está errada.

2) Se o produto pode ser transferido entre unidades, a habilitação para transferência deverá

ser corrigida.

9 Erro Datas inválidas Exemplo: 20101312 (quando o formato do campo data for AAAAMMDD – ano-mês-dia).

10 Erro Datas sobrepostas

Exemplo: um SIF foi desabilitado para um país qualquer a partir do dia 20/05/2008. Caso o SIF

for reabilitado para o destino, a data inicial da nova habilitação não poderá ser inferior à

data da desabilitação anterior.

11 Erro Datas inconsistentes

Exemplo: existe um registro de habilitação de SIF por país com data inicial maior que a data

final.

12 Alerta

Suprimento possui lead-time de

ressuprimento igual a zero

Um suprimento com tempo de ressuprimento igual a zero significa que o material estará

sempre disponível no estoque (ou seja, é ilimitado).

P2S1T2

Existem erros de dados?

Uma vez validados os dados, deve-se verificar a existência de erros nos mesmos. Caso a resposta seja “Não”, deve-se prosseguir para a

geração dos índices de controle dos dados cadastrais. No caso de a resposta for “Sim”, será preciso corrigi-los.

P2S1A6

Corrigir os dados

Uma vez confirmada a existência de erros de dados, deve-se proceder para a correção dos mesmos nas fontes primárias.

P2S1A7

Gerar os índices de controle

Os índices de controle deverão possuir metas para que seja avaliada a acuracidade dos dados. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

P2S1A7

Gerar os índices de controle

229

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Limites mínimo e máximo

do prazo de validade de

MPs resfriadas

O prazo de validade deve ser respeitado na

programação de cortes e de formulados. As

matérias-primas resfriadas possuem uma

média menor de dias de validade em relação

às MPs congeladas.

Dias

Número de dias de validade

de cada matéria-prima

resfriada.

Sugere-se

acompanhar a

cada rodada a

evolução do

indicador por meio

de gráficos de

controle.

Limites mínimo e máximo

do prazo de validade de

MPs congeladas

O prazo de validade deve ser respeitado na

programação de cortes e de formulados. As

matérias-primas congeladas possuem uma

média maior de dias de validade em relação

às MPs resfriadas.

Dias

Número de dias de validade

de cada matéria-prima

congelada.

Idem ao IC nº 1

Limites mínimo e máximo

o prazo de validade de

produtos finais resfriados

O prazo de validade deve ser respeitado na

programação de cortes e de formulados. Os

produtos finais resfriados possuem uma média

menor de dias de validade em relação aos

congelados.

Dias

Número de dias de validade

de cada produto final

resfriado.

Idem ao IC nº 1

Limites mínimo e máximo

do prazo de validade de

produtos finais

congelados

O prazo de validade deve ser respeitado na

programação de cortes e de formulados. Os

produtos finais congeladas possuem uma

média maior de dias de validade em relação

aos resfriados.

Dias

Número de dias de validade

de cada produto final

congelado.

Idem ao IC nº 1

Limites mínimo e máximo

do lead time de

ressuprimento

O lead-time de ressuprimento influencia no

aprazamento de pedidos.

Dias

Lead time de cada

suprimento.

Idem ao IC nº 1

Limites mínimo e máximo

do lote mínimo de

ressuprimento

O lote mínimo de ressuprimento influencia no

aprazamento de pedidos.

Depende

material

Lote mínimo de cada

suprimento.

Idem ao IC nº 1

Limites mínimo e máximo

dos tempos de

transferência entre

unidades, armazéns e

pontos de embarque

O tempo de transferência influencia no

aprazamento de pedidos.

Dias

Tempos de transferência

entre unidades, armazéns e

pontos de embarque.

Idem ao IC nº 1

230

Consistência entre o

cadastro de peso de

pallet e os estoques

iniciais

O peso do pallet influencia na programação

de estoques, enquanto que o estoque inicial

no aprazamento de pedidos.

Pallets

Comparar a quantidade

teórica de pallets¹ em

estoque com a capacidade

real de estoques (em número

de pallets) em cada local

onde houver estoque inicial.

¹ Soma das divisões do

estoque inicial de cada

produto em cada fábrica ou

unidade de estocagem pelo

peso unitário do pallet do

produto.

Sugere-se

acompanhar o

indicador por meio

de um gráfico antes

de cada rodada do

sistema.

P2S1T3

As metas foram atingidas?

Os resultados dos índices de controle deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não

atingidas, deverá proceder-se para a identificação dos erros. Se as metas de todos os índices de controle foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S1A8

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os índices de controle que não atingiram as metas.

2. Identificados os índices, deve-se verificar onde está o erro.

3. Encontrado o erro, deve-se corrigi-lo na fonte primária.

P2S1A9

Excluir os estoques de produtos

Uma vez atingidas as metas de todos os índices de controle, é necessário excluir os dados de estoques de produtos. Este procedimento

deve ser realizado por meio de um script de exclusão no banco de dados do sistema de programação de produção.

P2S1A10

Excluir as capacidades reais de estoques

Uma vez atingidas as metas de todos os índices de controle, é necessário excluir os dados de capacidades reais de estoques de produtos.

Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de programação de produção.

APÊNDICE D6 – Detalhamento fino das atividades e testes do Subprocesso 2.2

232

P2S2A1

Preparar a carga de dados cadastrais

A carga de dados cadastrais atualizada e corrigida deve ser preparada para ser importada para o sistema de programação da produção.

P2S2A2

Preencher o template das árvores de formulação de uma fábrica sem os roteiros de produção

O template deve ser preenchido utilizando os dados de árvores previamente coletados no Processo de Preparação de Dados, de apenas

uma fábrica e desconsiderando os roteiros produtivos.

P2S2A3

Preencher o template dos estoques fictícios para todas as MPs

O template deve ser preenchido com todos os códigos de matérias-primas que são utilizados na empresa, para todos os dias do horizonte,

em volumes elevados.

Obs.: considera-se elevada uma quantidade que jamais seria consumida em um dia de produção.

P2S2A4

Preencher o template com pedidos fictícios para os produtos formulados da fábrica escolhida

O template deve ser preenchido com o auxílio de scripts para a geração dos pedidos fictícios, com as seguintes condições:

• Apenas produtos formulados da fábrica escolhida devem ser ter pedidos fictícios.

• A quantidade dos pedidos deve ser de 1 kg.

• Todos os pedidos devem possuir o mesmo cliente e país.

• O SIF da fábrica deve estar habilitado, tanto na realidade quanto no sistema, para o cliente e o país escolhidos.

P2S2A5

Preencher o template das capacidades elevadas de estoques

O template deve ser preenchido com capacidades elevadas de estoques para todas as fábricas e unidades de armazenagem.

Obs.: considera-se elevada uma capacidade que jamais seria utilizada.

P2S2A6

Preencher o template com os lead times e os lotes mínimos de suprimentos zerados

O template deve ser preenchido por todos os suprimentos (embalagens e condimentos), porém com os dados de lead time e de lote

mínimo de compra zerados.

P2S2A7

Importar os templates

Os templates preenchidos nas atividades precedentes deverão ser importados para o sistema de seqüenciamento da produção.

P2S2T1

Houve erros nas importações?

Após a importação dos dados, devem-se analisar as mensagens geradas pelos logs

criados no Processo de Preparação de Dados. Se forem

constatados erros no processo de importação, devem-se identificar e corrigir os problemas. Caso a resposta à atividade for “Não”, deve-se

233

partir para a validação dos dados do banco.

P2S2A8

Identificar e corrigir os erros

1. Ao constatar-se que houve erros de importação para o sistema de seqüenciamento da produção, deve-se primeiramente identificar qual

template ou carga teve problemas.

2. Identificado o template ou carga de dados, deve-se identificar o erro e corrigir a fonte primária.

P2S2A9

Validar os dados do banco

As validações são cumulativas, logo a estrutura de dados será também validada pelas validações sugeridas em etapas anteriores.

P2S2A9

Validar os dados do banco

Nº Tipo Descrição da validação Função / Importância

13 Alerta

Produtos irmãos em uma árvore de formulação

pertencem a famílias de produto distintas

Um produto formulado não necessariamente deve possuir matérias-primas que

pertençam à mesma família de produto entre si, porém é importante alertar

para estes casos.

14 Erro

Fábrica não está habilitada para estocar

produtos, mas existe estoque para a mesma.

Esta validação abrange duas situações:

1) A fábrica talvez possa estocar produtos, logo a habilitação para estocagem

é que pode estar errada.

2) Se a fábrica tiver estoques cadastrados, mas realmente não possuir

habilitação para estocar, a carga de estoques foi feita para a fábrica errada.

15 Erro Produto em estoque não é estocável

Esta validação abrange duas situações:

1) Se o produto for estocável, existe erro na permissão de estocagem.

2) Se o produto realmente não for estocável, existe erro na carga de estoques.

16 Erro

Produto pai possui filhos alternativos e

compulsórios

Uma árvore jamais poderá ter filhos alternativos e compulsórios do mesmo pai,

pois a situação é conflitante no conceito destes termos: enquanto os alternativos

não possuem rendimento em uma árvore de cortes ou percentual de

formulação em uma árvore de formulação, os compulsórios são exatamente o

contrário.

17 Erro

Produto presente em uma árvore possui

rendimento zerado

Em uma árvore de cortes, um rendimento zerado significa que a massa do

produto pai não será desmembrada para o filho. Já em uma árvore de

formulação, a situação é inversa - a massa do produto filho não será utilizada

para a geração do produto pai.

234

18 Erro

Produto compulsório presente em uma árvore

de formulação possui percentual da

formulação zerado

Esta validação abrange duas situações:

1) Se o produto for realmente compulsório, existe erro no percentual de

formulação, pois isso fará com que a massa gerada do componente não seja

utilizada na programação do formulado.

2) Se o produto não for compulsório, deve ser transformado em alternativo.

19 Erro

Produto presente em uma árvore de

formulação possui filhos cuja soma dos

percentuais de formulação é diferente de 100

Uma árvore de formulação representa a montagem de um produto, logo não é

possível que a soma dos percentuais de formulação dos componentes da

mesma seja diferente de 100.

20 Alerta

Produto não consta em nenhuma árvore de

cortes ou de formulação

Um produto não necessariamente deve constar em uma árvore, pois pode estar

desativado por não ter previsão de ser produzido, por exemplo.

21 Erro

Produto consta em pedido, porém não está

habilitado em nenhuma fábrica

Todo produto que constar em pedidos deve estar habilitado em pelo menos

uma fábrica, caso contrário o mesmo não será programado.

22 Erro

Produto possui pedido, porém não consta em

nenhuma árvore de cortes ou de formulação

Todo produto que constar em pedidos deve estar cadastrado em pelo menos

uma árvore, caso contrário o mesmo não será programado.

23 Erro

Produto consta em pedido e nenhuma das

árvores nas quais está cadastrado está

habilitada

Mesmo que o produto esteja cadastrado em alguma árvore, esta deve estar

habilitada em pelo menos uma fábrica, caso contrário o produto não será

programado.

24 Erro

Produto consta em pedido e está habilitado

em pelo menos uma fábrica, porém não

consta em árvores que estejam vinculadas às

fábricas nas quais está habilitado.

Mesmo que o produto esteja cadastrado em alguma árvore e em alguma

fábrica, pelo menos uma das árvores deve estar habilitada para uma das

fábricas nas quais o produto esteja habilitado.

25 Erro

Produto formulado não possui componentes

(formulação)

Um produto formulado, pelo fato de ser "montado", deve possuir componentes

na sua árvore, caso contrário será impossível programar a produção do produto.

26 Erro Produto possui pedido, porém não é vendável

Esta validação abrange duas situações:

1) Se o produto realmente tiver pedidos, o atributo para venda deve ser

corrigido.

2) Caso o produto não for realmente vendável, o pedido está errado.

27 Alerta

O SIF da fábrica não está habilitado para o

país do pedido, porém pelo menos um dos

produtos do pedido está cadastrado em

alguma árvore da fábrica

Esta validação abrange duas situações:

1) Se o SIF da fábrica realmente não estiver habilitado para o país destino do

pedido, não há erros neste caso.

2) A habilitação do SIF da fábrica para o país destino do pedido pode estar

errada.

235

28 Alerta

O SIF da fábrica não está habilitado para o

cliente do pedido, porém está habilitado para

o país do cliente

Esta validação abrange duas situações:

1) O SIF da fábrica talvez realmente possa fabricar produtos para o cliente, logo

existiria um erro de cadastro.

2) A habilitação do SIF da fábrica para o país destino do pedido pode estar

errada.

29 Alerta

O SIF da fábrica está habilitado para o cliente

do pedido, porém não está habilitado para o

país do cliente

Esta validação abrange duas situações:

1) O SIF da fábrica talvez não possa fabricar produtos para o cliente, logo

existiria um erro neste cadastro.

2) A habilitação do SIF da fábrica para o país destino do pedido pode estar

errada.

30 Alerta

Validade máxima de produção permitida no

embarque é nula.

Se a validade máxima for zero, o sistema programará o atendimento do pedido

com lotes de produção cujas datas de fabricação sejam até 1 mês menores que

a data de embarque. Exemplo: um pedido com data de embarque para

13/03/2009 não poderia ser programado com lotes de produção inferiores a

13/02/2009. Quanto menor for a validade máxima de produção aceita na data

de embarque, menor será faixa de tolerância com a qual o sistema deverá lidar

para programar a produção.

31 Alerta

Produto possui demanda, mas não possui

pedidos

Este caso pode ser um indicativo de que o cadastro de demanda esteja

faltando ou que o pedido tenha sido colocado no produto errado.

32 Alerta

Produto possui pedidos, mas não possui

demanda

Este caso pode ser um indicativo de que o cadastro de demanda esteja

faltando ou que o pedido tenha sido colocado no produto errado.

33 Alerta

Árvore possui produto intermediário sem filhos

Dependendo-se da modelagem feita em uma árvore, esta situação pode não

configurar um problema, porém é importante verificar cada caso, pois uma

árvore geralmente chega ao nível do produto folha (ou seja, gera um produto

final ou MP).

34 Erro

Árvore de formulação possui suprimento do

tipo embalagem

Uma árvore de formulação deve possuir apenas os componentes que

contribuam para a geração da massa para o produto fin

al. Logo, a embalagem

não faz parte deste processamento.

35 Alerta

País não possui SIF produtor vinculado

Nem todo país necessita possuir relação com algum SIF, porém se um pedido for

colocado para um país que não permite a exportação de um SIF produtor não

habilitado ao referido país, o sistema não programará o pedido.

36 Alerta

SIF não apresenta país vinculado

Nem todo SIF necessita estar habilitado para algum país, porém, se um pedido

for colocado para um país que não permite a exportação do referido SIF, o

sistema não programará o pedido.

236

37 Erro

Fábrica está habilitada para estocar, porém

não possui capacidade de estocagem

cadastrada

Esta validação abrange duas situações:

1) A fábrica talvez não possa estocar produtos, logo a permissão para

estocagem é que pode estar errada.

2) Se a fábrica pode estocar produtos, mas não possui capacidade de

estocagem cadastrada, o sistema desconsiderará a possibilidade de programar

a produção para o estoque.

P2S2T2

Existem erros de dados?

Uma vez validados os dados, deve-se verificar a existência de erros nos mesmos. Caso a resposta seja “Não”, deve-se prosseguir para a

rodada do sistema. No caso de a resposta for “Sim”, será preciso corrigi-los.

P2S2A10

Corrigir os dados

Uma vez confirmada a existência de erros de dados, deve-se proceder para a correção dos mesmos nas fontes primárias.

P2S2A11

Gerar os índices de controle

Os índices de controle deverão possuir metas para que seja avaliada a acuracidade dos dados. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, não existem novos ICs, porém deverão ser mantidos os ICs 1 ao 4 e o 7.

P2S2T3

As metas foram atingidas?

Os resultados dos índices de controle deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não

atingidas, deverá proceder-se para a identificação dos erros. Se as metas de todos os índices de controle foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S2A12

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os índices de controle que não atingiram as metas.

2. Identificados os índices, deve-se verificar onde está o erro.

3. Encontrado o erro, deve-se corrigi-lo na fonte primária.

P2S2A13

Rodar o sistema

Quando as metas de todos os ICs forem atingidas, o sistema deverá ser rodado para que os resultados da fábrica escolhida sejam

237

analisados.

P2S2A14

Gerar os indicadores

Os indicadores deverão possuir metas para que sejam avaliados os resultados da rodada do sistema. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

P2S2A14

Gerar os indicadores

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Programação de

pedidos fictícios

(global)

Permite verificar se os dados

populados até esta etapa possuem

uma acuracidade que garanta a

programação dos pedidos.

Soma dos pedidos

programados, em kg,

dividida pelo total de

pedidos, em kg.

Sugere-se acompanhar a evolução do

indicador a cada rodada por meio de um

gráfico.

P2S2T4

As metas foram atingidas?

Os resultados dos indicadores deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não atingidas,

deverá proceder-se para a identificação e correção de erros de dados. Se as metas de todos os indicadores foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S2A15

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os índices de controle que não atingiram as metas.

2. Identificados os índices, deve-se iniciar um processo de identificação de erros e de oportunidades de melhoria, o qual é detalhado para

cada índice de controle.

Indicador 1 – Programação de pedidos fictícios (global)

1. Gerar uma listagem de todos os pedidos, na qual seja possível visualizar a quantidade solicitada no pedido e o volume programado do

pedido.

2. Classificar a lista pela ordem decrescente das diferenças absolutas entre o volume alocado e o solicitado em pedidos, priorizando a

análise das maiores diferenças.

3. Para cada pedido escolhido, analisar as seguintes situações:

3.1 Verificar se as quantidades solicitadas para os produtos do pedido estão corretas.

3.2 Verificar se todas as MPs e produtos intermediários que compõem as árvores dos produtos finais do pedido estão habilitados para a

fábrica na qual a árvore está vinculada.

238

3.3 Verificar se foi populada uma quantidade suficiente de estoque fictício de MP para atender a todos os pedidos de todos os produtos

que consta no pedido em análise.

3.4 Se os estoques fictícios de MPs não estiverem cadastrados na mesma fábrica que está sendo testada:

a) Verificar se existe permissão de transferência da fábrica na qual o estoque foi cadastrado para a fábrica em análise.

b) Verificar se existe permissão de transferência de todas as MPs para a fábrica em análise.

c) Verificar se o tempo de transferência entre as fábricas é coerente com a realidade.

3.5 Verificar se os percentuais de formulação e os rendimentos dos produtos do pedido em análise estão corretos.

P2S2A16

Excluir as árvores de formulação da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os dados de árvores de formulação. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S2A17

Excluir os pedidos fictícios da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os dados de pedidos fictícios. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S2T5

Todas as fábricas foram testadas?

Após a exclusão dos dados da última fábrica testada, deve-se verificar se todas as fábricas já foram testadas. Caso a resposta seja “Sim”,

deve-se prosseguir para o Subprocesso 2.3. No caso de a resposta for “Não”, uma nova fábrica deverá ser testada.

APÊNDICE D7 – Detalhamento fino das atividades e testes do Subprocesso 2.3

240

P2S3A1

Preparar a carga de dados cadastrais

A carga de dados cadastrais atualizada e corrigida deve ser preparada para ser importada para o sistema de programação da produção.

P2S3A2

Preencher o template das árvores de formulação de uma fábrica com os roteiros de produção

O template deve ser preenchido utilizando os dados de árvores atualizados, desta vez considerando os recursos produtivos e seus

respectivos calendários e tempos de processo.

P2S3A3

Preencher o template dos pedidos e demandas reais dos produtos formulados da fábrica escolhida

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os pedidos e demandas estejam armazenados, com a

condição de que apenas produtos formulados da fábrica escolhida sejam considerados.

P2S3A4

Preencher o template dos estoques iniciais dos produtos finais formulados

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os estoques estejam armazenados, com a condição

de que apenas produtos formulados da fábrica escolhida sejam considerados, mesmo que estejam estocados em outras unidades

produtivas ou armazéns.

P2S3A5

Preencher o template das compras de produtos finais

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as compras estejam armazenadas,

com a condição de

que apenas produtos formulados da fábrica escolhida sejam considerados.

P2S3A6

Importar os templates

Os templates preenchidos nas atividades precedentes deverão ser importados para o sistema de seqüenciamento da produção.

P2S3T1

Houve erros nas importações?

Após a importação dos dados, deve-se analisar as mensagens geradas pelos logs criados no Processo de Preparação de Dados. Se forem

constatados erros no processo de importação, devem-se identificar e corrigir os problemas. Caso a resposta à atividade for “Não”, deve-se

partir para a validação dos dados do banco.

P2S3A7

Identificar e corrigir os erros

1. Ao constatar-se que houve erros de importação para o sistema de seqüenciamento da produção, deve-se primeiramente identificar qual

template ou carga teve problemas.

2. Identificado o template ou carga de dados, deve-se identificar o erro e corrigir a fonte primária.

241

P2S3A8

Validar os dados do banco

As validações são cumulativas, logo a estrutura de dados será também validada pelas validações sugeridas em etapas anteriores.

P2S3A8

Validar os dados do banco

Nº

Tipo Descrição da validação Função / Importância

Erro

Recurso do tipo posição fixa possui

quantidade por posição igual a zero

A tempos de processo

zerada de um recurso faria com que o sistema ignorasse a utilização

do recurso na programação da produção.

Erro

Recurso do tipo batelada possui

quantidade por hora igual a zero

A tempos de processo

zerada de um recurso faria com que o sistema ignorasse a utilização

do recurso na programação da produção.

Erro

Recurso do tipo batelada possui

mínimo de batelada maior que o

máximo

A tempos de processo

zerada de um recurso faria com que o sistema ignorasse a utilização

do recurso na programação da produção.

Erro

Recurso do tipo unitário possui

quantidade por hora igual a zero

A tempos de processo

zerada de um recurso faria com que o sistema ignorasse a utilização

do recurso na programação da produção.

Alerta

Recurso possui diferentes quantidades

entre os dias da semana em um

mesmo turno de trabalho

Um recurso não deve necessariamente possuir a mesma quantidade durante todos os dias

da semana em um mesmo turno de trabalho, porém é importante analisar cada caso

para verificar se existem erros.

Alerta

Recurso possui diferentes quantidades

entre os turnos de trabalho de um

mesmo dia da semana

Um recurso não deve necessariamente possuir a mesma quantidade entre os turnos de

trabalho de um mesmo dia da semana, porém é importante analisar cada caso para

verificar se existem erros.

Alerta

Recurso possui diferentes tempos de

parada programada entre os dias da

semana em um mesmo turno de

trabalho

Um recurso não deve necessariamente possuir os mesmos tempos de parada programada

durante todos os dias da semana em um mesmo turno de trabalho, porém é importante

analisar cada caso para verificar se existem erros.

Alerta

Recurso possui diferentes tempos de

parada programada entre os turnos

de trabalho de um mesmo dia da

semana

Um recurso não deve necessariamente possuir os mesmos tempos de parada programada

entre os turnos de trabalho de um mesmo dia da semana, porém é importante analisar

cada caso para verificar se existem erros.

Alerta

Recurso possui diferentes tempos de

hora-extra entre os dias da semana

em um mesmo turno de trabalho

Um recurso não deve necessariamente possuir os mesmos tempos de hora-extra durante

todos os dias da semana em um mesmo turno de trabalho, porém é importante analisar

cada caso para verificar se existem erros.

Alerta

Recurso possui diferentes tempos de

hora-extra entre os turnos de trabalho

de um mesmo dia da semana

Um recurso não deve necessariamente possuir os mesmos tempos de hora-extra entre os

turnos de trabalho de um mesmo dia da semana, porém é importante analisar cada caso

para verificar se existem erros.

242

Alerta

Recurso possui diferentes horários de

início de turno entre os dias da

semana em um mesmo turno de

trabalho

Um recurso não deve necessariamente possuir os mesmos horários de início de turno entre

os dias da semana em um mesmo turno de trabalho, porém é importante analisar cada

caso para verificar se existem erros.

Alerta

Recurso possui diferentes horários de

término de turno entre os dias da

semana em um mesmo turno de

trabalho

Um recurso não deve necessariamente possuir os mesmos horários de término de turno

entre os dias da semana em um mesmo turno de trabalho, porém é importante analisar

cada caso para verificar se existem erros.

Erro

Recurso possui horários sobrepostos

entre dois ou mais turnos de trabalho

em um mesmo dia

Os horários de término de um turno e de início do turno subseqüente não podem estar

sobrepostos. Exemplo: o término do turno 1 não pode ser maior que o início do turno 2, em

um mesmo dia.

Alerta

Árvore de cortes possui nodo com

recurso cadastrado mais de uma vez

O cadastro de um recurso duas ou mais vezes no roteiro de um mesmo nodo de uma

árvore pode ser um erro, como também uma modelagem normal.

Alerta

Árvore de formulação possui recurso

cadastrado mais de uma vez

O cadastro de um recurso duas ou mais vezes no roteiro de um mesmo nodo de uma

árvore pode ser um erro, como também uma modelagem normal.

Alerta

Produto consta em árvore de corte,

não possui filhos e não possui recurso

cadastrado

Um produto que não possui filhos geralmente é o produto final. Deve-se verificar se existe o

consumo de recursos pelo produto.

Alerta

Nodo em árvore possui roteiro cujos

recursos têm um número diferente de

turnos disponíveis

A existência de recursos com um número diferente de turnos em um mesmo roteiro pode

prejudicar a programação da produção, pois os recursos que possuírem menos turnos

talvez não conseguirão comportar a necessidade de programação e acabarão limitando

os outros recursos.

Erro

Recurso sem calendário empregado

em nodo

Um recurso não necessita possuir um calendário vinculado. Porém, no momento em que é

cadastrado em uma árvore, deve possuir um calendário, caso contrário o sistema não

considerará o recurso na programação da produção.

P2S3T2

Existem erros de dados?

Uma vez validados os dados, deve-se verificar a existência de erros nos mesmos. Caso a resposta seja “Não”, deve-se prosseguir para a

geração dos índices de controle. No caso de a resposta for “Sim”, será preciso corrigi-los.

P2S3A9

Corrigir os dados

Uma vez confirmada a existência de erros de dados, deve-se proceder para a correção dos mesmos nas fontes primárias.

P2S3A10

Gerar os índices de controle

Os índices de controle deverão possuir metas para que seja avaliada a acuracidade dos dados. As metas deverão ser derivadas de

243

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, deverão ser mantidos os ICs 1 ao 4 e o 7.

P2S3A10

Gerar os índices de controle

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Limites mínimos e máximos do desvio-

padrão dos tempos de processo dos

recursos cadastrados em árvores de

formulação (por fábrica e família de

produto)

Os tempos de processo

dos recursos

influenciam diretamente na

programação da produção, pois

representam a capacidade

produtiva.

kg/h

Desvio-padrão dos

tempos de processo

de cada recurso, por

fábrica e família de

produto

Sugere-se acompanhar a

cada rodada a evolução do

IC por meio de gráficos de

controle.

P2S3T3

As metas foram atingidas?

Os resultados dos índices de controle deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não

atingidas, deverá proceder-se para a identificação dos erros. Se as metas de todos os índices de controle foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S3A11

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os índices de controle que não atingiram as metas.

2. Identificados os índices, deve-se verificar onde está o erro.

3. Encontrado o erro, deve-se corrigi-lo na fonte primária.

P2S3A12

Medir as disponibilidades dos recursos

O sistema de programação da produção deverá calcular automaticamente as disponibilidades dos recursos da fábrica por turno.

O cálculo

deve ser feito da seguinte maneira, para cada recurso e turno: (hora final - hora inicial) + horas-extras - paradas programadas.

244

P2S3T4

As disponibilidades estão corretas?

As disponibilidades calculadas na atividade anterior devem ser confrontadas com a realidade para se verificar se os dados estão corretos.

Caso a resposta seja “Sim”, deve-se prosseguir para a rodada do sistema. No caso de a resposta for “Não”, será preciso corrigir os

calendários.

P2S3A13

Corrigir os calendários

Os erros identificados na atividade anterior deverão ser corrigidos na fonte primária.

P2S3A14

Rodar o sistema

Quando as metas de todos os ICs forem atingidas, o sistema deverá ser rodado para que os resultados da fábrica escolhida sejam

analisados.

P2S3A15

Gerar os indicadores

Os indicadores deverão possuir metas para que sejam avaliados os resultados da rodada do sistema. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, não se utiliza o indicador nº 1 criado no Subprocesso 2.2, e sim apenas novas medições propostas neste subprocesso.

P2S3A15

Gerar os indicadores

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Programação de pedidos

(global)

Permite verificar se os dados

populados até esta etapa possuem

uma acuracidade que garanta a

programação dos pedidos.

Soma de pedidos programados, em kg,

dividida pelo total de pedidos

residuais¹, em kg.

¹ Referem-se aos pedidos cuja data de

embarque seja menor ou igual à última

data do horizonte de programação do

sistema.

Sugere-se

acompanhar a

evolução do

indicador a cada

rodada por meio de

um gráfico.

245

Programação de

demanda líquida² (global)

² Refere-se à soma das

diferenças entre a

demanda total e os

pedidos, em kg, de cada

produto.

Permite verificar se os dados

populados até esta etapa possuem

uma acuracidade que garanta a

programação da demanda líquida.

A análise decorrente deste indicador

possibilita uma análise por produto,

já que o indicador nº 2 mensura a

programação de pedidos.

Soma da alocação para demanda, em

kg, dividida pelo total de demanda

líquida, em kg.

Idem ao indicador nº

Aderência da

programação (global por

fábrica)

Contribui para a comparação dos

volumes programados pelo sistema

em relação à projeção de

produção. A partir dos resultados, é

possível também avaliar a

acuracidade dos dados de pedidos

e de previsão de demanda.

[1 - (soma dos desvios absolutos do

programado pelo sistema em rela

ção à

projeção de produção, em kg)]

dividido pelo total projetado, em kg,

por fábrica.

Idem ao indicador nº

Aderência da

programação (por fábrica

e família de produto)

Idem ao indicador nº 4, com a

diferença que permite visualizar a

aderência para cada família de

produto, facilitando o processo de

identificação de erros de dados.

Idem ao indicador nº 4, porém

discriminado por família de produto.

Idem ao indicador nº

Projeção de consumo

versus necessidade de MPs

(aberto por MP)

Este indicador permite identificar 2

tipos de problemas: (1) erros nos

pedidos ou demandas; e (2) erros

nas árvores.

[1 - (

Soma dos desvios absolutos entre o

volume total de consumo projetado,

em kg, de cada MP e o volume total

necessário³ da MP, em kg

) dividida pelo

total do consumo projetado].

³ É o percentual da MP sobre o produto

final vezes o total de pedidos e

demanda líquida do produto final.

Idem ao indicador nº

P2S3T5

As metas foram atingidas?

Os resultados dos indicadores deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não atingidas,

deverá proceder-se para a identificação e correção de erros de dados. Se as metas de todos os indicadores foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S3A16

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

246

1. Identificar os indicadores que não atingiram as metas.

2. Identificados os indicadores, deve-se iniciar um processo de identificação e correção de erros, o qual é detalhado para cada um.

Indicador 2 – Programação de pedidos (global)

1. Gerar uma listagem de todos os pedidos, na qual seja possível visualizar a quantidade solicitada no pedido e o volume programado do

pedido.

2. Classificar a lista pela ordem decrescente das diferenças absolutas entre o volume alocado e o solicitado em pedidos, priorizando a

análise das maiores diferenças.

3. Para cada pedido escolhido, analisar as seguintes situações:

3.1 Verificar se as quantidades solicitadas para os produtos do pedido estão corretas.

3.2 Verificar se todas as MPs e produtos intermediários que compõem as árvores dos produtos finais do pedido estão habilitados para a

fábrica na qual a árvore está vinculada.

3.3 Verificar se foi populada uma quantidade suficiente de estoque fictício de MP para atender a todos os pedidos de todos os produtos

que consta no pedido em análise.

3.4 Se os estoques fictícios de MPs não estiverem cadastrados na mesma fábrica que está sendo testada:

a) Verificar se existe permissão de transferência da fábrica na qual o estoque foi cadastrado para a fábrica em análise.

b) Verificar se existe permissão de transferência de todas as MPs para a fábrica em análise.

c) Verificar se o tempo de transferência entre as fábricas é coerente com a realidade.

d) Verificar se os percentuais de formulação e os rendimentos dos produtos do pedido em análise estão corretos.

Indicador 3 – Programação de demanda líquida (global)

1. Gerar uma listagem de todos os produtos que possuam demanda cadastrada, na qual seja possível visualizar a quantidade solicitada e o

volume programado.

2. Classificar a lista pela ordem decrescente das diferenças absolutas entre o volume alocado para a demanda líquida e a

demanda líquida

solicitada, priorizando a análise a partir das maiores diferenças.

3. Para cada produto escolhido, analisar as seguintes situações:

3.1 Verificar se as quantidades da demanda líquida estão corretas.

3.2 Verificar se todas as MPs e produtos intermediários que compõem as árvores dos produtos finais do pedido estão habilitados para a

fábrica na qual a árvore está vinculada.

3.3 Verificar se foi populada uma quantidade suficiente de estoque fictício de MP para atender a todos os pedidos de todos os produtos

que consta no pedido em análise.

3.4 Se os estoques fictícios de MPs não estiverem cadastrados na mesma fábrica que está sendo testada:

a) Verificar se existe permissão de transferência da fábrica na qual o estoque foi cadastrado para a fábrica em análise.

b) Verificar se existe permissão de transferência de todas as MPs para a fábrica em análise.

3.5 Verificar se os percentuais de formulação e os rendimentos dos produtos em análise estão corretos.

247

Indicador 4 – Aderência da programação (por fábrica)

Indicador 5 – Aderência da programação (por fábrica e família de produto)

O indicador 4 serve para se ter uma visão geral da programação dos produtos da fábrica. Portanto, independentemente do resultado

deste indicador, deve-se sempre analisá-lo conjuntamente com a aderência por família de produtos (indicador 5). Este indicador, por sua

vez, possibilita analisar a programação total dos produtos, e não somente o volume alocado para pedido e demanda líquida, como feito

nos indicadores 2 e 3. Abaixo são listadas outras análises possíveis por meio dos indicadores 4 e 5:

• Produtos programados mais ou menos que o necessário ou normal. Isso pode ocorrer quando há produtos quem possuem pedidos ou

demanda cujas quantidades estejam erradas. Neste caso, se o sistema tenha conseguido programar os produtos, não teriam sido

geradas diferenças nos indicadores nº 2 e 3, porém no indicador nº 5 isso será identificado.

• Produtos não programados por não possuírem pedidos nem demanda cadastrados, mas que deveriam ter.

1. Gerar uma listagem na qual seja possível visualizar os volumes projetados de produção e a programação sugerida pelo sistema, por

família de produto.

2. Classificar a lista pela ordem crescente das aderências, priorizando a análise a partir destas, somente para as famílias de produto que não

alcançaram a meta.

3. Para cada família de produto a ser analisada, deve-se gerar a lista dos produtos que fazem parte da família.

4. De posse da lista aberta da família de produtos, analisar as seguintes questões:

4.1 Verificar se todos os produtos realmente fazem parte da família. Caso não fizerem parte, devem ser cadastrados na família correta.

4.2 Verificar se to

dos os produtos programados podem ser produzidos na fábrica em análise (mesmo que não tenham sido projetados). Se

houver produtos que não puderem ser programados na fábrica, os mesmos deverão ser excluídos das árvores e da permissão de

produção na fábrica em análise.

4.3 Verificar se existem produtos que estejam previstos na projeção, mas que não estão sendo programados. Se houver produtos nesta

situação, os mesmos devem ser incluídos nas árvores de cortes e na permitidos na fábrica em análise, desde que existam pedidos ou

demandas para os mesmos.

5. Após verificar as situações do item 4, devem-

se analisar as seguintes situações para cada produto cuja aderência não tenha alcançado a

meta da família:

5.1 Verificar se as quantidades de pedidos e demanda do produto estão corretas.

5.2 Verificar se todas as MPs e produtos intermediários que compõem as árvores dos produtos finais do pedido estão habilitados para a

fábrica na qual a árvore está vinculada.

5.3 Verificar se foi populada uma quantidade suficiente de estoque fictício de MP para atender a todos os pedidos de todos os produtos

que consta no pedido em análise.

5.4 Se os estoques fictícios de MPs não estiverem cadastrados na mesma fábrica que está sendo testada:

a) Verificar se existe permissão de transferência da fábrica na qual o estoque foi cadastrado para a fábrica em análise.

b) Verificar se existe permissão de transferência de todas as MPs para a fábrica em análise.

5.5 Verificar se os percentuais de formulação e os rendimentos dos produtos do pedido em análise estão corretos.

248

Complemento à análise dos indicadores 2 a 5:

1. Quando verificar-se que a quantidade programada de um ou mais produtos estiver abaixo do normal, deve-se proceder para a análise

abaixo:

1.1 Escolher um produto para análise.

1.2 Verificar quais recursos estão cadastrados na árvore do produto.

1.3 Verificar se os tempos de processo dos recursos e as ordens nos roteiros estão subdimensionadas.

1.4 Se o recurso possuir recurso alternativo na realidade, deve-se verificar se ambos estão cadastrados e se as ordens dos recursos nos

roteiros é a mesma.

1.5 Abrir o relatório de ocupação de recursos.

1.6 Filtrar os recursos em análise.

1.7 Depois de filtrados somente os recursos de interesse, sugere-se analisar uma faixa de ocupação de recursos (de 80 a 100%, por

exemplo), pois, no caso de recursos do tipo batelada, a produção de um lote a mais em um turno de produção poderia ser impedida

caso a ocupação do recurso se tornasse superior a 100%. Como este tipo de situação não pode acontecer em um sistema de

seqüenciamento da produção que considera as capacidades finitas dos recursos, a análise de uma faixa de ocupação de recursos

contribui para a identificação dos recursos que estejam limitando a programação da produção.

1.8 Identificar as datas e turnos nos quais os recursos apresentam ocupação dentro da faixa escolhida.

1.9 Abrir o relatório de programação da produção por recurso.

1.10 Para cada recurso escolhido, verificar as seguintes situações:

a) Quais produtos estão utilizando (consumindo) o recurso. Se houver produtos que na realidade não utilizam o recurso, deve-se

excluir o recurso do roteiro destes produtos nas árvores.

Coerência da ocupação do recurso. Exemplo: se um ou poucos produtos ocuparem a maior parte do recurso (75%, por exemplo),

é possível que os tempos de processo destes produtos estejam mal dimensionadas. Neste caso, é necessário entrar nas árvores de

todos os produtos e analisar os tempos de processo e as ordens dos recursos nos roteiros, bem como verificar a existência de

recursos alternativos cadastrados de forma errada.

Indicador 6 - Projeção de consumo versus necessidade de MPs (aberto por MP)

1. Gerar uma listagem na qual seja possível visualizar os volumes necessários de MPs e as quantidades projetadas para o consumo de

formulações, por MP.

2. Classificar a lista pela ordem crescente das aderências, priorizando a análise a partir destas, somente para as MPs que não alcançaram a

meta.

3. Para cada MP escolhida para análise, caso o volume projetado e o necessário forem diferentes, devem-se verificar as seguintes situações:

3.1 Verificar se o volume projetado está errado.

3.2 Verificar em quais árvores de formulação a MP está cadastrada.

3.3 Dentre as árvores identificadas, verificar se a MP realmente faz parte da estrutura de produto.

3.4 Verificar se as quantidades de pedidos e demanda dos produtos cujas árvores possuem a MP cadastrada estão corretas.

3.5 Verificar se foi populada uma quantidade suficiente de estoque fictício de MP.

249

3.6 Se os estoques fictícios de MPs não estiverem cadastrados na mesma fábrica que está sendo testada:

a) Verificar se existe permissão de transferência da fábrica na qual o estoque foi cadastrado para a fábrica em análise.

b) Verificar se existe permissão de transferência de todas as MPs para a fábrica em análise.

3.7 Verificar se os percentuais de formulação e os rendimentos dos produtos do pedido em análise estão corretos.

3.8 Verificar se todas as MPs e produtos intermediários que compõem as árvores dos produtos finais que possuem a MP em análise estão

habilitados para a fábrica na qual a árvore está vinculada.

Obs.: o indicador 6 deve ser analisado com critério, pois a existência de MPs alternativas em uma formulação faz com que o cálculo de

necessidade seja "dobrado". Ou seja, nem todos os resultados que não alcançarem a meta necessariamente serão erros, pois as MPs

alternativas podem ser compensadas umas pelas outras na programação dos formulados.

P2S3A17

Excluir as árvores de formulação com os roteiros de produção da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os dados de árvores de formulação

com os

roteiros de produção. Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de

seqüenciamento de produção.

P2S3A18

Excluir os pedidos e demandas reais dos produtos da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os dados de pedidos e demandas reais.

Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S3A19

Excluir os estoques iniciais de produtos finais

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os estoques iniciais de produtos finais. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S3A20

Excluir as compras de produtos finais

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as compras de produtos finais. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

Atividade

Todas as fábricas foram testadas?

Após a exclusão dos dados da última fábrica testada, deve-se verificar se todas as fábricas já foram testadas. Caso a resposta seja “Sim”,

deve-se prosseguir para o Subprocesso 2.4. No caso de a resposta for “Não”, uma nova fábrica deverá ser testada.

APÊNDICE D8 – Detalhamento fino das atividades e testes do Subprocesso 2.4

251

P2S4A1

Preparar a carga de dados cadastrais

A carga de dados cadastrais atualizada e corrigida deve ser preparada para ser importada para o sistema de programação da produção.

P2S4A2

Preencher o template das árvores de formulação de uma fábrica com os roteiros de produção

O template deve ser preenchido utilizando os dados de árvores atualizados, considerando os recursos produtivos e seus respectivos

calendários e tempos de processo.

P2S4A3

Preencher o template dos pedidos e demandas reais dos produtos formulados da fábrica escolhida

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os pedidos e demandas estejam armazenados, com a

condição de que apenas produtos formulados da fábrica escolhida sejam considerados.

P2S4A4

Preencher o template dos estoques iniciais de suprimentos da fábrica escolhida

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os estoques estejam armazenados, com a condição

de que apenas suprimentos estocados na fábrica escolhida sejam considerados.

P2S4A5

Preencher o template das estruturas de embalagens da fábrica escolhida

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as estruturas de embalagens estejam armazenadas,

com a condição de que apenas as estruturas de embalagens de produtos formulados da fábrica escolhida sejam consideradas.

P2S4A6

Preencher o template dos lead times e lotes mínimos reais de suprimentos

O template deve ser preenchido com todos os suprimentos que sejam utilizados na fábrica que está sendo testada.

P2S4A7

Preencher o template dos estoques iniciais dos produtos finais formulados

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os estoques estejam armazenados, com a condição

de que apenas produtos formulados da fábrica escolhida sejam considerados, mesmo que estejam estocados em outras unidades

produtivas ou armazéns.

P2S4A8

Preencher o template das compras de produtos finais

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as compras de produto estejam armazenadas, com a

condição de que apenas produtos formulados da fábrica escolhida sejam considerados.

P2S4A9

Preencher o template das compras de suprimentos

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as compras de suprimentos (recebimentos futuros)

252

estejam armazenadas, com a condição de que apenas suprimentos comprados para a fábrica escolhida sejam considerados.

P2S4A10

Importar os templates

Os templates preenchidos nas atividades precedentes deverão ser importados para o sistema de seqüenciamento da produção.

P2S4T1

Houve erros nas importações?

Após a importação dos dados, devem-se analisar as mensagens geradas pelos logs criados no Proce

sso de Preparação de Dados. Se forem

constatados erros no processo de importação, devem-se identificar e corrigir os problemas. Caso a resposta à atividade for “Não”, deve-se

partir para a validação dos dados do banco.

P2S4A11

Identificar e corrigir os erros

1. Ao constatar-se que houve erros de importação para o sistema de seqüenciamento da produção, deve-se primeiramente identificar qual

template ou carga teve problemas.

2. Identificado o template ou carga de dados, deve-se identificar o erro e corrigir a fonte primária.

P2S4A12

Validar os dados do banco

Nesta etapa, existem duas novas validações. Apesar disso, como as validações são cumulativas, a estrutura de dados será também

validada pelas validações sugeridas em etapas anteriores.

P2S4A12

Validar os dados do banco

Nº

Tipo Descrição da validação Função / Importância

Erro

Produto possui suprimento com

quantidade zerada na estrutura de

embalagens

Se uma embalagem tiver quantidade igual a zero na estrutura de um produto, a mesma

não será considerada na programação da produção.

Alerta

Suprimento cadastrado na lista de

compras tem data de entrega

estimada no passado

Esta situação não representa necessariamente um erro, pois a entrega do material pode

estar atrasada. No entanto, a entrega não será utilizada pelo sistema na programação da

produção, o que refletirá na qualidade das informações geradas pelo mesmo.

P2S4T2

Existem erros de dados?

Uma vez validados os dados, deve-se verificar a existência de erros nos mesmos. Caso a resposta seja “Não”, deve-se prosseguir para a

geração dos índices de controle. No caso de a resposta for “Sim”, será preciso corrigi-los.

P2S4A13

Corrigir os dados

Uma vez confirmada a existência de erros de dados, deve-se proceder para a correção dos mesmos nas fontes primárias.

253

P2S4A14

Gerar os índices de controle

Os índices de controle deverão possuir metas para que seja avaliada a acuracidade dos dados. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, deverão ser mantidos os ICs 1 ao 7 e o 9.

P2S4A14

Gerar os índices de controle

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Limites mínimo e máximo

da quantidade na

estrutura de embalagens

A quantidade necessária de

embalagens por produto influencia

nas compras e projeções de

consumo do suprimento, bem como

no aprazamento de pedidos.

Depen

de do

material

Quantidade de embalagens na

estrutura das mesmas para os produtos.

Sugere-se

acompanhar a cada

rodada a evolução

do IC por meio de

gráficos de controle.

P2S4T3

As metas foram atingidas?

Os resultados dos índices de controle deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não

atingidas, deverá proceder-se para a identificação dos erros. Se as metas de todos os índices de controle foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S4A15

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os índices de controle que não atingiram as metas.

2. Identificados os índices, deve-se verificar onde está o erro.

3. Encontrado o erro, deve-se corrigi-lo na fonte primária.

P2S4A16

Rodar o sistema

Quando as metas de todos os ICs forem atingidas, o sistema deverá ser rodado para que os resultados da fábrica escolhida sejam

analisados.

P2S4A17

Gerar os indicadores

Os indicadores deverão possuir metas para que sejam avaliados os resultados da rodada do sistema. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

254

Neste ponto, deverão ser mantidos os indicadores 2 ao 6.

P2S4A17

Gerar os indicadores

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo

Acompanhament

Projeção de

consumo

versus

necessidade

suprimentos

A quantidade necessária de

suprimentos influencia nas

compras e projeções de

consumo dos mesmos, bem

como no aprazamento de

pedidos.

[1 - (Soma dos desvios absolutos entre a projeção de consumo

de cada suprimento e a necessidade¹ do material) dividida

pelo total do consumo projetado].

³ É o percentual do ingrediente sobre o produto final vezes a

programação do produto que utiliza o condimento mais a

quantidade de embalagem na estrutura vezes a programação

do produto utiliza este material.

Sugere-se

acompanhar a

evolução do

indicador a cada

rodada por meio

de um gráfico.

P2S4T4

As metas foram atingidas?

Os resultados dos indicadores deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não atingidas,

deverá proceder-se para a identificação e correção de erros de dados. Se as metas de todos os indicadores foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S4A18

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os indicadores que não atingiram as metas.

2. Identificados os indicadores, deve-se iniciar um processo de identificação e correção de erros, o qual é detalhado para cada medição.

Indicador 7 – Projeção de consumo versus necessidade de suprimentos

1. Gerar uma listagem na qual seja possível visualizar as quantidades necessárias e as projetadas de suprimentos, por material.

2. Classificar a lista pela ordem crescente das aderências, priorizando a análise a partir destas, somente para os suprimentos que não

alcançaram a meta.

3. Para cada suprimento escolhido para análise, devem-se verificar as seguintes situações:

3.1 Verificar se as metas dos indicadores de pedidos e de previsão de demanda estão sendo alcançadas.

3.2 Verificar se o estoque inicial do suprimento está correto.

255

3.3 Verificar se o volume projetado do suprimento está errado.

3.4 Verificar em quais árvores de formulação o ingrediente está cadastrado e em quais produtos a embalagem está vinculada.

P2S4A19

Excluir as árvores de formulação com os roteiros de produção da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as árvores de formulação com os roteiros

de produção. Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento

de produção.

P2S4A20

Excluir os pedidos e demandas reais dos produtos da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os pedidos e demandas reais. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S4A21

Excluir os estoques iniciais de suprimentos da fábrica escolhida

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os estoques iniciais de suprimentos. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S4A22

Excluir as estruturas de embalagens da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as estruturas de embalagens. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S4A23

Excluir os lead times e lotes mínimos reais de suprimentos

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os lead times e lotes mínimos reais de

suprimentos. Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento

de produção.

P2S4A24

Excluir os estoques iniciais de produtos finais formulados

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os estoques iniciais de produtos finais

formulados. Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento

de produção.

P2S4A25

Excluir as compras de produtos finais

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as compras de produtos finais. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

256

P2S4A26

Excluir as compras de suprimentos

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as compras de suprimentos. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S4T5

Todas as fábricas foram testadas?

Após a exclusão dos dados da última fábrica testada, deve-se verificar se todas as fábricas já foram testadas. Caso a resposta seja “Sim”,

devem-se excluir as capacidades elevadas de estoques. No caso de a resposta for “Não”, uma nova fábrica deverá ser testada.

P2S4A27

Excluir as capacidades elevadas de estoques de produtos

Após todas as fábricas terem sido testadas, devem-se excluir as capacidades elevadas de estoques para que se testem as limitações de

estoque no Subprocesso 2.5.

APÊNDICE D9 – Detalhamento fino das atividades e testes do Subprocesso 2.5

258

P2S5A1

Preparar a carga de dados cadastrais

A carga de dados cadastrais atualizada e corrigida deve ser preparada para ser importada para o sistema de programação da produção.

P2S5A2

Preencher o template das árvores de formulação de uma fábrica com os roteiros

O template deve ser preenchido utilizando os dados de árvores atualizados, considerando os recursos produtivos e seus respectivos

calendários e tempos de processo.

P2S5A3

Preencher o template dos pedidos e demandas reais dos produtos formulados da fábrica escolhida

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os pedidos e demandas estejam armazenados, com a

condição de que apenas produtos formulados da fábrica escolhida sejam considerados.

P2S5A4

Preencher o template dos estoques iniciais de suprimentos da fábrica escolhida

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os estoques estejam armazenados, com a condição

de que apenas suprimentos estocados na fábrica escolhida sejam considerados.

P2S5A5

Preencher o template das estruturas de embalagens da fábrica escolhida

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os estoques estejam armazenados, com a condição

de que apenas as estruturas de embalagens de produtos formulados da fábrica escolhida sejam considerados.

P2S5A6

Preencher o template dos lead times e lotes mínimos reais de suprimentos

O template deve ser preenchido com todos os suprimentos que sejam utilizados na fábrica que está sendo testada.

P2S5A7

Preencher o template dos estoques iniciais dos produtos finais formulados

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os estoques estejam armazenados, com a condição

de que apenas produtos formulados da fábrica escolhida sejam considerados, mesmo que estejam estocados em outras unidades

produtivas ou armazéns.

P2S5A8

Preencher o template das compras de produtos finais

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as compras de produto estejam armazenadas, com a

condição de que apenas produtos formulados da fábrica escolhida sejam considerados.

P2S5A9

Preencher o template das capacidades reais de estoques da fábrica

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as capacidades reais de estoques estejam

259

armazenadas, com a condição de que apenas as capacidades da fábrica escolhida sejam consideradas.

P2S5A10

Preencher o template das compras de suprimentos

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as compras de suprimentos (recebimentos futuros)

estejam armazenadas, com a condição de que apenas suprimentos comprados para a fábrica escolhida sejam considerados.

P2S5A11

Importar os templates

Os templates preenchidos nas atividades precedentes deverão ser importados para o sistema de seqüenciamento da produção.

P2S5T1

Houve erros nas importações?

Após a importação dos dados, devem-se analisar as mensagens geradas pelos logs

criados no Processo de Preparação de Dados. Se forem

constatados erros no processo de importação, devem-se identificar e corrigir os problemas. Caso a resposta à atividade for “Não”, deve-se

partir para a validação dos dados do banco.

P2S5A12

Identificar e corrigir os erros

1. Ao constatar-se que houve erros de importação para o sistema de seqüenciamento da produção, deve-se primeiramente identificar qual

template ou carga teve problemas.

2. Identificado o template ou carga de dados, deve-se identificar o erro e corrigir a fonte primária.

P2S5A13

Validar os dados do banco

Nesta etapa, não existem novas validações. Apesar disso, como as validações são cumulativas, a estrutura de dados será validada pelas

validações sugeridas em etapas anteriores.

P2S5T2

Existem erros de dados?

Uma vez validados os dados, deve-se verificar a existência de erros nos mesmos. Caso a resposta seja “Não”, deve-se prosseguir para a

geração dos índices de controle. No caso de a resposta for “Sim”, será preciso corrigi-los.

P2S5A14

Corrigir os dados

Uma vez confirmada a existência de erros de dados, deve-se proceder para a correção dos mesmos nas fontes primárias.

P2S5A15

Gerar os índices de controle

Os índices de controle deverão possuir metas para que seja avaliada a acuracidade dos dados. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

260

Neste ponto, não existem novos ICs, porém deverão ser mantidos os ICs 1 ao 10.

P2S5T3

As metas foram atingidas?

Os resultados dos índices de controle deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não

atingidas, deverá proceder-se para a identificação dos erros. Se as metas de todos os índices de controle foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S5A16

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os índices de controle que não atingiram as metas.

2. Identificados os índices, deve-se verificar onde está o erro.

3. Encontrado o erro, deve-se corrigi-lo na fonte primária.

P2S5A17

Rodar o sistema

Quando as metas de todos os ICs forem atingidas, o sistema deverá ser rodado para que os resultados da fábrica escolhida sejam

analisados.

P2S5A18

Gerar os indicadores

Os indicadores deverão possuir metas para que sejam avaliados os resultados da rodada do sistema. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, deverão ser mantidos os indicadores 2 ao 7.

P2S5A18

Gerar os indicadores

Nº

Descrição

Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Ocupação

média de

estoques

As limitações de

estoques influenciam na

programação da

produção.

Média da programação de estoques, em número de pallets¹,

dividida pela capacidade real de estoque, em número de pallets.

¹ Programação de estoques de cada produto, em kg, dividida pelo

peso do pallet de cada produto.

Sugere-se acompanhar

a evolução do

indicador a cada

rodada por meio de um

gráfico.

P2S5T4

As metas foram atingidas?

Os resultados dos indicadores deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não atingidas,

261

deverá proceder-se para a identificação e correção de erros de dados. Se as metas de todos os indicadores foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S5A19

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os indicadores que não atingiram as metas.

2. Identificados os indicadores, deve-se iniciar um processo de identificação e correção de erros, o qual é detalhado para cada

medição.

Indicador 8 – Ocupação média de estoques

1. Gerar uma listagem na qual seja possível visualizar os produtos e os respectivos volumes programados para o estoque ao longo do

horizonte.

2. Selecionar os estoques programados no último dia do horizonte.

3. Classificar a lista pela ordem decrescente dos volumes programados em estoque.

4. Para cada produto escolhido para análise, devem-se verificar as seguintes situações:

4.1 Verificar se o estoque inicial do produto está correto.

4.2 Verificar se os pedidos e demandas estão sendo atendidos.

4.3 Verificar as permissões e os tempos de transporte para os pontos de embarque.

P2S5A20

Excluir as árvores de formulação com os roteiros de produção da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as árvores de formulação com os roteiros

de produção. Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento

de produção.

P2S5A21

Excluir os pedidos e demandas reais dos produtos da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os pedidos e demandas reais. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S5A22

Excluir os estoques iniciais de suprimentos da fábrica escolhida

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os estoques iniciais de suprimentos. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S5A23

Excluir as estruturas de embalagens da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as estruturas de embalagens. Este

262

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S5A24

Excluir os lead times e lotes mínimos reais de suprimentos

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os lead times e lotes mínimos reais de

suprimentos. Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento

de produção.

P2S5A25

Excluir os estoques iniciais de produtos finais formulados

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os estoques iniciais de produtos finais

formulados. Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento

de produção.

P2S5A26

Excluir as compras de produtos finais

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as compras de produtos finais. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S5A27

Excluir as capacidades reais de estoques da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as capacidades reais de estoques da

fábrica testada. Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de

seqüenciamento de produção.

P2S5A28

Excluir as compras de suprimentos

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as compras de suprimentos. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S5T5

Todas as fábricas foram testadas?

Após a exclusão dos dados da última fábrica testada, deve-se verificar se todas as fábricas já foram testadas. Caso a resposta seja “Sim”,

devem-se prosseguir para o Subprocesso 2.6. No caso de a resposta for “Não”, uma nova fábrica deverá ser testada.

APÊNDICE D10 – Detalhamento fino das atividades e testes do Subprocesso 2.6

264

P2S6A1

Preparar a carga de dados cadastrais

A carga de dados cadastrais atualizada e corrigida deve ser preparada para ser importada para o sistema de programação da produção.

P2S6A2

Preencher o template das árvores de formulação de todas as fábricas com os roteiros

O template deve ser preenchido utilizando os dados de árvores atualizados, considerando os recursos produtivos e seus respectivos

calendários e tempos de processo.

P2S6A3

Preencher o template dos pedidos e demandas reais de todos os formulados

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os pedidos e demandas estejam armazenados, com a

condição de que apenas produtos formulados sejam considerados.

P2S6A4

Preencher o template dos estoques iniciais de suprimentos de todas as fábricas de formulados

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os estoques estejam armazenados, com a condição

de que apenas suprimentos estocados nas fábricas de formulados sejam considerados.

P2S6A5

Preencher o template das estruturas de embalagens de todas as fábricas de formulados

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os estoques estejam armazenados, com a condição

de que apenas as estruturas de embalagens de produtos formulados sejam consideradas.

P2S6A6

Preencher o template dos lead times e lotes mínimos reais de suprimentos

O template deve ser preenchido com todos os suprimentos que sejam utilizados nas fábricas de formulados.

P2S6A7

Preencher o template dos estoques iniciais de produtos finais formulados

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os estoques estejam armazenados, com a condição

de que apenas produtos formulados sejam considerados, mesmo que estejam estocados em outras unidades produtivas ou armazéns.

P2S6A8

Preencher o template das compras de produtos finais

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as compras de produto estejam armazenadas, com a

condição de que apenas produtos formulados sejam considerados.

P2S6A9

Preencher o template das capacidades reais de estoques de todas as fábricas de formulados

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as capacidades reais de estoques estejam

armazenadas, com a condição de que apenas as capacidades das fábricas de formulados sejam consideradas.

265

P2S6A10

Preencher o template das compras de suprimentos

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as compras de suprimentos (recebimentos futuros)

estejam armazenadas, com a condição de que apenas suprimentos comprados para as fábricas de formulados sejam considerados.

P2S6A11

Importar os templates

Os templates preenchidos nas atividades precedentes deverão ser importados para o sistema de seqüenciamento da produção.

P2S6T1

Houve erros nas importações?

Após a importação dos dados, devem-se analisar as mensagens geradas pelos logs criados no Processo de Preparação de Dados. Se

forem

constatados erros no processo de importação, devem-se identificar e corrigir os problemas. Caso a resposta à atividade for “Não”, deve-se

partir para a validação dos dados do banco.

P2S6A12

Identificar e corrigir os erros

1. Ao constatar-se que houve erros de importação para o sistema de seqüenciamento da produção, deve-se primeiramente identificar qual

template ou carga teve problemas.

2. Identificado o template ou carga de dados, deve-se identificar o erro e corrigir a fonte primária.

P2S6A13

Validar os dados do banco

Nesta etapa, não existem novas validações. Apesar disso, como as validações são cumulativas, a estrutura de dados será validada pelas

validações sugeridas em etapas anteriores.

P2S6T2

Existem erros de dados?

Uma vez validados os dados, deve-se verificar a existência de erros nos mesmos. Caso a resposta seja “Não”, deve-se prosseguir para a

geração dos índices de controle. No caso de a resposta for “Sim”, será preciso corrigi-los.

P2S6A14

Corrigir os dados

Uma vez confirmada a existência de erros de dados, deve-se proceder para a correção dos mesmos nas fontes primárias.

P2S6A15

Gerar os índices de controle

Os índices de controle deverão possuir metas para que seja avaliada a acuracidade dos dados. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, não existem novos ICs, porém deverão ser mantidos os ICs 1 ao 10.

266

P2S6T3

As metas foram atingidas?

Os resultados dos índices de controle deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não

atingidas, deverá proceder-se para a identificação dos erros. Se as metas de todos os índices de controle foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S6A16

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os índices de controle que não atingiram as metas.

2. Identificados os índices, deve-se verificar onde está o erro.

3. Encontrado o erro, deve-se corrigi-lo na fonte primária.

P2S6A17

Rodar o sistema

Quando as metas de todos os ICs forem atingidas, o sistema deverá ser rodado para que os resultados da fábrica escolhida sejam

analisados.

P2S6A18

Gerar os indicadores

Os indicadores deverão possuir metas para que sejam avaliados os resultados da rodada do sistema. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, deverão ser mantidos os indicadores 2 ao 8.

P2S6A18

Gerar os indicadores

Nº

Descrição

Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Pedidos

programad

os no prazo

Permite verificar se os

dados populados até

esta etapa possuem

uma acuracidade que

garanta a

programação dos

pedidos no prazo.

Soma de pedidos programados no prazo, em kg, dividida pelo total

de pedidos residuais¹, em kg.

¹ Referem-se aos pedidos cuja data de embarque seja menor ou

igual à última data do horizonte de programação do sistema.

Sugere-se acompanhar

a evolução do

indicador a cada

rodada por meio de um

gráfico.

P2S6T4

As metas foram atingidas?

267

Os resultados dos indicadores deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não atingidas,

deverá proceder-se para a identificação e correção de erros de dados. Se as metas de todos os indicadores foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S6A19

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os indicadores que não atingiram as metas.

2. Identificados os indicadores, deve-se iniciar um processo de identificação e correção de erros, o qual é detalhado para cada

medição.

Indicador 9 – Pedidos programados no prazo

1. Verificar quanto tempo está sendo necessário para que os pedidos que já entram atrasados sejam programados, pois eles podem estar

ocupando a massa que poderia estar sendo utilizada na programação de outros pedidos.

2. Gerar uma listagem na qual seja possível visualizar quais pedidos não foram programados no prazo.

3. Ordenar a lista pela ordem decrescente dos atrasos.

4. Para cada pedido escolhido para análise, devem-se verificar as seguintes situações:

4.1 Verificar se o estoque inicial dos produtos condiz com a realidade (datas dos lotes de produção, SIF produtor e volumes).

4.2 Verificar a existência de lotes de produção no estoque cujo SIF não esteja habilitado para o país ou o cliente do pedido. Se houver,

será necessário verificar se deveria existir a habilitação.

4.3 Verificar se os meses de validade do pedido estão corretos.

4.4 Verificar se as datas de embarque estão corretas.

4.5 Verificar se os produtos do pedido estão habilitados e cadastrados nas árvores de todas as fábricas cujos SIFs estejam habilitados para

o país de destino e o cliente do pedido.

4.6 Verificar se os SIFs das fábricas nas quais os produtos possuem árvore de formulação estão habilitados para o país de destino e o

cliente.

P2S6A20

Excluir as árvores de formulação e os roteiros de todas as fábricas

Uma vez atingidas as metas de todos os indicadores, é necessário excluir as árvores de formulação com os roteiros de produção. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S6A21

Excluir os pedidos e demandas reais de todos os formulados

Uma vez atingidas as metas de todos os indicadores, é necessário excluir os pedidos e demandas reais. Este procedimento deve ser

realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S6A22

Excluir os estoques iniciais de suprimentos de todas as fábricas de formulados

268

Uma vez atingidas as metas de todos os indicadores, é necessário excluir os estoques iniciais de suprimentos. Este procedimento deve ser

realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S6A23

Excluir as estruturas de embalagens de todas as fábricas de formulados

Uma vez atingidas as metas de todos os indicadores, é necessário excluir as estruturas de embalagens

. Este procedimento deve ser realizado

por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S6A24

Excluir os lead times e lotes mínimos reais de suprimentos

Uma vez atingidas as metas de todos os indicadores, é necessário excluir os lead times e lotes mínimos reais de suprimentos. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S6A25

Excluir os estoques iniciais de produtos finais formulados

Uma vez atingidas as metas de todos os indicadores, é necessário excluir os estoques iniciais de produtos finais formulados. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S6A26

Excluir as compras de produtos finais

Uma vez atingidas as metas de todos os indicadores, é necessário excluir as compras de produtos finais. Este procedimento deve ser

realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S6A27

Excluir as capacidades reais de estoques de todas as fábricas de formulados

Uma vez atingidas as metas de todos os indicadores, é necessário excluir as capacidades reais de estoques. Este procedimento deve ser

realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S6A28

Excluir os estoques fictícios de MPs

Uma vez atingidas as metas de todos os indicadores, é necessário excluir os estoques fictícios de matérias-primas. Este procedimento deve

ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S6A29

Excluir as compras de suprimentos

Uma vez atingidas as metas de todos os indicadores, é necessário excluir as compras de suprimentos. Este procedimento deve ser realizado

por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

Quando esta atividade for finalizada, deve-se iniciar o Subprocesso 2.7.

269

APÊNDICE D11 – Detalhamento fino das atividades e testes do Subprocesso 2.7

271

P2S7A1

Preparar a carga de dados cadastrais

A carga de dados cadastrais atualizada e corrigida deve ser preparada para ser importada para o sistema de programação da produção.

P2S7A2

Preencher o template das árvores de cortes de uma fábrica sem os roteiros de produção

O template deve ser preenchido utilizando os dados de árvores previamente coletados no Processo de Preparação de Dados,

desconsiderando os recursos produtivos e seus respectivos calendários e tempos de processo.

P2S7A3

Preencher o template das curvas de peso de uma fábrica

O template deve ser preenchido utilizando os dados de curvas de peso de cada árvore previamente coletados no

Processo de Preparação

de Dados.

P2S7A4

Preencher o template com pedidos fictícios para todos os cortes da fábrica escolhida

O template deve ser preenchido com o auxílio de scripts para a geração dos pedidos fictícios, com as seguintes condições:

• Apenas produtos do tipo corte da fábrica escolhida devem ser ter pedidos fictícios.

• A quantidade dos pedidos deve ser de 1 kg.

• Todos os pedidos devem possuir o mesmo cliente e país.

• O SIF da fábrica deve estar habilitado, tanto na realidade quanto no sistema, para o cliente e o país escolhidos.

P2S7A5

Preencher o template das capacidades elevadas de estoques

O template deve ser preenchido com o auxílio de relatórios da base de dados ou meio eletrônico onde as escalas de abates estejam

armazenadas.

P2S7A6

Importar os templates

Os templates preenchidos nas atividades precedentes deverão ser importados para o sistema de seqüenciamento da produção.

P2S7T1

Houve erros nas importações?

Após a importação dos dados, devem-se analisar as mensagens geradas pelos logs

criados no Processo de Preparação de Dados. Se forem

constatados erros no processo de importação, devem-se identificar e corrigir os problemas. Caso a resposta à atividade for “Não”, deve-se

partir para a validação dos dados do banco.

P2S7A7

Identificar e corrigir os erros

1. Ao constatar-se que houve erros de importação para o sistema de seqüenciamento da produção, deve-se primeiramente identificar qual

template ou carga teve problemas.

2. Identificado o template ou carga de dados, deve-se identificar o erro e corrigir a fonte primária.

272

P2S7A8

Validar os dados do banco

As validações são cumulativas, logo a estrutura de dados será também validada pelas validações sugeridas em etapas anteriores.

P2S7A8

Validar os dados do banco

Nº Tipo Descrição da validação Função / Importância

58 Alerta

Raiz de cortes de uma fábrica não

possui curva de peso associada

Dependendo-se do nível de detalhamento adotado para a modelagem das árvores de

cortes, as curvas de peso poderão não ser utilizadas. No entanto, é necessário analisar cada

situação indicada pela validação para verificar se existem erros.

59 Alerta

Raiz de cortes não está habilitada

em nenhuma fábrica

Uma raiz de cortes (ou faixa de peso vivo) não necessariamente deve estar habilitada em

alguma fábrica, porém é necessário analisar cada situação indicada pela validação para

verificar se existem erros.

60 Erro

O somatório dos percentuais da

curva de peso de uma raiz de

cortes é diferente de 100%

As curvas de peso, uma vez cadastradas, indicam qual será a divisão da faixa de peso

"mãe" para as demais faixas que fazem parte dela. Portanto, toda a massa de abates

gerada pela raiz mãe deverá ser completamente alocada para as outras faixas de peso.

61 Erro

Raiz de corte possui escala de

abate cadastrada, porém não

possui conteúdo (detalhamento da

árvore)

Se uma raiz de corte possui escala de abate, é imprescindível que possua uma estrutura por

meio da qual consiga gerar a massa necessária para atender pedidos, demandas e MPs.

Neste caso, é importante também avaliar se a raiz é abatida na realidade, pois a escala de

abate cadastrada é que pode estar errada.

62 Alerta

Produto possui pedido ou

demanda, porém nenhuma árvore

de cortes na qual está cadastrado

possui escala de abate

A escala de abate não é uma condição necessária para que um produto que possua

pedido ou demanda seja programado, porém a ausência da mesma pode indicar erros de

dados.

63 Alerta

Produto possui pedido ou

demanda, porém nenhuma árvore

de cortes na qual está cadastrado

possui escala nem limite de abates

Para que um produto que possua pedido ou demanda seja programado, é desejável que

pelo menos uma raiz de cortes possua escala ou limites de abates, caso contrário o sistema

decidirá pelo volume que achar mais conveniente.

64 Alerta

Fábrica pode cortar e não pode

formular, porém não possui escala

de abate

Uma fábrica que possa cortar e não possa formular produtos, se não estiver em operação

(por exemplo), não necessariamente precisa possuir escala de abate, porém é necessário

analisar cada situação indicada na validação para verificar se existem erros.

65 Erro

A classe do produto é diferente da

classe da raiz de cortes na qual

está cadastrado.

Um produto pode ser de classe "corte" ou "formulado". Em uma árvore de cortes, não

podem coexistir produtos de classes diferentes.

273

66 Erro

A origem do produto é diferente da

origem da raiz de cortes na qual

está cadastrado.

A origem está relacionada à espécie do animal.

Exemplo da validação: produto de origem "Suíno" consta em árvore de cortes de origem

"Frango".

67 Erro

Produtos irmãos em uma árvore de

cortes pertencem a famílias de

produto distintas

Em uma árvore de cortes, não podem coexistir produtos que sejam irmãos e cujas famílias

sejam distintas. Exemplo: se dois produtos irmãos pertençam às famílias "Coxa de frango" e

"Peito de frango", existem erros de dados.

68 Alerta

Produto presente em uma árvore

de cortes possui filhos cuja soma

dos rendimentos é diferente de 100

Os rendimentos de produtos irmãos não necessariamente devem somar 100%. Existem duas

situações possíveis:

1) Se a soma for menor que 100%, dependendo-se da modelagem da estrutura de produto,

a diferença talvez seja um resíduo que não será utilizado no processo produtivo nem

vendido.

2) Se a soma for maior que 100%, é possível que alguns filhos adquiram massa durante o

processo.

P2S7T2

Existem erros de dados?

Uma vez validados os dados, deve-se verificar a existência de erros nos mesmos. Caso a resposta seja “Não”, deve-se prosseguir para a

geração dos índices de controle. No caso de a resposta for “Sim”, será preciso corrigi-los.

P2S7A9

Corrigir os dados

Uma vez confirmada a existência de erros de dados, deve-se proceder para a correção dos mesmos nas fontes primárias.

P2S7A10

Gerar os índices de controle

Os índices de controle deverão possuir metas para que seja avaliada a acuracidade dos dados. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, deverão ser mantidos os ICs 1 ao 4 e o 7.

P2S7A10

Gerar os índices de controle

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Peso médio das raízes da

curva de peso de cada

raiz-mãe

Auxiliar na identificação das raízes

que não fazem parte da curva de

peso.

Média dos pesos das raízes cadastradas

na curva de peso de cada raiz-mãe.

Sugere-se

acompanhar a

evolução do IC por

meio de gráficos de

controle.

274

Variabilidade dos pesos

das raízes da curva de

peso de cada raiz-mãe

Idem ao IC nº 11. Kg

Desvio-padrão dos pesos das raízes

cadastradas na curva de peso de

cada raiz-mãe.

Idem ao IC nº 11.

Peso ponderado das raízes

da curva de peso de

cada raiz-mãe

Identifica percentuais errados na

curva de peso.

Soma das multiplicações dos pesos

unitários, em kg, de cada faixa de peso

em uma curva pelo respectivo

percentual sobre a raiz-mãe

Idem ao IC nº 11.

P2S7T3

As metas foram atingidas?

Os resultados dos índices de controle deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não

atingidas, deverá proceder-se para a identificação dos erros. Se as metas de todos os índices de controle foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S7A11

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os índices de controle que não atingiram as metas.

2. Identificados os índices, deve-se verificar onde está o erro.

3. Encontrado o erro, deve-se corrigi-lo na fonte primária.

P2S7A12

Rodar o sistema

Quando as metas de todos os ICs forem atingidas, o sistema deverá ser rodado para que os resultados da fábrica escolhida sejam

analisados.

P2S7A13

Gerar os indicadores

Os indicadores deverão possuir metas para que sejam avaliados os resultados da rodada do sistema. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, não existem novos indicadores, porém deverá ser mantido o indicador 1.

P2S7T4

As metas foram atingidas?

Os resultados dos indicadores deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não atingidas,

deverá proceder-se para a identificação e correção de erros de dados. Se as metas de todos os indicadores foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S7A14

Identificar e corrigir os erros

275

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os indicadores que não atingiram as metas.

2. Identificados os indicadores, deve-se iniciar um processo de identificação e correção de erros, o qual é detalhado para cada

medição.

P2S7A15

Excluir as árvores de cortes da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir as árvores de cortes da fábrica testada.

Este procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S7A16

Excluir os pedidos fictícios dos produtos da fábrica testada

Uma vez atingidas as metas de todos os indicadores para a fábrica testada, é necessário excluir os pedidos fictícios da fábrica testada. Este

procedimento deve ser realizado por meio de um script de exclusão no banco de dados do sistema de seqüenciamento de produção.

P2S7T5

Todas as fábricas foram testadas?

Após a exclusão dos dados da última fábrica testada, deve-se verificar se todas as fábricas já foram testadas. Caso a resposta seja “Sim”,

devem-se prosseguir para o Subprocesso 2.8. No caso de a resposta for “Não”, uma nova fábrica deverá ser testada.

APÊNDICE D12 – Detalhamento fino das atividades e testes do Subprocesso 2.8

277

P2S8A1

Preparar a carga de dados cadastrais

A carga de dados cadastrais atualizada e corrigida deve ser preparada para ser importada para o sistema de programação da produção.

P2S8A2

Preencher o template das árvores de cortes de uma fábrica com os roteiros de produção

O template deve ser preenchido utilizando os dados de árvores atualizados, desta vez considerando os recursos produtivos e seus

respectivos calendários e tempos de processo.

P2S8A3

Preencher o template das curvas de peso de uma fábrica

O template deve ser preenchido utilizando os dados de curvas de peso atualizados.

P2S8A4

Preencher o template das escalas e limites de abates da fábrica escolhida

O template deve ser preenchido com o auxílio de relatórios da base de dados ou meio eletrônico onde as escalas e limites de abates

estejam armazenados.

P2S8A5

Preencher o template dos pedidos e demandas reais de cortes da fábrica escolhida

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os pedidos e demandas estejam armazenados, com a

condição de que apenas cortes da fábrica escolhida sejam considerados.

P2S8A6

Preencher o template dos estoques iniciais de cortes finais

O template deve ser preenchido com o auxílio de relatórios da base de dados onde os estoques estejam armazenados, com a condição

de que apenas cortes da fábrica escolhida sejam considerados, mesmo que estejam estocados em outras unidades produtivas ou

armazéns.

P2S8A7

Preencher o template das compras de cortes finais

O template deve ser preenchido com o auxílio de relatórios da base de dados onde as compras de produto estejam armazenadas, com a

condição de que apenas cortes da fábrica escolhida sejam considerados.

P2S8A8

Importar os templates

Os templates preenchidos nas atividades precedentes deverão ser importados para o sistema de seqüenciamento da produção.

P2S8T1

Houve erros nas importações?

Após a importação dos dados, devem-se analisar as mensagens geradas pelos logs criados no Processo de Preparação de

Dados. Se forem

constatados erros no processo de importação, devem-se identificar e corrigir os problemas. Caso a resposta à atividade for “Não”, deve-se

278

partir para a validação dos dados do banco.

P2S8A9

Identificar e corrigir os erros

1. Ao constatar-se que houve erros de importação para o sistema de seqüenciamento da produção, deve-se primeiramente identificar qual

template ou carga teve problemas.

2. Identificado o template ou carga de dados, deve-se identificar o erro e corrigir a fonte primária.

P2S8A10

Validar os dados do banco

As validações são cumulativas, logo a estrutura de dados será também validada pelas validações sugeridas em etapas anteriores.

P2S8T2

Existem erros de dados?

Uma vez validados os dados, deve-se verificar a existência de erros nos mesmos. Caso a resposta seja “Não”, deve-se prosseguir para a

geração dos índices de controle. No caso de a resposta for “Sim”, será preciso corrigi-los.

P2S8A11

Corrigir os dados

Uma vez confirmada a existência de erros de dados, deve-se proceder para a correção dos mesmos nas fontes primárias.

P2S8A12

Gerar os índices de controle

Os índices de controle deverão possuir metas para que seja avaliada a acuracidade dos dados. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, deverão ser mantidos os ICs 1 ao 4, 7, 9 e 11 ao 13.

P2S8A12

Gerar os índices de controle

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

Limites mínimos e máximos do desvio-

padrão dos tempos de processo dos

recursos cadastrados em árvores de

cortes (por fábrica, árvore e família de

produto)

Os tempos de processo dos recursos

influenciam diretamente na programação

da produção, pois representam a

capacidade produtiva.

kg/h

Desvio-padrão dos

tempos de processo

de cada recurso, por

fábrica, árvore e

família de produto.

Sugere-se

acompanhar a

cada rodada a

evolução do IC por

meio de gráficos de

controle.

P2S8T3

As metas foram atingidas?

279

Os resultados dos índices de controle deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não

atingidas, deverá proceder-se para a identificação dos erros. Se as metas de todos os índices de controle foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S8A13

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os índices de controle que não atingiram as metas.

2. Identificados os índices, deve-se verificar onde está o erro.

3. Encontrado o erro, deve-se corrigi-lo na fonte primária.

P2S8A14

Medir as disponibilidades dos recursos

O sistema de programação da produção deverá calcular automaticamente as disponibilidades dos recursos

da fábrica por turno. O cálculo

deve ser feito da seguinte maneira, para cada recurso e turno: (hora final - hora inicial) + horas-extras - paradas programadas.

P2S8T4

As disponibilidades estão corretas?

As disponibilidades calculadas na atividade anterior devem ser confrontadas com a realidade para se verificar se os dados estão corretos.

Caso a resposta seja “Sim”, deve-se prosseguir para a rodada do sistema. No caso de a resposta for “Não”, será preciso corrigir os

calendários.

P2S8A15

Corrigir os calendários

Os erros identificados na atividade anterior deverão ser corrigidos na fonte primária.

P2S8A16

Rodar o sistema

Quando as metas de todos os ICs forem atingidas, o sistema deverá ser rodado para que os resultados da fábrica escolhida sejam

analisados.

P2S8A17

Gerar os indicadores

Os indicadores deverão possuir metas para que sejam avaliados os resultados da rodada do sistema. As metas deverão ser derivadas de

históricos da empresa, ou então de objetivos de desempenho baseados em medições similares existentes na realidade.

Neste ponto, deverão ser mantidos os indicadores 2 ao 5.

P2S8A17

Gerar os indicadores

Nº

Descrição Função / Importância

Unidade

métrica

Método de cálculo Acompanhamento

280

Aderência de abates por

tipo de animal (global,

abate empurrado e

puxado)

Avaliar a coerência do volume

programado de abate.

Volume total programado de abates,

em kg, dividido pelo volume projetado

de abates, em kg, por tipo de animal

(frango, peru, suíno, dentre outros).

Sugere-se acompanhar

a evolução do

indicador a cada

rodada por meio de um

gráfico. O indicador

deve ser analisado

conjuntamente com o

de nº 11.

Rendimento de cortes por

tipo de animal (global)

Avaliar a coerência do volume

programado de cortes em relação

ao volume abatido.

Volume total programado de cortes,

em kg, dividido pelo volume

programado de abates, em kg, por

tipo de animal (frango, peru, suíno,

dentre outros).

Sugere-se acompanhar

a evolução do

indicador a cada

rodada por meio de um

gráfico. O indicador

deve ser analisado

conjuntamente com o

de nº 10.

Volume de resíduos

(global)¹

¹ Refere-

se à programação

de produtos finais que não

sejam estocáveis

Possibilita a identificação de erros no

atributo de estocagem de um

produto. O resultado deste indicador

deve ser sempre zero, salvo se o

produto for realmente um resíduo.

Volume total programado de cortes,

em kg, menos o total programado de

produtos estocáveis, em kg.

Sugere-se acompanhar

a evolução do

indicador a cada

rodada por meio de um

gráfico.

Aderência de abate

empurrado (global, por

tipo de animal)

Permite avaliar a programação da

escala de abate global, a qual

influencia na programação no início

do horizonte.

Número de animais programados no

período do abate empurrado dividido

pelo número de animais da escala de

abate, por tipo de animal.

Idem ao indicador 12.

Aderência de abate

empurrado (por fábrica e

tipo de animal)

Idem ao indicador 13

, porém permite

avaliar a programação para cada

fábrica.

Idem ao indicador 13, porém por

fábrica e tipo de animal.

Idem ao indicador 12.

Aderência de abate

puxado (global, por tipo

de animal)

Permite avaliar a programação de

abate sugerida pelo sistema, a qual

influencia na programação do final

do período do abate empurrado até

o último dia do horizonte.

Número de animais programados no

período do abate puxado dividido

pelo número de animais da projetados

para o mesmo período, por tipo de

animal.

Idem ao indicador 12.

Aderência de abate

puxado (por fábrica e tipo

de animal)

Idem ao indicador 15, porém permite

avaliar a programação para cada

fábrica.

Idem ao indicador 15, porém por

fábrica e tipo de animal.

Idem ao indicador 12.

281

P2S8T4

As metas foram atingidas?

Os resultados dos indicadores deverão ser confrontados com as metas estabelecidas para cada um. Caso houver metas não atingidas,

deverá proceder-se para a identificação e correção de erros de dados. Se as metas de todos os indicadores foram atingidas, deve-se

prosseguir para a próxima atividade.

P2S8A18

Identificar e corrigir os erros

Uma vez que as metas não tenham sido alcançadas, os passos abaixo devem ser realizados:

1. Identificar os indicadores que não atingiram as metas.

2. Identificados os indicadores, deve-se iniciar um processo de identificação e correção de erros, o qual é detalhado para cada

medição.

Nesta atividade, além do detalhamento da análise dos novos indicadores (10 ao 16), são feitas adaptações à análise dos indicadores 2 a 5

em função de estarem sendo considerados produtos do tipo corte.

Indicador 2 – Programação de pedidos (global)

1. Gerar uma listagem de todos os pedidos, na qual seja possível visualizar a quantidade solicitada no pedido e o volume programado do

pedido.

2. Classificar a lista pela ordem decrescente das diferenças absolutas entre o volume alocado e o solicitado em pedidos, priorizando a

análise das maiores diferenças.

3. Para cada pedido escolhido, analisar as seguintes situações:

3.1 Verificar se as quantidades solicitadas para os produtos do pedido estão corretas.

3.2 Verificar se os produtos do pedido estão cadastrados em todas as árvores de cortes possíveis a partir das quais podem ser

programados.

3.3 Verificar se todos os produtos (inclusive os intermediários) que compõem as árvores estão habilitados para a fábrica na qual a árvore

está vinculada.

3.4 Analisar o “caminho” das árvores, do início para o final das mesmas, até se chegar aos produtos do pedido, priorizando as seguintes

questões:

a) Alternativos e compulsórios: verificar se as definições destes cadastros realmente estão corretas nas árvores, pois a utilização por

engano de um ou de outro pode desviar a massa abatida para os produtos errados.

b) Rendimentos de produtos compulsórios: aqui se sugere maior atenção dos pontos da árvore que estejam mais próximos do início

da mesma (ou seja, próximos da raiz). Quanto mais erros houver a montante de uma árvore, maiores serão os impactos negativos

a jusante (próximo dos produtos finais ou MPs), influenciando nos resultados do sistema.

Indicador 3 – Programação de demanda líquida (global)

282

1. Gerar uma listagem de todos os produtos que possuam demanda cadastrada, na qual seja possível visualizar a quantidade solicitada e o

volume programado.

Classificar a lista pela ordem decrescente das diferenças absolutas entre o volume alocado para a demanda líquida e a demanda líquida

solicitada, priorizando a análise a partir das maiores diferenças.

3. Para cada produto escolhido, realizar a mesma análise do indicador 2 (a partir do item 3), porém direcionando-se para a demanda

líquida.

Indicador 4 – Aderência da programação (global por fábrica)

Indicador 5 – Aderência da programação (por fábrica e família de produto)

O indicador 4 serve para se ter uma visão geral da programação dos produtos da fábrica. Portanto, independentemente do resultado

deste indicador, deve-se sempre analisá-lo conjuntamente com a aderência por família de produtos (indicador 5). Este, por sua vez,

possibilita analisar a programação total dos produtos, e não somente o volume alocado para pedido e demanda líquida, como feito nos

indicadores 2 e 3. Abaixo são listadas outras análises possíveis por meio dos indicadores 4 e 5:

• Produtos programados mais ou menos que o necessário ou normal. Isso pode ocorrer quando há produtos quem possuem pedidos ou

demanda cujas quantidades estejam erradas. Neste caso, se o sistema tenha conseguido programar os produtos, não teriam sido

geradas diferenças nos indicadores 2 e 3, porém no indicador 5 isso será identificado.

• Produtos não programados por não possuírem pedidos nem demanda cadastrados, mas que deveriam ter.

• Produtos que normalmente são produzidos em uma fábrica, mas que não estão cadastrados em todas as árvores da mesma.

1. Gerar uma listagem na qual seja possível visualizar os volumes projetados de produção e a programação sugerida pelo sistema, por

família de produto.

2. Classificar a lista pela ordem crescente das aderências, priorizando a análise a partir destas, somente para as famílias de produto que não

alcançaram a meta.

3. Para cada família de produto a ser analisada, deve-se gerar a lista dos produtos que fazem parte da família.

4. De posse da lista aberta da família de produtos, analisar as seguintes questões:

4.1 Verificar se todos os produtos realmente fazem parte da família. Caso não fizerem parte, devem ser cadastrados na família correta.

4.2 Verificar se todos os produtos programados podem ser produzidos

na fábrica em análise (mesmo que não tenham sido projetados). Se

houver produtos que não puderem ser programados na fábrica, os mesmos deverão ser excluídos das árvores e da permissão de

produção na fábrica em análise.

4.3 Verificar se existem produtos que estejam previstos na projeção, mas que não estão sendo programados. Se houver produtos nesta

situação, os mesmos devem ser incluídos nas árvores de cortes e na permitidos na fábrica em análise, desde que existam pedidos ou

demandas para os mesmos.

5. Após, deve-se realizar a mesma análise do IC 2 (a partir do item 3), porém do ponto de vista dos produtos cujas aderências não tenham

alcançado a meta da família.

Indicador 2 – Programação de pedidos (global)

283

Indicador 3 – Programação de demanda líquida (global)

Indicador 4 – Aderência da programação (global)

Indicador 5 – Aderência da programação (por família de produto)