tac scm - negociação automatizada para uma cadeia de ... · 3.2 estrutura geral da cadeia de...

TAC SCM - Negociação automatizada para uma Cadeiade Fornecimento

Henrique Pires dos Santos da Fonseca

Dissertação para a obtenção do Grau de Mestre em:

Engenharia de Telecomunicações e Informática

Orientador: Prof. José Alberto Rodrigues Pereira Sardinha

JúriPresidente: Prof. Paulo Jorge Pires Ferreira

Orientador: Prof. José Alberto Rodrigues Pereira SardinhaVogal: Prof. Diogo Manuel Ribeiro Ferreira

Maio 2014

Abstract

Nowadays, supply chains are central entities in our global economy with a tendency to become

bigger and more complex. Regarding the digital era, it is imperative to use Information Systems

in order to support the supply chains business processes. This way the information flow will

become more fluid resulting in an improved efficiency. The simulator TAC-SCM (Trading Agent

Competition - Supply Chain Management) [1] was developed with the goal to explore and test

Intelligent Agents with autonomous negotiation capabilities in a supply chain where computers

are produced from computer components and then sold, in order to generate profit margin for

the producer. This work documents an agent for an extension to TAC-SCM, the TAC-SCM-

Procurement Challenge [2], which focuses it’s activities on component procurement.

Keywords: TAC SCM, Supply Chain Management, Business Automation, Procurement

Market

i

Resumo

As cadeias de fornecimento são um ponto fulcral no panorama económico global tendo vindo a

aumentar exponencialmente a sua dimensão e complexidade. É imperativo recorrer ao uso de

Sistemas de Informação para suportar as atividades constituintes das cadeias de fornecimento

promovendo um melhor fluxo de informação resultando assim numa maior eficiência. O simula-

dor Trading Agent Competion - Supply Chain Management (TAC-SCM) [1] foi desenvolvido com

o intuito de explorar o desenvolvimento de Agentes Inteligentes com a capacidade de negociar

de forma autónoma numa cadeia de fornecimento onde são produzidos e transaccionados com-

putadores. Este trabalho tem como foco o desenvolvimento dum agente para este ambiente

com foco na aquisição de componentes, sendo baseado na extensão TAC-SCM-Procurement

Challenge [2]

Keywords: TAC SCM, Supply Chain Management, Business Automation, Procurement Market

iii

Conteúdo

Abstract i

Resumo iii

1 Introdução 1

2 Definição do Problema 3

2.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Background 5

3.1 Simulador TAC-SCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.2 Fornecedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.3 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Extensão TAC-SCM-PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1 Negociação, produção e entrega entre os agentes produtores e os clientes 14

3.2.2 Negociação de Long-term Contracts . . . . . . . . . . . . . . . . . . . . . . 15

3.2.3 Gameplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.4 Agente Padrão - Dummy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Trabalho Relacionado 19

4.1 CMieux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

v

4.1.2 Módulo de Previsões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.3 Módulo de Estratégia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1.4 Módulo de Escalonamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.5 Módulo de Venda de Computadores . . . . . . . . . . . . . . . . . . . . . . 23

4.1.6 Módulo de Compra de Componentes . . . . . . . . . . . . . . . . . . . . . 24

4.2 TacTex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.2 Módulo de Gestão de Vendas . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.3 Módulo de Gestão de Compras . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 CMieux - Procurement Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.1 Negociação de Long-term contracts . . . . . . . . . . . . . . . . . . . . . . 30

4.4 CrocodileAgent - Procurement Challenge . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.1 Negociação de Long-term contracts . . . . . . . . . . . . . . . . . . . . . . 31

4.4.2 Negociação de Short-term contracts . . . . . . . . . . . . . . . . . . . . . . 31

5 Implementação do Agente - Bull 33

5.1 Módulo de estratégia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2 Módulo de previsão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3 Módulo de negociação de Long-term Contracts . . . . . . . . . . . . . . . . . . . . 35

5.4 Módulo de negociação de Short-term Contracts . . . . . . . . . . . . . . . . . . . . 37

5.4.1 Decisão de Compra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6 Análise dos resultados 41

6.1 Análise do agente ao longo da implementação . . . . . . . . . . . . . . . . . . . . 42

6.1.1 Versão 1 - Implementação da estratégia de Long-term Contracts . . . . . . 42

6.1.2 Versão 2 - Implementação dos mecanismos Threshold e cutoff de inventário 44

6.1.3 Versão Final - Implementação dos mecanismos de previsão . . . . . . . . 45

6.2 Análise da performance do agente . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.2.1 Versus Warrior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

vi

6.2.2 Versus CrocodileAgent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2.3 Versus CMieux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7 Conclusão 55

7.1 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Bibliografia 57

vii

Lista de Tabelas

3.1 Parâmetros do simulador TAC-SCM-PC . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Parâmetros de negociação de Long-term Contracts . . . . . . . . . . . . . . . . . 15

6.3 Erro dos mecanismos de previsão . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

ix

Lista de Figuras

1.1 Exemplo duma Cadeia de Fornecimento. . . . . . . . . . . . . . . . . . . . . . . . 1

3.2 Estrutura geral da cadeia de fornecimento. . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Estrutura geral da cadeia de fornecimento. . . . . . . . . . . . . . . . . . . . . . . 14

3.4 Negociação de um Long-term Contract. . . . . . . . . . . . . . . . . . . . . . . . . 16

3.5 Fornecedores e componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.6 Modelo Geral do Agente CMieux a) Business to Consumer b) Business to Business 20

4.7 Arquitetura geral do Agente TacTex. . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.8 Constituição modular do agente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.9 Constituição modular do agente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.10 Análise de sensibilidade do valor de Qmax. . . . . . . . . . . . . . . . . . . . . . . 36

5.11 Diagrama de negociação de Short-term contracts . . . . . . . . . . . . . . . . . . 38

6.12 Lucro no final do jogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.13 Percentagem de uso da capacidade de fábrica. . . . . . . . . . . . . . . . . . . . . 42

6.14 Percentagem de encomendas entregues. . . . . . . . . . . . . . . . . . . . . . . . 43

6.15 Stock em inventário no final do jogo. . . . . . . . . . . . . . . . . . . . . . . . . . . 43







xi



6.24 Lucro no warrior do jogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48



6.27 Stock em inventário no warrior do jogo. . . . . . . . . . . . . . . . . . . . . . . . . 49

6.28 Lucro no crocodile do jogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50



6.31 Stock em inventário no crocodile do jogo. . . . . . . . . . . . . . . . . . . . . . . . 51

6.32 Lucro no cmieux do jogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52



6.35 Stock em inventário no cmieux do jogo. . . . . . . . . . . . . . . . . . . . . . . . . 53

xii

Lista de Acrónimos

TAC-SCM Trading Agent Competition - Supply Chain Management

PC Procurement Challenge

RFQ Request For Quotes

API Application programming interface

KPI Key performance indicator

xiii

1Introdução

No panorama económico actual é necessário efetuar uma gestão eficaz da cadeia de forneci-

mento permitindo uma correcta reacção às flutuações de mercado. Tendo em conta o potencial

de evolução pelo meio de certas optimizações (sendo abordadas neste trabalho) e também o

facto da grande maioria das cadeias de fornecimento serem estáticas (apostando na relação a

longo prazo com fornecedores e clientes), torna-se necessário introduzir dinamismo nas mes-

mas promovendo assim uma melhor reacção à mudança [1].

Figura 1.1: Exemplo duma Cadeia de Fornecimento.

Uma cadeia de fornecimento é constituída por uma rede de organizações interligadas por pro-

cessos de negócio com o objetivo de adquirir matéria prima, transformá-la em produtos intermé-

dios e finais, e distribuindo-os para os consumidores finais [3]. Na figura 1.1 podemos observar

1

2 CAPÍTULO 1. INTRODUÇÃO

uma cadeia de fornecimento com vários níveis de fornecedores e com vários intermediários até

ao consumidor final existindo sistemas no mundo real com números muito superiores ao ilus-

trado. Gerir uma cadeia de fornecimento é por norma um processo logístico complexo em que é

mandatária a coordenação entre os vários intervenientes. Mesmo com uma coordenação rígida

podem surgir ineficiências na cadeia de fornecimento tais como a falta de matéria prima, subutili-

zação da capacidade de fábrica, acumulação de stock, custos elevados de distribuição, atrasos.

Estes problemas surgem devido ao fraco e defeituoso fluxo de informação entre as várias entida-

des [3]. Um exemplo bem conhecido derivado do fluxo defeituoso de informação é o fenómeno

de bullwhip effect popularizado pelo MIT Beer Game [4] que aquando do aumento da procura

os vários fornecedores e produtores ao receberem essa informação podem adoptar uma estra-

tégia de safety stock, em que adquirem uma quantidade considerável de matéria prima podendo

levar à acumulação de stock ao longo da cadeia de fornecimento. Suportar as atividades da

cadeia de fornecimento com sistemas de informação é não só um passo importante em direção

ao melhor fluxo e processamento de informação como também na previsão do comportamento

das várias entidades. Este trabalho consiste no desenvolvimento dum agente inteligente [5]

que por definição é uma entidade computacional autónoma. Este agente vai ser implementado

numa cadeia de fornecimento simplificada pelo simulador TAC SCM [1] em que apenas existem

fornecedores de 1º nível, produtores e clientes. No caso específico do TAC SCM os fornecedo-

res produzem componentes de computadores, os produtores transformam esses componentes

em computadores que por sua vez são vendidos aos clientes. O agente insere-se no produtor

tendo de gerir a aquisição de componentes, a sua fábrica e a venda de computadores. Este

documento encontra-se organizado da seguinte maneira: na secção 2 será definido o problema

a resolver por este trabalho, na secção 3 é exposto o simulador TAC SCM [1] como também a

extensão TAC-SCM Procuremente Challenge [2], na secção 4 é feito o levantamento do trabalho

relacionado, na secção 5 é documentada a implementação do agente a ser desenvolvido neste

trabalh e finalmente na secção 6 serão validados os resultados obtidos.

2Definição do Problema

Nesta secção será exposto o problema que este trabalho pretende resolver. O ambiente em que

este trabalho se insere é o de uma cadeia de fornecimento dinâmica em que os vários produ-

tores são automatizados por agentes inteligentes. O simulador usado [1] simula uma cadeia de

fornecimento simplificada onde é minimizado o número de entidades ao essencial, fornecedores,

produtores e clientes eliminando qualquer intermediário como pontos de venda e distribuidores.

Também não é considerada a interação humana entre os vários responsáveis de cada enti-

dade sendo os contratos de Business to Business de fornecedores e produtores e Business

to Customer de produtores e clientes, um dado adquirido no sistema simulado. Esta simplifi-

cação permite focar os problemas de compra de componentes, agendamento de produção e

venda de computadores com o objetivo de obter a maior margem de lucro possível. Os preços

praticados ao longo da cadeia de fornecimento são consequência do número de pedidos dos

clientes sendo que a abundância dum dado recurso determina o seu valor [Miguel Gonçalves,

TEDxYouth, Braga 2011]. No mercado de compra de componentes o agente deverá conseguir

reagir às rápidas flutuações dos preços de modo a conseguir os melhores negócios possíveis

e atempadamente. No mercado de venda de computadores o número de pedido dos clientes

também varia ao longo do tempo sendo necessária uma gestão eficiente por parte do agente

sobre que pedidos aceitar. Adicionalmente é o agente que propõe o preço para os pedidos

dos clientes sendo indeterminado se os mesmos aceitam ou não. A agendamento de produção

também é da responsabilidade do agente sendo necessário lidar com as limitações de capaci-

dade e de falta de componentes. O ambiente simulado conta com a presença de outros agentes

3

4 CAPÍTULO 2. DEFINIÇÃO DO PROBLEMA

que competem entre si, tendo acesso exactamente aos mesmos clientes e fornecedores. Todos

os competidores possuem o mesmo objectivo de obter a maior margem de lucro do universo

simulado.

2.1 Objetivos

O objectivo deste trabalho é desenvolver um agente eficiente num ambiente simulado, sendo ne-

cessário realizar o levantamento das técnicas usadas neste tipo de ambientes. O simulador a ter

em consideração é o TAC-SCM (Trading Agent Competition – Supply Chain Management), que

é usado desde 2002 em competições de agentes inteligentes de modo a promover uma Testbed

para o estudo do uso de técnicas de inteligência artificial. O TAC-SCM simula uma cadeia de

fornecimento com apenas 1 nível de fornecedores e 1 nível de clientes. O agente inteligente a

ser desenvolvido opera entre estas duas entidades, no produtor. Neste ambiente os fornece-

dores vendem componentes de computador, os produtores transformam-nos em computadores

que por fim são vendidos aos clientes finais. Neste trabalho o foco vai incidir sobre a aquisição

de componentes o que permite balizar o problema sendo possível obter conclusões mais claras

acerca da eficácia das técnicas usadas. Para esse efeito, e no âmbito deste trabalho, o simu-

lador a ser usado é o TAC-SCM-PC (Procurement Challenge), um spin-off do jogo base. Nesta

versão o universo do jogo é constituído por 3 produtores concorrentes, 3 clientes e 10 fornece-

dores, sendo a simulação executada ao longo de 100 dias (10 segungos por dia). É necessário

ter em conta que este ambiente apenas simula algumas variáveis do mundo real sendo este

demasiado complexo de modo a extrapolar um modelo matemático fidedigno. Existe também a

limitação temporal de 10 segundos por dia em que o agente deve balizar todos os seus cálculos

e acções. O estudo do trabalho relacionado vai incidir sobre as técnicas, nomeadamente de

forecast, usadas por agentes bem sucedidos em competições passadas de modo a desenvol-

ver competências para o desenvolvimento dum agente próprio. Ao longo da realização deste

trabalho o agente vai ser fortemente testado usando os registos gerados pelas simulações.

3Background

Nesta secção será apresentado o simulador TAC-SCM [1] e a sua extensão TAC-SCM-PC [6]

[2] que serve como base deste trabalho, representando o ambiente em que será desenvolvido o

agente.

3.1 Simulador TAC-SCM

Com o intuito de simular um ambiente duma cadeia de fornecimento dinâmica e simplificada, foi

desenvolvido o simulador TAC SCM, em que o panorama geral está representado na fig. 3.2.

O Jogo consiste numa competição de 6 agentes a nível do produtor, tendo de competir entre si

pela aquisição de componentes de computadores aos fornecedores, e também por ordens de

encomenda de computadores por parte dos clientes. Diariamente os clientes lançam pedidos

de orçamento a todos os produtores que daqui em diante serão denominados por Request for

Quotes (RFQ), dando assim início a um leilão. Os produtores respondem com uma oferta que

posteriormente é analisada pelo cliente, seleccionando o conjunto de ofertas que resultam num

maior proveito. Os produtores estão limitados pela capacidade das suas linhas de montagem,

e têm de adquirir componentes dum conjunto de oito fornecedores. O agente está inserido

no produtor, sendo as outras entidades (clientes, fornecedores, banca, produção e serviços de

armazém) simuladas pelo servidor de jogo. No fim do tempo de jogo é declarado vencedor

5

6 CAPÍTULO 3. BACKGROUND

o agente que acumulou a maior quantia na banca. Apesar da simplicidade do simulador, são

simuladas várias situações reais de cadeias de fornecimento, sendo também necessário ter em

conta que o produtor tem de lidar com vários segmentos de mercado podendo a partir daí definir

a sua estratégia.

Figura 3.2: Estrutura geral da cadeia de fornecimento.

3.1.1 Agentes

Sendo os agentes o núcleo do produtor as suas responsabilidades diárias são:

• Negociar contratos de fornecimento

• Responder aos RFQs dos clientes

• Gerir a linha de montagem

• Arquivar a encomenda enviando o produto final aos respetivos clientes

Analisando a transferência de informação (fig. 3.2), o agente recebe diariamente vários artefac-

tos das diversas entidades presentes no jogo:

Dos Clientes

• RFQs.

• Status Quo dos leilões em que está envolvido.

3.1. SIMULADOR TAC-SCM 7

• Penalizações e cancelamento de encomendas devido a atrasos

Dos Fornecedores

• Envio de ofertas aos agentes em resposta aos RFQs enviados pelos mesmos.

• Entrega de componentes. Esses componentes apenas podem ser usados em produção

no dia seguinte

Da Banca

• Extracto bancário

Da fábrica

• Inventário (componentes e computadores)

Atentando às responsabilidades dos agentes e usando os artefactos recebidos, os mesmos

terão de realizar durante o dia um determinado número de acções:

1. Escolher os RFQs dos clientes aos quais se envia uma oferta licitando assim no leilão

aberto.

2. Escolher os componentes a comprar, enviando RFQs aos fornecedores.

3. Que ofertas dos fornecedores escolher, enviando para isso uma ordem de encomenda.

4. Decisão do escalonamento da fábrica de modo a gerir a capacidade de produção e o

inventário enviando um cronograma à fábrica.

5. Que computadores enviar para entrega de modo a satisfazer os pedidos pendentes dos

clientes enviando uma ordem de despacho à fábrica.

Todos os agentes possuem condições idênticas de linha de montagem e de armazém, sendo

preciso para cada modelo de computador um número de ciclos de montagem específico. A

capacidade diária de cada linha de montagem é fixa. É enviado diariamente o alinhamento de

produção à fábrica, a qual trata esse alinhamento de forma sequencial, porém apenas serão pro-

cessadas as entradas para as quais existam componentes suficientes. Os computadores recém-

montados são enviados para o armazém estando prontos para entrega no dia seguinte. As en-

tregas são controladas por uma ordem de entrega que é distribuída diariamente pelo agente à


fábrica. São realizadas através do inventário e processadas sequencialmente. Todos os produ-

tos do inventário vão ter associada uma taxa de armazenamento sendo esta taxa calculada no

início do jogo e é igual para todos os agentes. No início do jogo cada agente tem o saldo a zeros,

sendo transferidos fundos para a conta no momento da entrega de computadores. Aquando da

recepção de componentes por parte dos fornecedores é debitada a respectiva quantia, também

quando ocorrem penalizações devido a atrasos nas entregas. É permitido ao agente ter a conta

com um saldo negativo, sendo aplicada nessa situação uma taxa de juros segundo a seguinte

fórmula:

bd+1 = (1 +α

E)bd + creditsd − debitsd (3.1)

Sendo bd o balanço no dia d, α a taxa anual de empréstimo e E a duração do jogo. Quando

o saldo é positivo, o agente recebe juros segundo a fórmula 3.1, porém com um valor de α

ajustado.

3.1.2 Fornecedores

Numa instância de jogo existem 8 fornecedores diferentes, havendo 2 fornecedores para cada

tipo de componente necessário à produção de computadores. As acções diárias dos fornecedo-

res podem-se resumir a 3 pontos:

1. Gerir a produção de componentes.

2. Responder aos RFQs dos agentes com ofertas tendo em conta a capacidade futura.

3. Despacho de componentes.

Tendo uma natureza automática, os fornecedores regem-se segundo as seguintes suposições:

• Tirar o maior proveito nas encomendas.

• Reservar uma porção da capacidade a futuros negócios. Dar preferência a agentes que

possuam um histórico de ofertas aceites.

• Apenas serão produzidos componentes caso hajam encomendas, nunca serão produzidos

componentes com o objetivo de manter stock.

• Mesmo que uma encomenda demore vários dias a satisfazer, serão ignorados os custos

de armazém.


• Apenas são enviadas as encomendas com a quantidade acordada, exceptuando no último

dia de jogo em que podem ser escoadas fracções de encomendas.

• Caso a capacidade de produção não esteja lotada, essa capacidade será usada para en-

comendas pendentes. Contudo as encomendas apenas serão enviadas na data acordada

previamente. Componentes que fazem parte de encomendas futuras podem ser desvi-

ados para encomendas a mais curto prazo, mas apenas se a capacidade disponível for

suficiente para cumprir com as condições dessas encomendas.

• A cada dia é calculada a capacidade efectiva de forma aleatória segundo uma distribuição

uniforme.

• Os negócios são feitos com base na capacidade futura esperada.

• Caso a capacidade não seja suficiente para cumprir uma encomenda, essa encomenda

terá prioridade acrescida em relação a uma encomenda a mais longo prazo.

• Existe um sistema de fidelização. Os agentes que possuam um histórico de aceitar uma

percentagem maior de ofertas terão preferência na atribuição de ofertas por parte do for-

necedor.

Cada agente pode enviar diariamente 5 RFQs para cada tipo de componente (total de 10 RFQs

por fornecedor). Um RFQ contém toda a informação relevante ao pedido de um dado com-

ponente por parte do agente: quantidade requerida (Qrfq), data de entrega, preço de reserva

(preço máximo por unidade, Preserva). Após processamento é gerada uma oferta correspondente

a cada RFQ com uma quantidade (Qoferta) menor ou igual que a quantidade pedida (Qrfq) de

modo a satisfazer o preço de reserva (Preserva). Caso seja impossível cumprir o preço de re-

serva (Preserva), a oferta é enviada na mesma mas com quantidade (Qoferta) nula, de forma

a notificar o produtor. O processamento dos RFQs recebidos durante o dia são processados

no fim do mesmo, e as ofertas geradas enviadas no dia seguinte. Pode dar-se o problema de

não ser possível satisfazer um pedido por completo na data pedida, sendo nessa situação ve-

rificado o preço de reserva (Preserva) correspondente. Se o preço de reserva (Preserva) for 0

(sem limitação) ou acima dum limiar (valor que oscila no intervalo [0.9...1.2] do preço base dum

componente Pbase,c) o fornecedor responde com até duas ofertas, uma que alivia a quantidade

pedida (Qrfq) e/ou outra que atrasa a data de entrega. Caso sejam emitidas ambas as ofertas o

agente apenas poderá optar por uma delas. Todas as ofertas têm um limite de validade de um

dia.


Capacidade das linhas de produção. Para cada tipo de componente existe uma linha dedi-

cada tendo cada uma associado um valor Cnom que indica a capacidade nominal. A capacidade

efectiva para o dia d, ou seja o que o fornecedor vai produzir no dia d é calculada segundo a

equação 3.2.

Cacd,i = max(1, Cacd−1 + random(−0.05,+0.05)Cnom + 0.01(Cnom − Cacd−1)) (3.2)

No primeiro dia a capacidade efectiva do dia anterior Cacd−1 adopta um valor de ±35%

Podem ocorrer situações em que a capacidade é maior que a necessária, como o fornecedor

só produz para pedidos directos dos agentes, essa capacidade extra não será utilizada. Em

oposição a capacidade pode ser insuficiente para produzir todas as encomendas com data de

entrega no dia seguinte, sendo assim ocorrerão atrasos porém essas encomendas terão priori-

dade sobre as outras.

Planeamento da capacidade disponível. As ofertas em resposta aos RFQs dos produtores

são geradas com base na capacidade disponível e também no inventário transmissível a enco-

mendas com ordem de despacho mais próxima. Porém o fornecedor apenas está disposto a

alocar toda a sua capacidade até um certo dia no futuro, sendo que a partir do dia d+20 (sendo

d o dia corrente), o fornecedor aloca apenas uma porção da sua capacidade.

Reputação dos Agentes. À semelhança duma cadeia de fornecimento assente sobre o mundo

real onde a reputação dos vários actores é um factor determinante, no TAC SCM é implementado

um sistema de reputação que se baseia no rácio de ofertas (dos fornecedores) aceites pelo pro-

dutor pelo total de ofertas que o produtor recebeu. Posto isto, cada fornecedor detém um registo

da interacção entre ele próprio e os agentes, calculando o rácio com base na equação 3.3.

ζa =quantitityPurchasedaquantitityOffereda

(3.3)

Por defeito este rácio tem o valor unitário no início do jogo. O agente possui bastante controlo

sobre este valor tendo em conta que define um preço de reserva nos RFQs, pois os fornecedo-

res apenas respondem com uma oferta caso o preço não ultrapasse esse valor. Caso o preço

de reserva não possa ser cumprido, o fornecedor poderá processar uma oferta com uma quan-

tidade de componentes reduzida Q′r que possa respeitar o preço de reserva. Outra situação

extraordinária é quando o preço de reserva pode ser cumprido, mas por limitações de capa-

cidade a quantidade pedida não seja alcançada até à data pedida pelo agente sendo que irá

receber duas ofertas do fornecedor, uma oferta parcial e uma oferta com a quantidade pedida

mas sem limitações na data de entrega, apenas podendo escolher uma delas. Nestes casos,


o processamento da reputação será um pouco diferente, a variável quantityOffereda será a

maior de um dos seguintes pontos:

1. Quantidade da oferta escolhida.

2. 20% da quantidade reduzida Q′r.

Com o intuito de controlar a tentativa de um agente inundar os fornecedores com RFQs, a

reputação é calculada da seguinte segundo a equação 3.4.

repa =min(apr, ζa)

apr(3.4)

apr tomará valores diferentes para fornecedores que detenham o monopólio do tipo de compo-

nentes e para fornecedores que estejam inseridos no mesmo mercado. Tendo em conta ζ, é

concluído que existe uma forte prevenção de um agente tentar controlar o mercado, evitando

que o mesmo peça grandes quantidades com o intuito de subir o preço dos componentes ou

mesmo bloquear o mercado.

Preço dos componentes. O preço dos componentes flutua ao longo do tempo de jogo, sendo

calculado a partir do rácio da procura pela oferta. Aquando do processamento do preço de com-

ponentes destinado a um determinado agente com repa = y , a procura corresponde ao total

de componentes nas ofertas do dia d enviadas aos agentes com repa ≥ y mais a quantidade

de componentes nas encomendas pendentes. O preço dum componente a ser enviado no dia

d+ i+ 1 é dado por:

Pd,i = P basec

(1− δ

(Cavld,i

iCacd

))(3.5)

Sendo δ um fator de desconto, P basec o preço base do componente em questão, a capacidade

efectiva da linha de montagem P acd (3.2),e a capacidade disponível Cavld,i .

Processamento das Ofertas. De modo a maximizar o lucro, os fornecedores têm em conside-

ração o conjunto de RFQs recebidos para cada tipo de componente. Para isso e como primeira

aproximação é necessário encontrar o majorante da seguinte função:

∑rεRc

q′rPd,ir (3.6)

Sendo Rc o conjunto de RFQs recebidos para o tipo de componente c, q′

r ≤ q a quantidade


oferecida pelo RFQ r e ir o tempo de produção. São necessárias 3 operações de modo a gerar

o conjunto de ofertas a serem enviadas:

1. Seleccionar todos os RFQs vencedores, ou seja, que possam ser enderençados tendo em

conta o preço de reserva. Inerente ao anterior é o calculo do preço tendo em conta a

reputação de cada agente.

2. Caso existam limitações de capacidade, são geradas ofertas parciais dando preferência

aos agentes com reputação mais alta.

3. Para cada oferta parcial é gerada, se possível, uma oferta complementar com a quantidade

total pedida, mas numa data de entrega posterior.

Pagamento. Os agentes confirmam as ofertas respondendo com uma ordem de encomenda.

Alguns fornecedores podem pedir uma porção do pagamento como forma de sinal, tipicamente

10%, o restante é saldado na entrega.

3.1.3 Clientes

Os clientes encomendam computadores aos agentes seguindo um conjunto de regras. Os pe-

didos são feitos sobre a forma de RFQs tendo como campos o tipo de produto, a quantidade,

a data de entrega, o preço de reserva e o valor de penalização caso ocorram atrasos. Tanto a

preço de reserva, a data de entrega, e o valor de penalização são escolhidos pelo cliente se-

gundo uma distribuição uniforme porém a quantidade é escolhida segundo uma distribuição de

Poisson. Existem três gamas de mercado: gama alta, média e baixa. Para cada uma dessas

gamas os clientes vão calcular o número de RFQs que vão enviar aos produtores para cada

uma dessas gamas:

N = poisson(Qd) (3.7)

Qd representa a média de RFQs por segmento de mercado, sendo alterada em cada dia de jogo

segundo uma tendência τ :

Qd+1 = min(Qmax,max(Qmin, τdQd)) (3.8)

τd+1 = max(τ,min(τmax, τd + random(−0.01, 0.01)) (3.9)

3.2. EXTENSÃO TAC-SCM-PC 13

Processamento de Ofertas. Os RFQs são enviados a todos os produtores que podem ou não

responder aos mesmos sobre a forma de uma oferta. Essa oferta só será considerada pelo

cliente caso a quantidade, a data de entrega e o preço de reserva presentes no RFQ sejam

cumpridos. O critério do cliente é bastante simples, escolhe a oferta com o preço mais baixo.

Apenas o produtor vencedor receberá uma notificação no dia seguinte de modo a demonstrar o

interesse do cliente, sobre a forma de uma ordem de encomenda. No entanto todos os agentes

serão informados diariamente dos preços mínimos e máximos de cada computador praticados

no dia anterior.

Cumprimento das encomendas. Os produtos enviados no dia d apenas chegaram ao cliente

no dia d+1, dia esse em que é realizado o pagamento da encomenda, que será directamente

depositado na conta do produtor. As penalizações são processadas diariamente até um limite

de 5 dias. No término desse limite a encomenda é cancelada. No ultimo dia de jogo todas as

encomendas não penalizadas são penalizadas até ao 5º dia.

3.2 Extensão TAC-SCM-PC

O simulador que vai ser usado na implementação do agente é uma extensão do simulador TAC-

SCM [1]. Nesta extensão, TAC-SCM-PC [6] [2], é criada uma abstracção de toda a negociação

entre o agente produtor e os clientes, sendo o foco a negociação entre o agente produtor e os

fornecedores de componentes (fig. 3.3). São simulados 100 dias de operação em que 3 agentes

produtores competem entre si pelo maior lucro.

Nesta versão o simulador assume algumas das responsabilidades do agente produtor:

• Negociação entre o agente produtor e os clientes (mercado de venda de computadores).

• Agendamento de produção de computadores.

• Entrega de computadores aos clientes.

Diaramente todos os agentes recebem exactamente o mesmo conjunto de encomendas por

parte dos clientes. O simulador ordena as encomendas por ordem decrescente de preço, ten-

tando produzir PCs nessa ordem. Para cada encomenda na lista, caso o agente possua os


Figura 3.3: Estrutura geral da cadeia de fornecimento.

componentes necessários para satisfazer a encomenda, a mesma é produzida e enviada ao

cliente.

São retirados da simulação os seguintes elementos:

• Sistema de reputação de agentes perante os fornecedores.

• Encomendas entregues após a data de entrega acordada.

• Penalizações de encomendas não entregues.

3.2.1 Negociação, produção e entrega entre os agentes produtores e os

clientes

O simulador está encarregue de toda a negociação necessária entre os agentes produtores e

os clientes, como também da produção de computadores e entrega dos mesmos. Diariamente

cada cliente calcula o número de encomendas a fazer aos agentes, de forma semelhante ao jogo

base (Eq. 3.7). Calculado o número total de encomendas N , cada agente receberá o mesmo

número de encomendas N/n, sendo n o número total de Produtores.

Cada encomenda é constituída por um tipo de PC escolhido aleatoriamente, preço por unidade

pc, prazo de entrega lt e a quantidade de PCs qc. O preço é escolhido uniformemente segundo


Número médio de encomendas nossegmentos Alto e Baixo

[Qmin, Qmax] [12, 50]

Número médio de encomendas nosegmento Médio

[Qmin, Qmax] [12, 60]

Preço mínimo de um PC Pmin 75% do preço nominal dos com-ponentes

Preço máximo de um PC Pmax 125% do preço nominal doscomponentes

Prazo de entrega de computadores [ltmin, ltmax] [3, 12] dias a partir do dia da en-comenda

Quantidade de PCs por encomenda [qmin, qmax] [1, 20]

Tabela 3.1: Parâmetros do simulador TAC-SCM-PC

o intervalo [avgpricec − Pmin, avgpricec + Pmax] (o valor é truncando caso saia fora do intervalo

[Pmin, Pmax]) sendo avgpricec caracterizado pela equação 3.10.

avgpricec =N −Qmin

Qmax −Qmin.(Pmax − Pmin) + Pmin (3.10)

Desta forma é garantido que quanto maior a procura mais alto será o preço do componente.

Tanto o prazo de entrega lt e a quantidade de PCs por encomenda qc são calculados uniforme-

mente com base nos intervalos [ltmin, ltmax] e [qmin, qmax] respectivamente.

3.2.2 Negociação de Long-term Contracts

O jogo base TAC-SCM apenas possui um tipo de contratos, os Short-term Contracts, que são

elegíveis para uma única transacção. Na extensão TAC-SCM-PC são inseridos os Long-term-

Contracts. Estes contratos são negociados antes do início do jogo sendo válidos até ao ultimo

dia de jogo, sendo acordada a transacção duma quantidade dentro dum intervalo flexível numa

base semanal.

Factor de flexibilidade [αmin, αmax] [0.05, 0.30]Capacidade Nominal dos fornecedo-res (CPUs)

Cnom 137 componentes / dia

Capacidade Nominal dos fornecedo-res (motherboards, memorias e discosrígidos)

Cnom 275 componentes / dia

Tabela 3.2: Parâmetros de negociação de Long-term Contracts

Um Long-term-Contract entre um agente produtor e um fornecedor é definido por:

• Uma quantidade semanal mínima Qltsmin.


• Uma quantidade semanal máxima Qltsmax = (1 + α) ∗ Qltsmin. O parâmetro α é escolhido

uniformemente num intervalo definido (tabela 3.2) antes do início do jogo.

• Um preço de reserva de contrato pres definido pelo fornecedor, de tal modo que semanal-

mente independentemente da quantidade transaccionada entre o produtor e o fornecedor,

o produtor terá de pagar Qltsmax ∗ pres.

• Um preço de execução pexec cujo o agente de produção terá de pagar por cada compo-

nente transaccionado e será no mínimo equivalente ao preço de reserva por unidade pmin.

Qltsmax ∗ pres + q ∗ pexec (3.11)

Em suma, semanalmente o agente produtor adquire q (Qltsmin ≤ q ≤ Qltsmax) componentes de um

dado produtor e terá de pagar a esse fornecedor o valor obtido através da equação 3.11.

Figura 3.4: Negociação de um Long-term Contract.

Para cada componente existente (figura 3.5) estão associados dois fornecedores. Um apenas

provem Long-term Contracts e em contraste o outro apenas provem Short-term Contracts. Desta

forma é assegurada a diversidade a nível da categoria de contratos. A negociação dos Long-

term Contracts (figura 3.4) inicia antes do jogo começar, sendo definidos a partida por cada

fornecedor (Long-term) os valores de α e um preço de reserva pmin por unidade. O preço de

reserva por unidade é o preço mínimo pelo qual o fornecedor está disposto a vender a unidade

(difere do preço de reserva de contrato). Estes parâmetros são enviados ao agente produtor.

Neste momento o agente produtor poderá proceder a uma licitação (uma por cada fornecedor de

Long-term Contracts) que assume o seguinte formato: < Qltsmax, pexec > (caso Qltsmax < 0 ou pexec

inferior ao preço de reserva por unidade, a licitação é ignorada). Tendo todos os agentes produ-

tores efectuado as suas licitações e ainda antes de o jogo começar, cada fornecedor analisa o


conjunto de licitações de que foi alvo. O fornecedor aloca 100% da sua capacidade nominal se-

manal (5 dias) Cnom para o total de encomendas dos agentes produtores. Para isso vai ordenar

as licitações por ordem decrescente de pexec alocando para cada agente produtor a quantidade

máxima semanalQltsmax solicitada pelo produtor. No caso de não ser possível alocar a quantidade

requisitada, o valor final de Qltsmax será o restante da capacidade nominal do fornecedor. Este

leilão segue o modelo de Vickrey [William Vickrey, Columbia University, 1961], em que o preço

de execução final pexec será correspondente à licitação seguinte mais alta. Após este cálculo o

fornecedor retorna ao agente os valores a serem usados ao longo do jogo, celebrando assim o

contrato.

Figura 3.5: Fornecedores e componentes

3.2.3 Gameplay

No início de cada semana serão executadas as transacções relativamente aos Long-term Con-

tracts negociados no início do jogo. O agente produtor escolhe uma quantidade q tal que

Qltsmin ≤ q ≤ Qltsmax. Caso a quantidade total pedida pelo conjunto de produtores a um dado

fornecedor seja inferior à sua produção, todos os produtores são aprovisionados na totalidade.

Caso contrário, em que a produção total dum fornecedor não seja suficiente para aprovisionar

todos os pedidos, cada produtor receberá uma fracção q′= R ∗ q, sendo R o rácio entre pro-

dução e total de pedidos. Assim todos os produtores receberão a mesma fracção com base no

seu pedido.

3.2.4 Agente Padrão - Dummy

O desenvolvimento dum agente para o TAC-SCM-PC é realizado através do uso duma fra-

mework específica, sendo disponibilizada uma API para interagir com o simulador. É disponibi-

lizado um agente padrão que serve como ponto de partida para o desenvolvimento. O agente


dummy tem como base o agente padrão e é usado por defeito caso não se preencham as 3

vagas na competição, no entanto as suas diferenças para com o agente padrão não são docu-

mentadas, assim sendo assume-se que o agente dummy é igual ao agente padrão.

O agente dummy usa heurísticas simples para tomar as suas decisões, começando pelo mer-

cado de vendas onde vai aceitar todas as encomendas elaboradas pelos clientes, registando a

quantidade necessária de cada componente num vector.

3.2.4.1 Long-term Contracts

A negociação dos Long-term Contracts é efectuada usando o par < Qltsmax, pexec >. No caso do

agente dummy, para cada fornecedor, o valor da quantidade máxima (Qltsmax) é fixado em 500.

Para o valor do preço de execução (pexec) é calculado um número aleatório no intervalo uniforme

[0, 100] ao qual é acrescido o preço de reserva de unidade pmin. Tanto na primeira semana como

no restante jogo, o agente opta por encomendar a quantidade máxima (Qmax) acordada com o

fornecedor.

Algorithm 1 Pseudocódigo da negociação de Long-term Contracts

Recebe do fornecedor: pmin, αpexec = pmin + random(100)Qmax ← 500enviaLicitacao(Qmax, pexec)

3.2.4.2 Short-term Contracts

Os Short-term Contracts são negociados diariamente pelo agente. Para cada fornecedor o

agente verifica quantas unidades são necessárias para um dado componente, enviando um

RFQ essa quantidade com uma data de entrega a 2 dias no futuro.

Algorithm 2 Pseudocódigo da negociação de Short-term Contracts

quantidadeEncomendar ← QuantidadeNecessria[componente]diaDeEntrega← diaCorrente+ 2enviaRFQ(quantidadeEncomendar, diaDeEntrega)

4Trabalho Relacionado

Nesta secção de trabalho relacionado será realizado um levantamento de várias contribuições

externas de modo a criar uma base sólida para este trabalho. Serão abordados e analisados

agentes referentes ao simulador TAC-SCM (Secção 3.1) de modo a aprofundar o modelo geral

da cadeia de fornecimento simulada. Serão de seguida documentados agentes implementados

especificamente para a extensão TAC-SCM-PC (Secção 3.1.3). Os agentes a serem documen-

tados no âmbito do simulador TAC-SCM são:

• TacTex

• CMieux

Os agentes a serem documentos no âmbito da extensão TAC-SCM-PC são:

• CrocodileAgent

• CMieux

Todos os agentes desenvolvidos tanto para o simulador TAC-SCM como para a extensão TAC-

SCM-PC partilham o objectivo principal de optimizar a cadeia de fornecimento onde estão inse-

ridos de modo a maximizar a margem de lucro. Apesar deste objectivo comum os trabalhos que

vão ser aqui apresentados possuem abordagens e implementações diferentes com o intuito de

superar os seus oponentes.

19

20 CAPÍTULO 4. TRABALHO RELACIONADO

4.1 CMieux

4.1.1 Introdução

O Agente CMieux foi desenvolvido no âmbito do simulador TAC SCM [1] com o intuito de re-

solver os problemas inerentes às cadeias de valor dinâmicas, tendo como principal objectivo a

obtenção da maior margem de lucro possível durante o tempo de jogo estipulado pelo simula-

dor. Para isso o agente divide as várias tarefas de forma modular e com coesão forte entre os

vários módulos constituintes, de forma a reavaliar a sua situação nos mercados de forma rápida

e eficaz. A arquitectura geral do agente CMieux é constituída por 5 módulos [7]. O módulo de

venda de computadores analisa os pedidos (RFQs) dos clientes, o módulo de compra de com-

ponentes gera os RFQs a enviar para os fornecedores e numa fase posterior analisa as ofertas

em resposta a esses RFQs. O módulo de escalonamento agenda a produção ao longo de vários

dias no futuro baseando-se nos recursos disponíveis e na previsão de inventário. O módulo de

estratégia visa tomar decisões de alto nível (e.g. decidir a quota de mercado para cada tipo de

componente). Por fim o módulo de previsão tem como objectivo prever os preços dos compo-

nentes e computadores como também é responsável por prever as quantidades pedidas.

Figura 4.6: Modelo Geral do Agente CMieux a) Business to Consumer b) Business to Business

Como já foi referido os vários módulos são coesos entre si. Na imagem 4.6 a) é possível ve-

rificar as operações Business to Consumer entre o agente e os vários clientes. O módulo de

previsão produz as previsões a serem usadas pelo módulo de estratégia com o intuito de cal-

cular as quotas de mercado. O módulo de vendas responde às ofertas dos clientes segundo a

quota de mercado calculada pelo módulo de estratégia e por sua vez os pedidos dos clientes

são observações úteis para o módulo de estratégia. Na imagem 4.6 b) é focada a interacção

Business to Business dos fornecedores com o agente. O módulo de estratégia volta a ser uma

4.1. CMIEUX 21

peça fundamental na arquitectura do agente pois os dados referentes às quotas de mercado são

usados pelo módulo de compra para gerar as encomendas a enviar aos fornecedores.

4.1.2 Módulo de Previsões

Sendo o ambiente simulado pelo TAC SCM uma cadeia de fornecimento dinâmica, é desejável

a obtenção de informação acerca das condições futuras de mercado. O módulo de previsão é

portanto uma peça essencial do agente pois elabora previsões acerca dos preços de compra

dos componentes e venda de computadores e também previsões da quantidade de pedidos dos

clientes [7].

Previsão de Pedidos dos Clientes. Uma das previsões elaboradas pelo módulo de previsão é a

quantidade de pedidos efetuados pelos clientes. Para isso o módulo gera um conjunto de RFQs

representativos da projecção futura de pedidos. Diariamente para cada segmento de mercado

são gerados pedidos segundo uma distribuição de Poisson (3) tendo para cada segmento um

parâmetro de quantidade Q que evolui ao longo do tempo segundo uma tendência τ . De modo a

elaborar a previsão dos pedidos efetuados o módulo prevê esses dois parâmetros responsáveis

pela geração estocástica de pedidos. Para extrapolar a progressão futura destes parâmetros

é usada uma técnica de regressão, linear least squares fit usando os logs de jogos passados

como dados de treino.

Previsão de Preços. Outra das responsabilidades do módulo é a previsão dos preços pratica-

dos em ambos os mercados (compra de componentes e venda de computadores), suportando

assim decisões sobre as condições futuras de mercado. À semelhança da previsão da quan-

tidade encomendas dos clientes, os preços dos componentes também são calculados usando

a técnica de regressão linear least squares fit. Para a previsão dos preços dos componentes

é usada a técnica k nearest-neighbours [8] que consiste em prever o preço de um pedido com

data de entrega usando K RFQs passados com data de entrega mais próxima de d. O agente

documentado neste trabalho (Secção 5) usa k nearest-neighbours para a previsão de preços

dos componentes para uma data de entrega d. O módulo de compra de componentes é respon-

sável por elaborar os pedidos de componentes (RFQs), sendo as respostas dos fornecedores

usadas como dados de treino para a função de previsão. Adicionalmente o módulo de previsão

é responsável por prever os atrasos de entrega de componentes, baseando-se em observações

passadas.


4.1.3 Módulo de Estratégia

O módulo de estratégia funciona com base no módulo de previsões e afecta as decisões dos

módulos de compra, escalonamento e venda de componentes representando assim o módulo

central do agente CMieux. Concretamente é escolhido o subconjunto de pedidos dos clientes a

focar e também a fracção de computadores a vender num dado dia d [7].

Cálculo da Quota de Mercado. A primeira acção diária do módulo de estratégia é de deter-

minar a quota de mercado alvo (conjunto de itens e respectiva quantidade) baseando-se nas

previsões de pedidos dos clientes, priorizando o subconjunto que represente o maior proveito.

Este módulo depara-se com uma dualidade: ter como alvo uma quota de mercado mais alargada

obtendo um lucro distribuído ao longo de todo o tipo de produtos, ou ter como foco um nicho de

mercado obtendo um lucro maximizado dentro de um subconjunto de produtos. É necessário

ter em conta que o sistema simulado é composto por um número reduzido de actores (fornece-

dores, agentes, clientes). Adicionalmente e tendo em conta os limites de capacidade das linhas

de montagem, se as vendas estiverem numa fase de proveito positivo e se essa capacidade não

estiver totalmente aproveitada conclui-se que existe subaproveitamento dos recursos. É com

base nisto que é definida uma heurística que aloca a totalidade da capacidade caso se verifi-

quem essas condições.

Cálculo do Desired to Promise. Após computar a quota de mercado de cada tipo de compo-

nente é necessário obter um esboço do agendamento de fábrica para os dias futuros (scheduling

window). São usados como input a informação referente aos componentes presentes em inven-

tário, componentes esperados, e encomendas de clientes sendo que parte do agendamento

está reservado para encomendas de clientes e outra parte para satisfazer a fatia de mercado

de cada tipo de componente calculada anteriormente. Os itens produzidos que não perten-

cem a nenhuma encomenda passam a ser unidades constituintes do Available to promise (ATP)

schedule, que representa o número de unidades que o agente tem disponíveis para novas en-

comendas dentro do intervalo de dias da scheduling window. Tendo em conta o cenário em que

o demand é maior que o supply, o agente tem como base os dados que constituem a ATP com

o objectivo de encontrar o ponto de equilíbrio entre Lucro Vs Quantidade para o dia em questão,

definindo-se assim o Desire to promise (DTP) schedule que representa os dois primeiros dias

da ATP. A razão disto é que a DTP representa os computadores disponíveis e não associados a

nenhuma encomenda como também os computadores a serem produzidos no dia. Esta técnica

assegura que o agente nunca promete vender mais do que detém em inventário e do que produz

4.1. CMIEUX 23

diariamente permitindo ao módulo de venda de computadores operar em segurança.

4.1.4 Módulo de Escalonamento

O módulo de agendamento tem como objectivo ordenar as encomendas por ordem de priori-

dade e alocá-las às linhas de montagem da fábrica. É mantido um agendamento ao longo de

vários dias no futuro que conta com as encomendas correntes, as encomendas projectadas e

a projecção de inventário. As prioridades são calculadas segundo uma técnica que favorece as

encomendas com data de entrega mais próxima e penalidades elevadas por via dum parâmetro

α que representa o trade-off entre ambos. Obtida a probabilidade, o escalonador agenda pri-

meiro as encomendas com prioridade mais elevada seguido da verificação de capacidade para

o dia corrente. Caso não exista capacidade suficiente para satisfazer os requisitos de produção

duma dada encomenda é retirada da fila e considerada no dia seguinte [7].

4.1.5 Módulo de Venda de Computadores

O módulo de venda tem como finalidade responder aos pedidos dos clientes com base na DTP

produzida pelo módulo de estratégia [7].

Previsão de preços de licitação. Antes de tomar decisões sobre os RFQs recebidos por parte

dos clientes é necessário prever uma distribuição para cada pedido que permita especificar a

probabilidade do cliente aceitar uma oferta em função do preço. Estas distribuições são obtidas

usando uma distribution tree treinada com dados de jogos anteriores. A distribution tree tem

uma configuração semelhante a uma regression tree ou a uma decision tree, porém as folhas

da árvore em vez de representarem apenas um valor representam uma distribuição, neste caso

uma distribuição normal sobre a probabilidade do cliente aceitar uma oferta em função do preço

com base na data de entrega, penalidade, preço de reserva e condições de mercado.

Processo de licitação. Com as distribuições calculadas para cada RFQ recebido, é agora

possível responder aos pedidos dos clientes com o intuito de maximizar as receitas dentro dos

limites especificados pela DTP. O agente simplifica o problema da escolha de preços com a téc-

nica continuous knapsack problem (CKP) [9] que em termos genéricos e em modo de analogia,

dado o limite de peso duma mochila e um conjunto de itens com um dado peso e valor, que

fracções desses itens colocar na mochila de modo a maximizar o valor obtido. No caso concreto

do agente o limite de peso da mochila é análogo aos limites da DTP e o valor da fracção p é


referente a probabilidade p de um dado preço ser aceite pelo cliente.

4.1.6 Módulo de Compra de Componentes

O módulo de compra de componentes executa os pedidos de componentes aos fornecedo-

res como também tem a responsabilidade de tomar decisões sobre as respostas dos clientes

a esses mesmos pedidos. Na tentativa de explorar o comportamento dos fornecedores são

elaborados RFQs com quantidades e datas de entrega variadas de modo a sondar o menor

preço possível, idealmente mais baixo que os preços atribuídos a pedidos de outros agentes. O

agente documentado neste trabalho (Secção 5), para além dos RFQs que envia aos fornece-

dores com uma determinada quantidade, envia também sondas dando prioridade aos dias com

menos informação. Sendo assim as principais entradas deste módulo são as recentes ofertas

dos fornecedores, a projecção do inventário, a quota de mercado correspondente a cada tipo de

componente e a projecção dos preços dos componentes [7].

Ofertas dos Fornecedores. De modo a escolher as ofertas a aceitar é definido um limite má-

ximo aceitável de preço. Também é tida em conta a reputação do agente pois é desejável

mantê-la o mais alto possível levando assim o agente a aceitar as encomendas que cumpram a

data de entrega e a quantidade.

Pedido de Componentes. O módulo de compra de componentes tem como objectivo a ob-

tenção de componentes com o intuito de manter os níveis alvo de produção e apontando para

os menores preços possíveis. Para perceber que pedidos fazer, é processada a variável I que

denota a diferença entre os componentes necessários para manter os níveis de produção es-

tabelecidos pelo módulo de escalonamento, pela projecção do inventário até ao último dia de

jogo. O agente não necessita de adquirir essa diferença diariamente pois divide a aquisição de

componentes ao longo de vários dias. A variável I tende linearmente para 0 após o intervalo

de dias da scheduling window de modo a permitir ao agente obter componentes desse intervalo

de dias de uma forma agressiva. Isto permite evitar penalizações em encomendas pendentes e

também que sejam adquiridos pelo preço mínimo local ao da scheduling window. No agente do-

cumentado neste trabalho (Secção 5), é usada uma scheduling window de 12 dias, coincidindo

com a data de entrega de uma encomenda de computadores.

4.2. TACTEX 25

4.2 TacTex

4.2.1 Introdução

Com base no objectivo primário dum agente no ambiente TAC SCM [1] de obter o maior proveito

possível face aos competidores, é necessário existir um alto nível de coordenação entre os vários

módulos constituintes do agente de modo a existir uma interacção eficaz entre fornecedores,

clientes e a fábrica.

Figura 4.7: Arquitetura geral do Agente TacTex.

A figura 4.7 representa o modelo geral do agente TacTex [10] em que se realça os dois elemen-

tos motrizes, o módulo de gestão de compra de componentes e o módulo de gestão de venda de

computadores. O gestor de compras é responsável por enviar os RFQs de pedido de componen-

tes aos fornecedores e também pela decisão de quais ofertas aceitar. Em contraste, o gestor de

vendas controla as tarefas de produção e venda de computadores. Estes dois módulos têm uma

coesão forte existindo assim trocas de informação entre ambos. O gestor de compras comu-

nica ao gestor de vendas a projecção de inventário e os custos de reposição dos componentes

usados, sendo recebido pelo gestor de compras a projecção de uso dos componentes. Os dois

módulos aqui expostos actuam em conjunto com o intuito de obter o maior proveito possível. As-

sim sendo, o módulo de gestão de compras tenta minimizar os preços dos componentes obtidos

e o módulo de gestão de vendas tenta maximizar as receitas obtidas por cada computador pro-

duzido. Para poder actuar de forma eficiente sobre ambos os mercados é necessário alimentar

ambos os gestores com previsões futuras de mercado. O modelo de compras observa todas

as encomendas com os respectivos preços de modo a produzir previsões acerca da disponibili-

dade e preços futuros dos vários componentes. O modelo de vendas observa a quantidade de

pedidos em cada segmento de mercado, usando essa informação para estimar os parâmetros

usados nas funções que geram esses pedidos (secção 3.1.3). Esta previsão é usada para o

gestor de vendas planear a produção futura de computadores. Para decidir em que RFQs dos


clientes licitar é necessário existir um modelo de offer acceptance que associa cada RFQ a uma

função que tem como saída a probabilidade de um dado preço de licitação ser aceite pelo cliente.

4.2.2 Módulo de Gestão de Vendas

O gestor de vendas engloba todas as tarefas referentes à venda e produção de computadores

sendo nesta secção descrito o funcionamento do módulo e também dos Modelos de Previsão

que suportam as suas decisões [11]. Mais especificamente este módulo executa diariamente as

seguintes ações:

• Com base no modelo de vendas prever a quantidade futura de pedidos.

• Com base no modelo de offer acceptance gerar as funções de licitação para cada RFQ.

• Agendamento de produção futura das encomendas pendentes e das encomendas previs-

tas.

• Agendamento de produção para o dia seguinte.

• Actualizar a projecção de uso de componentes.

Previsão da quantidade futura de pedidos. Para elaborar o agendamento futuro de produção

é necessário ter como base a previsão da procura de computadores. Como descrito na secção

3.1.3 o mercado de vendas está dividido em 3 segmentos (alto, médio e baixo). A procura de

cada segmento é calculada de forma independente com base nos parâmetros quantidade média

Qd e tendência τd. O número de pedidos é gerado segundo uma função de Poisson com média

Qd. Qd+1 é obtido através de Qdτd sendo τd+1 calculado com base τd e num factor aleatório.

De modo a obter uma projecção futura destes parâmetros é adoptada uma técnica Bayesiana

usando como dados de treino logs de jogos passados.

Modelo de Offer Acceptance. Como a quantidade de pedidos é muito superior à capacidade

de fábrica, o objectivo do agente não é conseguir todas as encomendas mas sim encontrar o

subconjunto que maximiza a margem de lucro [11]. Assim sendo pode-se prever o preço máximo

a que cada leilão poderia ser ganho. Porém essa abordagem requer que sejam ganhas todas

as encomendas desse subconjunto, levando assim a uma abordagem mais sofisticada: realizar

licitações altas em vários leilões e esperar ganhar uma fracção dos mesmos. Para isso é ne-

cessário estimar a probabilidade de vencer o leilão em função do preço para cada RFQ e usar

4.2. TACTEX 27

essa estimativa para maximizar a margem de lucro do agente. O método usado pelo agente [12]

envolve discretizar o intervalo de preços dividindo-o em várias caixas, e estimar a probabilidade

em cada extremidade dessas caixas sendo a distribuição obtida por interpolação dos pontos

estimados. O treino dos vários estimadores é feito com base na competição que teve lugar em

Agosto de 2003 tendo acesso aos logs dos vários jogos. É criada uma instância de treino para

cada RFQ analisado sendo consideradas como features a data corrente, a quantidade pedida, a

penalidade, a data de entrega, o preço de reserva, e os máximo e o mínimo preço que o tipo de

computador em questão foi vendido nos últimos 5 dias. Para cada ponto x no intervalo discreto

de preços é treinado um estimador sendo atribuído o valor de 1 a um leilão cujo preço vencedor

seja maior que x e 0 caso contrário.

Algoritmo de Escalonamento. O agente tem um limite (imposto pelo próprio) de apenas aten-

der aos RFQs recebidos no dia corrente até um máximo de 12 dias no futuro, significando que o

agendamento deve ser cumprido no máximo em 10 dias (secção 3). O objectivo do escalonador

é maximizar o proveito segundo o número de ciclos, os componentes presentes e esperados

em inventário e os computadores completos em inventário. O proveito de uma encomenda é

a diferença do seu preço menos as penalidades de atraso e os custos de reposição. É usado

um greedy algorithm que tenta produzir as encomendas o mais tarde possível de modo a deixar

capacidade livre para encomendas mais recentes com datas de entrega mais próximas. O es-

calonador é actualizado ao início do dia com a informação transmitida pelo Gestor de Compras

a nível de recursos de fábrica, de seguida são agendadas as encomendas com data de entrega

de 1 dia no futuro. Após este processo são agendadas as restantes encomendas até lotar a

capacidade.

Licitação nos RFQs dos clientes. O foco é encontrar o subconjunto de RFQs a licitar de modo

a maximizar o proveito obtido pela venda de computadores tendo em conta os recursos dispo-

níveis para os próximos 10 dias e também agendar as encomendas previstas pois é necessário

reservar alguma capacidade para encomendas futuras usando assim as previsões de pedidos

dos clientes. De seguida são usadas as funções obtidas através do modelo de Offer Acceptance

para cada RFQ (reais e previstos) de modo a calcular o proveito de cada possível encomenda.

A licitação ideal para um subconjunto de RFQs, pondo de parte as limitações de recursos, pode

ser representado pelo majorante da seguinte função:

Expected profit =∑

i ε all RFQs

P (order|price) ∗ (price− cost) (4.12)


Porém o problema é demasiado complexo para se poder calcular o proveito do subconjunto de

RFQs de forma independente pois não existem garantias que o agente consiga ganhar todas as

encomendas do subconjunto identificado. Para simplificar o sistema é aplicada uma heurística

de licitação que assume que é possível reter uma fracção da encomenda, ou seja, na realidade

existe uma probabilidade p de vencer um dado leilão com um dado preço, aplicando a heurística

a probabilidade de vencer o leilão é total mas apenas será considerada a fracção p da enco-

menda. Com esta abstracção a equação 4.12 é usada para calcular o proveito do subconjunto

considerado. Pode existir o problema do agente vencer demasiadas encomendas face à sua

capacidade porém como parte desses RFQs são gerados pelo Gestor de Vendas do Agente, é

possível alterar a política de licitação futura de modo a compensar este excesso. Assim sendo é

possível focar o problema de encontrar o subconjunto de RFQs cujas licitações resultaram num

maior proveito usando um greedy algorithm. Primeiro é estipulado um preço de licitação para

todos os RFQs acima do preço de reserva, de seguida é escolhido um RFQ e é escolhido o novo

preço de licitação segundo 4.12. Após este processo é simulado o agendamento da encomenda

sendo todo este processo repetido até lotar a capacidade da fábrica. O critério de selecção do

próximo RFQ é dinâmico e está relacionado com os recursos de fábrica (ciclos de produção e

componentes). No caso em que a fábrica esteja a operar a menos de 90% de capacidade o

critério de selecção é o maior proveito obtido, caso contrário é o proveito por ciclo de fábrica. No

termino deste processo é obtido um agendamento de fábrica ao longo de 10 dias. As licitações

calculadas para os RFQs reais são enviadas ao cliente em forma de oferta.

4.2.3 Módulo de Gestão de Compras

O gestor de compras (fig. 4.7) [10] tem como principal função a compra de componentes aos

fornecedores com base no agendamento produzido pelo módulo de gestão de vendas. Por sua

vez o gestor de compras informa o gestor de vendas da chegada e custos de reposição dos

componentes. À semelhança do mercado de venda de computadores, também no mercado de

compra de componentes é necessário elaborar projecções acerca da disponibilidade e preço dos

produtos. Também é da responsabilidade deste módulo a supervisão da reputação do agente

e também o uso de RFQ probes de modo a melhorar os modelos de previsão. Previsão dos

preços. O modelo de compras (fig. 4.7) assiste o gestor de compras prevendo o preço que

um dado fornecedor oferece em resposta a uma dada quantidade e data de entrega pedidas no

RFQ. Para isso é necessário manter uma estimativa dos compromissos existentes dos vários

fornecedores. Está definido pelo ambiente simulado (secção 3) que o preço oferecido em res-

posta a um RFQ é totalmente calculado pela fracção de capacidade que é alocada ao longo do

4.2. TACTEX 29

dia corrente. Adicionalmente é possível ao gestor de compras calcular essa fracção de capaci-

dade pelo preço oferecido por RFQ. O processo envolve comparar ofertas do mesmo fornecedor

com datas de entrega distintas, a subtracção das capacidades alocadas entre essas duas datas

resulta na capacidade alocada no período entre essas datas. Cada linha de fornecimento tem

uma instância deste estimador alocada, sendo actualizada diariamente com as ofertas que re-

cebe. Existe também a hipótese de usar alguns dos RFQs disponíveis diariamente como probes,

sendo escolhidas as datas que se carece de informação. Devido à grande flutuação dos preços

a curto prazo o agente não planeia RFQs com datas de entrega inferiores a 5 dias, salvo uma

excepção que será exposta posteriormente.

Reputação. O agente possui um mecanismo de defesa contra o declínio de reputação abaixo

dum certo limiar. Cada fornecedor tem um rácio mínimo (secção 3) de reputação. Assim sendo

o modelo de vendas segue as ofertas recebidas dos fornecedores e informa o gestor de vendas

da quantidade que se pode rejeitar até chegar ao mínimo aceitável.

Encomendas de Componentes. Para obter o maior lucro possível é necessário vender os com-

putadores ao maior preço possível e também obter os componentes ao menor preço possível.

O papel do gestor de compras é então responder às necessidades de produção do gestor de

vendas decidindo que componentes obter. Existe um threshold mínimo de componentes em

inventário sendo no caso do agente TacTex de 800 componentes (400 no caso dos CPUs) du-

rante praticamente o jogo inteiro sendo que no final decresce linearmente. Com base nisto é

calculado diariamente o número de componentes necessários a serem encomendados de modo

a respeitar o threshold. Este cálculo é feito para todos os dias futuros e tem em conta todos

os componentes esperados, o inventário actual e o agendamento de produção. Decididos os

componentes a obter, o gestor de compras tem agora de se focar em assegurar esses itens ao

menor preço possível. Esta tarefa é simplificada sendo que para cada tipo de componente e para

um dado dia de entrega d, a entrega desse tipo de componente será feita ao cargo de apenas

uma encomenda. Assim foca-se o problema na escolha do dia a enviar esse RFQ e para que

fornecedor. Relembrando a habilidade do agente de prever os preços para um RFQ enviando

no dia corrente d com data de entrega d + i, de modo a projetar essa previsão para qualquer

d+ x com data de entrega d+ x+ i, o agente supõe que o padrão previsto pode ser deslocado

para qualquer intervalo de dias visto os preços flutuarem de forma suave de dia para dia. Na

prática é estimado um preço para datas de entrega entre [5,40] dias no futuro. Caso o preço

do componente em questão seja o mais baixo até à data de entrega requerida, é formalizado o

envio dum RFQ ao fornecedor que apresentar o preço mais baixo. Existe uma situação em que


é vantajoso enviar RFQs para encomendas a curto prazo (2 dias). Por norma o gestor de vendas

não espera até ao ultimo dia possível para enviar o seu interesse aos fornecedores pois essas

encomendas poderiam resultar em preços inflacionados. Porém se os preços oferecidos pelos

fornecedores para estes prazos forem inferiores aos preços oferecidos para RFQs em situação

normal, a oferta é aceite pelo agente. Tudo isto é feito tendo em conta a reputação do agente

perante o fornecedor em causa.

4.3 CMieux - Procurement Challenge

O agente CMieux - Procurement Challenge [6] foi desenvolvido com base na versão do simu-

lador base TAC-SCM com o foco no mercado de compra de componentes. Toda a estratégia

de compra relacionada com Short-term Contracts é importada do agente desenvolvido para o

simulador base (Secção 4.1), tal como o objectivo primário do jogo de deter a maior quantia em

banca no fim do jogo.

4.3.1 Negociação de Long-term contracts

Relembrando o processo de negociação de Long-term contracts especificado no capítulo de

Background da extensão TAC-SCM-PC (Secção 3.2), no início do jogo é negociado o par <

Qltsmax, pexec > (quantidade semanal máxima, preço de execução). Semanalmente o agente terá

de pagar a cada fornecedor com que celebrou um Long-term contract Qltsmax ∗ pres + q ∗ pexec.

O agente CMieux calcula (para cada componente) o preço de execução pexec com base no

preço médio do componente nos Short-Term contracts de dados recolhidos de jogos passados.

A quantidade máxima Qltsmax é um parâmetro que está associado ao risco que o agente está

disposto a assumir com o fornecedor de Long-Term contracts. Foi concluído que a perda de

lucro relacionado com o inventário que não serviu para produção durante o jogo pesa mais que

o ganho de lucro conseguido num jogo com mais procura por parte dos cliente. Este problema

advém do facto do intervalo de [Qltsmin, Qltsmax] não ser suficientemente flexível de modo a ter um

controlo aceitável sobre as quantidades semanais pedidas. Sendo assim o CMieux adopta uma

estratégia conservadora escolhendo um valor de Qltsmax com vista a uma simulação com baixa

procura de computadores por parte dos clientes.

4.4. CROCODILEAGENT - PROCUREMENT CHALLENGE 31

4.4 CrocodileAgent - Procurement Challenge

A equipa do agente CrocodileAgent - Procurement Challenge [13], à semelhança da equipa do

CMieux - Procurement Challenge [6], participou no jogo base TAC-SCM (Secção 3.1) e poste-

riormente na extensão TAC-SCM-PC. A equipa do CrocodileAgent provém do departamento de

telecomunicações da University of Zagreb, Croatia. Nesta secção serão abordadas as decisões

referentes à implementação do agente para o TAC-SCM-PC.

4.4.1 Negociação de Long-term contracts

Antes do começo dum jogo de Procurement Challenge são negociados os Long-term contracts

com duração até ao findar da simulação. A negociação é efectuada individualmente com cada

fornecedor de Long-term contracts. A primeira interacção é efectuada pelo fornecedor para

agente produtor, sendo enviado, entre outros, o preço de reserva por unidade pmin. O agente

deve proceder neste momento ao envio da sua licitação no formato < Qltsmax, pexec > (Quantidade

máxima por semana, Preço de execução). O valor de Qltsmax é calculado para cada fornecedor

com base no preço de reserva por unidade pmin anunciado. O valor de Qltsmax dos componentes

do tipo CPU assume o valor de 270 caso pmin = 0.5 ∗ pnominal decrescendo linearmente para

190 caso pmin = 0.75∗pnominal. Para os restantes componentes, Qltsmax oscila dentro do intervalo

[370, 250]. Quanto ao valor do preço de execução pexec, o CrocodileAgent assume uma estratégia

simples e conservadora, fixando o seu valor no preço de reserva (pexec = pmin). Esta estratégia

é adoptada pelo agente documentado neste trabalho (Secção 5).

No primeiro dia de jogo a decisão da quantidade semanal (Qweek) a adquirir será igual à quanti-

dade máxima (Qltsmax) desse contrato.

Nas restantes semanas a quantidade de cada componente a encomendar dependerá do inventá-

rio detido pela fábrica do agente produtor. Caso seja inferior a um certo Threshold, a quantidade

a encomendar (Qweek) será a quantidade máxima permitida (Qltsmax), caso contrário será uma

fracção de Qltsmax, tendo em conta que

Qweekε [Qltsmin, Q

ltsmax].

4.4.2 Negociação de Short-term contracts

O CrocodileAgent assume uma heurística para a negociação de Short-term contracts no início

do jogo: A compra de componentes no início do jogo (dia 0) pode resultar em componentes mais


baratos, isto porque não existe procura prévia ao dia 0. Segundo a especificação do simulador

TAC-SCM (secção 3.1), o preço está relacionado com a procura (equação 3.5). Com base

no referido, o agente vai utilizar os 5 RFQs disponíveis para cada fornecedor de Short-term

contracts, com datas de entrega espaçadas ao longo do jogo, isto para obter componentes

potencialmente mais baratos ao longo da simulação. À semelhança da estratégia de negociação

de Long-term contracts do CrocodileAgent, as decisões de negociação de Short-term contracts

ao longo do jogo têm como base a análise duma série de thresholds de modo a controlar o

inventário detido a cada momento .O agente documentado neste trabalho também implementa

um threshold máximo (Secção 5). No caso do CrocodileAgent, os valores de threshold mínimo e

máximo (Nmin e Nmax) variam ao longo do jogo segundo um factor de dia. Este factor aumenta

linearmente do dia 0 ao 60, revertendo a partir desse ponto até ao dia 95. Diariamente o agente

verifica para componente se a equação 4.13 representa uma condição é verdadeira.

Ninv + evaluatedQuantity ≥ Nmax (4.13)

Ninv representa a quantidade desse componente existente em inventário e

evaluatedQuantity a quantidade desse componente encomendada ainda não entregue, tendo

aplicado um factor de distância com base no dia de entrega (o factor de distância tende line-

armente para zero até 30 dias de distância). Caso a equação 4.13 se verifique, o agente não

procede à negociação de encomendas. Caso a equação 4.13 não se verifique o agente procede

à validação da condição exposta na equação 4.14.

Ninv +Ntdy > Nmin (4.14)

Ntdy denota a quantidade diária do componente usada pela fábrica. Se a condição na equação

4.14 não for válida o agente procede à negociação de encomendas de uma forma mais agressiva

de modo a conseguir cumprir a quantidade mínima em inventário Nmin desse componente. Para

além destas condições o agente só compra componentes até um certo preço com excepção do

inventário cair abaixo do threshold Nmin.

5Implementação do Agente - Bull

Este trabalho visa o desenvolvimento de um agente no âmbito do simulador TAC SCM – Pro-

curement challenge (secção 3.2), com o intuito de o testar contra agentes de outras equipas

que participaram anteriormente na competição. Nesta secção é detalhado todo o racional do

mesmo, que daqui em diante será denominado por Bull.

O agente Bull assume uma estrutura modular (fig. 5.8) e coesa. O módulo de previsão consome

os dados do ambiente envolvente e consequentemente armazena-os. Posteriormente usa os

dados armazenados de forma a elaborar uma estimativa dos preços praticados ao longo da série

temporal. O módulo de estratégia define limites de inventário ao longo do jogo de modo a manter

o controlo do armazem. Os módulos de negociação de Long-term e Short-term contracts tomam

as suas decisões de forma coordenada e com base nos módulos de previsão e de estratégia.

5.1 Módulo de estratégia

O módulo de estratégia advém da necessidade de controlar o inventário detido pelo agente a

cada momento, garantido que ao longo do jogo a aquisição dos vários componentes seja o

mais uniforme possível. Para isso é implementado um threshold máximo que ao ser atingido,

notifica os módulos de negociação de Long-term e Short-term contracts influenciando assim

33

34 CAPÍTULO 5. IMPLEMENTAÇÃO DO AGENTE - BULL

Figura 5.8: Constituição modular do agente.

as suas decisões de compra. Adicionalmente é implentado um mecanismo de cutoff que tem

como objectivo minimizar a quantidade de componentes em armazém no final do jogo. Estes

componentes estão assim associados a um prejuízo pois não foram usados em produção. O

mecanismo de cutoff actua directamente sobre o limite de threshold, fazendo com que o mesmo

diminua linearmente a partir do dia 85 até ao último dia do jogo.

5.2 Módulo de previsão

Para suportar a decisão de compra de componentes no mercado de Short-term Contracts, é

feito um estudo de mercado de forma a prever o preço de cada componente com um alcance de

12 dias.

Inicialmente o preço previsto para cada componente é fixado no seu preço base para todos os

dias de jogo. A cada dia de jogo é usado um algoritmo de regressão k nearest neighbours (kNN)

[8] de modo a basear a previsão de preço de um dado componente num dado dia, nos k dias

5.3. MÓDULO DE NEGOCIAÇÃO DE LONG-TERM CONTRACTS 35

Figura 5.9: Constituição modular do agente.

mais próximos. A escolha deste algoritmo baseia-se no seu rácio de eficácia e processamento

e também porque o seu uso não requer a etapa de treino. Decidiu-se fixar k=3 com base em

n1/2 (sendo n a quantidade máxima de valores vizinhos a analisar) de modo a atingir um baixo

valor de processamento. O algoritmo kNN apenas será usado para prever o preço nos dias em

que ainda não tenham sido observadas nenhuma encomenda de componentes ou sido usada

uma sonda (RFQ com quantidade nula). Diariamente é usado o algoritmo (equação 5.15) para

calcular ou recalcular a previsão dos dias [t+2; t+12] sendo t o dia corrente. Para cada dia são

encontrados os 3 dias mais próximos em que tenha sido efectuada pelo menos uma observação

de encomenda ou sonda. Seguidamente é calculada uma média ponderada sendo o peso o

inverso da distância.

kNNprediction =

∑Priceday ∗ 1

distanceday∑1

distanceday

(5.15)

Para os dias em já tenha sido efectuada pelo menos uma observação de preço para um dado

componente, é usada uma média móvel [14] de modo a obter um valor previsto com base na

tendência de preços. São apenas guardadas as 3 últimas observações que servem de entrada

para o cálculo da média aritmética, cujo resultado representa o preço previsto para esse dia..

5.3 Módulo de negociação de Long-term Contracts

Os Long-term Contracts são contratos celebrados no início do jogo e que prevalecem até ao

ultimo dia. O agente negoceia com o fornecedor uma quantidade flexível e um preço unitário com

um período de entrega semanal. No começo do jogo (dia -1) o agente negoceia os contratos de

quantidade flexível com cada fornecedor de long-term contracts. Para cada fornecedor o agente

recebe o valor do preço de reserva (Pmin) e estabelece o preço de execução igual ao preço

de reserva estabelecido pelo fornecedor (Pmin = Pexec). Adicionalmente o valor de quantidade

máxima (Qmax) é fixado nos 200 para componentes do tipo CPU, e 400 para todos os outros.


De seguida o par <Pexec Qmax> é enviado para os fornecedores de Long-term Contracts. O

valor estabelecido para Pexec (Pmin = Pexec) foi escolhido com o intuito de minimizar ao máximo

o preço semanal fixo a pagar ao fornecedor de Long-term Contracts. Os valores estabelecidos

para Qmax foram encontrados com base numa análise de sensibilidade detalhada no gráfico

representado na figura 5.10. No gráfico a quantidade máxima é referente aos componentes do

tipo diferente de CPU, dado que para os CPUs a quantidade é fixada a metade. Isto porque

existem 4 tipos de CPU no mercado ao invés dos 2 tipos para qualquer outra categoria de

componente. Isto assumindo como heurística que o agente necessita de aprovisionar todos

os tipos de componentes de igual forma. O valor de Qmax = 200 é descartado a partida pois

apresenta piores resultados que todos os outros. Analisando os restantes valores, todos eles

se sobrepõem, excepto os valores de Qmax = 250 e Qmax = 400. Sendo assimo valor da

quantidade máxima Qmax é 400.

Figura 5.10: Análise de sensibilidade do valor de Qmax.

No dia 0 os contratos são enviados dos fornecedores de Long-term Contracts para os agentes

produtores, indicando o preço de execução (Pexec), a quantidade máxima (Qmax), e o preço de

reserva de contrato (Pres). De modo a dar o impulso inicial, o agente submete todas as en-

comendas neste dia com quantidade encomendada igual à quantidade máxima (Qencomendada =

Qmax). Nas semanas seguintes, com o intuito de controlar o inventário de componentes, é usado

o threshold máximo de inventário que determina a quantidade semanal (Qweek) a ser encomen-

dada. Semanalmente, caso a quantidade em inventário de um dado componente se encontre

acima desse threshold, o agente vai encomendar a quantidade mínima possível (Qmin), caso

contrário encomenda a quantidade máxima (Qmax). Desta forma é possível manter o equilíbrio

evitando o armazenamento excessivo de componentes.

5.4. MÓDULO DE NEGOCIAÇÃO DE SHORT-TERM CONTRACTS 37

Algorithm 3 Pseudo-código da decisão de compra semanal por via de Long-term Contracts

if stock[componente] > threshold thenEncomenda(QuantidadeMnima)

elseEncomenda(QuantidadeMxima)

end if

5.4 Módulo de negociação de Short-term Contracts

Em contraste com os Long-term Contracts, os Short-term Contracts são contratos de curta du-

ração que contemplam apenas uma transacção. São negociados com o fornecedor de um dado

componente a quantidade, o preço por unidade e a data de entrega.

As encomendas de computadores por parte dos clientes têm associada uma data de entrega

compreendida num intervalo de [t+3,t+12] sendo t o dia corrente. Assim sendo e para simplificar

o desenvolvimento do agente, a cada momento apenas são considerados os 12 dias seguintes

para efeitos de aprovisionamento de inventário.

No decorrer do jogo é analisada diariamente a procura de cada computador por parte dos clien-

tes, sendo registadas num vector segmentado por dia, as quantidades de todos os componen-

tes necessários à produção desses computadores. Para cada tipo de componente é analisado

o threshold máximo, caso a quantidade em inventário seja superior ao valor do threshold, os

componentes não serão registados. O agente encontra-se programado para cobrir o número

máximo de encomendas possível o que o leva a considerar todas as propostas dos clientes para

efeitos de aprovisionamento.

5.4.1 Decisão de Compra

Relembrando a negociação entre fornecedores e o agente (secção 2) (fig. 5.11) de modo a

proceder a uma compra por via de um Short-term contract, o agente terá de elaborar um RFQ

contendo o preço de reserva (Preserva), a quantidade pretendida (Qrfq) e também a data de

entrega. O fornecedor poderá então emitir uma oferta onde vem descriminado o preço por

unidade (Poffer), a quantidade (Qoffer) e a data de entrega.

Diariamente o agente analisa o vector que contém os componentes necessários para cada dia de

forma a decidir o conjunto de encomendas a efectuar. Existe um limite diário de envio de 5 RFQs

associado a cada fornecedor, sendo que um RFQ pode tomar a forma de uma encomenda ou

de uma sonda (secção 2). É percorrido o vector que contém os componentes necessários para


Figura 5.11: Diagrama de negociação de Short-term contracts

os dias [t+3;t+12] sendo t o dia corrente. As encomendas de componentes terão de chegar pelo

menos um dia antes de modo a conseguir garantir a produção e entrega do computador, sendo

assim para cada dia analisado verifica-se qual o dia anterior que tenha associada a previsão

de preço mais baixa. A quantidade a encomendar é registada numa lista que associa um dado

dia a uma dada quantidade. Após percorrer os dias [t+3;t+12] o agente inicia o processo de

envio de RFQs percorrendo a lista de encomendas resultante. Caso o dia em questão contenha

uma quantidade maior que 0, é enviado um RFQ com a quantidade respectiva. Caso contrário

o agente poderá enviar uma sonda. É primeiro verificado se no dia seguinte a quantidade é

também 0, caso afirmativo são comparados o número de sondas e encomendas observadas em

cada dia. O dia que contiver o menor número de observações é-lhe associado uma sonda, sendo

enviado um RFQ com quantidade 0. O objectivo é distribuir o mais uniformemente possível o

número de sondas enviadas para cada dia, favorecendo o envio para os dias que contenham

menos informações de mercado. Este processamento continua até ter sido atingido o limite de

RFQs, neste caso 5.

5.4.1.1 Pseudo-Código da Decisão de Compra de Short-term contracts

5.4. MÓDULO DE NEGOCIAÇÃO DE SHORT-TERM CONTRACTS 39

Algorithm 4 Pseudo-código da negociação de Short-term Contracts

quantidadeEncomendar[dia]← 0 (lista que relaciona um dado dia com uma dada quantidade)

contadorRFQs← 0DiaPrecoMaisBaixofor i=3;i <= 12;i++ do

for j=2;i < j;j++ doif Preco[dia+ j] < Preco[DiaPrecoMaisBaixo] thenDiaPrecoMaisBaixo← dia+ j/x

end ifend forQuantidadeEncomendar[dia + j] ← QuantidadeEncomendar[dia + j] +QuantidadeRequerida[dia+ i]

end forfor h=2;h <= 11 || contadorRFQs = 5;h++ dodiaDeEntrega← dia+ hif QuantidadeEncomendar[dia+ h] > 0 thenEnviaRFQ(QuantidadeEncomendar[dia+ h], diaDeEntrega)contadorRFQs++

elseif QuantidadeEncomendar[dia+ h+ 1] > 0 thenContinua

elseenviaSonda(diaDeEntrega)contadorRFQs++

end ifend if

end for

6Análise dos resultados

Neste capítulo serão analisados os resultados da performance do agente Bull, documentado

neste trabalho (capítulo 5). Para obter uma leitura eficiente dos dados foram escolhidos um

conjunto de indicadores de performance (KPI) que representam no seu todo o comportamento

do agente permitindo também a comparação com os seus oponentes. O conjunto de KPIs

utilizados nestas análises são:

• Lucro total.

• Percentagem de uso da capacidade da fábrica.

• Percentagem de encomendas entregues ao cliente face às encomendas realizadas.

• Componentes em inventário no fim do jogo.

Adicionalmente é também medida a performance dos mecanismos de previsão usados pelo

agente Bull.

A validação dos resultados obtidos será efectuada em várias fases, sendo primeiro abordada a

evolução do agente Bull ao longo do seu desenvolvimento, tendo nesta fase como oponentes

os agentes dummy (secção 3.2.4). Posteriormente o Bull será posto à prova contra os agentes

Warrior [13], Crocodile [13] e CMieux [6]. Os dados foram retirados das simulações corridas

usando o simulador TAC-SCM-PC, e analisados com base numa API. Para cada fase serão re-

alizadas n simulações, segundo o teorema do limite central [8] se n (n = 35) for suficientemente

41

42 CAPÍTULO 6. ANÁLISE DOS RESULTADOS

alto (n = 30), a amostra de dados tende para uma representação de uma distribuição normal.

Com base nisto, serão calculados os intervalos de confiança a 95% para a amostra.

6.1 Análise do agente ao longo da implementação

Nesta secção serão analisadas 3 versões chave no desenvolvimento do agente.

6.1.1 Versão 1 - Implementação da estratégia de Long-term Contracts

A primeira versão foca a implementação da estratégia de negociação dos Long-term Contracts

(secção 5.3), mantendo a estratégia de base de negociação de Short-term Contracts (sec-

ção 3.2.4).

Figura 6.12: Lucro no final do jogo.

Figura 6.13: Percentagem de uso da capacidade de fábrica.

6.1. ANÁLISE DO AGENTE AO LONGO DA IMPLEMENTAÇÃO 43

Figura 6.14: Percentagem de encomendas entregues.

Figura 6.15: Stock em inventário no final do jogo.

Nesta fase o agente Bull obteve resultados no geral negativos. O lucro obtido (figura 6.12) pelo

agente cai para valores negativos na ordem dos milhões, face aos dummy que se encontram em

valores positivos. Em contraste as percentagens de uso da capacidade da fábrica (figura 6.13)

e de encomendas entregues (figura 6.14) são superiores às dos agentes dummy. O lucro (fi-

gura 6.12) negativo é reflexo do inventário (figura 6.15) retido no final do jogo pelo agente Bull,

representando itens comprados pelo agente que não serviram para produção. É possível tam-

bém observar que o inventário detido para os componentes do tipo CPU (100, 101, 110 e 111)

é em geral inferior ao dos agentes dummy, isto porque tendo em conta que existem o dobro das

categorias deste tipo de produto face aos restantes produtos, os contratos são negociados com

metade da quantidade.


6.1.2 Versão 2 - Implementação dos mecanismos Threshold e cutoff de

inventário

Nesta versão foi identificada a necessidade de aplicar um Threshold (secção 5.1) máximo em

cada componente do inventário, que tende para 0 na fase final do jogo. Isto porque a acumulação

de stock no final do jogo leva a uma perda considerável no lucro do agente. Adicionalmente

nesta fase, é usado um vector (secção 5.4) que regista por dia a quantidade necessária de

cada componente de modo a satisfazer as ordens de compra dos clientes. Em contraste com o

agente dummy, o agente Bull passa a usar a quantidade máxima de RFQs (secção 5.4) que tem

disponível para cada fornecedor de Short-term contracts, aumentado assim o seu potencial de

aquisição.



Analisando os dados recolhidos é possível concluir que o lucro (figura 6.16) do Bull é superior

ao dos dummy. Um factor importante para a obtenção deste resultado é a gestão de inven-

tário (figura 6.19) levando a um stock final bastante reduzido, o que representa uma melhoria




relativamente à versão 1. Com isto a maioria dos componentes adquiridos são usados para

produzir PCs, o que leva a um aumento do lucro. Adicionalmente as percentagens de uso da

capacidade da fábrica (figura 6.17) e de encomendas entregues (figura 6.18) são mais elevadas

que na versão 1 (figuras 6.13 e 6.14) , podendo resultar do aumento do potencial de compra de

compontentes (secção 5.4).

6.1.3 Versão Final - Implementação dos mecanismos de previsão

Nesta fase final são adicionados os mecanismos de previsão de preços de componentes usa-

dos pelo agente Bull, com o intuito de diminuir o preço de aquisição dos componentes. Os

mecanismos adicionados são o k Nearest Neighbours e a média móvel.



Numa primeira aproximação é de notar que o lucro (figura 6.20) obtido é superior ao das fases

anteriores, sendo assim possível inferir que apesar das incertezas inerentes ao mercado de

componentes, os mecanismos de previsão permitem ao agente a aquisição de componentes

a um preço mais baixo, resultando numa margem de lucro superior. Na tabela 6.3 é possível

observar a performance dos mecanismos implementados. Nesta tabela estão representados os

erros relativos (equação 6.16) do uso das duas técnicas de previsão usadas, kNN e média móvel.

O erro de cada técnica foi obtido de forma isolada sendo Pobservado correspondente ao preço

calculado através de uma das duas técnicas e Preal o preço real de compra de componentes

nesse mesmo dia. É de reforçar que quando não existem informações de mercado acerca dum

determinado dia, é usado o preço base do componente para extrapolar o preço para esse dia.

No entanto o erro associado ao uso do preço base como forma de previsão é bastante elevado

devido às flutuações de preço inerentes ao mercado de componentes. Conclui-se que o uso dos

mecanismos de previsão é abonatório, pois o erro obtido é bastante inferior em relação ao uso

exclusivo do preço base.

Preço Base 59,44%Moving Average 6,91%

kNN 10,11%

Tabela 6.3: Erro dos mecanismos de previsão

δ =Pobservado − Preal

Preal∗ 100 (6.16)


6.2 Análise da performance do agente

Nesta secção são apresentados os resultados e respectivas análises da performance do agente

Bull quando posto à prova contra agentes de outras equipas. Cada uma destas análises terá

como concorrentes o agente Bull, um agente de outra equipa e um dummy.

6.2.1 Versus Warrior

A primeira análise recai quando o oponente é o agente Warrior [13]. Este agente foi desenvolvido

por uma equipa da University of Michigan tendo participado na competição de 2007 do TAC-

SCM-PC.

Figura 6.24: Lucro no warrior do jogo.


6.2. ANÁLISE DA PERFORMANCE DO AGENTE 49


Figura 6.27: Stock em inventário no warrior do jogo.

Numa primeira aproximação, analisando o gráfico (figura 6.24), o agente Bull obtém uma mar-

gem de lucro bastante superior relativamente ao seu competidor. O mesmo é verdade para as

percentagens de uso da capacidade da fábrica (figura 6.25) e de encomendas entregues (fi-

gura 6.26). Porém analisando o inventário detido no fim do jogo (figura 6.27), o agente Warrior

é no geral superior. O lucro superior do agente documentado neste trabalho (capítulo 5) é ex-

plicado pela aquisição duma quantidade mais elevada de componentes, mantendo a fábrica a

produzir a um ritmo mais elevado, o que resulta numa percentagem maior de encomendas entre-

gues. Adicionalmente o agente Bull consegue uma maior margem de lucro devido aos sistemas

de previsão implementados (secção 5.2).

6.2.2 Versus CrocodileAgent

De seguida são analisados os dados resultantes das simulações corridas contra o agente Cro-

codile [13] (secção 4.4). A equipa que desenvolveu o agente CrocodileAgent provém do depar-

tamento de telecomunicações da Universidade de Zabreb, Croácia. Este agente participou na

competição de 2007 do TAC-SCM-PC.


Figura 6.28: Lucro no crocodile do jogo.


O lucro (figura 6.28) dos agentes Bull e Crocodile sobrepõem-se tendo em conta os intervalos de

confiança cálculados, não sendo assim possível averiguar qual o mais eficiente. No entanto ana-

lisando os outros KPIs é possível perceber que o agente Crocodile é ligeiramente mais eficiente

no tocante às percentagens de uso da capacidade da fábrica (figura 6.29) e de encomendas

entregues (figura 6.30). Em contrapartida o Crocodile acumula uma maior quantidade de inven-

tário no final do jogo comparando com o Bull, isto devido à estratégia de cutoff (secção 5.1)

do threshold máximo de invetário permitido por componente. É de notar que tanto o agente

Bull como o agente Crocodile têm ambos uma melhor performance que o dummy em todos os

aspectos analisados.



Figura 6.31: Stock em inventário no crocodile do jogo.

6.2.3 Versus CMieux

Por fim é analisada a performance do agente Bull contra o agente CMieux [6] (secções 4.1 e 4.3).

O CMieux foi desenvolvido por uma equipa da Carnagie Mellon University, tendo participado na

competição de 2007 do TAC-SCM-PC.

Analisando os dados recolhidos é possível observar que o agente CMieux tem uma melhor

performance a nível de lucro obtido (figura 6.32). Quanto aos restantes KPIs os dois agentes

encontram-se equilibrados, sendo que ambos são superiores ao agente dummy. O CMieux pos-

sui algumas características que o colocam à frente do agente Bull, como a selecção da quota de

mercado em que vai focar as suas decisões de compra de componentes, maximizando assim o

seu lucro. Adicionalmente produz previsões do escalonamento das suas linhas de montagem,

dos níveis de stock em inventário e também do mercado de vendas de computadores, essenci-

ais nas decisões a tomar a nível de aprovisionamento de componentes. É também um agente

bastante selectivo a nível do preço de aquisição dos componentes, não aceitando a transacção

caso o preço se encontre acima de um dado limiar. Em contrapartida o agente Bull implementa


Figura 6.32: Lucro no cmieux do jogo.


estratégias de controlo do threshold (secção 5.1) que permitem manter o mesmo nível de in-

ventário final que o CMieux (figura 6.35). As percentagens de uso da capacidade da fábrica

(figura 6.33) e de encomendas entregues (figura 6.34) são muito próximas entre os dois agentes

não sendo possível inferir qual dos dois é superior nestes campos, devendo-se este resultado

aos módulos de negociação de Long-term (secção 5.3) e Short-term (secção 5.4) contracts.

Mesmo o lucro do CMieux sendo superior ao do Bull, os dois agentes não estão muito distantes

neste KPI específico.



Figura 6.35: Stock em inventário no cmieux do jogo.

7Conclusão

O estabelecimento da era digital revolucionou para sempre o mundo em que vivemos, desenca-

deando a massificação de informação, passando a ser o bem mais valioso e tornando-se assim

a base da economia mundial. Os sistemas de informação têm um papel fulcral no suporte aos

negócios hoje em dia, permitindo a análise de grandes volumes de informação. Mais concre-

tamente no caso das cadeias de fornecimento, estes sistemas são essenciais para a análise

da tendência de mercado. Da necessidade de estudar técnicas inteligentes de gestão das ca-

deias de valor nasce em 2002 a competição TAC-SCM (secção 3.1) que coloca à prova agentes

numa cadeia de fornecimento simulada. Mais tarde em 2007 dá-se o aparecimento do TAC-

SCM Procurement Challenge (secção 3.2). Foi neste panorama que foi desenvolvido o agente

documentado neste trabalho (secção 5). O agente Bull foi testado contra agentes que competi-

ram na competição TAC-SCM-PC de 2007 obtendo resultados positivos (secção 6) ao longo das

várias simulações, conseguindo superar alguns dos agentes. Todas as decisões tomadas ao

longo do seu desenvolvimento tiveram o foco de aumentar a margem de lucro obtida. O agente

tenta aprovisionar-se com os componentes necessários a satisfazer o maior número possível de

encomendas (secções 5.3 e 5.4) dos clientes o que faz com que as percentagens de uso da

capacidade de fábrica e de encomendas entregues tenha subido ao longo do seu desenvolvi-

mento. A decisão de implementar um threshold e uma estratégia de cutoff permite ao agente

ter um maior controlo sobre o seu inventário (secção 5.1), permitindo terminar o jogo com uma

quantidade reduzida de componentes. Os mecanismos de previsão (secção 5.2) permitem ao

agente a aquisição de componentes a preços mais baixos, aumentando assim a margem de

lucro na venda de cada computador.

55

56 CAPÍTULO 7. CONCLUSÃO

7.1 Trabalho futuro

Como trabalho futuro propõe-se a extensão do módulo de estratégia do agente documentado

neste trabalho (secção 5.1), de modo a incluir um threshold mínimo de componentes em inven-

tário. Quando um certo componente se encontrar abaixo desse threshold o agente activa um

modo mais agressivo de aprovisionamento com o intuito de respeitar os níveis de quantidade

mínimos. Em relação ao módulo de previsão (secção 5.2), a sua extensão implica realizar previ-

sões de pedidos por parte dos clientes com o objectivo de reagir mais rápidamente às flutuações

de mercado. Adicionalmente seria interessante treinar o agente com dados de jogos passados

de forma a melhorar a capacidade de previsão do mesmo. No módulo de Long-term contracts

(secção 5.3) poderá ser realizada uma análise mais detalhada de forma a elaborar uma licitação

mais eficiente na negociação dos mesmos. Por fim no módulo de Short-term contracts (sec-

ção 5.4) deverá ser imposto um limite de preço máximo que guiará o agente na aceitação de

ofertas dos fornecedores, com o objectivo de manter uma elevanda margem de lucro.

Bibliografia

[1] Collins, J., Arunachalam, R., Sadeh, N., Eriksson, J., Finne, N., Janson, S.: The Supply

Chain Management Game for the 2007 Trading Agent Competition. Supply Chain Manage-

ment (December 2006) (2007)

[2] Alberto Sardinha, Michael Benisch, J.A.N.S.: The 2007 Supply Chain Trading Agent Com-

petition - Procurement Challenge. Supply Chain Management (June 2007) (2007)

[3] Laudon, K.C., Laudon, J.P.: Management Information Systems. Twelfth ed edn. (2012)

[4] Senge, P.: The Fifth Discipline: The Art and Practice of the Learning Organization. (1990)

[5] Lo, W.S., Hong, T.P., Jeng, R., Liu, J.P.: Intelligent Agents in Supply Chain Management as

an Early Warning Mechanism. 2006 IEEE International Conference on Systems, Man and

Cybernetics (October 2006) 2161–2166

[6] Sardinha, A., Benisch, M., Sadeh, N., Ravichandran, R., Podobnik, V., Stan, M.: The 2007

procurement challenge: A competition to evaluate mixed procurement strategies. Electronic

Commerce Research and Applications (2009)

[7] Benisch, M., Sardinha, A., Andrews, J., Ravichandran, R., Sadeh, N.: CMieux: Adaptive

strategies for competitive supply chain trading. Electronic Commerce Research and Appli-

cations 8(2) (March 2009) 78–90

[8] Mitchell, T.M.: Machine Learning. International edn. (1997)

[9] Benisch, M., Andrews, J., Sadeh, N.: Pricing for Customers with Probabilistic Valuations as

a Continuous Knapsack Problem. Work

[10] Pardoe, D., Stone, P.: An Autonomous Agent for Supply Chain Management. Information

Systems (May) (2007)

[11] Pardoe, D., Stone, P.: Bidding for Customer Orders in TAC SCM. (2005)

57

58 BIBLIOGRAFIA

[12] Schapire, R.E., Stone, P., Cs, M., Edu, D.: Modeling Auction Price Uncertainty Using

Boosting-based Conditional Density Estimation. (2002)

[13] Milivic, T., Podobnik, V., Petric, A., Jezic, G.: The CrocodileAgent: A Software Agent for

SCM Procurement Gaming

[14] Chopra, S., Meindl., P.: MSupply Chain Management - Strategy, Planning, and Operations.

Second ed edn. (2004)

tac scm - negociação automatizada para uma cadeia de ... · 3.2 estrutura geral da cadeia de...

Documents