Dissertacao RitaSantos Final
Dissertacao RitaSantos Final
Dissertacao RitaSantos Final
Dissertação de Mestrado
Orientador na FEUP: Prof. Pedro Alexandre Rodrigues João
2020-01-26
Resumo
i
Abstract
The fashion industry is often challenged by rapid changes and unpredictable demand. These
changes, are believed to create an environment of entropy throughout the supply chain, that reveals
to be the first step of responsiveness to the market trends. In fact, in order to keep up with the
moves of the other market players, it is crucial to build up smart logistic strategies to enable the
achievement of short fulfillment lead-times, while a good service level is maintained as the center
of the business model.
This Dissertation, took place at HUUB, a portuguese startup which the core business is to
provide end-to-end logistics for distinctive fashion brands. The company has been witnessing a
trend of exponential growth, which leads to tougher business processes and new complex issues,
coming up on a daily basis.
Hence, came the need of improving, standardizing and documenting the process of identifi-
cation and resolution of issues that emerge from the fulfillment process, one of the key processes
of supply chain, and the most critical one for the team of Global Operations of HUUB. The first
target that was set for the project, was focused on redesigning the process of identification and
resolution of fulfillment issues. Secondly, the target of centralization and uniformization of the
communication flows of that process was set.
The current Dissertation, was triggered by the analysis of the initial situation, focusing, mainly,
on the business processes related with the topic. At this stage, the root cause of the problems was
studied, using issue management and continues improvement methodologies. Afterwards, seve-
ral improvement opportunities were identified, which served as an inspiration for the solutions’
design.
When the design and implementation of the solutions started, the stage was divided into two
different phases. The first phase consisted on process mapping, as a mean to address the problems
justified with processual root cause. Hereafter, in order to respond to the identified communication
root cause problems, a CRM platform, Hubspot, was implemented as an issue management tool
and automation of some parts of the process.
The set of solutions implemented contributed to improve the service level of the company,
leading the SLA to increase from 88% to 97%. Furthermore, the fulfillment lead-time and admi-
nistrative cost, were set lower, with the lead-time decreasing from 2,990 days to 1,553 days and
the cost lessen in 48%. Moreover, it was also possible to optimize a set of KPI relevant to the pro-
cess, for instance, the percentage of issues with a direct influence on the SLA that demonstrated
to lower down in 7%.
Finally, the implementation of Hubspot has played a key role in the optimization of the daily
work backlog. Moreover, it can be seen that Hubspot, revealed to be an opportunity for a more
technological future, revolving around the customer. As a result, it is foreseen that more business
processes will be part of the platform in a near future.
ii
Agradecimentos
Ao Francisco Mesquita Alves, por me ter guiado durante o projeto, pela transmissão de conhe-
cimento e responsabilidade depositada. Ao Pedro Santos pelo voto de confiança e ensinamento de
uma melhor visão de negócio.
À HUUB, em particular à equipa de supply chain, por ter tornado estes meses numa agradável
experiência, pela disponibilidade e preocupação ao longo desta jornada. Aos "estagiários", pela
partilha deste desafio com amizade desde o primeiro dia.
À FEUP pela exigência e capacidade de resiliência ensinadas, por me ter preparado para o
futuro, certamente, da melhor forma.
À Catarina Santos, Catarina Marques e Mariana Tavares, por toda a ajuda, amizade e pelo
exemplo de capacidade de trabalho.
À ESN Porto e à FEP Junior Consulting, por me terem desafiado, ensinado a ser disciplinada e
a sonhar, por terem tornado a faculdade num percurso fascinante.
Aos meus pais e irmão, pelas oportunidades que me proporcionaram, pelo apoio incondicio-
nal ao longo de todo o meu percurso académico e escolar e por viverem as minhas alegrias e
preocupações como se fossem as deles.
Por fim, às minhas amigas e ao Jan, pelo companheirismo, momentos passados e por sempre
acreditarem em mim.
A todos, obrigada.
iii
“In the end she became more than she expected. She became the journey, and like all journeys,
she did not end, she just simply changed directions and kept going.”
Robert M. Drake
v
Conteúdo
1 Introdução 1
1.1 Enquadramento da Dissertação e Motivação . . . . . . . . . . . . . . . . . . . . 1
1.2 Apresentação da HUUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objetivos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Enquadramento Teórico 5
2.1 Gestão da Cadeia de Abastecimento . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Abastecimento de Encomendas . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Gestão de Incidências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Ferramentas de Gestão de Incidências . . . . . . . . . . . . . . . . . . . 8
2.3 Metodologias de Melhoria Contínua . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Ciclo Plan-Check-Do-Act (PCDA) . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Relatório A3 para Resolução de Problemas . . . . . . . . . . . . . . . . 11
2.4 Gestão do Serviço ao Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Customer Relationship Management (CRM) . . . . . . . . . . . . . . . 13
2.4.2 Hubspot como Plataforma de Gestão de Serviços . . . . . . . . . . . . . 15
vii
4.3 Ferramenta A3 de Gestão de Projeto . . . . . . . . . . . . . . . . . . . . . . . . 43
6 Conclusões 54
Referências 57
BD Brand Development
BS Brand Success
B2B Bussiness to Bussiness
B2C Bussiness to Consumer
CM Cargo Movement
CRM Customer Relationship Management
CS Customer Support
CSM Customer Support Management
FIFO First In First Out
GI Gestão de Incidências
GO Global Operations
HNCR Holistic Non-Conformity Reduction
LIFO Last In Fist Out
OPL One Point Lesson
PCDA Plan-Check-Do-Act
PE Process Exception
PFMEA Potential Failure Mode and Effect Analysis
PO Portal Order
PO-RE Portal Order Reception
RCA Root Cause Analysis
SC Supply Chain
SCM Supply Chain Management
SLA Service Level Agreement
SO Sales Order
WS Webshop
3PL Third-party Logistics
ix
Lista de Figuras
xi
5.5 Percentagem de comunicação à marca de incidências "on time" . . . . . . . . . . 52
5.6 Percentagem de incidências por classe na fase 2 do projeto . . . . . . . . . . . . 52
5.7 Ferramenta A3 após a medição e análise de resultados. . . . . . . . . . . . . . . 53
D.1 Incidências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
D.2 Descrição de cada incidência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
D.3 Classe de resolução associada a cada incidência . . . . . . . . . . . . . . . . . . 70
G.1 Quadro resumo dos resultados medidos e analisados no início e final do projeto . 74
xiii
Capítulo 1
Introdução
1
2 CAPÍTULO 1. INTRODUÇÃO
ano de 2019. Este crescimento, naturalmente, implica o trabalho com novas marcas, novos co-
laboradores, novos centros logísticos e novas transportadoras. Para se ter uma ideia da realidade
vivida naquela, contam-se por dezenas, os fluxos de resolução, por centenas, os e-mails internos
recebidos todos os dias, são várias as ferramentas de comunicação e é crescente a complexidade
de priorização de tarefas. Para além destas circunstâncias, a HUUB abarca um conjunto vasto de
marcas com números de coleções e ciclos de vidas anuais dispares. O efeito conjunto, implica
diferentes necessidades logísticas, movimentando uma gestão de cadeia de abastecimento com
necessidades personalizadas a cada cliente.
Com o crescimento, vem também a promessa de entrega de serviços com maior rigor. Assim
sendo, surge uma necessidade, crescente, de documentar e normalizar a resolução das incidências
de forma a torná-las cada vez mais eficientes, e com capacidade de resposta a elevadas entropias
que caracterizam o mercado.
Do ponto de vista do fluxo percorrido por uma determinada incidência, é necessário que os
agentes de resolução sejam notificados da forma mais ágil e simples possível. Assim, a imple-
mentação de uma ferramenta de trabalho transversal à empresa vem contribuir para uma maior
produtividade do trabalho e para menores adversidades diárias. Consequentemente, reflete-se num
melhor serviço para o cliente e para todos os stakeholders envolvidos, implicando, ainda, menores
custos operacionais.
Fundada em 2015, a HUUB entrou na indústria da moda como uma plataforma logística para
marcas distintivas, o SPOKE, a qual permite às partes interessadas, visibilidade sobre a cadeia
de abastecimento da marca. Inicialmente o foco da empresa incidiu sob a captação de marcas do
segmento infantil; atualmente o leque de serviços expandiu também para o setor de adultos.
A proposta de valor da empresa consiste em gerir toda a cadeia de abastecimento das marcas,
desde os fornecedores, até aos clientes finais. Desta forma, a HUUB lida diariamente com um va-
riado número de partes interessadas, incluindo, marcas, clientes finais (retalhistas e compradores),
fornecedores, transportadoras e operações logísticas subcontratadas, todas com uma dispersão ge-
ográfica global. A organização posiciona-se relativamente às suas partes interessadas de acordo
com o esquema representado na figura 1.1.
O objetivo primordial da HUUB é permitir que as marcas se foquem no seu core business, isto
é, no desenvolvimento de produto, nas vendas e no marketing, retirando-lhes a responsabilidade
de gerir a complexidade da cadeia de abastecimento inerente ao seu negócio. Por outro lado, sendo
as empresas, normalmente, de pequena dimensão, a HUUB vem possibilitar-lhes o acesso a uma
competitividade e nível de serviço, apenas acessíveis a marcas de topo, que de outra forma não
seria possível. As operações logísticas da HUUB estão, atualmente, centralizadas em 3 armazéns
diferentes, um na Holanda (NL) e dois em Portugal (na Maia), sendo, um deles, subcontratado
(Agility) e, o outro, próprio (HUUB).
1.3. OBJETIVOS DO PROJETO 3
1.4 Metodologia
De forma a cumprir, escrupulosamente, os objetivos do projeto, dividiram-se os trabalhos a
realizar em diferentes fases.
A primeira fase, centrou-se no mapeamento da situação inicial da empresa, na identificação de
situações problemáticas que surgem como motivação do projeto - e das respetivas causas raiz, bem
como na procura de oportunidades de melhoria. Durante esta fase, fez-se uma análise exaustiva
aos processos relevantes da empresa. Numa segunda fase, realizou-se o levantamento e desenho
de soluções a implementar, a partir das oportunidades de melhoria identificadas e tendo em conta
os objetivos antes enunciados. A terceira fase do projeto consistiu na medição e análise de um
conjunto de indicadores definidos para averiguar o sucesso global das soluções implementadas.
O projeto foi gerido com o auxílio da ferramenta A3, a qual é abordada capítulo 2, e que foi
atualizada, em cada fase, de modo a manter visível a evolução, objetivos e motivação do projeto.
Numa perspetiva temporal, dividiu-se o projeto na base de sprints, segundo a metodologia
Scrum. Esta metodologia retrata a gestão de projetos tecnológicos complexos segundo a filosofia
Agile que visa o aumento de energia, foco e transparência ao longo dos projetos (Sutherland et al.,
2007). Deste modo, organizou-se o projeto em kanbans de trabalho quinzenais, com objetivos
diários definidos.
Enquadramento Teórico
Neste capítulo são abordados conceitos teóricos que surgem como alicerce ao trabalho de-
senvolvido na presente Dissertação. São exploradas ferramentas para a gestão do projeto, meto-
dologias de suporte à identificação do problema, bem como, ferramentas auxiliares ao desenho e
implementação de soluções.
5
6 CAPÍTULO 2. ENQUADRAMENTO TEÓRICO
também o desenho de uma rede e procedimentos que permitam um bom nível de serviço a baixo
custo. Além disto, mais do que logística, requer também uma coordenação inteligente com os
fornecedores e clientes (Croxton, 2003). Assim, o processamento de encomendas baseia-se na
promessa de determinado nível e expectativas de serviço, traduzindo-se em tornar os pedidos num
serviço entregue ao cliente (Ellram et al., 2004).
A nível estratégico, os processos são redesenhados com recurso ao parecer de fornecedores e
clientes, de forma a serem interdisciplinares. A nível operacional, traduz-se maioritariamente em
funções logísticas (Lambert and Enz, 2017), podendo envolver a preparação da encomenda (pi-
cagem, embalamento, etc.), comunicação, entrada, reporte do estado da encomenda e preparação
para o envio (Boon-itt et al., 2017).
A figura 2.2 mostra os sete sub-processos e atividades do processamento de encomendas ope-
racional. Todos se focam em gerir o ciclo percorrido e atividades primárias necessárias (Croxton,
2003).
A gestão de incidências (GI) é crucial para uma organização que pretenda atingir um nível
de serviço de excelência, essencialmente quando as empresas em questão se caracterizam por
ambientes competitivos e acelerados aquando da introdução de novas tecnologias (Giorgetti et al.,
2017).
A GI consiste no processo de identificação, análise, resolução e relato de discrepâncias. É
cada vez mais usada numa ótica de gestão pro-activa de problemas, podendo estes últimos ser pro-
venientes de terceiros ou de processos internos da empresa. Nesta gestão proativa, as incidências
são descobertas mais cedo, o que se reflete numa maior satisfação do cliente, menor número de
atrasos e menos custos. Em sentido oposto, a gestão não proactiva pode levar a crises que terão
um impacto negativo nos níveis de serviço (Wagner et al., 2016).
2.2. GESTÃO DE INCIDÊNCIAS 7
A GI requer uma compreensão extensiva das incidências e do seu estado, bem como o foco
no desenvolvimento de fluxos de trabalho detalhados para a sua resolução (Ciervo et al., 2019).
Segundo Ivanov (2015), as tarefas mais importantes na GI são a identificação de causas raiz, o
desenvolvimento de ações corretivas e de ações necessárias para previr erros.
Numa situação ideal, a solução seria ser-se sempre capaz de prevenir incidências. No entanto,
devido à natureza imprevisível e complexidade das empresas (quando se lida por exemplo com
parceiros subcontratados, cadeia de abastecimento extensa, ou vários stakeholders), a ocorrência
de discrepâncias é inevitável. Desta forma, deve ser criado um modelo de resolução de incidências
que surjam dos vários processos da empresa, considerando como objetivo a máxima eficiência
desses processos (Giorgetti et al., 2017).
Ainda assim, a prevenção é sempre possível e deve ser procurada através da gestão de ris-
cos. O conceito de risco é definido por Wagner et al. (2016) como um evento futuro que pode ter
impacto numa operação. É identificado proativamente antes da ocorrência (Ciervo et al., 2019).
Distingue-se de uma incidência, apesar de serem conceitos frequentemente confundidos, pois uma
incidência diz respeito, a um problema ou preocupação do presente, que influencia o sucesso da
operação. Assim, as incidências podem descrever-se como riscos que se concretizaram (Wagner
et al., 2016). Ambos são mitigados através de ações e decisões, sendo que os riscos e aprendiza-
gens de ocorrências anteriores devem ser documentados.
Assim sendo, manter uma ligação entre riscos, incidências, ações e decisões permite à equipa
de GI a habilidade de identificar problemas que são ocasionais, ou problemas de ocorrência sis-
temática. Detetar estas tendências, permite a posterior identificação da causas raiz (Ciervo et al.,
2019).
8 CAPÍTULO 2. ENQUADRAMENTO TEÓRICO
• Identificação da incidência;
• Documentação: Deve conter uma breve descrição, a ser compreendida tanto pelas operações
como pelo staff corporativo, responsável da incidência, situação atual, situação desejada e
ação;
De forma a garantir a melhoria continua dos processos e da empresa como um todo, é neces-
sário criar um processo de gestão de incidências robusto. Assim, são usadas algumas ferramentas
de forma a desconstruir o problema. Estas ferramentas servem não apenas para a identificação de
discrepâncias, mas, também, para entender o seu impacto em termos de capacidade de resolução
e custos associados (Giorgetti et al., 2017).
Matriz de Prioridades
Esta ferramenta pesa o potencial impacto do problema no normal decorrer da operação com
a probabilidade de ocorrência. Aquando da sua utilização, é essencial que o posicionamento e
descrições sejam regularmente revistos e atualizados. Além disso, as incidências de cada processo
não devem ser analisadas isoladamente, mas comparativamente a incidências semelhantes noutros
processos. Na figura 2.3 podem ver-se exemplos das categorias das incidências que se situam na
secção vermelha da matriz (de prioridade máxima), as quais exigem uma ação corretiva urgente.
As que se situam na secção amarela, exigem especial atenção, com risco de evolução para secção
vermelha, e reporte frequente. Por fim, as categorias de incidências situadas na secção verde não
exigem uma monitorização tão próxima, uma vez que se trata das menos ameaçadoras (Wagner
et al., 2016).
Análise de causas raiz
Esta ferramenta baseia-se na avaliação conjunta do impacto do problema no Service Level
Agreement (SLA), dos recursos existentes e do custo associado. O objetivo desta análise é iden-
tificar a causa real do problema e as ações corretivas necessárias para a eliminar. Deste modo, o
processo começa por analisar um problema de cada vez. Assim, é definida a prioridade de en-
contrar métodos de resolução para cada problema, multiplicando a frequência de ocorrência pelo
risco (severidade de impacto no negócio). Tendo como base o método explicado anteriormente,
este método acaba por incidir apenas nas incidências que vão ter um maior impacto, medido em
custo (Giorgetti et al., 2017).
Em suma, a análise de causas raiz (RCA) visa a identificação dos fatores controláveis que se
revelam como a causa raiz para o problema (Giorgetti et al., 2017). Esta abordagem apresenta
2.2. GESTÃO DE INCIDÊNCIAS 9
algumas limitações, especialmente quando são utilizadas novas tecnologias que abrem caminhos a
novos problemas e por isso novas soluções, as quais poderiam ser semelhantes a alguma desenhada
para uma outra incidência.
A estrutura da análise inicia-se com a definição da causa real do problema; seguidamente
identifica-se uma ação corretiva, onde deve ser analisado o ambiente de ocorrência do problema,
respeitando tempos e custos definidos como aceitáveis; por último, procede-se à monitorização da
solução definida (Giorgetti et al., 2017).
Um método comummente utilizado para averiguar formalmente as causas raiz da ocorrência
de incidências é a potencial failure mode and effect analysis (PFMEA). Esta técnica pretende
avaliar a potencial falha de um produto ou processo e os seus efeitos. Para tal, quantifica o risco
de cada uma das falhas identificadas através de uma combinação de indicadores classificados pelo
analista. Posteriormente, aponta ações que devem ser tomadas de modo a minimizar, ou eliminar,
a frequência de ocorrência dessas falhas. Esta ferramenta é usada essencialmente na fase inicial
do projeto, isto é, fase de planeamento (Johnson and Khan, 2003).
deixa de se criar ações de resolução para uma incidência de cada vez, permitindo que o desenho
de soluções seja mais focado e consequentemente mais robusto.
Em resumo, torna-se extremamente ineficiente dar resposta a cada incidência individualmente,
à medida que a empresa se vai devolvendo, ou tecnologias vão sendo introduzidas. Neste contexto
deve surgir a introdução do HNRC.
A estrutura da ferramenta é a seguinte:
consciencialização para os problemas que são em cada momento enfrentados, de modo a que eles
não ocorram novamente, melhorando a performance a longo prazo.
A estrutura da metodologia é iniciada com o planeamento "Plan". Nesta fase o problema é
estudado a fundo sob vários pontos de vista, de forma a encontrar as causas raiz. Posteriormente,
ainda na mesma fase, são escolhidas soluções para o problema, as quais são organizadas num plano
de implementação detalhado, indicando os responsáveis por cada ação. A fase seguinte denomina-
se por "Do"; trata-se da fase de implementação das soluções anteriormente planeadas, de forma
cautelosa e eficiente. Uma vez concluída aquela, entra-se na terceira fase "Check"; aqui inicia-
se a medição dos efeitos da implementação (resultados) e é feita a comparação com os objetivos
definidos. Em último lugar, inicia-se a fase "Act"onde são interpretados os resultados extraídos
na fase anterior e, finalmente, é estabelecido o novo processo ou solução standard definido, caso
os resultados tenham sido os expectáveis, ou, são tomadas ações corretivas, se os resultados não
tiverem ido de encontro aos objetivos.
Em suma, na fase 1 é desenvolvida a hipótese e o desenho experimental, na fase 2 é feita
a condução da experiência e implementação das soluções, na fase 3 é realizada a coleção de
medições e na última fase a é feita a interpretação de resultados, agindo em concordância (Sobek,
2012)
O pensamento A3 é usado para uma resolução eficaz de problemas. O nome dado remete para
o formato da folha de papel em que o relatório é impresso. É uma ferramenta criada pela Toyota
para garantir que a sua filosofia lean é cumprida, sendo por isso um documento compacto, com a
compilação de todos os resultados provenientes do ciclo PCDA.
Estes relatórios devem servir como suporte à identificação das causas raiz, que devem ser
posteriormente usadas como lição para referências futuras (Sobek, 2012). A ferramenta pode ser
usada para relatar resultados de uma atividade corrente, para resolver problemas, reportar estados
de projetos, ou, para a passagem de conhecimento a outros membros da equipa. Deste modo, a
estrutura do relatório pode ser variável consoante o propósito do mesmo (Sobek and Jimmerson,
2004).
Relativamente à sua estrutura, o relatório A3 divide-se nas seguintes partes:
12 CAPÍTULO 2. ENQUADRAMENTO TEÓRICO
4. Análise de causas raiz: Envolve a investigação das causas raiz do problema. Para isso,
é possível recorrer a várias metodologias. Uma das mais comuns é o "método dos cinco
porquês", onde determinada pergunta é questionada cinco vezes até que se chegue ao fundo
da questão.
7. Atividades futuras: Envolve o desenho de um plano para as atividades que não foram com-
pletadas durante o período do projeto. Além disso, inclui pontos que advéem, normalmente,
de dificuldades encontradas durante a implementação e que têm potencial para serem me-
lhoradas no futuro (Chakravorty, 2009).
quanto ao nível de serviço. De forma a garantir que o SLA é cumpridos da forma mais eficiente
possível, a equipa de CSM trabalha em conjunto com as outras equipas internas, bem como com
os clientes e restantes stakeholders (Yemisi et al., 2003).
O objetivo desta equipa é providenciar um ponto de contacto com o cliente para a resolução
de problemas operacionais (Yemisi et al., 2003) e, ao mesmo tempo, evitar ou resolver falhas de
serviço, assistindo o cliente de forma a que ele adquira o valor expectável da sua compra (Smith,
2006). Um dos pontos chave para um apoio ao cliente bem sucedido é trabalhar no abastecimento
de encomendas de uma forma proativa, respondendo às incidências que surjam ativamente.
O processo de CSM necessita de um sistema em tempo real para responder a pedidos / recla-
mações dos clientes. Idealmente, toda a informação deve estar contida num só local, de forma a
responder a incidências não planeadas de forma ágil e eficiente. Esta tendência traduz-se, nos dias
de hoje, na utilização de uma plataforma de informação consistente para gerir o serviço ao cliente
de forma eficiente (Yemisi et al., 2003). No entanto, cada serviço tem as suas especificidades o
que torna o CSM diferenciador. É necessário adquirir a habilidade de aplicar processos e tecno-
logias para gerar uma experiência consistente e individual ao longo de todas as interações com os
clientes (Smith, 2006).
Após a solução de CSM ser implementada na plataforma, começa a monitorização e reporte
da performance do processo. O feedback das melhorias processuais pode ajudar a evitar futuras
incidências.(Yemisi et al., 2003) Em resumo, o CSM deve ser introduzido com o objetivo de
melhoria da qualidade dos serviços e resposta a pedidos do cliente (Boon-itt et al., 2017).
As empresas deparam-se, frequentemente, com a dificuldade em ter uma visão global sobre o
cliente. Enfrentam desafios quando a informação se encontra desatualizada ou duplicada, tornando
os processos de negócio mais lentos (Yadav, 2016). Para contrariar esta tendência, as plataformas
CRM surgem com o objetivo de aumentar, continuamente, a satisfação dos clientes proporcio-
nando uma melhor assistência e redução de custos de serviços ao cliente (Lang et al., 2002). CRM
é o termo usado para descrever práticas, estratégias e tecnologias de gestão e análise da interação
com clientes ao longo do seu ciclo de vida na organização.
Uma plataforma CRM é um sistema integrado de informação que é usado para planear e con-
trolar as atividade de pré e pós-vendas. Inclui todas as fases de contacto com o cliente, tais como,
serviço de call-center, vendas, marketing, suporte técnico e outros serviços (Yadav, 2016). A
informação de vários canais pode ser compilada num só canal, possibilitando que as equipa de
assistência ao cliente resolvam os problemas apresentados de forma mais eficiente, uma vez toda
a informação necessária está pronta a dar resposta (Al-homery et al., 2019). Ao mesmo tempo,
uma plataforma CRM pode contemplar automatismos dos processos de negócio (Yadav, 2016).
Este tipo de plataforma pode ter uma abordagem proativa ou reativa. Quando adotada a pers-
pectiva reativa, significa que a empresa escolhe responder às recomendações e reclamações dos
clientes, agindo apropriadamente. A abordagem proativa é aquela que se baseia nas previsões
14 CAPÍTULO 2. ENQUADRAMENTO TEÓRICO
feitas para responder às necessidades do cliente, de forma espontânea. Em vez de esperar por re-
clamações dos clientes, ela procura encontrar a insatisfação e resolvê-la previamente (Al-homery
et al., 2019).
Relacionando o conceito de CRM com as atividades de supply chain, a plataforma permite
gerir a logística e cadeia de abastecimento de uma forma mais eficiente, uma vez que possibilita
gerar dados para medir o nível de satisfação do cliente e performance do trabalho (Yadav, 2016).
A implementação de uma plataforma CRM obriga a centrar todos os processo de negócio no
cliente. Requer, portanto, um redesenho dos processos internos da organização, de forma a irem
ao encontro dos desafios propostos (Campbell, 2003).
Em suma, o CRM promove o crescimento e lucro da empresa a longo prazo, através de uma
melhor perceção do cliente (Yadav, 2016) o que se traduz essencialmente por tentar atingir três
metas:
• Ter mais receitas, por cliente, através de um melhor conhecimento do cliente e melhor ser-
viço;
• Reduzir os custos de serviço e aquisição de clientes, através de uso de tecnologias, para criar
automatismos, gerir processos de negócio e analisar dados (Lang et al., 2002).
Em termos de características, a maioria das plataformas CRM permite gravar as várias intera-
ções com o cliente (como por exemplo e-mails) e automatizar processos como, tarefas, alertas,
mensagens, ou e-mails (Yadav, 2016). A automatização de serviços serve para suportar a sua
gestão e permitir que os objetivos sejam atingidos mais rapidamente, gerando, consecutivamente,
uma melhor experiência para o cliente (Al-homery et al., 2019).
2.4. GESTÃO DO SERVIÇO AO CLIENTE 15
Há várias plataformas de CRM; algumas das mais conhecidas são o Salesforce, Zoho e o
Hubspot. Para selecionar a plataforma mais indicada, é necessário ter em conta os seguintes
aspetos: objetivos específicos do negócio; simplicidade de utilização; capacidade de acompanhar o
crescimento da empresa (Butler and Carignan, 2017); flexibilidade e personalizações necessárias;
grau de simplicidade ou complexidade do processo de negócio; dados necessários a extrair (Yadav,
2016).
Tickets
Os tickets representam um pedido de ajuda, suporte ou reclamação de um cliente ou uma
incidência interna. São uma ferramenta de serviço que monitoriza os estados das incidências. Nele
estão organizados documentos, notas e e-mails trocados aquando do fluxo de resolução daqueles.
É ainda possível priorizá-los, de modo a tornar o dia-a-dia de trabalho mais eficiente. Além
disto, toda a informação dos estados percorridos pelo ticket, tempo de resolução e prioridade,
são gravados numa localização central de modo a que esta esteja acessível facilmente.
A ferramenta de tickets inclui a organização em pipelines para gerir os diferentes estados
percorridos. Diferentes pipelines podem conter diferentes estados percorridos pelos tickets. Os
pipelines representam o fluxo que a resolução do ticket percorre. Podendo estes últimos ter, nas di-
ferentes fases, automatismos. Na figura 2.5 representa-se um exemplo de um automatismo contido
numa fase de um pipeline. Finalmente, um pipeline pode ser definido, por exemplo, para tratar
16 CAPÍTULO 2. ENQUADRAMENTO TEÓRICO
Nesta secção, pretende-se apresentar a realidade da empresa de uma forma detalhada, com
o propósito de compreender as circunstâncias do projeto. Comparativamente às fases do ciclo
PDCA, referido no capítulo 2, este capítulo trata da primeira fase - "Plan"
Marcas
Este stakeholder é o cliente da HUUB. Assim sendo, é para ele que a HUUB trabalha diaria-
mente, de modo a cumprir a proposta de valor apresentada. A maioria das transações monetárias
ocorrem entre a marca e a HUUB e, por isso, são as marcas que geram receitas para a organização.
Clientes Finais
A HUUB tem operação B2B (Wholesale) e B2C (Webshop); assim sendo, os clientes finais
da cadeia podem ser tanto retalhistas, no primeiro caso, como clientes individuais, no segundo
caso. Estes stakeholders não têm visibilidade sobre as operações desempenhadas pela HUUB,
mas são aqueles nos quais se reflete o cumprimento do ciclo de fulfillment e consequentemente do
SLA. Este último indicador é o medidor operacional da satisfação da marca e, por isso, cumpri-lo
significa cumprir a proposta de valor apresentada às marcas.
Fornecedores
Este stakeholder tem o primeiro contacto com a marca, garantindo a produção das coleções
por ela desenhadas. Apenas tem contacto com a HUUB no momento da entrega das mesmas nos
armazéns, nas datas acordadas entre ambas as partes. Este processo de recebimento de produtos
17
18 CAPÍTULO 3. CARACTERIZAÇÃO DO ESTADO ATUAL
Transportadoras
Responsável por garantir o transporte do processo de envio, este stakeholder representa uma
ponte entre todos os mencionados anteriormente. A HUUB lida com várias transportadoras,
selecionando-as, para cada envio pretendido, com base numa matriz que pesa o SLA esperado,
o custo do transporte e a rota a percorrer.
operacional ao cliente e às restantes equipas. No decorrer das tarefas diárias, a equipa segue
metodologias lean de forma a aumentar a sua eficiência e diminuir custos. A sub-equipa de Supply
Chain Solutions foca-se na otimização da cadeia de valor e das operações. Por último, a equipa
de Controlling foca-se no tratamento e análise dos dados provenientes dos processos da cadeia de
abastecimento.
Financial
Esta equipa é responsável pelas atividades financeiras da empresa, tais como a cobrança a
clientes e garantia de que todas as transações ocorrem de acordo com as normas estipuladas. Em
acréscimo, promove o desenvolvimento de KPI de performance financeiros internos, como suporte
ao desenvolvimento de estratégias futuras da empresa.
People
Esta equipa é responsável pela gestão de todas as atividades ligadas aos recursos humanos, gere
as atividades de recrutamento, organização de atividades e gestão de alguns processos internos.
Product
A equipa de Product (produto) funciona como ponte entre as equipas de negócio e as equipas
tecnológicas. As suas atividades iniciam-se com o levantamento de requisitos das equipas de
negócio e posteriormente na tradução dessas necessidades no desenvolvimento da arquitetura do
SPOKE - a plataforma de gestão global da cadeia de abastecimento, desenvolvida pela HUUB e
que é utilizada por todos os intervenientes.
As marcas podem optar pela venda em dois canais diferentes: Webshop (WS) e Wholesale .
Assim, a HUUB compromete-se a exercer o processo de abastecimento e envio para retalhistas ou
distribuição direta ao cliente final. Estes canais divergem em várias propriedades, nomeadamente,
o número de itens por encomenda, frequência de envio e processo de abastecimento. As marcas
têm vindo a converter as suas vendas para o canal WS, acompanhando as tendências do mercado.
Por sua vez, este canal representa a maioria dos envios da HUUB, apesar de ser menor em termos
de volume de peças.
O canal Webshop (B2C) representa envios individuais. Para este canal, uma encomenda é
despoletada por parte do cliente final quando ele compra um produto no website específico da
marca. Posteriormente, a HUUB é informada do pedido, executa o processo de abastecimento
da encomenda e entrega diretamente ao cliente. Neste caso, a marca envia uma coleção, em
quantidade estimada, para os armazéns, a qual fica em stock durante a estação. Apesar de métodos
de previsão utilizados, especialmente em períodos em que se espera alta procura, as quantidades
necessárias a serem expedidas são muitas vezes imprevisíveis. Este canal é o mais exigente para
a organização por apresentar envios com maior frequência e com uma promessa lead-time mais
curto.
O processo de Wholesale (B2B) diz respeito à venda em retalhistas, como, por exemplo, lojas
multi-marca. Neste caso, as quantidades vendidas, datas e localizações de entrega, são, normal-
mente, estabelecidas antes da estação começar, em feiras frequentadas pelos retalhistas e marcas,
e, por esse motivo, previsíveis para a HUUB. A previsibilidade do processo facilita a organização e
planeamento do abastecimento das encomendas. Este canal caracteriza-se pelo envio de um maior
número de itens por cada encomenda.
Todo o processo de fulfillment é mais demorado para o primeiro canal referido, uma vez que o
empacotamento, etiquetagem e destinatário, são independentes para cada item enviado, tornando
este processo mais caro, quando comparado com o B2C. Pela sua exigência e complexidade acres-
cidas, a maioria das discrepâncias de fulfillment que chegam a afetar o SLA, ocorrem no canal WS.
Assim sendo, o foco do projeto incidirá sobre as incidências deste canal.
Nesta secção é descrita a situação inicial em que os processos relevantes para a presente Dis-
sertação se encontravam.
3.2. SITUAÇÃO AS-IS 21
entrega, especialmente no canal WS. Além disso, a HUUB compromete-se a coordenar a cadeia de
abastecimento de forma física, paralelamente com transparência de informação na sua plataforma.
Neste último ponto podem ocorrer erros de integração ou disparidades de informação.
Assim sendo, a equipa de GO lida diariamente com a resolução de incidências identificadas no
decorrer do processo de fulfillment (cadeia de abastecimento), as quais, surgem como entrave ao
fluxo normal definido, provocando atrasos, não-eficiência e custos extra. Estas incidências podem
ocorrer tanto de erros do fluxo de informação como do fluxo físico das encomendas. Por outro
lado, podem ser resultantes de discrepâncias nos processos internos, chamadas discrepâncias de
serviço ou qualidade, ou causadas por fatores externos não controláveis, gerados pelos clientes
finais ou fornecedores, chamadas discrepâncias do tipo process exception. No último caso, não
contribuem para abalar o valor do SLA prometido.
se tratar de uma discrepância relativa a uma SO do armazém HUUB, as etapas seguintes são da
responsabilidade do Downstream assistant.
Este processo inicia-se com a monitorização de um ficheiro em formato Excel (status orders),
atualizado com recurso á base de dados, que visa informar sobre o estado de fulfillment de uma
encomenda. Este ficheiro permite saber se a encomenda já foi picada através de uma classificação
em três estados: "not picked"; "partially picked"; "fully picked".
Assim, dependendo de cada um desses estado, a figura 3.4 mostra os possíveis estados dis-
crepantes de uma encomenda. Como se pode observar, não é possível concluir de que incidência
se trata. Deste modo, torna-se necessário proceder à investigação da causa para especificação
da discrepância. Além disso, o ficheiro apenas permite a identificação de incidências relativas
a discrepâncias de stock, uma vez que as "fully picked"são assumidas como livres de qualquer
problema.
Na fase de investigação, é feita uma análise mais a fundo, a qual, dependendo do problema,
pode ser feita recorrendo a vários meios: análise do mesmo ficheiro (caso de discrepâncias de
stock); análise em SPOKE; contacto direto com armazéns ou com outras equipas.
Com os problemas categorizados, é tempo de os resolver. Nesta fase, há certos processos com
resolução documentada, mas muitos são relativos a incidências sem categorização estandardizada,
cuja resolução está centrada no conhecimento de experiência do colaborador.
As categorizações conhecidas nesta altura são as apresentadas na tabela 3.1
Foi mapeado o processo de identificação e resolução de incidências conhecidas no armazém
HUUB, podendo este ser consultado no anexo B. Posteriormente, mapeou-se o mesmo fluxo, mas
relativo a armazéns parceiros, também consultável no anexo B. Estes mapeamentos de processo
foram desenvolvidos por meio de observação e reuniões com os responsáveis pelas diferentes
funções.
Na figura 3.5 pode observar-se um exemplo da resolução de uma discrepância. Neste caso,
trata-se de uma incidência do tipo partial fulfillment. No presente exemplo, o problema é diagnos-
ticado pela operação. Depois, através de uma das ferramentas de comunicação, Trello ou Slack,
o dowstream assistant é avisado (assumindo que se trata de uma discrepância em armazém PT).
Este último irá notificar a equipa de BS, por e-mail ou Slack, a qual, por sua vez, irá notificar a
marca, por e-mail, acerca do item discrepante. Quando a marca responde, com a ação que quer
que seja tomada - que poderá ser, cancelar a encomenda, enviar a encomenda sem o item que
falta, ou substituir o item em falta por um outro - o downstream manager agirá de acordo com a
instrução. Assim, estando a incidência resolvida, a operação é avisada, pelo Trello ou Slack, de
forma a proceder-se em concordância.
compreende-se que o foco maior do projeto tenha incidido no canal WS, devido à maior percenta-
gem do número de discrepâncias quando comparado com o outro canal. Além disso, no armazém
HUUB, o canal B2B tem um número total de encomendas e de encomendas discrepantes pouco
significativo. No canal webshop, a percentagem observada, de entre 16% a 18% de incidências
no total de encomendas, gera um grande impacto no normal decorrer da operação, afetando o
lead-time das tarefas normais, o que leva a atrasos no ciclo de fulfillment e consequentemente de-
créscimos no SLA. O objetivo primordial do projeto foi garantir que a forma como as incidências
são tratadas é mais eficiente, fazendo com que essas não cheguem a contribuir para a penalização
do SLA.
Assim, com o objetivo final em mente, procurou-se retratar os principais pontos de falha do
processo atual. Primeiramente, eles foram identificados, através de observação e análise de alguns
3.2. SITUAÇÃO AS-IS 27
dados. Seguidamente, analisou-se a causa raiz de cada um deles, recorrendo-se ao método PFMEA
(Potential failure mode and effect analysis). Por último, definiram-se oportunidades de melhoria.
De um ponto de vista mais macro, observa-se a não definição de funções da parte dos agentes
identificadores e resolutores das incidências. Assim, por um lado, estas funções estão por vezes
duplicadas e, por outro, não tomam a prioridade que deviam. No segundo caso, os agentes res-
ponsáveis pelos fluxos de resolução de incidências, acumulam outras funções além desta, pelo
que esta função significa apenas uma parte do seu tempo ativo. No caso do armazém HUUB, o
downstream assistant é também responsável pela criação de cartas de porte e devoluções. No caso
dos armazéns 3PL, o 3PL manager é responsável pela comunicação de encomendas e contacto
com o armazém parceiro. Assim sendo, nenhum dos dois tem tempo suficiente para se focar e
especializar nesta tarefa, o que tem impacto no tempo e qualidade de resolução das incidências, e,
consequentemente no SLA.
Esta falta de tempo, leva a que não seja possível analisar as encomendas que se encontram
"on time", isto é, dentro do ciclo de fulfillment, mas que já apresentam uma incidência. Esta
análise poderia evitar atrasos e melhorar o SLA, diminuindo o número de incidências que surgem
como reclamação. Resumindo, sempre que há uma incidência, esta apenas é comunicada à marca
quando se encontra atrasada (estado "late"). Estes fatores tornam o lead-time de comunicação às
marcas muito elevado.
Quanto às incidências que surgem por via de reclamação, observa-se que não são categorizadas
no momento prévio à resolução. Quando atrasadas, gera-se um "retrabalho", por serem analisadas
no dia seguinte, sem necessidade, diminuindo os níveis de eficiência. Por outro lado, as incidências
que nunca chegam a tornar-se atrasadas, geram conflitos na fidedignidade dos dados retirados do
processo, uma vez que deviam fazer parte das ocorrências categorizadas para posterior análise.
Outro ponto chave - talvez o mais crítico notado - é a falta de estandardização e documentação
do processo. Primeiramente, grande parte dos problemas que têm de ser resolvidos não têm uma
categorização equivalente, ou seja, são categorizados em branco, o que tem impacto aquando da
28 CAPÍTULO 3. CARACTERIZAÇÃO DO ESTADO ATUAL
análise de dados. Em segunda instância, constata-se que algumas das incidências categorizadas
não tem um processo de resolução totalmente definido.
Dentro das incidências documentadas, a resolução apresenta, por vezes, fluxos redundantes,
portanto, não otimizados. Tome-se, como exemplo o fluxo representado na figura 3.5. Neste
caso, deparamos-nos com três plataformas de comunicação diferentes e, em alguns casos, a não
definição de qual delas usar para uma comunicação específica. Além disso, observa-se que a
marca é informada por intermediário da equipa de BS, a qual não cria qualquer valor à informação
passada à marca, o que aumenta bastante o tempo de comunicação e consequentemente o tempo
de resolução da incidência.
Analisando a comunicação geral do processo atual, observa-se que se revela demorada e com
pouca qualidade. Apenas 30% das tipologias de e-mails que é necessário enviar à marca, apresen-
tam um template de e-mail standard. Adicionalmente, a responsabilidade de funções, no decorrer
do fluxo de determinada incidência, por vezes não está definida, o que exige que certas comunica-
ções decorram na base de tentativa erro de encontrar o responsável da função. Quanto ao método
de comunicação usado dentro de determinado fluxo de resolução, nota-se que são usados o Trello,
o Outlook (e-mail) e o Slack. Consequentemente, é necessário que cada agente monitorize várias
plataformas em paralelo, gerando falta de foco e de método de trabalho.
O ficheiro status order, usado como meio proativo de identificação de discrepâncias, é baseado
em queries, de forma a poder concluir determinados estados do processo de abastecimento. Por
vezes, conclui-se que são despoletados falsos alarmes ou que certas ocorrências não são identifi-
cadas. Além disso, como mostra a figura 3.4, o ficheiro status order apenas permite identificar
incidências de stock, além de que não leva a concluir uma identificação clara da categoria da inci-
dência, exigindo uma posterior investigação. Todas as restantes incidências possíveis (tais como
problemas de morada, faturas, etc) são apenas identificadas no momento da comunicação da en-
comenda, pela transportadora, ou pela marca. Em suma, este ficheiro não apresenta um formato
ótimo, nem amigável do utilizador, o que leva a trabalho extra e, consecutivamente, a maiores
tempos de resolução de incidências.
O último ponto observado é relativo à forma discrepante de alocação de stocks, quando se
compara o armazém e a operação (downstream assitant, 3PL manager). Observa-se que o ficheiro
status order aloca o stock segundo o método FIFO (first in, first out), e por isso, as incidências
de stock são categorizadas segundo esse regime. No entanto, as encomendas em 3PL são comu-
nicadas segundo o método LIFO (last in, first out). Por último, em armazém, as encomendas
são picadas por ordem da primeira transportadora que as virá recolher. Esta falha de informação
gera falsas comunicações de incidências às marcas e novas incidências de stock não previstas, que
poderiam ser evitáveis caso a alocação se desse de forma uniforme.
No anexo B é mostrada uma explicação mais detalhada dos problemas identificados e seguida-
mente descritos, através da análise PFMEA, bem como a potencial causa, características críticas
e recomendações de melhoria. Nesta análise, avaliaram-se ainda a gravidade, a probabilidade de
ocorrência, a probabilidade de deteção e o risco associado a cada potencial modo de falha. Tal
análise, surgiu como auxílio à definição do foco seguido no desenho de soluções, de acordo com
3.2. SITUAÇÃO AS-IS 29
Com base nos problemas descritos anteriormente, e com o auxílio da análise PFMEA, foram
levantadas as seguintes oportunidades de melhoria:
Este capítulo pretende completar a fase "Plan"do ciclo PDCA, referido no capítulo 2, através
do desenho de soluções e proceder à fase "Do", referente à implementação das soluções dese-
nhadas. Os problemas enunciados no capítulo 3 dividem-se, fundamentalmente, em dois grandes
grupos: problemas processuais e problemas de comunicação. Assim, o desenho e implementa-
ção de soluções, que surgem como resposta às falhas identificadas, dividiu-se-se em duas fases
distintas, apresentadas na figura 4.1. A primeira fase pretende responder aos problemas proces-
suais referidos no capítulo 3. Essa fase, consiste num redesenho e normalização do processo de
identificação e resolução de incidências de fulfillment. A segunda fase incide sobre os problemas
relativos à comunicação, para a qual se recorreu à implementação de uma plataforma de gestão de
serviços, transversal a todos os intervenientes internos.
As soluções desenhadas, foram pensadas com o objetivo de acréscimo dos níveis de SLA, di-
minuição dos tempos de resolução de incidências e dos custos operacionais associados e melhoria
da comunicação externa e interna. Além disso, as soluções foram desenhadas procurando priorizar
a resposta às potencias falhas detetadas que revelaram um maior risco na análise PFMEA.
30
4.1. FASE 1 - MELHORIA DO PROCESSO DE IDENTIFICAÇÃO E RESOLUÇÃO DE INCIDÊNCIAS31
Noutro novo campo que foi introduzido, é possível ver o estado da encomenda comparativa-
mente ao ciclo de fulfillment, tempo de duração do abastecimento da encomenda necessário de
acordo com o SLA. Assim, se a encomenda apresentar o estado "late"significa que está atrasada
devido a alguma discrepância e se apresentar o estado "on time", que ainda não ultrapassou o
tempo necessário do ciclo de fulfillment, o que não significa que não o apresente no dia seguinte.
A combinação do estado relativo aos stocks e ao ciclo de fulfillment pode despoletar as incidências
que se encontram identificadas na figura 4.2, caso a encomenda se encontre atrasada. No caso
da encomenda ainda estar a tempo de ser abastecida, as incidências passíveis de ser identificadas
pelo ficheiro estão identificadas na figura 4.3. Pela análise da figura 3.4 e das figuras referidas
anteriormente, é possível comparar a facilidade de identificação de incidências na versão anterior
e na versão atualizada, sendo que esta última se apresenta mais ágil.
Figura 4.2: Incidências possíveis de serem identificadas na nova versão do ficheiro status order
quando a encomenda se encontra no estado "late"
Assim, passa a ser possível identificar novas incidências que não eram passíveis de identifica-
ção no ficheiro antigo. Nomeadamente, todas as incidências relativas aos problemas que advêm
do estado "fully fulfillable", apesar de nestes casos serem necessárias novas investigações para en-
tender de que incidência de facto se trata. As incidências de stocks, estado "partially fulfillable"e
"not fulfillable", têm agora o problema especificado no ficheiro, não sendo necessário recorrer a
investigações complementares. Além disto, é possibilitada a identificação de incidências relativas
a encomendas "on time", ou seja, dentro do ciclo de fulfillment.
Com o novo ficheiro, pretende-se que a informação sobre as incidências seja mais precisa e
acessível. Consequentemente, consegue-se que a informação passada a intervenientes externas
seja transmitida com uma maior qualidade. Por último, uma vez que o número de investigações
complementares necessárias, se torna menos significativo, espera-se que o processo de torne mais
eficiente, através do decréscimo do tempo de identificação de cada incidência.
4.1. FASE 1 - MELHORIA DO PROCESSO DE IDENTIFICAÇÃO E RESOLUÇÃO DE INCIDÊNCIAS33
Figura 4.3: Incidências possíveis de serem identificadas na nova versão do ficheiro status order
quando a encomenda se encontra no estado "on time"
prova seja maior do que o valor de significância da análise, HO deverá ser rejeitado, provando-se
que as variáveis de interesse não apresentam uma associação significativa. (Zou et al., 2010) Para
tal, atribuiu-se um código numérico a cada incidência. Com um valor r (correlação) de 0,076 e
um valor de prova de 0.1957, rejeitou-se a hipótese nula, uma vez que o valor de prova é maior do
que o o nível de significância usado (0,05). Esta análise permitiu avançar com, segurança, com o
método de divisão em classes, proposto anteriormente.
Assim, mapeou-se o fluxo de resolução de cada uma das classes. O fluxo de resolução da
classe A está representado na figura 4.4, o da classe B na figura 4.5. Finalmente, o da classe C está
representado na figura 4.6. No fluxo C, os outros agentes podem ser a sub-equipa de supply chain
controlling, a equipa de BS, a equipa de BD e finalmente a operação, que se subdivide dependendo
do armazém em que se desenrolou a incidência.
Na tabela D.3, no anexo D encontra-se a lista de incidências categorizadas por cada uma das
classes de resolução.
Criação de OPL
Primeiramente, procedeu-se à criação de OPL; trata-se de um instrumento baseado em tuto-
riais explicativos de determinadas ações. O objetivo é que colaboradores que estejam a realizar
determinado processo pela primeira vez consigam fazê-lo corretamente, apenas com recurso ao
documento. (Rice and Liu, 2017).
Criaram-se as seguintes OPL:
• Preenchimento do ficheiro azul, explicando-se qual a categorização correta para cada caso;
4.2. FASE 2 - IMPLEMENTAÇÃO DE UMA PLATAFORMA CRM PARA GESTÃO DE INCIDÊNCIAS37
Sessões de treino
Com os materiais prontos, prosseguiu-se com as sessões de treino. Estas iniciaram-se com uma
reunião geral de abertura da implementação. Posteriormente, foi dada formação mais detalhada
aos intervenientes. Esta foi baseada na parte processual ligada às suas áreas de atuação, e, por isso
personalizada para cada um deles.
Hypercare
Após a fase 1 do projeto estar implementada, seguiu-se a fase de Hypercare. Nesta, mediram-
se, diariamente, indicadores que determinaram o sucesso das melhorias alcançadas com o novo
processo. Os indicadores e os respetivos resultados serão analisados no capítulo 5. Além da com-
ponente analítica, os intervenientes mais importantes do processo foram acompanhados de perto,
de forma a garantir que o os objetivos delineados estavam a ser rigorosamente cumpridos. Esta
fase apenas terminou quando deixaram de se verificar falhas processuais e quando os principais
intervenientes se mostraram confortáveis com a mudança.
Tendo com objetivo colmatar os problemas de comunicação e falta de foco (informação dis-
persa por várias plataformas), decidiu implementar-se uma plataforma CRM para a gestão de In-
cidências. A plataforma escolhida foi o Hubspot, que se encontra brevemente descrita no capítulo
2. Pretende-se com esta implementação melhorar os fluxos de comunicação.
Esta plataforma revela-se fundamental para a função de CS manager, tal como referido no
capítulo 2. Espera-se que o processo de contacto com as marcas, referentes à resolução das in-
cidências classe A, seja melhorado, que os tempos de resposta decresçam e que o tratamento de
pedidos de clientes seja mais eficiente.
38 CAPÍTULO 4. PROPOSTA DE SOLUÇÕES E A SUA IMPLEMENTAÇÃO
Nesta secção é explicada a arquitetura que foi desenvolvida em Hubspot para a resolução de
incidências de fulfillment. Inicialmente, apresenta-se a construção técnica da plataforma. Segui-
damente, refere-se como foram usadas as funcionalidades do Hubspot para o desenvolvimento de
uma solução capaz de responder ao desafio proposto.
4.2.1.1 Tickets
Um ticket corresponde a uma incidência. Assim, sempre que uma incidência é detetada, um
ticket é criado para que a incidência a que ele se refere seja resolvida. Dentro do ticket estão organi-
zados os e-mails, que correspondem ao assunto da incidência, a notas deixadas por colaboradores
que também intervieram na sua resolução e todas as propriedades que descrevem a discrepância.
4.2.1.2 Pipelines
Um pipeline corresponde ao local onde os tickets estão gravados e onde o backlog de trabalho
é gerido. Assim, um ticket pode estar em determinados estados do pipeline, sendo esses estados
personalizáveis.
Veja-se, como exemplo, a figura 4.8. Cada cartão branco corresponde a um ticket; em cada
um deles é possível identificar-se o título, o responsável pela resolução (owner), a prioridade e em
que estado de resolução se encontra. Se se abrir o ticket, podem ser consultadas propriedades com
informação mais detalhada. Os pipelines encontram-se organizados em diversas fases de resolu-
ção. Dentro do pipeline a informação pode ser filtrada, de forma a que apareçam apenas os tickets
relativos a determinado owner, ou de determinada prioridade, ou qualquer outra propriedade. No
caso da figura 4.8, pretende-se que, quando o agente se informa sobre uma incidência, mova o
ticket para o estado "to solve", quando a resolução está em curso para o estado "being solved"e
4.2. FASE 2 - IMPLEMENTAÇÃO DE UMA PLATAFORMA CRM PARA GESTÃO DE INCIDÊNCIAS39
quando a incidência está resolvida, para o estado "closed". Cada um desses estados (status) pode
ter automatismos que agilizam o processo de resolução que deve ser concretizado nesse estado
específico.
Com esta arquitetura, pretendeu-se que cada agente de resolução apenas trabalhasse num só
pipeline, centralizando-se lá todo o seu backlog de trabalho.
Pipeline A
Este pipeline é exclusivamente gerido pelo CS manager e serve para a função de assistência
ao cliente, ou seja, contacto com as marcas.
As fases desenhadas para este pipeline podem ser vistas na figura 4.9. Pretende-se que quando
um ticket é criado, este fique na fase "New". Em seguida espera-se que seja arrastado para a fase
"Waiting on brand", ingressando num fluxo de envio de e-mail automático à respetiva marca, com
o template correspondente à incidência de fulfillment específica. Por forma a que certa informação
possa ser diferente em cada e-mail automático enviado, os dados específicos de cada incidência
são inseridos como propriedade do ticket, fazendo parte das colunas a preencher no ficheiro de
importe. Quando a marca responde ao e-mail enviado, o ticket é movido automaticamente para o
estado "New repply from brand", através do ingresso noutro workflow criado. Quando o assunto se
encontrar tratado, o ticket é finalmente movido para o estado "Closed". Se a marca não responder
ao e-mail num período superior a dois dias úteis, um novo workflow será despoletado para envio
de um e-mail de lembrança ao contacto.
Esta arquitetura pretende ter uma gestão visual do backlog, permitindo saber que os únicos
tickets que é necessário gerir, são os contidos na fase "New repply from brand". Além disso, ela
permite remover os tempos de envio de e-mails e tempos administrativos acrescidos devido a uma
gestão não organizada do backlog diário.
Pipeline B
Este pipeline serve, apenas, para que se saiba que ocorreu determinada incidência, com certas
propriedades. Quando um ticket ingressa neste pipeline, no estado "New", é automaticamente mo-
vido para o estado "closed". Assim sendo, este pipeline não requer a sua gestão por um utilizador,
uma vez que trata incidências sem resolução necessária.
4.2. FASE 2 - IMPLEMENTAÇÃO DE UMA PLATAFORMA CRM PARA GESTÃO DE INCIDÊNCIAS41
Pipeline C
Este pipeline serve para contemplar a funcionalidade de um automatismo de lançamento para
outros pipelines correspondentes aos respetivos agentes de resolução da incidência. Na figura
4.10, pode ser observada a arquitetura do pipeline C.
Quando o ticket é criado, localiza-se no estado "New"e deste estado é passado automatica-
mente para o estado "Changing to another owner/pipeline". Nesta fase, é despoletado o workflow
"Mudança de pipeline", o qual pode ser observado por dois trechos nas figuras F.1 e F.2, contidas
no anexo F. Esse workflow permite que o owner seja alterado para o agente resolutor da incidên-
cia e o pipeline trocado para aquele gerido por esse owner, dependendo da propriedade "Issue
Category"que descrimina a categoria da incidência. Depois de cumprir este workflow, o ticket de-
saparece do pipeline C, aparecendo no novo pipeline. Quando o ticket é fechado pelo novo owner,
no respetivo pipeline para o qual foi lançado, volta para o estado "Closed"do pipeline C.
Na tabela 4.1, estão representados os pipelines e owners para onde o ticket é lançado pelo
pipeline C, dependendo da categoria da incidência.
Esta arquitetura possibilita a redução dos tempos de comunicação aos agentes de resolução,
ou comunicações erradas. Possibilita, ainda, que a informação chegue aos agentes de resolução de
forma mais precisa, estruturada e rapidamente.
Quando o agente de resolução tem alguma questão ou informação a acrescentar ao ticket, tem
a possibilidade de recorrer à funcionalidade das notas, colocando uma anotação a ser consultada
42 CAPÍTULO 4. PROPOSTA DE SOLUÇÕES E A SUA IMPLEMENTAÇÃO
Uma vez que a plataforma, de algum modo, consistiu numa solução disruptiva para a equipa,
decidiu-se recorrer a uma implementação faseada, de acordo com o diagrama da figura 4.11
Desenvolvimento de OPL
Após a fase anterior, desenvolveram-se as OPL de funcionamento geral da plataforma, do
preenchimento das propriedades dos tickets e das ferramentas de gestão de backlogs de trabalho
existentes.
Sessões de treino
Seguidamente, desenrolaram-se várias sessões de treino, aos diversos intervenientes da equipa
de GO e supply chain controllers, à semelhança da fase 1. Nessas sessões foi explicado o funciona-
mento da plataforma e dos pipelines específicos a serem utilizados por cada um dos colaboradores.
Por fim, apresentaram-se as ferramentas existentes de gestão diária do backlog em Hubspot.
Implementação
4.3. FERRAMENTA A3 DE GESTÃO DE PROJETO 43
Nesta fase procedeu-se ao início da utilização da plataforma para gestão de incidências. Ini-
cialmente, em paralelo com o ficheiro azul, para que não fosse perdida a visibilidade dos dados
gerados, no caso de erros. Quando se demonstrou uma coerência total de ambos os meios, du-
rante um período de tempo considerado razoável, abandonou-se o método antigo, passando-se a
proceder, apenas, de acordo com o processo montado em Hubspot.
Devido à sensibilidade do envio de e-mails automáticos, inicialmente, desempenhou-se o pro-
cesso montado com e-mails manuais. Quando o CS manager se revelou confortável no uso da
plataforma, ativou-se o fluxo de envio de e-mails automáticos. Deste modo, deu-se como imple-
mentada a fase 2. Seguiu-se a fase de hypercare.
Hypercare
Nesta fase, foi acompanhado, diariamente, e com os vários intervenientes, o novo processo,
tornando-o mais fluído. Mediram-se indicadores de melhoria, sendo os resultados obtidos alvo de
análise no capitulo 5. Esta fase foi dada com concluída, quando deixaram de se verificar falhas na
utilização da plataforma e no desempenho do processo desenhado.
Como já referido ao longo da dissertação, o SLA é o principal indicador de serviço e por isso
o principal indicador da melhoria alcançada pelas medidas propostas na presente Dissertação. É
também por este indicador que se mede o sucesso da equipa de SC.
O SLA mede a percentagem de encomendas pedidas que são abastecidas, a tempo de serem
enviadas antes da data limite de envio estipulada. Através de um algoritmo desenvolvido pela
equipa de BI, é calculada a data limite de envio, para que a encomenda chegue ao destino no dia
combinado. Assim, se por interferência de uma incidência de responsabilidade interna a enco-
menda não tiver sido expedida até essa data, irá contribuir para a penalização do indicador. É
importante notar que as encomendas cujo atraso é refletido por uma incidência do tipo process
exception (ocorrência de responsabilidade da marca) não contribuem para a penalização do SLA.
Através do dashboard construído pela equipa de SC controlling em Power BI, foi possível
captar informação diária sobre o estado do indicador e das incidências que ocorreram. Deste modo,
extraíram-se os dados referentes ao SLA do mês 0 (fase 0) - antes de qualquer implementação -
do mês 1 (fase1) - após a primeira fase de implementações descrita no capítulo 4 - e, por fim, dos
meses 2 (fase 2a)) e 3 (fase 2b)), quando a fase 2 se encontrava implementada.
Por sua vez, de forma a avaliar se o aumento do nível de serviço se deveu a uma diminuição
do volume de trabalho, em vez de ter sido causado pela otimização das operações, importa cruzar
aquele indicador com o número de encomendas consideradas fulfillable, que não revelaram uma
44
5.1. ANÁLISE AO SERVICE LEVEL AGREEMENT (SLA) 45
process exception (PE), em cada um dos períodos. A análise feita está compilada num gráfico que
pode ser observado na figura 5.1
Entre a fase 0 e a fase 1, observa-se um aumento abrupto do SLA, de 88% para 96%. Entre
as duas fases, foram implementadas as soluções de otimização processual que se acredita que
tenham sido o agente com o maior impacto nesta alteração, apesar da diminuição do volume de
encomendas.
A fase 2 foi subdividida em dois meses, a) e b), uma vez que a fase 2b) se caracterizou pela
presença de variados fatores externos que se acredita terem penalizado o indicador.
Entre as fases 1 e 2 a) verifica-se que o SLA aumentou 1%, apesar do aumento do número
de encomendas nesse mês ter sido consideravelmente mais elevado. Apesar do valor do indicador
se manter praticamente inalterado, prova-se que a melhoria dos fluxos de comunicação e a apli-
cação da plataforma Hubspot contribuíram para tornar o processo mais ágil, tornando-o imune a
aumentos de procura neste período.
Entre as fases 0 e 2b) observa-se um decréscimo de 5% do SLA, comparando com o mês
anterior (fase 2a)). Este mês caracterizou-se pela saída de um número considerável de colabora-
dores da equipa, essenciais à operação do processo, férias de outros colaboradores, e por fim, um
período alto de procura, devido à época do Natal. Atendendo a estes fatores, considera-se este
período como atípico, julgando-se que não deva ser contabilizado na retirada de conclusões sobre
a eficácia das soluções implementadas.
Não obstante, quando comparados os meses extremos da análise, é visível uma variabilidade
positiva de 4 pontos percentuais. Conclui-se assim que, apesar dos fatores incontroláveis descritos,
os novos processos se revelaram eficazes.
Assumindo as fases 0 e 2a) como as fases inicial e final da análise, observa-se que o indicador
passou de 88% para 97% desde o início ao final do projeto, aumentando em 9%. Prevê-se que a
melhoria do indicador em análise se traduza diretamente num aumento da satisfação, generalizada,
46 CAPÍTULO 5. ANÁLISE DOS RESULTADOS OBTIDOS
Como referido no tópico anterior, as incidências categorizadas como process exception (PE)
não penalizam o SLA. Deste modo é interessante relacionar as restantes incidências, quality is-
sue e service level, com o total de encomendas que não foram enviadas dentro da data limite de
expedição e prejudicaram, por isso, o SLA.
Na figura 5.2 está representado um gráfico de barras com o número de encomendas discrepan-
tes diferentes de PE e o número de encomendas fulfillable (sem PE) que não foram expedidas a
tempo. Nesta análise, parte-se do pressuposto que todas as encomendas que não foram abastecidas
dentro do ciclo de fulfillment, não o foram devido a incidências de fulfillment.
Figura 5.2: Percentagem de encomendas fulfillable enviadas com atraso devido a uma incidência
diferente de PE
Na fase inicial, fase 0, observa-se que 101% das encomendas com discrepâncias não foram ex-
pedidas a tempo. O facto deste valor ser superior a 100% resulta de que na fase inicial não tenham
sido categorizadas a totalidade das incidências. Adicionalmente, naquela fase as incidências "on
time"não eram analisadas, levando a que a totalidade das encomendas incidentes que o tenham
sido quando já se encontravam atrasadas. Assim, caso todas tivessem sido categorizadas, o valor
seria, obviamente, 100%, valor a ser usado nesta análise.
5.2. ANÁLISE ÀS INCIDÊNCIAS COM INFLUÊNCIA DIRETA NO SLA 47
Na fase 1, as incidências "on time"passaram a ser categorizadas, o que não significa que as res-
petivas encomendas tenham conseguido ser enviadas dentro da data limite de expedição. Observa-
se que 82% das encomendas com incidências originaram envios atrasados. No entanto, os restantes
18% foram resolvidos a tempo de serem enviadas dentro da data limite de expedição estipulada.
Acredita-se que esta melhoria de 18%, em relação à fase anterior, se deve à especialização da
função CS manager, ao início da análise das incidências "on time"e à maior eficácia geral do
processo.
Na fase 2a), apesar do total de encomendas discrepantes relativas à fase anterior ter aumen-
tado, verificou-se que o indicador em análise decresceu para 62%, menos 20% do que na fase
anterior. Com a nova plataforma de comunicação, Hubspot, gerou-se mais tempo para a análise e
tratamento das incidências "on time". Prova-se, assim, que com fluxos de resolução centralizados
e otimizados, há a oportunidade de resolver as incidências de forma mais rápida, de modo a serem
enviadas dentro da sua data limite de expedição.
Na fase 2b), observa-se que o indicador em análise piora, ou seja, 87% das encomendas com
incidências originaram atrasos. Pensa-se que esta regressão relativamente à fase anterior se deva
aos fatores incontroláveis descritos na secção 5.1.
Analisando as fases consideradas como extremas do projeto, fase 0 e 2a), nota-se que 38%
das encomendas que não eram enviadas dentro da data limite de expedição, devido a incidências
diferentes de PE, passaram a sê-lo. Ou seja, a variação do indicador foi de 100% para 62% desde
o momento incial ao momento final do projeto.
Este indicador revela um impacto direto no SLA, uma vez que, matematicamente, quanto
maior for o número de encomendas não enviadas devido a uma incidência de responsabilidade
interna, menor será o SLA.
Quando comparada a fase 1 com a fase 2a), verifica-se que a percentagem de incidências se
mantém, o que já era esperado, uma vez que entre as duas fases não foram implementadas medidas
preventivas para a ocorrência de discrepâncias.
Por outro lado, entre as fases 2a) e 2b), observa-se que a percentagem em análise aumenta 4
pontos percentuais, alterando o indicador para 9%. Este aumento não ótimo, é justificado, nova-
mente, pelos fatores incontroláveis vividos no mês em análise, prevendo-se que na sua ausência o
indicador se mantivesse praticamente inalterado face ao mês anterior.
Entre a fases inicial (fase 0) e final (fase 2a)) do projeto, a percentagem de incidências (dife-
rentes de PE) num total de incidências fulfillable, alterou-se de 12% para 5%.
48 CAPÍTULO 5. ANÁLISE DOS RESULTADOS OBTIDOS
Tabela 5.1: Tempo médio de abastecimento de uma encomenda discrepante (em dias)
Figura 5.4: Tempo médio decorrido no abastecimento de uma encomenda discrepante (em dias)
representativa. No entanto, o desvio padrão diminuiu consideravelmente, o que revela uma uni-
formização no número de dias necessários ao abastecimento de uma encomenda discrepante, que
se acredita ser representativa da uniformização dos fluxos de comunicação.
Entre as fases 2a) e 2b) observa-se que, apesar da crise identificada, o processamento de enco-
mendas se tornou ligeiramente mais rápido, a média (x̄) decresceu. O desvio padrão manteve-se
praticamente inalterado.
Concluindo, ambas as fases do projeto mostraram ter potencial para a diminuição do tempo
de abastecimento de encomendas com incidências identificadas. Por outro lado, observa-se uma
menor variabilidade no número médio de dias necessários para o processo. Note-se que, no canal
webshop, o tempo de fulfillment deve estar compreendido entre 0 e 1 (mesmo dia, dependo da hora
de processamento) e, no canal wholesale, entre 1 a 2 dias (dia seguinte), de forma a cumprir o SLA,
como referido no capitulo 3. No final do projeto, fase 2b), o indicador encontra-se mais próximo
de cumprir o tempo de abastecimento prometido às marcas (1,553 dias), apesar da encomenda ter
enfrentado uma ou mais incidências ao longo do processo.
o custo médio administrativo unitário de uma encomenda discrepante (CA), em função de X, pela
seguinte fórmula:
CA = T F × 8 × X × 6
Na tabela 5.2 é apresentado o valor de CA, em função do parâmetro X, para cada uma das
fases. Analisando o conteúdo da tabela, conclui-se que entre as fase 0 e 1, o CA sofreu um
decréscimo de 35%. Entre as fase 1 e 2a) sofreu um decréscimo de 5% e, finalmente, entre as
fases 2a) e 2b), um decréscimo de 16%; esse decréscimo é de 48% entre as fases inicial e final
do projeto. Acredita-se que esta redução tenha sido motivada pelas mesmas razões que levaram à
melhoria do indicador em análise na secção 5.3. Neste caso, a redução do custo, possibilita que
haja o processamento de um maior número de encomendas e consecutivamente uma influência
positiva sob SLA. Além disso, permite uma maior margem, para resposta a períodos de pico de
procura. Eventualmente, implica a alocação destes recursos monetários poupados a outras tarefas
relevantes, isto é, alocação do trabalhador a novas tarefas para as quais o seu salário seria aplicado.
Pretendeu-se com esta análise averiguar a precisão do reporte diário de incidências de fulfill-
ment. Para tal, analisaram-se os dados de um armazém como amostra, HUUB (dados da população
de encomendas da HUUB, dos meses 0, 1, 2 e 3 (fase 0, 1, 2a), 2b) retirados da base de dados).
Recorreu-se à avaliação da quantidade de encomendas discrepantes que não demonstraram qual-
quer categorização específica. Os resultados do estudo podem ser consultados na tabela 5.3
Inicialmente, a maioria das encomendas discrepantes não era categorizada com uma incidên-
cia específica, uma vez que não havia categorizações suficientes e o processo de identificação não
estava otimizado nem normalizado. Com a criação de novas categorizações e com a construção
de métodos de identificação de incidências mais eficientes, o número de categorizações aumentou
41% (até à fase 1). Quando os colaboradores se tornaram mais especializados e quando o Hubs-
pot foi implementado, com obrigatoriedade de classificação das incidências, a categorização de
incidências passou a ocorrer para a totalidade das encomendas discrepantes, 100%.
A falta de precisão dos dados categorizados nas primeiras fases da Dissertação, levou a que as
análises relativas às categorias, classes das incidências e tempos incorridos desde a categorização,
não fossem conclusivas. No entanto, quando houver uma maior fiabilidade dos dados disponíveis,
espera-se que aquelas análises sejam possíveis e venham a contribuir para a tomada de decisões
importantes.
Por fim, analisou-se a probabilidade de ocorrência de cada uma das incidências, após se te-
rem implementado as soluções desenhadas do projeto, de forma a avaliar a eventual necessidade
de trabalhos futuros. Como referido anteriormente, apenas a fase 2 do projeto apresenta dados
fidedignos relativos às categorizações, tendo sido, portanto, a única fase em que foi possível a
condução da presente análise.
Pela análise da população dos meses da fase 2 chega-se à distribuição representada no gráfico
da figura 5.6
Observa-se que o menor grupo de incidências (11%) se classifica como tipo A (contacto com as
marcas). É também neste grupo onde se localiza a maioria das incidências consideradas como PE.
Estima-se que o tempo de resolução de incidências deste grupo tenha descido significativamente
com a implementação da plataforma CRM e e-mails automáticos. Assim sendo, acredita-se que a
resolução de incidências deste grupo se encontra otimizada.
As incidências do tipo B representam 30% da população. Este tipo de incidências não requer
5.8. RESUMO DOS RESULTADOS DOS INDICADORES ANALISADOS 53
resolução. De qualquer das formas, sugere-se a condução de uma análise futura aos principais mo-
tivos de ocorrências das mesmas, por forma a potenciar uma diminuição do número de incidências
desta classe.
O grupo C, que requer a intervenção de outros agentes, como equipas externas, representa
59% das incidências totais. Sugere-se que, no futuro, o processo de resolução conduzido por estes
intervenientes, mesmo externos à equipa, constitua um trabalho conjunto de melhoria, por forma
a atingir métodos de resolução, mais rápidos e mais inovadores, alinhados ao longo de toda a
empresa.
Conclusões
54
55
apresenta 59% das ocorrências na fase 2. Para tal, sugere-se a integração do Hubspot com os
armazéns 3PL. Com isto, pretende-se que as resoluções das incidências, nas quais os armazéns
se tornam frequentemente agentes de resolução, se dêem de forma mais rápida, centralizada e
transparente.
Por outro lado, no futuro, seria desejável que a plataforma fosse estendida à resolução de outro
tipo de incidências, essencialmente nas áreas do tracking e do inbound. O objetivo final preten-
dido, seria que todos os processos de trabalho recorrente, estivessem englobados na plataforma
Hubspot, para que o trabalhador viesse a ter uma visão global do backlog diário de trabalho e da
prioridade das tarefas. Além disto, a presente medida, a ser concretizada, permitiria tornar todas
as comunicações da empresa (internas e externas) mais fluídas.
Referências
Al-homery, H. A., Asharai, H., and Ahmad, A. (2019). The Core Components and Types of CRM
I . Introduction. 7(1):121–145.
Amaresan, S. (2019). 7 Ways to Set Up Automated Customer Service in 2019. https:
//blog.hubspot.com/service/automated-customer-service. (último acesso:
15/11/2019).
Bhuiyan, N. and Baghel, A. (2005). An overview of continuous improvement: From the past to
the present. Management Decision, 43(5):761–771.
Boon-itt, S., Wong, C. Y., and Wong, C. W. (2017). Service supply chain management pro-
cess capabilities: Measurement development. International Journal of Production Economics,
193:1–11.
Butler, B. and Carignan, M. (2017). Developing a CRM Strategy for Small Businesses. Merrimack
ScholarWorks.
Campbell, A. J. (2003). Creating customer knowledge competence: Managing customer relati-
onship management programs strategically. Industrial Marketing Management, 32(5):375–383.
Chakravorty, S. S. (2009). Process Improvement: Using Toyota’s A3 Reports. Quality Manage-
ment Journal, 16(4):7–26.
Christopher, M., Lowson, R., and Peck, H. (2004). Creating agile supply chains in the fashion
industry. International Journal of Retail & Distribution Management, 32(8):367–376.
Ciervo, J., Shen, S. C., Stallcup, K., Thomas, A., Farnum, M. A., Lobanov, V. S., and Agrafiotis,
D. K. (2019). A new risk and issue management system to improve productivity, quality, and
compliance in clinical trials. JAMIA Open, 2(2):216–221.
Croxton, K. L. (2003). The Order Fulfillment Process. The International Journal of Logistics
Management.
Ellram, L. M., Tate, W. L., and Billington, C. (2004). Understanding and managing the Services
Supply Chain. The Journal of supply Management.
Expresso (2019). Web Summit. HUUB apresenta programa de transparência carbónica para in-
dústria da moda. https://expresso.pt/web-summit/2019-11-04-Web-Summit.
-HUUB-apresenta-programa-de-transparencia-carbonica-para-industria-da-moda.
(último acesso: 16/11/2019).
Giorgetti, A., Cavallini, C., Ciappi, A., Arcidiacono, G., and Citti, P. (2017). A holistic model for
the proactive reduction of non-conformities within new industrial technologies. International
Journal of Mechanical Engineering and Robotics Research, 6(4):313–317.
57
58 REFERÊNCIAS
Hines, P. and Rich, N. (1997). The seven value stream mapping tools Peter. Lean Enterprise
Research Centre, Cardiff Business School, Cardiff, UK Introduction, 17(1):46–64.
Ivanov, N. (2015). Analysis of the Data Using a Semantic Network as a Tool for Management
Non-Conformities in Quality Management System. Modern Applied Science, 10(1):47.
Johnson, K. G. and Khan, M. K. (2003). A study into the use of the process failure mode and
effects analysis (PFMEA) in the automotive industry in the UK. Journal of Materials Processing
Technology, 139(1-3 SPEC):348–356.
Lambert, D. M. and Enz, M. G. (2017). Issues in Supply Chain Management: Progress and
potential. Industrial Marketing Management, 62:1–16.
Lang, A., Paravicini, D., and Revaz, E. (2002). From Customer Relationship Management ( CRM
) to Supplier Relationship Management ( SRM ). Management, 2002:81.
Rice, V. J. and Liu, B. (2017). Advances in Social & Occupational Ergonomics. Springer, 605
edition.
Smith, A. (2006). CRM and customer service: strategic asset or corporate overhead? Handbook
of Business Strategy, 7:87–93.
Sobek, D. K. and Jimmerson, C. (2004). A3 reports: Tool for process improvement. IIE Annual
Conference and Exhibition 2004, m:1047–1052.
Sokovic, M., Pavletic, D., and Pipan, K. K. (2010). Quality Improvement Methodologies – PDCA
Cycle, RADAR Matrix, DMAIC and DFSS. Journal of Achievements in Materials and Manu-
facturing Engineering, 43(1):476–483.
Sutherland, J., Viktorov, A., Puntikov, N., and Blount, J. (2007). Distributed Scrum: Agile Pro-
ject Management with Outsourced Development Teams. IEEE Transactions on Antennas and
Propagation, 39(3):309–317.
Tezel, A., Koskela, L., and Tzortzopoulos, P. (2016). Visual management in production manage-
ment: A literature synthesis. Journal of Manufacturing Technology Management, 27:766–799.
Wagner, J., Jones, M., and Nash, K. (2016). Issue management and sustainability: Lessons from a
major oilfield development in Madagascar. Society of Petroleum Engineers - SPE International
Conference and Exhibition on Health, Safety, Security, Environment, and Social Responsibility.
Yadav, S. (2016). “Customer Relationship Management Is the Need of Today”. BEST: Internati-
onal Journal of Humanities, Arts, Medicine and Sciences (BEST: IJHAMS), 4(2):107–116.
REFERÊNCIAS 59
Yemisi, A., Bolumole, A., and Lambert, M. (2003). The Customer Service Management Process.
International Journal of Logistics Management, 14(2):15–31.
Zhen Yong, C. (2014). Customer Relationship Management (CRM) System. Faculty of Informa-
tion and Communication Technology (Perak Campus), UTAR, 53(9):1689–1699.
Zou, K. H., Tuncaly, K., and Silverman, S. G. (2010). Correlation and simple linear regression.
Statistical Concepts Series, 27(4):427–434.
Apêndice A
Nota: O primeiro mapa de processo é relativo ao processo do armazém HUUB. O segundo mapa
de processo refere-se ao processo nos armazéns CBFashion e Agility (armazéns 3PL).
60
Excel Status Orders
(tab daily ecommerce) -
Filters: Unfulfilled, Excel Customer
Late, Webshop, Issue Support Report
as blank Standard
Private orders are not
considered in this
filter
Error on
No No A
invoice?
Wrong
Address? Yes
Yes
1.Identify new No
Search for the SO 2.Fill excel file with
orders that need Need to
in Spoke issue details
investigation contact
brand?
Is other problem
with stock? Is possible to identify the
DS
Yes
Evadne: just check
this old issues Identify Operation
when has time in "Pending "Card
DS visit this card Act accordingly or "Cartas de A
when has time Porte Manual +
Invoice"
Go to "Cartas de Need to
contact Pending Card is more
Porte + Invoice" used to identify stock
brand? Contact Brand
problems
Yes
- Filters: Unfulfilled,
Late, Webshop, Send feedback
Send feedback
Issue filled
HUUB
BD
Excel Status
Orders tab:
fulfilment
Yes
Communicate
Contact Brand A
response to WH
Send feedback
63
P F M E A - Potential Failure Mode Effect Analisys
(risk priority
Ocorrência
Gravidade
number )
Deteção
RPN
Potencial Modo de Falha Potencial Efeito Potencial Causa Atuais Controlos Características críticas Ações Recomendadas
Os dados provenientes do
"Retrabalho", categorizações erradas, baixa Queries não são ótimas; Processo de atualização do
Status orders nem sempre são 7 7 Comunicação com outros membros da equipa 4 196 Estrandardização do backlog geral pela lógica FIFO
produtividade. ficheiro
fidedignos
A equipa de BS já procedeu à
Comunicar a incidências duas vezes;
comunicação com as marcas de Falta de normalização da comunicação - Dúvida Definir claramente em que casos deve ser BS a comunicar a incidência à marca
Baixa produtividade - DS verifica com a equipa de BS 4 5 Comunicação informal entre BS e DS 4 - 80
modo a informá-las sobre a sobre os casos em que deverá ser BS a comunicar as
se a incidência já foi comunicada
incidência. incidências às marcas
Agentes de resolução acumulam diferentes funções; Redefinição das funções dos colaboradores e especialização; Definição de agentes responsáveis
Resolução de incidências não é Diminuição do SLA; Descontentamento dos clientes; Não há uma ferramenta de organização do backlog de trabalho
9 Não definição dos responsáveis pela resolução e das 8 Reclamações da equipa de BS 4 288 por cada ação do processo; Categorização da totalidade das incidências; Métodos de organização
uma prioridade Entropias entre equipas internas. diário
ações de resolução de backlog através de uma plataforma comum às várias funções desempenhadas.
Comunicação de falsas
Método discrepante de alocação de stocks
incidências às marcas e Falta de confiança das marcas na HUUB, diminuição
9 dependendo do processo (LIFO, FIFO, por 4 Colaboração entre colaboradores 7 252 Uniformização do método de alocação de stocks para o FIFO
surgimento de novas da satisfação do cliente.
transportadora).
incidências evitáveis
Mapeamento do Processo de
Identificação de Incidências do Estado
Final (To-Be)
65
Apêndice D
Categorização de Incidências de
Fulfillment (TO-BE)
67
68 APÊNDICE D. CATEGORIZAÇÃO DE INCIDÊNCIAS DE FULFILLMENT (TO-BE)
71
Apêndice F
72
73
Tabela G.1: Quadro resumo dos resultados medidos e analisados no início e final do projeto
74