O documento aborda o gerenciamento de um projeto de desenvolvimento de um sistema de atendimento automatizado em um call center, destacando a importância da humanização no atendimento e a estrutura de WBS (Work Breakdown Structure) para planejamento. Ele também apresenta critérios de make or buy, detalhando análise de custos e seleção de fornecedores, além de especificações funcionais para a plataforma de atendimento. Por fim, o texto menciona as etapas de execução, incluindo pagamentos, documentações e fiscalização do projeto.

1. Gerenciamento de Projetos
Disciplina: Gerenciamento de Aquisições
Cidade: Campinas
Turma: GProj-37

2. TEAG Call Center
 TEAG Call Center é uma Organização que tem como objetivo de atender
Empresas que queiram se aproximar dos seus Clientes através de um
atendimento personalizado visando a qualidade, agilidade e
comodidade.
TEAG

3. Equipe do Projeto
 1 – Alex Gallo
 2 – Andre Santana da Silva
 3 – Evandro Gressoni
 4 – Tiago Barros
1 - Alex Gallo
2 - Andre
Santana
3 - Evandro
Gressoni
4 – Tiago Barros

4. Projeto URA
 Desenvolvimento de processos de atendimento em aplicação para URA para a
empresa de Call center, a fim de propiciar a criação de atendimento
automatizado via URA aos clientes.
 Humanização do atendimento na URA;
Projeto
URA

5. WBS do Projeto
1 - Projeto URA
1.1 - Estudo
Preliminar
1.1.1 - Definição
do Escopo
1.1.2 - Estimativa
de Custos
1.1.3 - Elaboração
do Cronograma
Macro
1.1.4 - Definição
de Recursos
1.2 -
Especificação
Funcional
1.2.1 - Definição
de Requisitos
1.2.2. -
Documentação
1.2.3 - Aprovação
do BBP
1.3 - Construção
1.3.1 -
Desenvolvimento
do Software
1.3.2 - Integração
de Sistemas
1.3.3 - Testes
Unitários
1.4 -
Homologação
1.4.1 - Massa de
Testes
1.4.2 - Testes de
Integração
1.4.3 - Coleta de
Evidencias
1.5 - Go Lives
1.5.1 - Cut Over
1.5.2 -
Monitoramento
1.5.3 -
Encerramento

6. Critérios Make or Buy
1 – Capacidade (quantidade e Qualidade) da equipe usar a experiência e Know How da
equipe executar o trabalho
2 – Necessidade de fornecimento de tecnologia especializada para desenvolvimento da
inteligência do sistema;
3 – Necessidade de absorção da tecnologia;
4 – Restrição de Prazo – não superlocar recursos em atividades viáveis de atividades é
incompatível com a força tarefa disponível;
5 – Requisitos da Qualidade – o fornecedor contratado para execução do projeto deve
atender as especificações de qualidade apresentada no projeto;
6 – Custo – Análise para verificar qual o valor para executar as atividades (fazer) ou
contratar externamente (contratar);
7 – Monitoramento e Controle – trabalho realizado pelo time do projeto, que tem
facilidade de gestão;

7. Pacote Make / Buy
1 - Projeto URA
1.1 - Estudo
Preliminar
1.1.1 - Definição do
Escopo
1.1.2 - Estimativa
de Custos
1.1.3 - Elaboração
do Cronograma
Macro
1.1.4 - Definição de
Recursos
1.2 - Especificação
Funcional
1.2.1 - Definição de
Requisitos
1.2.2 -
Documentação
1.2.3 - Aprovação
do BBP
1.3 - Construção
1.3.1 -
Desenvolvimento
do Software
1.3.2 - Integração
de Sistemas
1.3.3 - Testes
Unitários
1.4 - Homologação
1.4.1 - Massa de
Testes
1.4.2 - Testes de
Integração
1.4.3 - Coleta de
Evidencias
1.5 - Go Lives
1.5.1 - Cut Over
1.5.2 -
Monitoramento
1.5.3 -
Encerramento
Pacote Buy
Pacote Make
Legenda:

8. Mapa de Aquisições
Concorrência Item a ser
contratado
Ref. WBS Vendor List Cronograma Orçamento Critério Make
or Buy
1 1.3.1 Desenvolvimento de
Software
Accenture
IBM
8 semanas
R$ 30.000
2
2 1.3.2 Integração de
sistemas
Accenture
IBM
3 semanas
R$ 15.000
2,3
3 1.3.3 Testes Unitários Accenture
IBM
1 semana
R$ 5.000
1,5
4 1.4.1 Massa de Testes Accenture
IBM
1 semana
R$ 5.000
1,5
5 1.4.2 Testes de Integração Accenture
IBM
3 Semanas
R$ 7.000
1,5
6 1.4.3 Coleta de evidencias
documentação
Accenture
IBM
3 semanas
R$ 5.000
1,2,5
7 1.5.1 Cut Over Accenture
IBM
2 dias
R$ 10.000
1,2
8 1.5.2 Monitoramento Accenture
IBM
2 semanas
R$ 8.000
1,2

9. WBS Revisada
1 - Projeto
URA
1.1 - Estudo
Preliminar
1.1.1 - Definição do
Escopo
1.1.2 - Estimativa de
Custos
1.1.3 - Elaboração
do Cronograma
Macro
1.1.4 - Definição de
Recursos
1.1.5 – Analise M/B
1.2 -
Especificação
Funcional
1.2.1 - Definição de
Requisitos
1.2.2 - -
Documentação
1.2.3 - Aprovação
do BBP
1.2.4 – Doc.
Aquisição
1.2.4.1 - RFP
1.2.4.2 - RFQ
1.2.4.3 - RFI
1.2.5 - Análise
1.2.5.1 - Equalização
1.2.5.2 - Pontuação
1.2.5.3 - Julgamento
1.2.5.4 – Tira Duvidas
1.2.5.5 - Revisões
1.2.6 - Contratos
1.2.7 – Mapa de
Aquisições
1.3 - Construção
1.3.1 -
Desenvolvimento do
Software
1.3.2 - Integração
de Sistemas
1.3.3 - Testes
Unitários
1.3.4 -
Administração
1.4 - Homologação
1.4.1 - Massa de
Testes
1.4.2 - Testes de
Integração
1.4.3 - Coleta de
Evidencias
1.5 - Go Lives
1.5.1 - Cut Over
1.5.2 -
Monitoramento
1.5.3 -
Encerramento
Pacote Buy
Pacote Make
Legenda:

10. Mapas de Aquisições
Evento de Risco Resposta ao Risco Momento da Resposta ao
Risco
Falta de Profissionais
qualificados para a
execução dos serviços
contratados
Determinarmos os
profissionais que
participarão do projeto no
momento da assinatura do
contrato apresentando
currículos.
(cont.)
(adm.)
Atraso na Entrega do
Equipamento
Estabelecer em contrato
uma multa por atraso (adm.)

11. Seleção do Item – Mapa de Aquisições
Concorrência Item a ser
contratado
Ref. WBS Vendor List. Orçamento Cronograma Criterio WBS
1
Desenvolvimento
do Software
1.3.1
Accenture
IBM
R$ 30.000 8 Semanas 2

12. Critérios Eliminatórios adotados
1 – Know how – Ter feito projetos de mesmo porte anteriormente
2 – será considerado diferencial as proponentes que forem
certificadas com a Norma – ISO 27001
3 – Aceleração da minuta padrão – Documentação padrão
4 – Qualificação técnica da equipe que deverá ser apresentado
por meio de currículo detalhado e individual
5 – Comprovação de experiência de 05 anos no mercado;

13. Critérios Classificatórios Adotados
1 – Capacidade de atendimento – Horas disponíveis para o projeto;
2 – Infraestrutura – Numero mínimo de maquinas disponíveis para o
projeto;
3 – Desenvolvimento e apresentação de cronograma com avanços
de cada etapa do projeto;
4 – Apresentação de garantia para cumprimento de todos os
marcos contratuais estabelecidos dentro do prazo estipulado;
5 – Comprovação de experiência de 05 anos no mercado;

14. Critérios de Avaliação para Contratação
Optamos por Divulgar os critérios de avaliação aos convidados, afim
de:
 Transparência no processo;
 Estabelecer relacionamento de confiança com o futuro fornecedor;
 Dissuadir de concorrer fornecedores que não se encaixem nos critérios de
avaliação;
 Evitar o questionamento dos critérios pelos proponentes;
 Evitar o questionamento dos resultados pelos proponentes;

15. Declaração de Trabalho
• O hardware a ser utilizado para URA será do fabricante Avaya
(www.avaya.com) e o mesmo será de propriedade da TEAG Call
Center.
• A plataforma deverá possuir mecanismo de “call parking”, para
retenção das chamadas (com música de espera, mensagens
promocionais, etc.) enquanto não houver atendentes disponíveis no
serviço desejado pelo cliente.
• A plataforma deverá suportar tratamento especializado por chamador
e por tipo de serviço;
• A plataforma deverá suportar uma estratégia específica de tratamento
de chamada em espera pode ser selecionada, baseada na
quantidade de tempo que o chamador terá que aguardar na fila;
• A plataforma deverá permitir que seja oferecido o retorno ao chamador
(Call Back) baseado na estratégia de tratamento da chamada em
espera;
• A plataforma deverá suportar a funcionalidade de Call Back do mesmo
fornecedor, suportando os modos: agente primeiro e cliente primeiro;
Especificação
Funcional

16. Declaração de Trabalho
•O Call Back poderá ser executado tanto de forma automática quando agendado
para um horário específico;
•O Call Back deverá permitir a parametrização de janelas com os horários de retornos
que serão oferecidos ao chamador;
•A plataforma deverá suportar a funcionalidade de URA ativa para voz, email e SMS;
•A plataforma deverá suportar estratégias baseado nas informações coletadas
durante a interatividade na sessão de tratamento de chamada, incluindo o suporte a
re-roteamento/re-priorização. durante a chamada em espera/fila;
•A solução deverá utilizar o Expected wait time (EWT) para decidir qual o melhor
tratamento a ser dado para um chamador;
•A plataforma deverá permitir a criação e o gerenciamento de Campanhas Ativas de
Voz, SMS e email;
•A plataforma deverá permitir a importação de mailing para as Campanhas Ativas;
•A plataforma deverá permitir a parametrização de mensagens associadas a cada
Campanha por tipo de mídia;
•A plataforma deverá permitir a troca de anúncios, configuração de horários de
atendimento, habilitação de menus e transações de forma amigável, via interface
Web sem a necessidade de desenvolvimento ou indisponibilidade no ambiente;
•A plataforma deverá permitir a ativação/desativação das alterações de forma
agendada;
Especificação
Funcional

17. Declaração de Trabalho
•A plataforma deverá possuir controle de acesso e registrar as atividades de alterações de
configuração realizadas por cada usuário;
•A plataforma deverá permitir a tomada de decisão de tratamento dado ao chamador
baseado em contatos repetidos (Rechamada) e relatórios específicos para análise destas
situações;
•A plataforma deverá permitir a inclusão em tempo real de contatos nas Campanhas ativas
via Web Services;
•A plataforma deverá possuir relatórios que permitam analisar o comportamento das
chamadas (TMA, abandono, retenção, derivação para atendimento humano);
•A plataforma deverá possuir relatórios que apresentem as informações por intervalo
sumarizadas por intervalo e por dia.
•A plataforma deverá possuir níveis de criticidade alteradas de acordo tempo de espera,
quantidade de circuitos fora e enviados e-mail e SMS para a equipe de gestão.
•Mix adequado de interações humanas, auto-serviços realizados na URA e atendimentos
automáticos.
•Árvore de atendimento dinâmica em função do tamanho da fila com informação do
tempo de atendimento.
•Atendimento automático que contemple a identificação do usuário para que seja possível
o tratamento personalizado com a transferência da ligação, juntamente com a
transferência de tela ao agente.
Especificação
Funcional

18. Declaração de Trabalho
•A plataforma deverá possuir ferramenta de comunicação ao Operador com
informações de navegação na URA, evitando assim solicitar novamente ao cliente as
mesmas informações e atendendo o decreto 6523, o protocolo inicial é carregado
do SAP,
•A plataforma deverá possuir banco de dados (instalação, ET, telefone, nome, etc)
com integração aos sistemas técnicos e comerciais da CONTRATANTE Envio de
anúncios personalizados aos clientes, quando em fila de espera.
•A CONTRATADA deverá informar a programação de possíveis alterações que
venham ser realizadas na URA;
•A CONTRATADA ficará responsável por toda manutenção de hardware, software
básico e aplicações transacionais da URA.
•A aplicação da URA deverá ser portável, possibilitando o remanejamento da
aplicação Monitoramento do tempo de execução dos processos desde seu início
com a ligação do cliente até sua finalização com o encerramento da chamada do
cliente.
•Facilidade na configuração;
•A CONTRATADA deverá garantir um índice de disponibilidade técnica de no mínimo
de 99% do tempo em operação da Central de Relacionamento – 24 (vinte e quatro)
horas. Observando principalmente o horário entre as 6 horas e 23 horas, como
período mais critico;
Especificação
Funcional

19. Declaração de Trabalho
•Toda e qualquer janela de intervenção técnica e ou tecnológica deverá ter aviso e
agendamento antecipado (no mínimo 36 horas) com as devidas aprovações da
equipe TEAG Call Center , bem como riscos envolvidos e ações de contingências;
•A CONTRATADA deverá disponibilizar sistema de “tracking” de sistemas e verificação
de disponibilidade e performance de todos os softwares, equipamentos e links de
comunicação de dados para acompanhamento e auditoria da CONTRATANTE.
•Para casos de indisponibilidade parcial e/ou total, deverá ser desenhada uma matriz
de acionamento de TI das equipes CONTRATANTES x CONTRATADA para diagnosticar
e/ou relatar o problema e ações;
•Segurança/Firewall, Infraestrutura de Windows Server, Banco de Dados e Aplicações
e demais profissionais necessários para garantir o SLA.
•A CONTRATADA deverá propor o desenho e custos em separadamente para
contingência observando localização, links de dados, links de voz, equipamentos,
etc;
•A empresa participante da RFP deverá apresentar o seu plano de contingência
preliminar para avaliação da equipe TEAG Call Center ;
•A empresa contratada deverá definir em conjunto com a TEAG Call Center e
fornecedor de Call Center a Matriz de responsabilidades tanto para as etapas de
desenvolvimento, projeto e implantação como para o suporte e manutenção.
Especificação
Funcional

20. •Profissionais especializados em suas áreas de formação, experiência em trabalhos
semelhantes.
•As comprovações de expertise e conhecimentos técnicos deverão ser apresentadas.
Qualidade
•As entregas dos módulos deverá obedecer o cronograma validado de acordo com os
marcos contratuais da contratação
•Os serviços deverão ser executados no prazo de 8 semanas já inclusos o tempo de
mobilização da equipe.
Prazo
•A proponente deve declarar Garantia de Qualidade de seus trabalhos, assegurando perfeita
conformidade aos requisitos especificados desta cotação, comprometendo-se à imediata
correção dos trabalhos considerados pela TEAG Call Center não conformes, sem que isso
signifique ônus adicionais ao contratante.
Garantia
•Formal, Prestação de Serviço, Preço Global.Contrato
•Campinas (SP)Local de Entrega
Declaração de Trabalho

21. Declaração de Trabalho
• São estabelecidos os seguintes limites máximos para
eventos de pagamentos à Contratada, entendendo-se
como tal os respectivos aceites das Contratantes quanto
aos mesmos:
• E1: No início do projeto: até 10% do valor total.
• E2: No término da fase de preparação e desenvolvimento
da atualização: acumulado (E1 + E2) até 30%.
• E3: No término da implantação da atualização (Cutover +
Go Live): acumulado (E1 + E2 + E3) até 70%.
• E4: No término do período de acompanhamento pós-
implantação, incluindo o primeiro fechamento contábil e
estabilização do ambiente de produção: acumulado até
100%.
Pagamento

22. Sistema de Pontuação
Critério Peso
Accenture IBM
Nota Média Nota Média
Experiência no ramo de negócios da TEAG Call
Center
20% 9 180 8 160
Experiência em implementação de demandas
de URA
25% 10 250 3 75
Experiência em processos de negócios 10% 10 100 6 60
Aderência aos processos estabelecidos pela
empresa
20% 9 180 9 180
Metodologia de implementação 5% 10 50 9 45
Metodologia de planejamento e controle de
projeto
10% 9 90 8 80
Metodologia de transferência de
conhecimentos
10% 7 70 7 70
Total 100% 64 920 50 670

23. Documentos de Aquisições Adotados
RFP (Request for Proposal)
• Utilizaremos a RFP para que os fornecedores
apresentem em suas propostas características
distintas para que possamos mensurar qual a melhor
atenderá às expectativas da TEAG Call Center

24. Meio adotado para envio do convite
O envio dos convites será realizado através das seguintes ferramentas:
 Correspondências diretas aos fornecedores,
Pois desta forma seremos eficientes e eficaz na comunicação com os
fornecedores.

25. Contrato
Forma de Contrato
• O Contrato será formal através de carta contrato em virtude de tratar-se de
uma prestação de serviços.
Espécie de Contrato
• Prestação de serviços com incentivo de qualidade de acordo com a lei
10.406/2002 do código civil
Tipo de Contrato
• Será adotado o Preço Global (Preço Fixo), em que o risco é suportado pelo
contratado e o valor não será alterado em caso de ocorrerem imprevistos

26. Concorrência Privada
Inicio 01 – Elabora RFP 02 – Vendor List
03 – Convid. Definid.
04 – Critério de Qualificação de
fornecedor
05 – Aplicar critério de
classificação
07 – Proposta desativada
06 – Proposta
Aprovada
08 – Seleciona Proposta
09 – Comunicar o
fornecedor
Fim
10 – Assinar o Contrato
11 – Contrato Assinado
não sim

27. Atitudes e Fiscalização para Controlar
Aquisições
Atitudes
• Verificar o contrato de trabalho e checar se esta de acordo com as leis vigentes;
• Exigir o laudo de comprovação técnica da equipe;
• Impor clausula de desempenho dentro do esperado;
• Cobrar a regularidade fiscal;
Fiscalização
• Revisão do contrato e da minuta;
• Revisar os laudos;
• Acompanhar semanalmente os resultados
• Monitorar os contratos;
• Fazer verificação constantemente;

28. Relatórios para Controlar Aquisições
Boletim de Medição
Fornecedor Periodo Medido Data
Atividades
Monitoradas
Avanço Medido
Custo Extra e
Despesas
Identificação da
medição do
fornecedor
Evolução semanal pelos
pacotes buy
S/N Detalhar as
atividades
relacionadas aos
pacotes de
trabalho
Evolução
medida em
cada uma das
atividades e
valores
correspondentes
aos avanços
Eventuais custo extra
escopo ocorridos no
período de
apuração e
despesas previstas

29. Como Conduzir e Controlar Aquisições
PGP
Aprovado
Enviar
Convites
Esclarecimento
Receber
Proposta
Julgar
Propostas
Aprovar
Proposta
Elaborar
Contrato
Kick Off
Meeting
Executar WBS
do Contrato
Entregas
Terminadas
Doc. Do
Desempenho do
Projeto
Evidencia dos
testes Unitários
Conduzir a
Qualidade
Como Controlar
o contrato do
desenvolviment
o do Software
Validação das
Evidencias dos
testes unitários
Aceitar os
Testes Unitários
Visitar
Fornecedor
para verificar o
andamento do
projeto
Analisar e julgar
os desvios do
contrato
Gerenciar os
Pagamentos

30. Fluxograma para Encerrar o Contrato
Encerramento do
Contrato
Avaliação das
entregas
Escopo
atendido?
Reunião de
Encerramento
Pagamento
Encerrar Contrato
Registros
não
sim

31. Sumário do Plano de Gerenciamento
de Aquisições
Sumário
 1. Introdução de Plano de Gerenciamento das Aquisições
 2. Objetivos do PGA
 3. Método de Gerenciamento das Aquisições
 3.1. Processos de Aquisições
 3.2. Decisões de Comprar
 3.3. Documentos Padronizados de Aquisições
 3.4. Responsabilidades das Aquisições da Equipe do Projeto
 3.5. Premissas e Restrições
 3.6. Métricas
 3.7. Fornecedores Pré-Qualificados
 4. Conduzir as Aquisições
 4.1. Tipos de Contratos
 4.2. Critérios de Avaliação das Cotações e das Propostas
 5. Controlar as Aquisições
 5.1 Avaliação de Fornecedores
 6. Encerrar as Aquisições