a escolha de softwares de e-procurement: uma análise...
TRANSCRIPT
FACULDADE DE ECONOMIA E FINANÇAS IBMEC PROGRAMA DE PÓS-GRADUAÇÃO E PESQUISA EM ADMINISTRAÇÃO E ECONOMIA
DDIISSSSEERRTTAAÇÇÃÃOO DDEE MMEESSTTRRAADDOO PPRROOFFIISSSSIIOONNAALLIIZZAANNTTEE EEMM AADDMMIINNIISSTTRRAAÇÇÃÃOO
A escolha de Softwares de E-Procurement: Uma análise multicritério
SSííllvviiaa BBeeaattrriizz NNeeiivvaa
OORRIIEENNTTAADDOORR:: PPrrooff.. DDrr.. LLuuiizz FFlláávviioo AAuuttrraann MMoonntteeiirroo GGoommeess
Rio de Janeiro, 28 de Novembro de 2006.
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
A ESCOLHA DE SOFTWARES DE E-PROCUREMENT: UMA ANÁLISE MULTICRITÉRIO
SÍLVIA BEATRIZ NEIVA
Dissertação apresentada ao curso de Mestrado Profissionalizante em Administração como requisito parcial para obtenção do Grau de Mestre em Administração. Área de Concentração: Administração Geral
ORIENTADOR: PROF. DR. LUIZ FLÁVIO AUTRAN MONTEIRO GOMES
BANCA EXAMINADORA:
PROF. DR. LUIZ FLÁVIO AUTRAN MONTEIRO GOMES PROF. DR. EDSON JOSÉ DALTO
PROF. DR.SUL BRASIL PINTO RODRIGUES
Rio de Janeiro, 28 de Novembro de 2006.
FICHA CATALOGRÁFICA 658.4038011 N397
Neiva, Sílvia Beatriz. A escolha de softwares de E-Procurement: uma análise multicritério / Sílvia Beatriz Neiva -. Rio de Janeiro: Faculdades Ibmec. 2006. Dissertação de Mestrado Profissionalizante apresentada ao Programa de Pós-Graduação em Administração das Faculdades Ibmec, como requisito parcial necessário para a obtenção do título de Mestre em Administração. Área de concentração: Administração Geral. 1. Sistemas de informação - Administração. 2. Apoio à decisão. 3. Análise multicritério.
v
RESUMO
Esta dissertação tem como objetivo central mostrar como a escolha de softwares de e-
procurement pode ser facilitada pela aplicação da Teoria de Utilidade Multiatributo (MAUT).
Através da aplicação da teoria em uma empresa, verificou-se como a MAUT pode ajudar os
decisores nessa escolha e como a teoria fornece um maior aprendizado sobre o problema em
pauta, seus valores e suas prioridades. Também foi demonstrada a importância dos decisores
em todo o processo de escolha.
Para a atribuição de pesos foi utilizada a técnica do Swing Weighting. A técnica exige um
processo interativo com o decisor para que os pesos de todos os critérios, sub-critérios e
questões sejam estabelecidos.
Utilizou-se as soluções de alguns fornecedores (Ariba, Oracle, RightWork e SAP) para
atender às necessidades da empresa compradora em questão.
No início, realizaram-se reuniões para identificar o nível de conhecimento da empresa na
solução de e-procurement, possíveis problemas culturais em relação à solução, o volume de
fornecedores, se estes estavam preparados para uma solução via Internet, o volume de
requisições, solicitações, pedidos de compras e leilões de compras, necessidade de relatórios,
identificação de outros sistemas, necessidade de integração com ERP (Enterprise Resources
Process) e com marketplaces, existência de desenvolvedores internos, possibilidade de
investimento em servidores, entre outros pontos. Esses levantamentos foram essenciais para
verificar-se o risco do fracasso da implantação da ferramenta e a necessidade de uma equipe
de gestão da mudança durante o projeto.
Apresentam-se o contexto de estudo, as justificativas, a relevância, a metodologia utilizada,
uma análise de sensibilidade e o resultado. Uma revisão da bibliografia apresenta a questão
conceitual da solução de compras via Internet, os métodos multicritérios escolhidos e o
contexto no qual os mesmos serão aplicados.
Palavras-chave: Escolha de Softwares – e-procurement – MAUT – Swing Weighting
vi
ABSTRACT
This work aims at showing how Multi-Attribute Utility Theory (MAUT) can be applied to
evaluation and choice of e-procurement softwares. Applying this theory in a company, it was
possible to verify how MAUT can help the decision maker in this choice and how it supplies a
more consistent learning on the problem, its values and its priorities. It also demonstrates the
importance of the decision makers in this choice.
The Swing Weighting Technique was used for weights attribution. This technique demands an
interactive process with the decision maker while establishing the criteria, sub-criteria and
questions.
This work was based on some supplier’s solutions (Ariba, Oracle, RightWork and SAP) to
meet the company’s requirements.
In the beginning, some meetings were carried out in order to identify the company’s e-
procurement knowledge, culture problems, vendors volume, if these vendors were prepared to
an Internet solution, volumes of requisitions, purchase orders, bids and requests for
quotations, reports necessity, other systems interfaces, possible ERP (Enterprise Resources
Process) interfaces, possible marketplaces interfaces, necessity of internal developers,
possibility of servers investment, and others. These surveys were essential to verify any risk
in the implementation of the tool and the necessity of a change in the management team
engaged in the project.
The study context, justifications, relevance, methodology, sensitivity analyze and result will
be presented. The bibliography review presents the main conceptual question about e-
procurement solution, the methods chosen and the context in which it will be applied.
Key Words: Software Choice - e-procurement - MAUT – Swing Weighting
vii
LISTA DE FIGURAS Figura 1 – Processo de uma empresa antes da implantação do e-procurement ...............2 Figura 2 – Processo de uma empresa depois da implantação do e-procurement.............3 Figura 3 – Resultado gráfico final........................................................................................28
viii
LISTA DE TABELAS Tabela 1 – Critérios e Sub-Critérios .........................................................................................21 Tabela 2 – Nota e Peso dos sub-critérios do critério Empresa. ................................................23 Tabela 3 – Nota e Peso dos sub-critérios do critério Financeiro. .............................................23 Tabela 4 – Nota e Peso dos sub-critérios do critério Processo.................................................23 Tabela 5 – Nota e Peso dos sub-critérios do critério Requerimentos Técnicos. ......................23 Tabela 6 – Nota e Peso dos sub-critérios do critério Interface.................................................24 Tabela 7 – Nota e Peso dos sub-critérios do critério Relatórios...............................................24 Tabela 8 – Nota e Peso dos sub-critérios do critério Interface com Usuário. ..........................24 Tabela 9 – Nota e Peso dos sub-critérios do critério Conteúdo................................................24 Tabela 10 - Nota e Peso de todos os critérios...........................................................................24 Tabela 11 – Notas das questões recebidas pela Oracle ............................................................26 Tabela 12 – Notas dos sub-critérios do critério Relatórios ......................................................27 Tabela 13 – Notas dos sub-critérios do critério Relatórios ......................................................27
ix
SUMÁRIO
1. PROBLEMA.........................................................................................................1
1.1 Introdução................................................................................................................................................ 1
1.2 E-procurement ........................................................................................................................................ 3
1.3 Casos de Sucesso...................................................................................................................................... 8
1.4 Problema.................................................................................................................................................. 9
2 REFERENCIAL TEÓRICO ................................................................................10
2.1 Introdução teórica................................................................................................................................. 10
2.2 Conceitos e definições gerais ................................................................................................................ 12
2.3 Teoria de Utilidade Multiatributo (MAUT) ....................................................................................... 13
2.4 Atribuição de Pesos – Teoria................................................................................................................ 17
3 A ESCOLHA ......................................................................................................18
4 METODOLOGIA DE ÁNALISE .........................................................................20
4.1 Método ................................................................................................................................................... 20
4.2 Atribuição de Pesos ............................................................................................................................... 22
4.3 Tratamento dos dados........................................................................................................................... 25
4.4 Análise de sensibilidade ........................................................................................................................ 28
4.5 Conclusão............................................................................................................................................... 29
4.6 Pesquisas futuras................................................................................................................................... 30
REFERÊNCIAS BIBLIOGRÁFICAS.........................................................................32
APÊNDICE................................................................................................................35
GLOSSÁRIO.............................................................................................................50
1
1. PROBLEMA
1.1 Introdução
A preocupação com a redução de custos nas empresas de todo o mundo tem
levado à procura de sistemas que possam ajudar a reduzir a complexidade e
conseqüentemente, o tempo de execução dos processos. No departamento de
compras, uma das soluções que tem sido implantada para ajudar na redução de
custo é o e-procurement ou, simplesmente, o processo de compras via Internet.
Um sistema para atender a esta finalidade pode incluir diversas
funcionalidades, como por exemplo, requisição de compras, solicitações de
cotações, pedidos, leilões, aprovações, relatórios. Estas funcionalidades são
escolhidas e implantadas dependendo da necessidade de cada empresa.
A Associação Brasileira de e-business divulgou em novembro de 2005 a
segunda edição da pesquisa sobre o cenário do e-procurement no Brasil. Um total
de 48 empresas respondeu ao questionário da Associação, entre elas Alcoa, Arno,
Bayer, CPFL, Ericsson, Gerdau, Martins, Pirelli, entre outras (Associação
Brasileira de e-business, 2005).
O resultado da pesquisa mostra que o e-mail e o fax ainda são os principais
meios de comunicação das empresas com os seus fornecedores, totalizando mais
de 60% das solicitações.
Apesar disto, a maior parte das companhias já está ingressando em projetos de
e-procurement. O uso ainda é tímido: a maioria das empresas não faz mais do que
10% do total de seus pedidos pelo meio on-line.
Contudo, os números da pesquisa sugerem que, a partir do momento em que os
resultados são comprovados, há uma migração direta para um percentual acima dos
50% dos pedidos da companhia. As compras de serviços indiretos representam a
maior parte das transações eletrônicas, com 58% da fatia, sendo que os 42%
restantes são baseados nas compras de materiais produtivos (Associação Brasileira
de e-business, 2005).
Dezesseis por cento das empresas que ainda não utilizam o e-procurement
pretendem iniciar projetos ainda no ano de 2006. Dezoito por cento das empresas
pretendem aumentar suas transações eletrônicas em mais de 51%, o dobro em
2
relação a 2005. O crescimento do uso dos pedidos eletrônicos em relação a 2004
foi de 14,9%, e a projeção de aumento para 2006 é de 22,9%. (Associação
Brasileira de e-business, 2005)
Ainda nesta pesquisa, foi levantado que, em média, 26,8% dos pedidos serão
feitos via e-procurement, em 2006. Em 2005, esse número totalizou em 21,8%. A
previsão para 2009 é que metade das transações das compras seja feita por esse
meio.
Uma das principais metas das empresas com a utilização do e-procurement é a
redução de custo que pode ser alcançada com a diminuição do tempo de realização
dos processos depois da implantação da solução. Ilustra-se esse ganho nas figuras 1
e 2.
Check1
Figura 1 – Processo de uma empresa antes da implantação do e-procurement
Fonte: Deloitte Consulting Brasil (2001)
Product Selection1
Availability/ Price Check1
Requisition1 Requisition Approval3
P.O. Generation2
P.O. SubmissionBlanket Release2
P.O.Confirmation Status Check2
Receipt of Product1
Receipt of Invoice2
Invoice Review & Payment2
30 min 5 min 25 min 15 min
20 min 5 min
20 min
20 min
1 min 9 min
1End-user = 80 min 2A/P = 55 min 3Supervisor = 15 min
= 150 min
3
Figura 2 – Processo de uma empresa depois da implantação do e-procurement
Fonte: Deloitte Consulting Brasil (2001)
Com isso, para posicionar-se de modo mais eficaz no mercado e após a
execução de um business case que comprove o ganho no investimento, as
empresas estão partindo para a implantação de um software de e-procurement. Mas
o que é e-procurement? Como escolher o melhor software para sua empresa?
1.2 E-procurement
O e-procurement pode ser definido como um conceito que transfere para a Web
o processo e gerenciamento de compras de suprimentos, aliviando, assim, a carga
de trabalho e os custos dessa área nas corporações. O e-procurement traz a
eliminação do papel, proporciona uma cotação de preços mais abrangente e
possibilita um melhor acompanhamento do desempenho dos fornecedores. Num
outro estágio, amplia a integração da cadeia de relacionamento. Também pode ser
o termo usado para o relacionamento eletrônico entre uma empresa e seus
fornecedores, principalmente na automatização dos processos de compras on-line.
Esse relacionamento inclui desde pesquisas de produtos e preços até transações
propriamente ditas, passando por consultas a informações e outros serviços que
Product Selection1
Availability/Price Check1
Requisition1 RequisitionApproval3
P.O. Generation2
P.O. Confirmation Status Check2
Receipt of Product1
Receipt of Invoice2
Invoice Review & Payment2
9 min 1 min 10 min 1 min
1 min 1 min2 min
20 min
1 min 5 min
1End-user = 40 min 2A/P = 10 min 3Supervisor = 1 min
= 51 min
P.O. Submission
Blanket Release2
4
possam estar associados às atividades de fornecimento. Os sistemas de e-
procurement podem ser desenvolvidos ou implantados de várias formas,
dependendo da posição que a empresa se encontra dentro da cadeia produtiva e de
como estão organizados seus fornecedores (Teixeira, 2003).
As ferramentas de Internet, com suas várias denominações – e-procurement,
cotação eletrônica, leilão reverso, catálogos eletrônicos, dentre outros, – vieram
com a idéia inicial de substituir boa parte do processo estratégico de compras.
Desenvolvidos em linguagem Web, os sistemas podem elaborar cadastros
eletrônicos, nos quais é possível analisar produtos e preços, indicando as melhores
opções de compra de acordo com parâmetros pré-estabelecidos.
O e-procurement faz parte de uma das três fases que podem melhorar o
processo de compras em uma organização (Pinto, Apolinário, Pires, Rodrigues e
Magalhães, 2004):
Sourcing: Processos de identificação de fornecedores importantes para
a organização, em que se estabelecem contratos de fornecimento de
bens e serviços e se acordam regras comerciais, descontos de
quantidade, volume de compras anuais, etc.;
E-Procurement: Após o estabelecimento do contrato, cabe ao
departamento de compras disponibilizar informação dos produtos e
serviços negociados. Os outros departamentos não devem se preocupar
em procurar melhores propostas, pois têm a certeza que o que está
disponível no catálogo de compras é o melhor negócio possível. Nesta
fase, são também definidos os fluxos de aprovações para as requisições
de cada departamento. Ou seja, existem regras pré-definidas para se
realizarem compras e estas são claras para qualquer colaborador da
organização. Um dos objetivos do e-procurement é possibilitar a
interligação ponto a ponto entre os sistemas dos compradores e dos
fornecedores. É ainda objetivo do e-procurement possibilitar a
interligação do sistema de e-procurement com os sistemas financeiros
da sua organização;
Análise: Uma vez que o sistema de e-procurement esteja perfeitamente
interligado com quaisquer outros sistemas, exemplo sistemas
5
financeiros, o gestor passa a ter a possibilidade de analisar em tempo
real o que se passa na organização.
Entre os resultados imediatos estão: o aumento efetivo dos níveis de eficiência
e controle em compras, além de uma redução sensível dos custos operacionais e
dos preços dos produtos comprados (como demonstrado nas figuras 1 e 2). Por
exemplo, a média administrativa de custo para um simples pedido de compras
estava em 2001, entre US$75 e US$125. Assim sendo, um pedido para compra de
um produto que tinha preço de US$10, em 2001, custava mais do que US$85. O e-
procurement usa um refinado processo de negócios e relacionamentos com
fornecedores, auxiliado pela tecnologia para automatizar processos, eliminando
papel, reduzindo erros e, em última instância, reduzindo os custos administrativos
de um pedido de compra em mais do que 75%. O pedido de compra que antes
custava US$75 em administração, em 2001 custava somente US$18,75, o que
representou uma economia de US$56,25 (Thompkins, 2001).
Em maio de 2002, a revista Industry Week publicou os seguintes resultados de
pesquisa, no artigo “E-Procurement Explosion” (Thompkins, 2001):
Owens Corning reduziu 60% dos custos de engarrafamento de água,
25% em embalagem e 22% sobre outros custos. Total de economia de
10% sobre os gastos de $3,4 bilhões.
Hewlett-Packard (HP) economizou mais do que 30% em propaganda e
$220.000 em energia elétrica.
AMR Research afirmou que empresas devem esperar de 15 a 20% de
economia dependendo do que eles compram: 5% em energia, 15 a 20%
em químicos e adesivos, 32% em papel corrugado, 19% em metais e
componentes de máquinas, 36% em mão-de-obra temporária, 40% em
manutenção, reparos e outras operações.
HP divulgou 20 a 25% de aumento na eficiência, de acordo com uma
redução do número de pedidos de compras e administração.
Lucent declarou 60 a 70% de redução no tempo de transações.
Texas Instruments reduziu o custo de um pedido de compras de $80
para $25, Deere & Co. de $97 para $22. 3M informou que custos foram
de $120 para $40 e erros foram de 30% para 0%.
6
Owens Corning usou leilões para cortar o tempo de negociação de 2 a 3
meses para menos de 90 minutos.
O Retorno Sobre o Investimento (ROI) contribui para o valor proposto
também. A Home Depot implantou uma solução de fornecimento em 10
semanas e informou que o investimento pagou por si mesmo em menos
de 3 meses. A American Express anunciou que conseguiu seu
investimento de volta em 100 dias após assinatura de um contrato de e-
procurement.
Vários outros benefícios podem ser enumerados (Thompkins, 2001):
Melhoria do processo de comunicação entre a organização e os
fornecedores;
Recolhimento de melhores dados que retratam com exatidão as
despesas da organização;
Informação mais fiável para as atividades de negociação e
acompanhamento de gastos;
Consulta das compras efetuadas;
Redução da logística interna no tratamento do material ou serviços
adquiridos;
Processo de aprovação transparente para o requisitante;
Redução de número de notas de encomenda;
Redução significativa das tarefas administrativas da compra;
Redução do ciclo de compras dentro da organização;
Possibilidade de acompanhamento do processo por responsáveis não
intervenientes;
Maior responsabilidade para o requerente;
Os profissionais de compras focalizam-se em tarefas mais estratégicas
para a organização;
Eficiência melhorada na obtenção de tempos reduzidos de ciclo;
Melhorias no cumprimento dos contratos com fornecedores chave;
Compras com as melhores condições negociadas de bens e serviços;
Possibilidade de se realizarem previsões de consumo;
• •
Benefícios Intangíveis
7
Redução dos processos de reconciliação de pagamentos de requisições
de compra;
Redução dos custos administrativos e operacionais;
Redução dos erros de processamento de requisições e respectivas
informações contabilísticas;
Menor risco no investimento.
Mas é claro que também existem dificuldades durante a implantação de um e-
procurement. Entre as desvantagens, podem ser citadas:
Problemas culturais: a introdução do e-procurement pode encontrar
alguma resistência, uma vez que pode ir contra a cultura empresarial.
Em muitas organizações, é dado poder às unidades de negócio locais.
Portanto, um processo de compras centralizado não será bem visto
pelos gestores de negócio, caso os mesmos considerem isso como perda
de poder. Só quando eles tomarem consciência que existirá um retorno
financeiro é que ficarão convencidos que o e-procurement pode
funcionar. É necessário motivar os usuários finais para a adoção do
novo sistema.
Confiabilidade: No caso de um leilão, normalmente as empresas não
têm conhecimento de seus concorrentes. Neste cenário, algumas
empresas imaginam, por exemplo, que a empresa compradora possa
criar um fornecedor virtual para participar do leilão e abaixar os preços
a todo o momento.
Fornecedores: Nem todos os fornecedores podem ter a infra-estrutura
necessária para a utilização do e-procurement, como por exemplo, um
acesso rápido à Internet. Além disso, depois da implantação, é
necessário treinar os fornecedores.
Manutenção: Um software de e-procurement, assim como qualquer
software, exige uma manutenção contínua.
Legislação: Ainda não existem regras muito claras na legislação do
Brasil para as transações realizadas na Internet. Por exemplo, ainda
discute-se a legalidade da assinatura digital. Em caso de não
cumprimento de alguma regra de fornecimento, um processo judicial
8
pode ser bastante desgastante. Ainda recomenda-se a assinatura de
contratos após qualquer transação executada via Internet.
1.3 Casos de Sucesso
A Associação Brasileira de e-business realizou dia 17 de agosto de 2006, no
Hotel Meliá - WTC em São Paulo, o III Fórum Nacional de e-procurement que
reuniu cerca de 300 pessoas de diversos estados, interessadas em conhecer mais
sobre o mercado de compras eletrônicas.
Estiveram presentes profissionais de importantes empresas como Sadia, Pirelli,
Souza Cruz, Hospital Albert Einstein, Volkswagen, bancos Bradesco e Real,
Accor do Brasil, Votorantin e muitas outras, de diferentes setores da economia.
A apresentação da Multibrás mostrou que seu projeto de e-procurement tem
um diferencial, já que utiliza conceitos de supply chain e colaboração logística.
Para compô-lo, a empresa estabeleceu uma relação eletrônica com 100% dos seus
fornecedores de matéria-prima. Nesta comunicação, passou a trocar informações
como previsões de compras, planejamento de coletas, avisos de embarque e
informações de qualidade. Esta iniciativa de colaboração proporcionou à empresa a
possibilidade de suprir muitas de suas necessidades, como reduções nas atividades
administrativas e no inventário de matéria-prima, liberando o tempo dos
especialistas para tarefas com valor agregado (Associação Brasileira de e-business,
2006)
Já a Bunge Fertilizantes mostrou que, após a implantação do e-procurement –
com aplicação de um processo de Strategic Sourcing, a empresa conseguiu reduzir
em dois terços o tempo de compras, aumentando, assim, a produtividade. Além
disso, houve uma redução de custos de 11% em compras e redução de 1,08% no
volume total de compras. A Bunge também obteve um melhor acesso a
informações, histórico de compras, abordagem preventiva com auditoria on-line, e
capacidade de descobrir e inibir fraudes (Associação Brasileira de e-business,
2006).
A Unilever adotou o programa que batizou de Vértice. Implantado no Brasil
em 2003, o projeto segue a tendência do modelo de SRM (Supplier Relationship
Management). Nas unidades da América Latina, houve melhorias de 25% no nível
9
de serviço. Já os índices de rejeição de materiais foram reduzidos em 16%. O
grupo melhorou a interação com os fornecedores, gerando um aumento geral do
comprometimento, além de maior aceitação para processos envolvendo novas
ferramentas eletrônicas. No Brasil, as reduções de custos com pedidos estão
girando em torno de 1% do faturamento da empresa (Associação Brasileira de e-
business, 2006).
Na apresentação da Sabesp, o gerente de departamento, Álvaro Manuel
Mendes, contou como o pregão eletrônico da estatal é hoje modelo em todo o
Estado de São Paulo e também no país. Todos os fornecedores atuam por meio de
licitações que podem ser visualizadas com transparência através do portal da
companhia. Só com o Pregão Sabesp on-line, a empresa já obteve uma economia
de R$ 96 milhões este ano (Associação Brasileira de e-business, 2006).
A Pakprint, empresa de tecnologia fundada em 2001 pelas cinco maiores
empresas de papel e celulose do Brasil, tem como objetivo obter ganhos de escala
e elevar o nível tecnológico do setor, por meio de soluções de e-business
compartilhadas. O sistema de e-procurement com interface Web, desenvolvido e
chamado de e-fornecedores, oferece funcionalidades como cotação, pedido de
compra, folha de registro de serviço, espelho da nota fiscal, espelho do
conhecimento de transporte, demonstrativo de pagamentos aos fornecedores,
avaliação de fornecedores e até antecipação do item contas a pagar para os
fornecedores. ''Quando todo o setor desenvolve robustas soluções de e-business,
todo o segmento tem uma evolução tecnológica, não é só e-commerce'', afirma
Marcelo Cunha Pereira, gerente de negócios da PakPrint. Hoje a Ripasa, Klabin e
Suzano já estão operando no sistema. A International Paper está iniciando sua
inclusão e a Votorantin está em processo de avaliação do sistema. As empresas
que compõem e utilizam o portal conseguiram reduzir em 50% os gastos com
telefone, fax ou papel. Houve também uma economia de 47,5% no tempo gasto
com cotação e de 40% na resposta para a cotação (Joaquim, 2006).
1.4 Problema
Qual software deve ser escolhido para uma empresa, dado que a mesma já se
definiu pela implantação do e-procurement?
10
2 REFERENCIAL TEÓRICO
2.1 Introdução teórica
O ambiente no qual as decisões devem ser tomadas torna-se cada vez mais
complexo e ambíguo devido às inúmeras tarefas envolvidas no processo de tomada
de decisão. Segundo Keeney e Raiffa (1982), a análise de decisão, do ponto de
vista técnico, é uma filosofia articulada por um conjunto de axiomas e
procedimentos sistemáticos que visam analisar responsavelmente a complexidade
inerente a problemas de decisão. Assim sendo, a metodologia de análise
multicritério proporciona uma estrutura eficiente que combina áreas de pesquisa
operacional, administração e análise de sistemas, com julgamentos de valor de
especialistas para auxiliar no processo de tomada de decisão.
Podemos caracterizar as principais etapas do desenvolvimento e do uso de uma
função multiatributo por (Gomes, Araya e Carignano, 2004):
Etapa 1 – Identificar os tomadores de decisão
Etapa 2 – Definir as alternativas
Etapa 3 – Definir os critérios relevantes para o processo de decisão
Etapa 4 – Avaliar as alternativas em relação aos critérios
Etapa 5 – Determinar a importância relativa aos critérios
Cumpre observar, portanto, que o propósito principal da análise de decisão é
auxiliar o decisor a tomar melhores decisões através de um processo interativo de
informações entre analistas e decisores envolvidos no problema.
Antes do aparecimento da análise multicritério, a definição dos problemas de
decisão caracterizava-se, freqüentemente, por um único ponto de vista.
Não obstante, na realidade, a comparação de várias alternativas ou decisões
viáveis é raramente norteada por um único ponto de vista. Assim, a análise
multicritério origina-se como crítica ao modelo racional clássico da teoria de
11
decisão, passando de uma concepção na qual o problema de decisão é
matematicamente bem definido; decisor e critério são únicos e a informação é
perfeita para um enfoque cuja característica reside na pluralidade dos atores e
critérios, bem como na informação imperfeita (Zapata, 1995).
Assim sendo, as teorias de análise multicritério têm sido alvo de inúmeras
pesquisas nas últimas décadas em nível mundial e, como conseqüência, surgiram
várias escolas de decisão multicriterial, cada uma delas propondo um conjunto de
modelos e métodos mais flexíveis e confiáveis baseados numa estrutura forte que
permite a resolução de problemas de decisão com mais de um objetivo, critério ou
atributo.
Os algoritmos multicritério podem ser classificados de acordo com a teoria em
que se baseiam, sendo as escolas Americana e Francesa os dois mais importantes
agrupamentos de métodos analíticos (Gomes, Gomes e Almeida, 2002). Os
métodos da chamada Escola Americana do apoio multicritério à decisão, nos quais
a MAUT acha-se inserida, alicerçam-se na definição de uma função que designa
um valor a cada alternativa, resultado de sua avaliação segundo cada critério. Tais
métodos pressupõem ainda que não exista a incomparabilidade e que existe
transitividade nas relações de preferências e de indiferença entre as alternativas
(Keeney e Raiffa, 1999). Desta forma, os métodos analíticos dessa escola visam à
construção de um critério único de síntese. Destacam-se, dentre eles, a própria
MAUT, introduzida por Keeney e Raiffa (1976), e o Método de Análise
Hierárquica (AHP), que faz uso da construção de uma hierarquia de critérios,
introduzido por Saaty também na década de 70 (Gomes, Araya e Carignano, 2004).
A Escola Francesa do apoio multicritério à decisão, por sua vez, dispõe de métodos
analiticamente mais flexíveis, embora mais carentes de uma fundamentação
axiomática, aceitando a incomparabilidade entre alternativas e a não existência de
transitividade. De uma maneira geral, os métodos da Escola Francesa são
conhecidos como métodos de superação (Gomes, Gomes e Almeida, 2002). Dentre
estes, destacam-se os das famílias Electre e Prométhée (Gomes, Araya e
Carignano, 2004).
12
2.2 Conceitos e definições gerais
Para analisar problemas de decisão envolvendo múltiplos critérios, há
necessidade de definir algumas terminologias usadas com freqüência, tais como
ator, família de critérios, atributo, solução eficiente, entre outras. Esses elementos
são descritos a seguir:
O termo analista refere-se ao cientista, ou técnico que tem como papel
fundamental ajudar o decisor no processo. Ele auxilia o decisor a
expressar suas preferências para tirar conclusões definitivas sobre o
conjunto de ações (alternativas viáveis).
O termo decisor é empregado para referenciar o indivíduo ou grupo de
indivíduos que intervém no processo, influenciando direta ou
indiretamente a decisão através da manifestação das preferências e
julgamentos de valor fornecidos em distintas fases do processo. OBS:
Uma ação é a representação que um decisor constrói para si da solução
de um problema.
Um critério é uma medida base para a efetividade da avaliação, ou seja,
permite estabelecer um julgamento de preferência entre as ações. Os
critérios podem ser metas, alvos ou objetivos almejados.
O conjunto de critérios, usualmente chamado família de critérios F,
deve ser coerente com a definição do problema e mutuamente
exclusivo.
O atributo é uma medida que fornece uma base para avaliar os níveis de
vários objetivos e definir se as metas têm sido atingidas ou não, dada
uma decisão particular.
O conceito de dominância explica uma situação na qual uma ação A é
ao menos tão boa quanto uma ação B para todos os pontos de vista
considerados, e estritamente melhor que B para ao menos um ponto de
vista. Neste caso a ação A domina B.
O conceito de trade-off entre dois critérios refere-se à quantidade
(importância) que o decisor está disposto a conceder sobre um dos
critérios para obter uma unidade do outro critério.
13
A análise multicritério abrange um número bastante significativo de métodos
baseados na construção de um modelo matemático restrito e na informação
levantada dos decisores sobre sua estrutura de preferências.
2.3 Teoria de Utilidade Multiatributo (MAUT)
A teoria da utilidade multiatributo, referida freqüentemente por MAUT (Multi-
Attribute Utility Theory), incorpora à teoria da utilidade a questão do tratamento de
problemas com múltiplos objetivos (Gomes, Gomes e Almeida, 2002).
A noção de utilidade foi descrita por Daniel Benoulli, em 1738, como a
unidade para medir preferências (o autor associou noções como: quanto gostamos
mais de um bem do que de outro; quanto mais temos de algo, menos estamos
dispostos a pagar mais). Em seguida, Jeremy Bentham, em obra publicada em
1789, tratou também dessa noção. Ele ressaltou que a humanidade estaria sob o
governo de dois senhores: a dor e o prazer. Associou à noção de utilidade
“propriedade em qualquer objeto, pela qual ele tende a produzir benefício,
vantagem, prazer, bem ou felicidade” (Gomes, Gomes e Almeida, 2002).
MAUT é a principal abordagem baseada nos resultados para tratar riscos,
desde que Von Neumann e Morgenstern (1947) propuseram um jogo de axiomas
formais para definir o comportamento racional. Nela, um indivíduo escolhe uma
alternativa de um conjunto de possíveis alternativas, a qual maximize o valor
esperado da função utilidade. Esta é definida com base em um conjunto de
resultados para os atributos mais importantes do problema.
Ela também se caracteriza pela definição de uma função de utilidade destinada
a representar as preferências dos decisores em termos de múltiplos atributos,
levando-se sempre em consideração o comportamento racional dos avaliadores.
Assim, a teoria da utilidade permite avaliar essas conseqüências por meio de um
processo de elicitação de preferências que busca incorporar aos problemas as
escolhas do decisor e o seu comportamento em relação ao risco.
Assim, a teoria da utilidade multiatributo implica em primeiro lugar,
representar as preferências do decisor para cada critério ou atributo, por uma
14
função Ui de forma que uma ação A é melhor que uma ação B para cada índice se e
somente se Ui (A) também é melhor do que Ui (b) . Em segundo lugar, essas
funções Ui devem ser agregadas numa única função global U a fim de que o
problema inicial envolvendo múltiplos critérios possa ser substituído por um
problema monocritério.
Desta maneira, a MAUT baseia-se na existência de uma função de valor real U
definida sobre um conjunto de ações potenciais (ou alternativas viáveis) A = {a, b,
c,..... } que o decisor deseja, conscientemente ou não, para examinar o seu
problema de decisão. Assim sendo, a função U representa a preferência global do
decisor após ter sido feita a agregação do conjunto de critérios ou atributos {g1, g2
.... gn}.
O papel do analista é, portanto, auxiliar ao decisor a determinar essa função de
utilidade.
Conseqüentemente, o decisor deve ser capaz de escolher, sem qualquer tipo de
ambigüidade, uma e somente uma dentre as seguintes possibilidades:
a P b: a é estritamente preferida a b,
b P a: b é estritamente preferida a a,
a I b: a é indiferente a b.
A relação binária P (definida em A) deve ser assimétrica e transitiva. Assim
sendo, o conceito de modelagem de preferências é incorporado na função de valor
real U, de forma que o decisor faça sua escolha segundo as seguintes regras:
a P b <=> U(a) P U(b)
b P a <=> U(b) P U(a)
a I b <=> U(a) I U(b)
Para definir uma função U, como bem aponta Roy (1990), é importante que se
deva diferenciar se o tipo de problema corresponde a um caso determinístico ou a
um caso probabilístico. Quando os resultados não envolvem algum grau de risco, o
15
problema de decisão pode ser abordado através de uma função de valor. Mas, se
envolve algum risco, pode então ser utilizada uma função de utilidade mediante o
cálculo de uma utilidade esperada. Contudo, as formas analíticas das funções de
agregação podem ser de caráter aditivo, multiplicativo ou constituir-se ainda de
modelos mais complexos.
O caso determinístico corresponde a uma estrutura de modelagem onde existe
clareza na definição e operacionalização dos atributos, ou seja, para cada
alternativa corresponde somente um atributo (ou conseqüência) com o seu
respectivo valor bem conhecido (Roy, 1901).
O caso probabilístico corresponde a outra estrutura de modelagem na qual os
atributos (ao menos um) são vistos como variáveis aleatórias. Por isso, procura-se
uma função de utilidade sobre os n atributos, com o objetivo de que o valor da
utilidade esperada represente a ordem de preferências do decisor para as
alternativas em questão.
Naturalmente, essa função de utilidade deve refletir a atitude do decisor
perante o risco e, por isso, não deve ser confundida com a função de valor. Neste
caso, a teoria da utilidade assume que o valor de uma dada alternativa a para um
ponto de vista é dado pelo valor esperado de Gi:
Valor esperado de Gi = Ui (a) =∑=
n
i
xPa1
( i) Gi (xi)
Sendo:
Pa(xi) = probabilidade de ocorrência da conseqüência xi dado que a alternativa a é escolhida.
Gi(xi) = valor do atributo para a conseqüência xi.
Neumann e Morgenstern (1947) desenvolveram axiomas bem conhecidos para
poder interpretar as preferências dos decisores e, a partir deles, construir uma
função de probabilidade que permita auxiliar a tomada de decisão. Mas, deve ficar
claramente estabelecido que a interpretação desses axiomas depende da natureza
16
da abordagem e das características do problema analisado. Segundo Vincke
(1985), duas abordagens são reconhecidas na literatura: a preditiva e a prescritiva.
Na abordagem preditiva, as suposições da teoria da utilidade devem
representar as preferências do decisor de forma que o modelo seja capaz de
antecipar sua atitude. Já na abordagem prescritiva, as suposições da teoria da
utilidade devem definir o que é uma atitude racional para o decisor, de forma que o
modelo seja um guia para o decisor.
Uma idéia subjacente à teoria da utilidade multiatributo diz respeito à
propriedade da independência preferencial. Esta propriedade implica que as
preferências do decisor possam ser representadas por uma função aditiva definida
assim:
U(g1,g2,gn)=U(gi)+ U(g2)+U(gn)
A forma aditiva da função utilidade implica que cada subconjunto de pontos de
vista ou atributos deva ser preferencialmente independente no conjunto de todos os
pontos de vista. Portanto, antes de pressupor uma forma aditiva de valor, deve ser
testado se, pelo menos, a independência mútua de preferência se verificar
aproximadamente.
Quanto à agregação da utilidade global, deve ser destacada a existência de um
conjunto de regras agrupadas em duas categorias: as regras compensatórias e as
não compensatórias. O primeiro caso está relacionado com aquele conceito da taxa
marginal de substituição ou trade-off. Ou seja, desde que exista uma função U que
permita agregar os critérios {g1, g2,..... gn}, deve também existir funções para
mensurar a quantidade que o decisor está disposto a ceder de algum critério para
obter uma unidade de um outro critério. Desta forma, a possível desvantagem em
relação a um critério pode ser compensada com a vantagem de outro ou outros
critérios. Portanto, tendo-se as taxas de substituição em alguns pontos, pode-se
construir curvas de utilidade ou de indiferença que servirão de auxílio para se
decidir pela preferência entre critérios.
17
O segundo caso tem como objetivo verificar se o conjunto de critérios sobre os
quais um critério é preferido a outro, por exemplo, a P b, é mais importante que o
subconjunto de critérios sobre os quais a situação é contrária b P a. Desta forma, a
diferenciação e especificação da importância relativa dos critérios é seu ponto
central.
Contudo, ambas as situações combinam-se para mostrar o grau de participação
ou contribuição dessa alternativa no objetivo do problema. A forma mais usual de
agregação corresponde a uma combinação linear dessas funções. No entanto,
existem outras formas muito mais complexas de cálculo obtidas como resultado de
um conjunto de experiências e de processos teóricos.
2.4 Atribuição de Pesos – Teoria
Após a fase de estruturação do problema, constrói-se um modelo de
preferências, a fim de se representar quantitativamente as preferências e
julgamentos de valores do decisor.
As escalas de medida utilizadas devem fornecer meios para mensurar o
desempenho das alternativas em relação a cada critério. Segundo Belton e Stewart
(2002), uma escala pode ser local ou global. Define-se a escala local pelo grupo de
alternativas disponíveis, sendo atribuído valor 100 à melhor alternativa e 0 à pior.
Às demais alternativas são atribuídos valores entre os pontos de referência 0 e 100.
Já na escala global, leva-se em consideração alternativas que não estão sendo
avaliadas. Ou seja, os pontos de referências são a melhor e a pior alternativa que
poderiam ocorrer, independentemente do fato destas alternativas estarem ou não
sob avaliação.
Para Clemen e Reilly (2001), pode-se usar o procedimento de classificar as
alternativas entre 0 e 100, de acordo com as preferências do agente decisão, para
fornecer uma mensuração que tenha significado lógico, a partir de qualquer escala
de atributos. A medida de desempenho de cada alternativa – denominada
informação intracritério – pode ser alcançada de várias formas. Belton e Stewart
(2002) dividem essas formas em três grupos possíveis: definição de uma função
parcial de valor, construção de uma escala de valor qualitativa e valoração direta
das alternativas. Por sua vez, o peso de um critério representa sua importância
18
relativa aos demais critérios considerados para avaliação das alternativas – nisto
consiste a chamada informação intercritério. Tal importância é influenciada, entre
outros motivos, pelas preferências pessoais dos agentes de decisão. Segundo
Clemen e Reilly (2001), este é o problema essencial de qualquer tomada de decisão
com objetivos múltiplos, ou seja, como optar pelas compensações (trade-offs)
ideais entre um objetivo e outro. É exatamente neste momento que o decisor deve,
a partir de seu próprio julgamento, confrontar os diferentes critérios, definindo
limites de perdas para os demais ao optar por um critério específico. O resultado
desta avaliação é a ordenação de todos os critérios, de acordo com sua importância.
Para efetuar-se tal avaliação existem técnicas que servem para que o decisor
traduza seus próprios julgamentos de valor em uma informação objetiva. Segundo
Gomes, Gomes e Almeida (2002), as seis principais técnicas de atribuição de pesos
aos critérios são: SMART (Simple Multi-Attribute Rating Technique); Métodos
Ordinais; AHP (Analytic Hierarchy Process); Atribuição Direta de Peso ou
Pontuação Direta (Direct Rating); Swing Weighting; e Trade-off Weighting. O
procedimento adotado nesta dissertação foi o Swing Weighting (Von Winterfeldt e
Edwards, 1986). Usando esta técnica, o decisor expressa suas preferências com
relação aos critérios, imaginando mudanças da pior para a melhor alternativa em
cada critério, partindo da pior hipótese possível, na qual todos os critérios obtêm a
pior classificação. Descreve-se na seção seguinte a aplicação da metodologia ao
caso estudado (Castanhar, 2004).
3 A ESCOLHA
Para o desenvolvimento da pesquisa descrita neste artigo, optou-se pela
MAUT, uma vez que a mesma permite fazer-se uma avaliação mais profunda sobre
as trocas ou compensações (trade-offs) que o decisor deveria estabelecer entre os
critérios conflitantes de seu problema de decisão (Keeney e Raiffa, 1999). O foco
dessa abordagem é a modelagem das preferências do decisor. Segundo Belton e
Stewart (2002), a intenção deste método analítico é a associação de um valor a
cada alternativa, produzindo-se uma ordem de preferência entre as alternativas de
modo consistente com os julgamentos de valor do decisor. O modelo da MAUT
consiste assim em calcular-se uma utilidade, expressa por uma nota ou pontuação,
19
para cada objetivo (ou critério) e depois somar-se essas utilidades, em particular no
caso em que se emprega a modelagem pela função de utilidade aditiva,
ponderando-se apropriadamente os critérios, de acordo com suas importâncias
relativas aos demais, segundo descrevem Clemen e Reilly (2001).
Por conseguinte, o pressuposto básico da modelagem pela MAUT é de que
existe uma função de utilidade individual para cada um dos diferentes critérios. Por
sua vez, a função de utilidade aditiva é a agregação, por adição, de um caso
particular de tal função, consistindo em uma média ponderada das utilidades
individuais, conforme explicado por Clemen e Reilly (2001), Gomes, Araya e
Carignano (2004) e Keeney e Raiffa (1999), dentre outros autores. Para o uso
adequado de tal função aditiva, assume-se ainda que o domínio comum das
funções individuais encontra-se na mesma escala, de 0 a 1 (Castanhar, 2004).
A ordem de preferência resultante do uso da função de utilidade implica,
entretanto, na observância de algumas condições técnicas. Além disto, as
preferências modeladas por essa função matemática são sempre completas, isto é,
para cada par de alternativas, uma delas é estritamente preferível à outra ou são
indiferentes; ou seja, o emprego da MAUT não permite a incomparabilidade entre
alternativas. E, ainda, preferências e indiferenças são transitivas. Isto implica que,
para três alternativas A, B e C, se A é preferível a B, e B é preferível a C, então A é
preferível a C. Estas duas condições constituem dois axiomas fundamentais da
MAUT, o da ordenabilidade e o da transitividade.
Para que a função de utilidade aditiva possa ser usada como instrumental de
avaliação, é necessário ainda que os critérios de decisão satisfaçam a condição de
independência. Segundo Belton e Stewart (2002), isso significa que a compensação
entre quaisquer dois critérios que o tomador de decisão esteja disposto a aceitar
não depende de qualquer outro critério. Essa condição implica que a ordenação de
preferência em termos de um critério, admitindo-se que os níveis de desempenho
de outros critérios são fixos, não deve depender de quais são os níveis de
desempenho dos demais critérios. Keeney e Raiffa (1999) sugerem um modelo de
diálogo que o analista deve ter com o decisor para determinar se a condição de
independência é satisfeita ou não. Caso seja constatada dependência entre qualquer
par de critérios, recomenda-se que a família de critérios seja repensada e
20
transformada eventualmente através de agrupamentos ou, mesmo, de redefinições,
segundo Clemen e Reilly (2001). É necessário, no entanto, certificar-se de que os
novos critérios refletem todos os aspectos do problema e sejam mensuráveis.
Segundo Belton e Stewart (2002), depois que se obtêm os primeiros resultados
calculados pela MAUT, é necessário realizar-se uma análise de sensibilidade, com
o intuito de verificar se as conclusões preliminares são suficientemente robustas,
ou se são muito sensíveis a determinadas mudanças em variáveis do modelo. Tais
mudanças devem ser conduzidas com o intuito de verificar o impacto de uma
possível falta de informação ou, mesmo, de até fornecer uma perspectiva diferente
ao problema. Ainda segundo esses dois autores, do ponto de vista técnico, a análise
de sensibilidade visa determinar se algum parâmetro exerce influência crítica na
avaliação geral do modelo, ou seja, se uma pequena mudança em um peso ou
desempenho das alternativas em um critério pode provocar uma nova ordem de
preferências. Já do ponto de vista individual, a análise multicritério realizada
através da MAUT fornece embasamento para o analista ou decisor testarem sua
intuição sobre a avaliação particular do problema (Castanhar, 2004).
4 METODOLOGIA DE ÁNALISE
4.1 Método
O método a ser utilizado foi a aplicação de teoria MAUT, restrito a uma única
empresa.
Inicialmente, foram realizadas entrevistas com o departamento de compras e
tecnologia da informação da empresa para identificação do cenário da empresa.
Durante essas reuniões, foi identificado o nível de conhecimento da empresa sobre
a solução de e-procurement, possíveis problemas culturais em relação à solução, o
volume de fornecedores, se estes fornecedores estavam preparados para uma
solução via Internet, o volume de requisições, solicitações, pedidos de compras e
leilões de compras, necessidades de relatórios, identificação de outros sistemas,
necessidades de integração com ERP (Enterprise Resources Process) e com
marketplaces, existência de desenvolvedores internos, possibilidade de
investimento em servidores, entre outros pontos. Também foi necessário o uso da
observação direta com o intuito de obter-se uma melhor compreensão de todos os
21
processos da empresa, de seu cotidiano, bem como do contexto no qual ela se
insere.
Com essas entrevistas e com a ajuda de um decisor, foram desenhados os
critérios e sub-critérios relevantes para a empresa em questão. Essas entrevistas
também foram muito úteis para a identificação dos fornecedores que deveriam
participar da seleção.
Os seguintes critérios e sub-critérios foram definidos:
Empresa Implementação / Suporte Relacionamento com o Mercado Financeiro Viabilidade e Referências Proposta Financeira Processo Geral Requisição Aprovação - Workflow Pedido Recebimento Pagamento Requerimentos Técnicos Segurança Arquitetura Usuário Arquitetura Servidor Performance Banco de Dados Rede Interfaces Interfaces Conexão com Marktplace Módulos específicos Viagens e Despesas Relatórios Relatórios Queries Interface com Usuário Amigável Escalável Miscelânea Conteúdo Gerenciamento do conteúdo
Tabela 1 – Critérios e Sub-Critérios
22
Para cada um destes critérios e sub-critérios foram criadas diversas questões
para serem enviadas aos fornecedores escolhidos. O documento enviado aos
fornecedores foi chamado de RFI (Request for Information).
Enquanto os fornecedores respondiam ao RFI, continuamos trabalhando com o
cliente para atribuir pesos às questões, aos critérios e sub-critérios. Para isto,
utilizamos à técnica do Swing Weighting explicada em detalhe mais abaixo.
Após o recebimento das respostas, foi realizada a análise das mesmas e em
alguns casos foi identificada a necessidade de esclarecimentos adicionais. Para
esses casos, foi necessário o envio de um novo questionamento para o fornecedor e
a realização de algumas reuniões para verificar detalhes adicionais e
funcionalidades específicas da solução proposta.
Enfim, como já dito, para considerar as diferenças de desempenho das
empresas na definição dos pesos em cada atributo, foi utilizado o Swing Weighting.
4.2 Atribuição de Pesos
Para a atribuição de pesos foi utilizada a técnica do Swing Weighting. Esta
técnica exige que se estabeleça um processo interativo com o decisor para que os
pesos de todos os critérios, sub-critérios e questões sejam determinados. Ela
funciona da seguinte maneira: primeiramente defini-se uma situação hipotética,
caracterizada como sendo a pior hipótese possível (benchmark), onde todos os
critérios/sub-critérios tenham a pior avaliação possível. Por exemplo, para o
critério Empresa caracterizamos como benchmark a hipótese do fornecedor em
questão não ter um bom relacionamento com o mercado (sub-critério) e não ter
muita experiência em implantações/suporte de e-procurement (sub-critério). É
importante ressaltar que só foi considerada a capacidade desses fornecedores no
que diz respeito ao serviço de e-procurement. Depois da definição do pior cenário,
perguntamos ao decisor qual destes dois sub-critérios ele escolheria, caso somente
um deles pudesse ser melhorado. A resposta dele foi que a implantação/suporte de
e-procurement tinha uma maior relevância para o seu processo do que o
relacionamento com o mercado. Como para o critério Empresa só tínhamos 2 sub-
critérios, obviamente o segundo sub-critério escolhido foi relacionamento com o
mercado. Para podermos finalizar a atribuição de pesos deste critério, foi feita ao
decisor a seguinte pergunta: se a implantação/suporte de e-procurement tem um
23
peso de 100, qual o peso atribuído ao relacionamento com o mercado? A resposta
foi 30. Com isso, definiu-se a nota 0 para o benchmark, 100 para
implantação/suporte de e-procurement e 30 para relacionamento com o mercado. O
peso foi obtido dividindo-se a nota pela a soma total de todas as notas, obtendo-se
os resultados mostrados na tabela 2.
Empresa Ranking Nota Peso Pior Hipótese (Benchmark) 3 0 0 Implementação / Suporte 1 100 0.769231 Relacionamento com o Mercado 2 30 0.230769
Tabela 2 – Nota e Peso dos sub-critérios do critério Empresa.
Esta técnica foi usada sucessivamente, repetindo-se a pergunta ao decisor para
todos os critérios e sub-critérios, conforme ilustrado nas tabelas 3 a 10.
Financeiro Ranking Nota Peso Pior Hipótese 3 0 0 Viabilidade e Referências 1 100 0.625 Proposta Financeira 2 60 0.375 Tabela 3 – Nota e Peso dos sub-critérios do critério Financeiro.
Processo Ranking Nota Peso Pior Hipótese 7 0 0 Geral 6 30 0.068493 Requisição 1 100 0.228311 Aprovação – Workflow 2 98 0.223744 Pedido 4 70 0.159817 Recebimento 5 60 0.136986 Pagamento 3 80 0.182648
Tabela 4 – Nota e Peso dos sub-critérios do critério Processo.
Requerimentos Técnicos Ranking Nota Peso Pior Hipótese 7 0 0 Segurança 1 100 0.228311 Arquitetura Usuário 2 98 0.223744 Arquitetura Servidor 3 95 0.216895 Performance 4 60 0.136986 Banco de Dados 5 55 0.125571 Rede 6 30 0.068493
Tabela 5 – Nota e Peso dos sub-critérios do critério Requerimentos Técnicos.
24
Interfaces Ranking Nota Peso Pior Cenário 5 0 0 Interfaces 1 100 0.309598 Conexão com Marktplace 2 98 0.303406 Módulos específicos 3 75 0.232198 Viagens e Despesas 4 50 0.154799
Tabela 6 – Nota e Peso dos sub-critérios do critério Interface.
Relatórios Ranking Nota Peso Pior Cenário 3 0 0 Relatórios 2 88 0.468085 Queries 1 100 0.531915 Tabela 7 – Nota e Peso dos sub-critérios do critério Relatórios.
Interface com Usuário Ranking Nota Peso Pior Cenário 4 0 0 Amigável 2 60 0.285714 Escalável 3 50 0.238095 Miscelânea 1 100 0.47619
Tabela 8 – Nota e Peso dos sub-critérios do critério Interface com Usuário.
Conteúdo Ranking Nota Peso Pior Cenário 2 0 0 Gerenciamento do conteúdo 1 100 1 Tabela 9 – Nota e Peso dos sub-critérios do critério Conteúdo.
Critérios Ranking Nota Peso Pior Hipótese 9 0 0 Processo 3 50 0.141243 Conteúdo 8 9 0.025424 Interface com Usuário 7 10 0.028249 Relatórios 6 25 0.070621 Interfaces 5 40 0.112994 Requerimentos Técnicos 4 45 0.127119 Empresa 1 100 0.282486 Financeiro 2 75 0.211864
Tabela 10 - Nota e Peso de todos os critérios.
25
4.3 Tratamento dos dados
Nessa fase, como explicado na seção referente ao do método, foi necessário
analisar, comparar e avaliar todas as respostas emitidas pelos fornecedores,
identificando-se as necessidades de esclarecimentos adicionais sobre as respostas
recebidas, e de envio de um novo questionamento para o fornecedor. Em alguns
casos, foi necessária a realização de reuniões com os fornecedores para verificar
detalhes adicionais e funcionalidades específicas da solução proposta.
Assim como todos os critérios e sub-critérios, todas as perguntas enviadas aos
fornecedores tiveram um peso atribuído pelos decisores. Após a análise das
respostas, cada questão recebeu uma nota entre 0 e 1 (onde 0 é a pior nota). Esta
nota foi multiplicada pelo peso da questão e então somou-se todas as notas
pertencentes ao mesmo sub-critério (valores em vermelho abaixo). Veja exemplo
das notas recebidas pela Oracle, no critério Relatórios (OBS: As perguntas estão
em inglês, pois algumas delas foram respondidas por profissionais fora do Brasil):
26
Critério Relatórios Peso Nota
Sub-critério Relatórios 100% 73% 4.1.1 - Does the system provide pre-defined reports? 5% 1 5%
4.1.1.1 - Can they be customized, and is source code available to do so? 8% 1 8%
4.1.2 - Does the application provide an “ad-hoc” reporting tool to allow individualized custom reports? 8% 1 8%
4.1.2.1 - Can the user define unique custom reports? 9% 1 9%
4.1.3 - Can “ad-hoc” reports be built from
4.1.3.1 - requisition data? 3% 0.5 2%
4.1.3.2 - approval workflow data? 3% 0.5 2%
4.1.3.3 - PO data? 9% 0.5 5%
4.1.3.4 - receiving data? 9% 0.5 5%
4.1.3.5 - P-card data? 6% 0.5 3%
4.1.3.6 - T&E data? 6% 0.5 3%
4.1.4 - Does the reporting tool support the following output:
4.1.4.1 - saved to a file? 3% 1 3% 4.1.4.2 - displayed on the screen? 3% 1 3% 4.1.4.3 - sent to a printer? 8% 1 8%
4.1.5 - Does the system allow use of a bolt-on reporting tool? 8%
4.1.5 - Does the system allow consolidated reports? 11% 1 11% Sub-critério - Queries 100% Note 81% 4.2.1 - Does the system provide query functions? 16% 1 16% 4.2.2 - Can the query be saved? 14% 4.2.2.1 - Can queries be organized hierarchically? 5% 4.2.3 - Can queries be built from: 4.2.3.1 - requisition data? 5% 1 5% 4.2.3.2 - approval workflow data? 5% 1 5% 4.2.3.3 - PO data? 16% 1 16% 4.2.3.4 - receiving data? 16% 1 16% 4.2.3.5 - P-card data? 11% 1 11% 4.2.3.6 - T&E data? 11% 1 11%
Tabela 11 – Notas das questões recebidas pela Oracle
Com esta metodologia, cada sub-critério recebeu um valor (73% e 81% no
exemplo acima) que multiplicado pelo seu peso, definido pelo decisor, (0.468085 e
27
0.531915, respectivamente no exemplo) forneceu a nota final do sub-critério para
cada fornecedor. Observa-se na tabela 12 as notas dos dois sub-critérios do critério
Relatórios.
Relatórios Oracle RightWork SAP Ariba Relatórios 0.34375 0.4022606 0.234043 0.468085 Queries 0.431282 0.5031627 0.265957 0.531915 0.775032 0.9054234 0.5 1
Tabela 12 – Notas dos sub-critérios do critério Relatórios
As somas de todas as notas finais de um sub-critério (0.775032 para o critério
Relatórios e fornecedor Oracle, no exemplo acima) multiplicadas pelo peso do
critério, definido pelo decisor, (0.070621 para o exemplo) forneceram a nota final
do critério. Nesse caso, o resultado foi 0.054734 (em vermelho) para o critério
Relatórios e fornecedor Oracle.
Oracle RightWork SAP Ariba
Empresa 0.091575 0.0962315 0.251443 0.140467 Financeiro 0.089337 0.0790479 0.162223 0.154857 Processo 0.11556 0.1004242 0.097286 0.120241 Requerimentos Técnicos 0.108332 0.104264 0.095852 0.108939 Interfaces 0.067219 0.0526095 0.052505 0.073236 Relatórios 0.054734 0.0639423 0.035311 0.070621 Interface com Usuário 0.016049 0.0239108 0.018237 0.023218 Conteúdo 0.017158 0.0233716 0.020065 0.024113 56% 54% 73% 72%
Tabela 13 – Notas dos sub-critérios do critério Relatórios
A soma de todas as notas finais de um fornecedor indicou seu posicionamento
para a empresa em questão. Nesse caso, a Oracle obteve 56%.
Com a aplicação desta metodologia para todas as questões, critérios e sub-
critérios, tivemos a posição de todos os fornecedores para a empresa.
Segue o resultado gráfico do posicionamento dos fornecedores:
28
Comparação Fornecedores - e-procurement
0%
20%
40%
60%
80%
100%Processo
Conteúdo
Interface com Usuário
Reportes
Interfaces
Requerimentos Técnicos
Empresa
Financeiro
SAP-EBPRightworksAribaOracle-iprocurement
Note : - A avaliação da empresa é feita somente em relação a capacidade dos softwares de e-procurement.
Figura 3 – Resultado gráfico final
4.4 Análise de sensibilidade
Durante a realização desta pesquisa aconteceu um fato inédito no Brasil. A
empresa Ariba fechou todos os seus escritórios no Brasil e o critério Empresa, que
era apontado como o mais relevante para nosso decisor, fez com que a Ariba, que
estava em primeiro lugar, fosse ultrapassada pela SAP apesar da primeira ter um
produto muito mais consistente na época. Essa decisão foi de fato aplicada e o EBP
(Enterprise Buyer Professional) produto da SAP na época foi implantado.
Abaixo, é apresentada a análise de sensibilidade com algumas simulações,
alterando-se principalmente os pesos dos critérios:
Analisando os pontos obtidos pelas empresas em questão, foi verificado
que a SAP é muito forte no critério Empresa e este critério foi apontado
como o mais importante para o decisor. Foi simulada uma troca de
pesos entre os critérios 1 (Empresa) e 2 (Financeiro). Apenas com esta
troca, a Ariba volta a ultrapassar a SAP.
Outro ponto em que a SAP é mais fraca que todos os outros
fornecedores é no critério de Processo. Alterando o critério Processo
para o segundo mais importante e colocando-o com um peso de 80%, a
29
Ariba empata com a SAP e os percentuais da Oracle e da RightWork
melhoram consideravelmente.
Mantendo-se a alteração anterior e estabelecendo-se o critério Empresa
como último critério com peso de 8, a Ariba dispara na frente da SAP
(80 X 68) e a Oracle praticamente empata com a SAP.
Em geral, na época em questão, a Ariba realmente tinha um produto bastante
vantajoso e quase todas as simulações fazem com que a Ariba ganhe de todos os
outros fornecedores.
4.5 Conclusão
Apesar do e-mail e do fax ainda serem os principais meios de comunicação
utilizados pelas empresas para se comunicarem com seus fornecedores, existe uma
previsão bastante otimista para o ano de 2006 e os anos subseqüentes com relação
ao uso de outras formas de comunicação. Como mostrado, dezoito por cento das
empresas pretendem aumentar suas transações eletrônicas em mais de 51%, o que
representa o dobro em relação a 2005. O crescimento do uso dos pedidos
eletrônicos em relação a 2004 foi de 14,9%, e a projeção de aumento para 2006 é
de 22,9% (Associação Brasileira de e-business, 2005).
Com este crescimento na utilização de softwares de e-procurement, as
empresas vão necessitar cada vez mais de ajuda na escolha do melhor software a
ser implantado. Esta dissertação mostrou uma metodologia que pode ser utilizada
por qualquer empresa sem grandes dificuldades.
A aplicação da metodologia foi bastante simples, mas exigiu o
comprometimento total dos decisores, principalmente na fase de atribuição dos
pesos.
Obviamente, as variáveis envolvidas em uma análise multicritério, como a que
foi conduzida nesta pesquisa, devem mudar de acordo com a empresa e produto em
questão. No entanto, a forma de estruturar o problema e conduzir o levantamento
de dados será basicamente a mesma. Nesse sentido, a realização desta pesquisa foi
capaz de gerar um modelo inicial que pode ser seguido por outras empresas,
levando-se em conta eventuais adaptações necessárias. A aplicação desse modelo à
empresa utilizada como objeto do estudo mostrou os resultados que podem ser
obtidos com o uso de uma metodologia analítica como suporte do processo
30
decisório. O resultado final do estudo proporcionou segurança à empresa quanto à
oportunidade que lhe era apresentada: a de escolher o melhor software de e-
procurement para a sua empresa.
Como podemos verificar pelos resultados e pela análise de sensibilidade, o
principal objetivo da utilização da MAUT não é fornecer uma solução única e sim
apoiar o decisor ao longo de todo o processo decisório. O estudo em questão
mostrou como é possível ajudar as empresas a escolher, de forma estruturada, o
melhor software de e-procurement para a sua empresa. Também foi mostrada a
importância do decisor neste processo. Uma decisão diferente sobre algum critério
ou seu peso pode levar a uma escolha totalmente diferente. Na impossibilidade de
eliminar a subjetividade, ao explicitá-la através da modelagem do problema,
garantiu-se maior transparência ao processo de decisão, o que é típico de
aplicações dessa metodologia analítica (Belton e Stewart, 2002; Gomes, Gomes e
Almeida, 2002; Gomes, Araya e Carignano, 2004). Apesar da empresa SAP ter
sido indicada como o software mais apropriado na época para a empresa em
questão, a Ariba também tinha um produto bastante vantajoso. O problema foi o
fato de seu único escritório ter sido fechado no Brasil, o que foi totalmente
indicativo para os decisores.
Apesar do estudo ter como foco os softwares de e-procurement, toda a
metodologia aplicada poderia ter sido utilizada para a escolha de qualquer software
em questão.
4.6 Pesquisas futuras
Outras dissertações anteriormente desenvolvidas no IBMEC RJ, como a de
Daniela Castanhar em 2004, a do Mario Lott em 2005 e a do Fabio Castro em
2006, serviram como base para o desenvolvimento deste estudo e, com certeza, a
dissertação aqui apresentada servirá para que outros mestrandos iniciem os seus
trabalhos.
Para pesquisas futuras nessa área, primeiramente, seria bastante interessante
atualizá-la com os fornecedores e produtos atuais. Como já mencionado
anteriormente, esta pesquisa foi realizada em 2003 e o mercado de e-procurement
em 2006 ainda está em franco desenvolvimento. Alguns fornecedores mudaram e
31
os produtos se desenvolveram bastante. A SAP, gigante alemã de ERP, possui hoje
84% de Market-Share no mercado de corporações (Alba Spectrum, 2006) e isso
coloca a SAP em bastante vantagem competitiva no mercado de e-procurement. É
óbvio que essa vantagem depende dos critérios e pesos definidos pelos decisores,
já que existem softwares de e-procurement de outros fornecedores com
conectividade com o SAP R/3, mas a compatibilidade do SAP com o software de
e-procurement da mesma empresa é nata.
Esta mesma metodologia também poderia ser aplicada para escolha de outros
softwares, como por exemplo, um ERP. Os resultados desse novo trabalho
indicariam quais as facilidades e dificuldades da aplicação desta metodologia para
cada tipo de software.
Também seria bastante interessante incluir, em uma nova análise, a
possibilidade de desenvolvimento de um software de e-procurement interno que
atendesse às necessidades da empresa. Várias empresas, como a Pirelli Cabos e
Pneus, apesar de terem o SAP como o ERP, optaram por desenvolver seu próprio
software de e-procurement. Este desenvolvimento foi feito em linguagem de
programação asp e é totalmente integrado ao SAP R/3. O sucesso do software
desenvolvido na Pirelli foi tão grande que o sistema foi implantado em várias
subsidiárias do grupo, em toda a América Latina. O servidor de e-procurement
ficou, no Brasil, conectado aos servidores SAP R/3 de todos os países da América
Latina. A vantagem do desenvolvimento interno é a construção totalmente voltada
para as necessidades da empresa e a flexibilidade nas mudanças. Os softwares de
empresas como a SAP possuem bastantes limitações para mudanças nas
funcionalidades padrões.
Outras metodologias também poderiam ser utilizadas para a escolha de
sofwtares de e-procurement, como, por exemplo, AHP (Analytic Hierarchy
Process), gerando um comparativo com as vantagens e desvantagens de cada
metodologia.
32
REFERÊNCIAS BIBLIOGRÁFICAS
Alba Spectrum, Brasil: SAP BO – Um obstáculo para os ERPs “estrangeiros” Alba
Spectrum . 2006. Disponível em: < http://www.albaspectrum.com/PressReleases/POR-
Brasil-SBO-ERP-Estrangeiros-Press-Release.htm > Acesso em: Setembro, 2006.
Associação Brasileira de e-business. Segunda edição da pesquisa sobre o cenário do e-
procurement no Brasil. Novembro, 2005. Disponível em: <
http://www2.uol.com.br/canalexecutivo/notas05/111120056.htm > Acesso em: Setembro,
2006.
Associação Brasileira de e-business. III Fórum Internacional de e-procurement. -
cenário do e-procurement no Brasil. Agosto, 2006. Disponível em: <
http://www.ebusinessbrasil.com.br/eprocurement2006/temario.htm > Acesso em:
Novembro, 2006.
BEAL, Adriana. Business Case: Um bom ponto de partida para projetos de T.I.
Setembro, 2001. Disponível em: < http://www.vydia.com.br/vydia/tecno08.html > Acesso
em: Agosto, 2006.
BELTON, Valerie; STEWART, Theodor J. Multiple criteria decision analysis: an
integrated approach. Boston: Kluwer Academic Press, 2002.
CASTANHAR, Daniela. Análise de estratégias para exportação: um estudo de caso
em microempresa, Rio de Janeiro, 2004. Dissertação (Mestrado em Administração) -
IBMEC RJ.
CASTRO, Fabio Wellish. Implementação de estratégias de realização de Leilão
Reverso: estudo de caso em empresa do segmento industrial, Rio de Janeiro, 2006.
Dissertação (mestrado em administração) – IBMEC RJ.
CLEMEN, Robert T.; REILLY, Terence. Making Hard Decisions: An Introduction to
Decision Analisys. Pacific Grove: Duxbury, 2001.
33
COOPER, M. C.; LAMBERT, D. M.; PAGH, J. D. Supply chain management: more
than a new name for logistics. The International Journal of Logistics Management, v. 8,
n. 1, 1997.
Deloitte Consulting Brasil. E-Procurement: Tendências, Desafios e Melhores Práticas.
2001.
GOMES, Luiz Flavio Autran Monteiro; ARAYA, Marcela Cecília González;
CARIGNANO, Claudia. Tomada de decisões em cenários complexos: introdução aos
métodos discretos do apoio multicritério à decisão. São Paulo: Pioneira Thomson
Learning, 2004.
GOMES, Luiz Flavio Autran Monteiro; GOMES, Carlos Francisco Simões; ALMEIDA,
Adiel Teixeira de. Tomada de decisão gerencial: enfoque multicritério. São Paulo:
Atlas, 2002.
JOAQUIM, Patrícia. B2B Magazine. Tecnologia no B2B. Setembro, 2006. Disponível
em: < http://www.b2bmagazine.com.br/ler_materia.aspx?numero=17245> Acesso em:
Novembro, 2006.
KEENEY, Ralph L.; RAIFFA, Howard. Decisions with multiple objectives: preferences
and value tradeoffs. Cambridge: Cambridge University Press, 1999.
PACHECO, Mario Henrique Lott. Compra eletrônica: estudo de caso de Leilão
Reverso Empresarial, Rio de Janeiro, 2005. Dissertação (Mestrado em Administração) –
IBMEC RJ.
PINTO, Andréia; APOLINÁRIO, Eduardo; PIRES, João Paulo; RODRIGUES, Magda;
MAGALHÃES, Magda. Gestão de Aprovisionamento. 2004. . Disponível em: <
http://pwp.netcabo.pt/0440369301/gestao_web/5sem/ga/eprocurement.htm > Acesso em:
Agosto, 2006.
TEIXEIRA, Flávia Silva. Verificação do entendimento e da utilização do e-
procurement em duas empresas globalizadas, Taubaté, 2003. Monografia (MBA em
Gerência Financeira) – Universidade de Taubaté.
34
TOMPKINS, A.. E-Procurement. 1 ed. Califórnia: Tompkins Associates Monograph
Series, 2001.
ZAPATA, Juan Carlos. Modelo híbrido para estimativa de parâmetros de referência
como suporte à avaliação social de projetos, Florianópolis, 1995. Dissertação (Mestrado
em engenharia de produção) - Universidade Federal de Santa Catarina.
35
APÊNDICE
RFI aplicada na escolha de um software de e-procurement:
Category Number Requirements
1 Process 1.1 Process - General
1.1.1 1.1.1 - Does the system allow to track requisitions by 1.1.1.1 1.1.1.1 - status? 1.1.1.2 1.1.1.2 - viewing the audit trail/log? 1.1.1.3 1.1.1.3 - viewing the approval workflow? 1.1.2 1.1.2 - Does the system 1.1.2.1 1.1.2.1 - support GL (General Ledger) account data entry at the
requisition level? 1.1.2.2 1.1.2.2 - support GL account data entry at the requisition line level? 1.1.2.3 1.1.2.3 - pass GL account data at each level of the process? 1.1.3 1.1.3 - Does the system default GL account data by requisitioner? 1.1.4 1.1.4 - Does the system
1.1.4.1 1.1.4.1 - support Oracle 7.4 / SAP 4.6 / People Soft project accounting data entry at the requisition level?
1.1.4.2 1.1.4.2 - support Oracle 7.4 / SAP 4.6 / People Soft project accounting data entry at the requisition line level?
1.1.4.3 1.1.4.3 - pass Oracle 7.4 / SAP 4.6 / People Soft project accounting data at each level of the process?
1.1.5 1.1.5 - Does the system default Oracle 7.4 / SAP 4.6 / People Soft project accounting data by requisitioner?
1.1.6 1.1.6 - Security Rules-- The capability to limit the “accounts” available to specific users. For example, a specific user or group of users may only have access to specific Legal Entities, Business Entities or Cost Centers.
1.1.7 1.1.7 - Cross Validation Rules-- The capability to control the combination of the account segments based on predefined business rules.
1.2 Process - Requisition 1.2.1 1.2.1 - Does the system allow the user to 1.2.1.1 1.2.1.1 - save an uncommitted requisition for future use? 1.2.1.2 1.2.1.2 - use templates for a requisition? Can the system create
templates per user or at the organization level? 1.2.1.3 1.2.1.3 - create a new requisition from an existing one? 1.2.1.4 1.2.1.4 - copy a requisition line from an existing requisition to
another one? 1.2.1.5 1.2.1.5 - duplicate at the line level the information filled at the
header level? 1.2.1.6 1.2.1.6 - withdraw a requisition before it has been approved? 1.2.1.7 1.2.1.7 - resubmit a withdrawn requisition? 1.2.2 1.2.2 - Does the system allow the user to add a comment 1.2.2.1 1.2.2.1 - at the requisition level? 1.2.2.2 1.2.2.2 - at the requisition line level? 1.2.2.3 1.2.2.3 - Can the comment be transferred and printed to the PO? 1.2.3 1.2.3 - Does the system allow the user to add a document
36
1.2.3.1 1.2.3.1 - at the requisition level? 1.2.3.2 1.2.3.2 - at the requisition line level? 1.2.3.3 1.2.3.3 - Is the document attached to the PO when it is sent?
1.2.4 1.2.4 - Does the system support all types of attached documents? 1.2.5 1.2.5 - Does the system allow the user to create a requisition "on
behalf of” another user? 1.2.5.1 1.2.5.1 - In that case, does the system apply accounting
information and approval workflow relating to that "on behalf of" user?
1.2.6 1.2.6 - Can the system force data entry for some fields on the requisition?
1.2.6.1 1.2.6.1 - What fields can/cannot force data entry. 1.2.6.2 1.2.6.2 - Data validation capabilities of the solution (e.g., range of
data, list, format of data, etc.). 1.2.7 1.2.7 - Does the system handle multiple suppliers on the same
requisition? 1.2.7.1 1.2.7.1 - If yes, how does the system handle the creation of several
PO’s from a single requisition? 1.2.8 1.2.8 - Does the system allow the requisitioner to specify different
“Ship-to” information by requisition line? 1.2.9 1.2.9 - Does the system handle requisitions for non-catalog (ad-
hoc) items? 1.2.10 1.2.10 - Can the system support catalog items and non-catalog
Items on the same requisition? 1.2.11 1.2.11 - Does the system allow the user to propose/force a supplier
for a non-catalog item? 1.2.12 1.2.12 - Can the requisitioner manually split a requisition? 1.2.12.1 1.2.12.1 - If yes, on what criteria can the user split the requisition
(dollar amount, quantity, line, etc)? 1.2.13 1.2.13 - Can a request be tied to inventory data coming from an
external inventory management system? 1.2.13.1 1.2.13.1 - Can the system query the “on-hand” inventory
information? 1.2.13.2 1.2.13.2 - Can the system query the “on-order” inventory
information? 1.2.14 1.2.14 - Can the system create automatic orders based on data
coming from an external inventory information?
1.2.15 1.2.15 - Can the requisitioner input shipping priorities?
1.2.16 1.2.16 - Can the requisitioner input time limits? 1.3 Process - Approval Workflow
1.3.1 1.3.1 - Does the system extend approval workflow functionality to
1.3.1.1 1.3.1.1 - requisitions? 1.3.1.2 1.3.1.2 - service requests? 1.3.1.3 1.3.1.3 - catalogue changes? 1.3.1.4 1.3.1.4 - user profile changes? 1.3.1.5 1.3.1.5 - expense reports? 1.3.2 1.3.2 - For requisitions, does the system define the approval
workflow at 1.3.2.1 1.3.2.1 - the requisition level? 1.3.2.2 1.3.2.2 - the requisition line level? 1.3.3 1.3.3 - Does the system present preview of the the approval flow
before the requisition is submitted? 1.3.4 1.3.4 - Does the system allow graphical approval workflow
37
viewing? 1.3.4.1 1.3.4.1 - Alternative ways for the user to see the approval flow 1.3.5 1.3.5 - Can the user easily access the approval workflow from
his/her working interface? 1.3.6 1.3.6 - Is approval workflow updated in real-time when triggered by
an event?(e.g., modification of the requisition) 1.3.7 1.3.7 - Does the system handle hierarchical approval levels? 1.3.7.1 1.3.7.1 - Is there any limitation to the numbers of levels? 1.3.7.2 1.3.7.2 - Does it accept parallel / concurrent approvals? 1.3.7.3 1.3.7.3 - Does it accept sequential approvals? 1.3.7.4 1.3.7.4 - Can a level be a role instead of a user name? 1.3.8 1.3.8 - Does the system allow the (management) users to modify
the dynamic approval workflow in the following ways: 1.3.8.1 1.3.8.1 - reorganize the sequence of approvers? 1.3.8.2 1.3.8.2 - delete a level of approvers? 1.3.8.3 1.3.8.3 - add a level (in parallel / in sequence) of approvers? 1.3.8.4 1.3.8.4 - replace a level of approvers? 1.3.9 1.3.9 - As an approver, can a user 1.3.9.1 1.3.9.1 - modify the past part of the dynamic approval workflow? 1.3.9.2 1.3.9.2 - modify the upcoming part of the dynamic approval
workflow? 1.3.10 1.3.10 - Does the system handle the following type of approval
responsibility: 1.3.10.1 1.3.10.1 - approver 1.3.10.2 1.3.10.2 - observer 1.3.11 1.3.11 - Can modification on the approval workflow be done by the
system administrator: 1.3.11.1 1.3.11.1 - graphically? 1.3.11.2 1.3.11.2 - other ways 1.3.12 1.3.12 - Does the system allow delegation of approval authority by: 1.3.12.1 1.3.12.1 - specifying valid time range? 1.3.12.2 1.3.12.2 - specifying type of request? 1.3.12.3 1.3.12.3 - specifying workflow responsibility? 1.3.13 1.3.13 - Does the system allow "escalation" of approval authority: 1.3.13.1 1.3.13.1 - automatically (time counter)? 1.3.13.2 1.3.13.2 - manually? 1.3.13.3 1.3.13.3 - Can the “escalation” function be turned on/off? 1.3.14 1.3.14 - Does the system allow the approval workflow to be based
on the following criteria: 1.3.14.1 1.3.14.1 - GL accounts? 1.3.14.2 1.3.14.2 - commodity codes? 1.3.14.3 1.3.14.3 - product? 1.3.14.4 1.3.14.4 - department / costs centers? 1.3.14.5 1.3.14.5 - supplier data? 1.3.14.6 1.3.14.6 - amount? 1.3.14.7 1.3.14.7 - catalogue changes? 1.3.14.8 1.3.14.8 - user role? 1.3.14.9 1.3.14.9 - budget ? 1.3.14.10 1.3.14.10 - Can the requisition be stopped if that requisition put the
department/cost center over budget? 1.3.14.11 1.3.14.11 - other fields on the requisition? 1.3.15 1.3.15 - Does the system support approver notification of the
38
following events: 1.3.15.1 1.3.15.1 - requisitions? 1.3.15.2 1.3.15.2 - service requests?
1.3.15.3 1.3.15.3 - catalogue changes? 1.3.15.4 1.3.15.4 - user profile changes? 1.3.15.5 1.3.15.5 - expense reports? 1.3.15.6 1.3.15.6 - delegation of authority? 1.3.15.7 1.3.15.7 - problems in receiving (overdue, over shipment, under
shipment and rejection)? 1.3.16 1.3.16 - Does the system allow notification to approvers 1.3.16.1 1.3.16.1 - by summary e-mail (what email system)? 1.3.16.2 1.3.16.2 - by individual e-mail (what email system)? 1.3.16.3 1.3.16.3 - by pop-up message? 1.3.16.4 1.3.16.4 - by voicemail? 1.3.16.5 1.3.16.5 - by remote device? 1.3.17 1.3.17 - Does the notification have a dynamic link to the action to
be performed by the approvers? 1.3.18 1.3.18 - Can the notification system be turned on/off by user/role? 1.3.18.1 1.3.18.1 - by the actual user? 1.3.18.2 1.3.18.2 - by the system administrator? 1.3.19 1.3.19 - Can the approver affect the requisition by 1.3.19.1 1.3.19.1 - rejecting the entire requisition? 1.3.19.2 1.3.19.2 - partially rejecting the requisition (splitting)? 1.3.19.3 1.3.19.3 - adding a document? 1.3.19.4 1.3.19.4 - adding a comment? 1.3.19.5 1.3.19.5 - changing data on the existing requisition? 1.3.19.6 1.3.19.6 - adding new line(s)? 1.3.20 1.3.20 - Can the requisitioner bypass the approval workflow?
1.4 Process - Order Processing 1.4.1 1.4.1 - Can the system handle the following types of transfers from
requisitions to PO's: 1.4.1.1 1.4.1.1 - manual? 1.4.1.2 1.4.1.2 - automatic? 1.4.2 1.4.2 - Can the system pull transactions created in a back-end
system, including: 1.4.2.1 1.4.2.1 - requisitions? 1.4.2.2 1.4.2.2 - PO’s? 1.4.3 1.4.3 - Can the system handle Order Acknowledgement or
Advanced Shipping Notifications? 1.4.3.1 1.4.3.1 - OA 1.4.3.2 1.4.3.2 - ASN 1.4.4 1.4.4 - Can the system utilize the following transmission media for
transferring PO's to the suppliers: 1.4.4.1 1.4.4.1 - fax (paper format)? 1.4.4.2 1.4.4.2 - mail (paper format)? 1.4.4.3 1.4.4.3 - e-mail (electronic format)? 1.4.4.4 1.4.4.4 - EDI (electronic format)? 1.4.4.5 1.4.4.5 - XML (electronic format)? 1.4.4.6 1.4.4.6 - e-commerce network? 1.4.4.8 1.4.4.7 - combination of these? 1.4.5 1.4.5 - Can the PO's be customized by 1.4.5.1 1.4.5.1 - suppliers?
39
1.4.5.2 1.4.5.2 - transmission medium? 1.4.6 1.4.6 - Does the system allow the user to add a comment to a PO 1.4.6.1 1.4.6.1 - at the PO level? 1.4.6.2 1.4.6.2 - at the PO line level? 1.4.7 1.4.7 - Does the system allow the user to add a document to a PO 1.4.7.1 1.4.7.1 - at the PO level? 1.4.7.2 1.4.7.2 - at the PO line level? 1.4.8 1.4.8 - Does the system allow other changes to the PO before it is
sent? 1.4.9 1.4.9 - Does the system handle change orders? 1.4.9.1 1.4.9.1 - Does it provide a special workflow in this case?
1.4.10 1.4.10 - Does the system support multiple requisitions merge into one order?
1.4.10.1 1.4.10.1 - automatic merge of requisitions based upon business rules (by item, by supplier,…)?
1.4.10.2 1.4.10.2 - manual merge by approver? 1.5 Process - Receiving
1.5.1 1.5.1 - Can the system handle the following types of receiving: 1.5.1.1 1.5.1.1 - complete receiving? 1.5.1.2 1.5.1.2 - partial receiving (backorder)? 1.5.1.3 1.5.1.3 - complete rejection? 1.5.1.4 1.5.1.4 - partial rejection? 1.5.1.5 1.5.1.5 - centralized receiving (for a limited set of users)? 1.5.1.6 1.5.1.6 - decentralized receiving? 1.5.1.7 1.5.1.7 - "on behalf of" receiving? 1.5.1.8 1.5.1.8 - automatic receiving? 1.5.1.8.1 1.5.1.8.1 - based on a time counter ? 1.5.1.8.2 1.5.1.8.2 - based on other factors (i.e., commodity code)? 1.5.2 1.5.2 - Can the system handle the following addenda in the
receiving process: 1.5.2.1 1.5.2.1 - comments (free form)? 1.5.2.2 1.5.2.2 - additional receiving data collected through a structured
form? 1.5.2.3 1.5.2.3 - documents? 1.5.3 1.5.3 - Can the system handle negative receiving? 1.5.4 1.5.4 - Can the system support tolerance criteria in identifying
receiving problems? 1.5.5 1.5.5 - Can the system support quality control tracking in
receiving? 1.5.6 1.5.6 - Does the system always receive against a requisition? 1.5.7 1.5.7 - Does the system support tracking/notification of delayed
shipments? (Describe how this is supported) 1.5.8 1.5.8 - Does the system have functionality to support returns? 1.5.9 1.5.9 - At the receiving step, can the system push data to update
external inventory system? 1.6 Process - Payment
1.6.1 1.6.1 - Can the system handle invoice process functions? 1.6.1.1 1.6.1.1 - 3 way matching 1.6.1.2 1.6.1.2 - 2 way matching 1.6.2 1.6.2 - Can the system handle payment process functions (i.e.,
Accounts Payable), including 1.6.2.1 1.6.2.1 - EFT - Electronic Funds Transfer
40
1.6.2.2 1.6.2.2 - ERS – Evaluated Receipt Settlement 1.6.2.3 1.6.2.3 - Tax processing and reporting 1.6.2.4 1.6.2.4 - Other payment systems 1.6.2.5 1.6.2.5 - List the other payment systems 1.6.3.8 1.6.3.8 - How does the system manage the following in the
matching process: 1.6.3.8.1 1.6.3.8.1 - electronic matching 1.6.3.8.2 1.6.3.8.2 - manual matching 1.6.3.8.3 1.6.3.8.3 - 3 way matching 1.6.3.8.4 1.6.3.8.4 - 2 way matching 1.6.3.8.5 1.6.3.8.5 - use of tolerance criteria 1.6.3.8.6 1.6.3.8.6 - matching when there is a problem or delay in receiving 1.6.3.9 1.6.3.9 - How does the system provide information about
reconciliation exceptions to users: 1.6.3.9.1 1.6.3.9.1 - automatic notification based on rules (fixed or variable)? 1.6.3.9.2 1.6.3.9.2 - manual? 1.6.4 1.6.4 - How does the system support closing PO's: 1.6.4.1 1.6.4.1 - manual process? 1.6.4.2 1.6.4.2 - automatic process? 1.6.4.3 1.6.4.3 - variable (setup by parameters)? 1.6.5 1.6.5 - How are credit note processed?
2 Catalog Management/ Content Management 2.1 2.1 - Can the system support the following types of catalogs: 2.1.1 2.1.1 - buyer hosted catalog 2.1.2 2.1.2 - supplier hosted catalog (web site access - Punch out) 2.1.3 2.1.3 - network hosted catalog (i.e., exchanges) 2.2 2.2 - Can the catalog handle the following categories of items: 2.2.1 2.2.1 - physical items 2.2.2 2.2.2 - non-physical items (services, training, consulting, etc) 2.2.3 2.2.3 - capital items 2.2.4 2.2.4 - configurable items 2.2.4.1 2.2.4.1 - internally configured items 2.2.4.2 2.2.4.2 - items that are configured using the configuration tool at
the supplier web site 2.3 2.3 - Can the catalog be tailored to a user/group of users through: 2.3.1 2.3.1 - user/user group specific item lists? 2.3.2 2.3.2 - user/user group specific price lists? 2.4 2.4 - Can the catalog support importing/exporting items or item
attributes between the ERP item master file and the catalog? 2.4.1 2.4.1 - Can the catalog support automatic synchronization of
catalogs and the ERP item master file? 2.5 2.5 - Can the system support multiple catalog formats while
providing catalog data seamlessly to the user? 2.6 2.6 - Does the catalog handle multiple item number formats: 2.6.1 2.6.1 - SPSC code (Standard Products and Services Codes) 2.6.2 2.6.2 - others / list them 2.7 2.7 - Does the catalog support searches 2.7.1 2.7.1 - based on item description? 2.7.2 2.7.2 - based on common commodity attributes? 2.7.3 2.7.3 - based on commodity specific attributes ? 2.7.4 2.7.4 - with multiple attributes included in search criteria? 2.7.5 2.7.5 - with use of Boolean logic for search criteria?
41
2.7.6 2.7.6 - that highlight criteria that generated no hits? 2.7.7 2.7.7 - that allow definition of unlimited search attributes? 2.7.8 2.7.8 - that allow searches for the same item across multiple
suppliers? 2.7.9 2.7.9 - by supplier? 2.8 2.8 - Can the catalog support product comparison (for product
and price comparisons) 2.8.1 2.8.1 - by catalog types? 2.8.2 2.8.2 - across catalog types? 2.8.3 2.8.3 - on normalized fields (i.e., price)? 2.8.4 2.8.4 - on non-normalized fields (i.e., description)? 2.9 2.9 - Does the catalog support bookmark functionality by user? 2.10 2.10 - Can the catalog data be displayed by the following criteria: 2.10.1 2.10.1 - by supplier? 2.10.2 2.10.2 - by commodity? 2.10.3 2.10.3 - by another criteria? 2.11 2.11 - Can the user navigate through the catalog via 2.11.1 2.11.1 - graphical tree ? 2.11.2 2.11.2 - other ways? 2.12 2.12 - Is the user interface for managing catalogs consistent for all
suppliers? 2.13 2.13 - Can the system update and track version and revision
changes for reengineered items? 2.13.1 2.13.1 - Can the system inform users of potential replacement and
interchangeable parts? 2.13.1 2.13.2 - Can the system inform users of potential associated
products? 2.14 2.14 - Does the system provide an interface to manage both
catalog data and catalog structures and make changes to the following:
2.14.1 2.14.1 - the hierarchy of the commodities? 2.14.2 2.14.2 - the updates of the catalogs? 2.14.3 2.14.3 - the updates of the suppliers? 2.15 2.15 - Does the system allow the following updates for catalog
data: 2.15.1 2.15.1 - manual correction? 2.15.2 2.15.2 - manual upload (from a file)? 2.15.3 2.15.3 - automatic upload (from a file)? 2.15.4 2.15.4 - from an external source? 2.16 2.16 - Supplier Management 2.16.1 2.16.1 - Does the system provide tools for evaluating 2.16.1.1 2.16.1.1 - supplier content (i.e., pricing)? 2.16.1.2 2.16.1.2 - supplier performance? 2.17 2.17 - Does the system or its associated e-commerce network
support the sale and/or disposal of excess inventory? 2.18 2.18 - Does the system also include auction, reverse auction and
exchange functionality? 2.19 2.19 - Does the system support user notification to specific catalog
changes (e.g. user subscribes to IT hardware catalog changes? 2.19.1 2.19.1 - instant notification?
2.19.2 2.19.2 - periodic notification?
2.19.3 2.19.3 - on login notification of logged catalog changes?
42
2.20 2.20 - Can the system support multiple pricing rules on the same catalog?
2.21 2.21 - Can the system support changing the pricing rules without changing the catalog? How?
3 User Interface 3.1 User Interface - Friendliness
3.1.1 3.1.1 - Recommended approach for developing end user proficiency with your application (e.g. no training, self training, formal training programs, etc.)?
3.1.2 3.1.2 - How the system provides users with “real-time” help facilities within the applications.
3.1.3 3.1.3 - Does the system provide tool-tip help on all icons and fields?
3.1.4 3.1.4 - Does the system provide wizards to assist end-users? 3.1.4.1 3.1.4.1 - Can the wizards be turned off for more experienced end-
users? 3.1.4.2 3.1.4.2 - Are wizards available for 3.1.4.2.1 3.1.4.2.1 - requisition entry? 3.1.4.2.2 3.1.4.2.2 - receiving? 3.1.4.2.3 3.1.4.2.3 - running reports? 3.1.4.2.4 3.1.4.2.4 - T&E? 3.1.4.2.5 3.1.4.2.5 - profile changes? 3.1.4.2.6 3.1.4.2.6 - new user self-enrollment? 3.1.4.3 3.1.4.3 - Does the wizard include hypertext link to on-line help? 3.1.5 3.1.5 - Does the system provide “Forward” and “Back” navigation
buttons for easy correction of entry on previous screens? 3.1.6 3.1.6 - Does the system allow users to easily “Undo” previous
entries? 3.1.7 3.1.7 - Does the system default previously entered field values for
ease of repetitive data entry 3.1.7.1 3.1.7.1 - by copy/paste? 3.1.7.2 3.1.7.2 - using templates for requisition? 3.1.7.3 3.1.7.3 - by auto-filling: 3.1.7.3.1 3.1.7.3.1 - repeat previous entry? 3.1.7.3.2 3.1.7.3.2 - proposed list of values? 3.1.8 3.1.8 - Does the system use the same "look and feel" UI for all
components of the solution (i.e. requisitions, receiving, T&E)? 3.1.9 3.1.9 - Does the system allow the use of short cuts? Can the
requisitioner create its own short cuts to its "favorites" screens? 3.1.10 3.1.10 - Does the system allow the requisitioner to create its "own
requisition template" (most variables set as default)? 3.1.11 3.1.11 - Does the system give help or prompts concerning
mandatory field that have not been completed? 3.2 User Interface - Scalability
3.2.1 3.2.1 - Can the UI be customized by 3.2.1.1 3.2.1.1 - modifying/adding fields? 3.2.1.2 3.2.1.2 - modifying/adding screens? 3.2.1.3 3.2.1.3 - changing sequence of the screens? 3.2.2 3.2.2 - Can the UI be customized by user profile? 3.2.3 3.2.3 - Can a non-programmer customize the UI graphically? 3.2.4 3.2.4 - Can the UI customization be done without external
(contractors) assistance? 3.2.5 3.2.5 - Can on-line help be customized?
43
3.2.6 3.2.6 - Can wizards be customized? 3.2.7 3.2.7 - Is it possible to add screens: 3.2.7.1 3.2.7.1 - to capture additional data on a requisition? 3.2.7.2 3.2.7.2 - to capture additional data on a catalogue search? 3.2.7.3 3.2.7.3 - to capture a service request? 3.2.7.4 3.2.7.4 - supported by an approval workflow? 3.2.7.5 3.2.7.5 - unsupported by/outside an approval workflow? 3.2.8 3.2.8 - Can the UI define the following attributes for a field: 3.2.8.1 3.2.8.1 - required? 3.2.8.2 3.2.8.2 - view-only? 3.2.8.3 3.2.8.3 - hidden? 3.2.8.4 3.2.8.4 - other?
3.3 User Interface - Miscellaneous 3.3.1 Which are the languages provided for the user interface, apart from
English? 3.3.2 Does the system support double currency (e.g.: French and Euro)? 3.3.3 How does the system show the double currency to the user?
3.3.4 Does the system supports multiple cost centers structure with a multiple department structure? How?
3.3.5 Does the system supports multiple supplier code number for the same supplier?
4 Reporting 4.1 Reporting - Reports
4.1.1 4.1.1 - Does the system provide pre-defined reports? 4.1.1.1 4.1.1.1 - Can they be customized, and is source code available to
do so? 4.1.2 4.1.2 - Does the application provide an “ad-hoc” reporting tool to
allow individualized custom reports? 4.1.2.1 4.1.2.1 - Can the user define unique custom reports? 4.1.3 4.1.3 - Can “ad-hoc” reports be built from 4.1.3.1 4.1.3.1 - requisition data? 4.1.3.2 4.1.3.2 - approval workflow data? 4.1.3.3 4.1.3.3 - PO data? 4.1.3.4 4.1.3.4 - receiving data? 4.1.3.5 4.1.3.5 - P-card data? 4.1.3.6 4.1.3.6 - T&E data? 4.1.4 4.1.4 - Does the reporting tool support the following output: 4.1.4.1 4.1.4.1 - saved to a file? 4.1.4.2 4.1.4.2 - displayed on the screen? 4.1.4.3 4.1.4.3 - sent to a printer? 4.1.5 4.1.5 - Does the system allow use of a bolt-on reporting tool? 4.1.6 4.1.5 - Does the system allow consolidated reports?
4.2 Reporting - Query 4.2.1 4.2.1 - Does the system provide query functions? 4.2.2 4.2.2 - Can the query be saved? 4.2.2.1 4.2.2.1 - Can queries be organized hierarchically? 4.2.3 4.2.3 - Can queries be built from: 4.2.3.1 4.2.3.1 - requisition data? 4.2.3.2 4.2.3.2 - approval workflow data? 4.2.3.3 4.2.3.3 - PO data? 4.2.3.4 4.2.3.4 - receiving data? 4.2.3.5 4.2.3.5 - P-card data?
44
4.2.3.6 4.2.3.6 - T&E data? 5 Interfaces
5.1 5.1 - Does the system allow the following ownership models for the data in the e-procurement system:
5.1.1 5.1.1 - Only the e-procurement system controls the data? 5.1.2 5.1.2 - Both back-end and e-procurement systems can modify the
data? 5.2 5.2 - Does the system support interfaces with Travel booking
systems? 5.3 5.3 - Does the system support interfaces with warehouse
management systems? 5.4 5.4 - Does the system support interfaces with production planning /
maintenance systems? 5.5 5.5 - Does the system support interfaces with Oracle 7.4 / SAP 4.6
/ People Soft? 5.5.1 5.5.1 - At the requisition step? 5.5.1.1 5.5.1.1 - Can push requisitions to Oracle 7.4 / SAP 4.6 / People
Soft? 5.5.1.2 5.5.1.2 - Can pull requisitions from Oracle 7.4 / SAP 4.6 / People
Soft? 5.5.2 5.5.2 - At the PO step? 5.5.2.1 5.5.2.1 - Can push entire PO’s to Oracle 7.4 / SAP 4.6 / People
Soft? 5.5.2.2 5.5.2.2 - Can partially push PO’s to Oracle 7.4 / SAP 4.6 / People
Soft? 5.5.2.3 5.5.2.3 - Can pull PO’s from Oracle 7.4 / SAP 4.6 / People Soft? 5.5.3 5.5.3 - At the receiving step? 5.5.3.1 5.5.3.1 - Can push receiving data to Oracle 7.4 / SAP 4.6 / People
Soft to support accrual? 5.5.3.2 5.5.3.2 - Can pull receiving data from Oracle 7.4 / SAP 4.6 / People
Soft? 5.5.4 5.5.4 - At the payment step? 5.5.4.1 5.5.4.1 - Can push invoices to Oracle 7.4 / SAP 4.6 / People Soft? 5.5.4.2 5.5.4.2 - Can pull invoices from Oracle 7.4 / SAP 4.6 / People Soft? 5.5.4.3 5.5.4.3 - Can push project accounting data to Oracle 7.4 / SAP 4.6
/ People Soft? 5.5.4.4 5.5.4.4 - Can pull project accounting data from Oracle 7.4 / SAP
4.6 / People Soft? 5.6 5.6 - Are those interfaces provided with the eProcurement product? 5.7 5.7 - Do you support upgraded interfaces based on future releases
of Oracle 7.4 / SAP 4.6 / People Soft? 5.8 5.8 - Can the system integrate with multiple instances of Oracle
7.4 / SAP 4.6 / People Soft? 5.9 5.9 - Does the system support integration with Oracle 7.4 / SAP 4.6
/ People Soft on the following points: 5.9.1 5.9.1 - Can pull accounting data from Oracle 7.4 / SAP 4.6 / People
Soft (e.g., Charts of Account, GL accounts)? 5.9.2 5.9.2 - Can pull financial data from Oracle 7.4 / SAP 4.6 / People
Soft (e.g., budget, payment terms)? 5.9.3 5.9.3 - Can pull user profile and role data from Oracle 7.4 / SAP
4.6 / People Soft? 5.9.4 5.9.4 - Can pull workflow data from Oracle 7.4 / SAP 4.6 / People
Soft? 5.9.5 5.9.5 - Can pull item data from Oracle 7.4 / SAP 4.6 / People Soft
(e.g., general item data, inventory data)?
45
5.9.6 5.9.6 - Can pull project data from Oracle 7.4 / SAP 4.6 / People Soft (e.g., list of projects)?
5.9.7 5.9.7 - Can pull supplier data from Oracle 7.4 / SAP 4.6 / People Soft?
5.9.8 5.9.8 - Can pull UOM data from Oracle 7.4 / SAP 4.6 / People Soft?
5.1 5.10 - Does the system provide a Capital Asset Management system?
5.11 5.11 - Does the system provide interfacing capabilities for suppliers to exchange catalog content and supplier performance information?
5.11.1 5.11.1 - Can suppliers participate at no cost to them? 5.11.2 5.11.2 - Can the suppliers participate with no need to install
software/add-ons on their own system? 5.11.3 5.11.3 - Can the suppliers submit their catalogs in the following
formats: 5.11.3.1 5.11.3.1 - CIF files? 5.11.3.2 5.11.3.2 - OBI compliant catalog format? 5.11.3.3 5.11.3.3 - CSV files? 5.11.3.4 5.11.3.4 - XML files? 5.11.3.5 5.11.3.5 - CAT files ? 5.11.3.6 5.11.3.6 - other files format? 5.12 5.12 - Does the system allow scheduling of the catalog updates
from the supplier site? 5.13 5.13 - Can the system capture supplier data directly from the
supplier site? 5.14 5.14 - Can the supplier directly update catalog data in the system? 5.15 5.15 Does your system integrate with the budget? In real time?
Connection to Market Places 5a.1 Messages and documents available for Market Place dispatch 5a.1.1 Does the system support Purchase Order document 5a.1.2 Does the system support Purchase Order status tracking
messages 5a.1.3 Does the system support quick inventory check message 5a.1.4 Does the system support Advance Shipment Note (ASN) 5a.1.5 Does the system support European Invoice 5a.1.6 Does the system allow a RFP / RFQ (Auction) to be created
as Purchase Order 5a.1.7 Does the system support Good Received Note (GRN) 5a.1.8 Does the system support document attached to PO for
specific attributes (Smart Form) 5a.2 Message Language and Customization 5a.2.1 Are the messages compatible with Xcbl?xCBL (Commerce
One, ARIBA language) 5a.2.3 Can we create or change messages send to the Market
Place without coding 5a.3 Connectivity to other Market places 5a.2.2 Are the messages compatible with other type of Market
place languages 5a.3.2 Can we connect to several Market Places based on Supplier
alignment 6a Specifics modules
Does the system provide an asset management application (example : to manage computers) ?
Flux / without order (ex. EDF)
46
Can the system handle VAT or other type of sales tax? Does the system provide a specific module to manage capital
expenditure expenses ? Does the system provide a specific module to manage utilities and
office supplies expenses ? Does the system provide a specific module to manage contract staff
expenses ? Does the system provide a specific module to manage subscription
expenses ? Does the system provide a specific module to manage external
services expenses ? 6b Travel and Expense
6.1 6.1 - Are wizards provided for T& E entry (i.e. Hotel Bill Wizard)? 6.2 6.2 - Does the system support credit card pre-population? 6.2.1 6.2.1 - Can the user to select a range of charges to add to a
report? 6.2.2 6.2.2 - Can the user mark charges as "personal"? 6.2.3 6.2.3 - Does the credit card interface distribute charges to
individual users automatically? 6.2.4 6.2.4 - Can the system send e-mail notification to users that
charges have been received? 6.2.5 6.2.5 - Can the system send e-mail notification of charges that
have not been applied to a report? 6.3 6.3 - Can the system receive information from a central reservation
system in order to pre-populate a T&E entry? 6.4 6.4 - Does the system support rules-based expense violation
notification? 6.4.1 6.4.1 - Can violation rules be changed without programming? 6.4.2 6.4.2 - Can the user enter reason codes for violations? 6.5 6.5 - Can the system send rules-based preferred supplier
notification messages? 6.6 6.6 - Can the user indicate charges for which they have a receipt? 6.7 6.7 - Does the system leverage the same dynamic workflow as in
the requisition process? 6.7.1 6.7.1 - Can the approver access "exceptions" quickly without
having to review all expense items? 6.8 6.8 - Does the system leverage the same intuitive user interface
used for requisition process? 6.9 6.9 - Does the system leverage the same integration capabilities
used for requisition process? 6.10 6.10 - Does the system leverage the same GL accounting rules
and data described above? 6.11 6.11 - Does the system record that all expense receipts have been
received by the Expense Department? Technical Requirements 7 Technical Requirements - Security
7.1 7.1 - Does the system provide restricted access within the e-procurement application
7.1.1 7.1.1 - for data? 7.1.2 7.1.2 - for processes? 7.1.3 7.1.3 - by user? 7.1.4 7.1.4 - by role? 7.2 7.2 - Can the system leverage security definitions maintained in
other systems (e.g., ERP, LDAP)? 7.3 7.3 - Does the system manage system access through login and
47
password entry? 7.3.1 7.3.1 - Are user name and password encrypted? 7.3.2 7.3.2 - Can the system leverage login/password from Windows
NT? 7.3.3 7.3.3 - Can the system leverage login/password from Oracle 7.4 /
SAP 4.6 / People Soft? 7.4 7.4 - Can the system handle different means of managing users? 7.4.1 7.4.1 - Can users define their own user profiles? 7.4.2 7.4.2 - Does the system support "organic growth", allowing new
users to identify and request use of the system? 7.4.3 7.4.3 - Are new user profiles routed for approval through the same
dynamic workflow as requisitions? 7.5 7.5 - Does the system support the following connection security
protocol: 7.5.1 7.5.1 - SSL 2.0? 7.5.2 7.5.2 - SSL 3.0? 7.5.3 7.5.3 - Public Key Infrastructure? 7.5.4 7.5.4 - Does the system support other forms of security protocol? 7.6 7.6 - Can the system leverage the use of firewalls? 7.7 7.7 - How does the system handle data confidentiality through the
interfaces? 7.8 7.8 - Does the system handle encryption for certain fields?
8 Technical Requirements - Client Architecture 8.1 8.1 - Does the system support Windows 98 clients? 8.2 8.2 - Does the system support Windows NT 4.0 clients? 8.3 8.3 - Does the system support Windows 2000 clients? 8.4 8.4 - Does the system use a thin client (Web browser)? 8.4.1 8.4.1 - Internet Explorer release 4 or higher browser 8.5 8.5 - Does the system support Lotus? 8.6 8.6 - Does the system handle the following technologies for
increasing ease of maintenance of the client: 8.6.1 8.6.1 - use of an industry standard language (JAVA, C++, C, etc)? 8.6.1.1 8.6.1.1 - Object Oriented technology 8.6.1.2 8.6.1.2 - Procedural programming technology 8.6.2 8.6.2 - authorization to access the source code? 8.7 8.7 - How does the system handle performance tuning?
9 Technical Requirements - Server Architecture 9.1 9.1 - Are server components developed with industry standard
tools (e.g., Java for Object-Oriented)? 9.2 9.2 - Can server components access other data sources? 9.3 9.3 - Can the system support and leverage multi-processor
servers? 9.4 9.4 - Does the system leverage RPC (Remote Procedure Call) for
network efficiencies? 9.5 9.5 - If the system handles scheduled tasks, where is the scheduler
engine resident: 9.5.1 9.5.1 - Linked to the e-procurement solution server? 9.5.2 9.5.2 - Linked to the operating system server? 9.6 9.6 - Are API’s available for integration with other systems? 9.7 9.7 - Does the system handle the following technologies for
increasing ease of maintenance of the metadata: 9.7.1 9.7.1 - Use of an industry standard language (XML, etc)? 9.7.2 9.7.2 - Other?
48
9.8 9.8 - Does the system provide administration system tools? 9.8.1 9.8.1 - Is there an integrated server control panel and monitor for
technical support users? 9.8.2 9.8.2 - Is there an integrated metadata management panel and
monitor for technical support users? 9.8.3 9.8.3 - Is there an integrated transaction control panel and monitor
for technical support users? 9.8.4 9.8.4 - Are debugging tools provided to help with problem
resolution? 9.9 9.9 - Does the system maintain transaction logs to monitor activity
and assist with problem resolution? 10 Technical Requirements - Performance
10.1 10.1 - Application scalability - growth in number of users 10.2 10.2 - Application scalability - growth in number of transactions 10.3 10.3 - Is the system information updated in real-time? 10.4 10.4 - Can the system perform and operate efficiently over low-
bandwidth networks (i.e., 28.8K modem connection)? 10.5 10.5 - Application scalability - growth in number of suppliers or
products 10b Technical Requirements - Data Base
10b.1 10b. 1 - Which database structure do you support? List them 10b.2 10b.2 - Is the structure of the database documented? 10b.3 10b.3 - Under which conditions can the structure of the database be
enriched? 10b.4 10b.4 : under what conditions can the data of the database
enriched 10c Technical Requirements - Specific
10c.1 Firewall police Company Profile 11 Company Profile - Implementation Approach and Ongoing Support
11.1 11.1 - Vendor’s involvement during implementation 11.2 11.2 - Performance guarantees and penalties for non-performance. 11.3 11.3 - Service level guarantees along with the respective penalties
with respect to defects in code, performance, security, implementation milestones, and deadlines.
11.4 11.4 - On-going services included in proposed prices. 11.5 11.5 - User support included in proposed prices. 11.6 11.6 - Maintenance support included in proposed prices. 11.7 11.7 - Training support included in proposed prices.
12 Company Profile - Vendor's Approach to Market 12.1 12.1 - the company’s overall business approach to the current e-
procurement marketplace. 12.2 12.2 - How the company sees this marketplace changing over the
next two to three years. 12.3 12.3 - What changes will produce critical impacts on content
management, communications, buying communities, portals, etc.? 12.4 12.4 - How will e-procurement software vendor consolidation
impact the above scenarios? 12.5 12.5 - How will your company achieve critical mass in this market
space? 12.6 12.6 - What distinguishes them from their competitors? 12.7 12.7 - What is your upgrade policy? Which support do you provide?
Financial Proposal 13 Financial Proposal - Company Viability
49
13.1 Financial Position
13.1.1 13.1.1 - Financial position of the company. 13.2 Organizational
Strength
13.2.1 13.2.1 - When was the company founded? 13.2.2 13.2.2 - How long has the company been active in electronic
commerce? In electronic procurement? 13.2.3 13.2.3 - How many employees (FTE’s) are in the company? What
is the breakdown in terms of professional, technical and clerical positions?
13.2.4 13.2.5 - How many key individuals are dedicated to the e-procurement product division of the organization? To the external electronic marketplace solution? What is your turnover rate on programmers and developers?
13.3 Research and Product Development
13.3.1 13.3.1 - The approach to on-going improvement of the solution. 13.3.2 13.3.2 - The product update cycle. 13.3.3 13.3.3 - Products under development that would be appropriate to
enhance the solution 13.3.4 13.3.4 - What percentage of the annual operating budget is spent
on R&D? 13.4
CustomerService and Reach
13.4.1 13.4.1 - Current and anticipated geographic reach. 13.4.2 13.4.2 - Supplier adoption / management services. 13.5
CustomerReferences
13.5.1 13.5.1 - Industry. 13.5.2 13.5.2 - Previously identified references in an Oracle 7.4 / SAP 4.6
/ People Soft environment. 13.5.3 13.5.3 - Other industry/environment.
14 Financial Proposal - Financial Proposal 14.1 Application
Costs
14.1.1 14.1.1 - Application costs 14.2
Implementation and Conversion Costs
14.2.1 14.2.1 - Implementation and Conversion Costs 14.3 Training Costs
14.3.1 14.3.1 - Training Costs 14.4 Transaction
Costs
14.4.1 14.4.1 - Transaction Costs 14.5
AdditionalCosts
14.5.1 14.5.1 - Additional Costs
50
GLOSSÁRIO
MAUT (Multi-Attribute Utility Theory)
Teoria de Utilidade Multiatributo – teoria de suporte à tomada de decisão
utilizada nesta pesquisa. Explicada em detalhe na parte de referencial teórico.
ERP (Enterprise Resources Process)
Sistema que controla e integra todos os processos de uma empresa: compras,
finanças, controladoria, vendas e distribuição, administração de materiais, recursos
humanos, entre outros. Exemplos: SAP, Baan.
E-procurement
Realização dos processos de compras com utilização da Internet. Exemplos:
requisição de compras, solicitações de cotações, pedidos, leilões, aprovações e
relatórios.
EBP (Enterprise Buyer Professional)
Produto de e-procurement da empresa SAP.
SRM (Supplier Relationship Management)
É a cadeia de relacionamento entre a empresa e os fornecedores. Automatiza
processos entre a procura por fornecedores e aquisições, dentro da empresa e ao
longo de toda a base de oferta. Aumenta a visibilidade da cadeia de produção e
fornecendo uma visão completa de gastos globais.
RFI (Request for Information)
Questionário enviado aos fornecedores para levantamento das informações
necessárias para a escolha da melhor solução. Normalmente utilizada pelo
departamento de compras antes do envio de uma RFQ (Request for Quotation) –
solicitação de cotação.
51
Supply Chain
É a integração dos processos de negócio, desde o usuário (cliente) final até o
fornecedor original, gerando produtos, serviços e informações que agregam valor
para o consumidor (Cooper, Lambert e Pagh, 1997).
Strategic Sourcing
É um conjunto de procedimentos, ferramentas e capacitações que abordam de
maneira objetiva, as oportunidades de redução de custos de categorias específicas,
capturando economias com maior agilidade através da rápida implantação de
projetos em categorias previamente selecionadas (Pinto, Apolinário, Pires,
Rodrigues e Magalhães, 2004).
MarketPlace
Portal eletrônico de compras. São sites que funcionam como um ponto de
encontro, ou mercado virtual, onde vendedores e compradores ficam frente a frente
para negociar e concretizar negócios de maneira simples e rápida.
No marketplace, são efetuadas transações de e-procurement e leilão reverso.
Business Case
Principalmente nos projetos que envolvem altos custos e possam trazer riscos
significativos para a organização, o Business Case é um instrumento bastante útil
para o processo decisório. O Business Case identifica o problema, analisa as
alternativas para sua solução, estima prazos e custos do projeto, seus riscos e
benefícios e conseqüências para o fluxo de caixa da organização, permitindo que a
alta direção possa cercar-se das informações necessárias para uma tomada de
decisão bem fundamentada sobre os projetos que devem ser iniciados
imediatamente, aguardar uma oportunidade futura, ou simplesmente ser
arquivados. Ter um bom Business Case não garante o sucesso de um projeto, mas
fornece um ponto de partida claramente definido, que poderá servir de referência
sempre que complicadores financeiros, gerenciais ou de natureza técnica venham a
ameaçar sua concretização (Beal, 2001).
Livros Grátis( http://www.livrosgratis.com.br )
Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas
Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo