FACULDADE DE TECNOLOGIA DE SÃO PAULO

ABRAÃO GEORGE HALCSIK

GESTÃO DA QUALIDADE NA PRESTAÇÃO DE

SERVIÇOS DE TI: UM ESTUDO EM UMA ÁREA DE
SUPORTE TÉCNICO

SÃO PAULO-SP
2011
 FACULDADE DE TECNOLOGIA DE SÃO PAULO

ABRAÃO GEORGE HALCSIK

GESTÃO DA QUALIDADE NA PRESTAÇÃO DE

SERVIÇOS DE TI: UM ESTUDO EM UMA ÁREA DE
SUPORTE TÉCNICO

Monografia apresentada como

um dos pré-requisitos para
obtenção do grau de especialista
em Gestão Empresarial.
Orientador: Professor Me. Ramsés Henrique Martinez

SÃO PAULO-SP
2011

ii
 GESTÃO DA QUALIDADE NA PRESTAÇÃO DE
SERVIÇOS DE TI: UM ESTUDO EM UMA ÁREA DE
SUPORTE TÉCNICO

Abraão George Halcsik

Monografia apresentada como um pré-requisito para a conclusão do

curso de Especialização em Gestão Empresarial da Faculdade de
Tecnologia de São Paulo.

Aprovada por:

iii
 Dedico este trabalho ao Deus Todo-
Poderoso que me conduziu até aqui com sua
forte mão e ao seu Filho Jesus Cristo, que
ressuscitou dos mortos para vir morar dentro da
minha alma. Dedico não somente este trabalho,
mas também todo esforço empreendido desde o
início da minha vida, o qual só foi possível
porque foi Ele em mim que fez, faz e fará todas
as coisas.

iv
 Agradeço ao Deus Eterno, o Senhor dos
Exércitos, que me fez trilhar passo a passo muitos
caminhos difíceis e espinhosos até este momento
presente. Minha gratidão e reverência a Ele, que não
esconde a batalha de mim, nem me polpa do combate,
mas antes me auxilia em tudo, com a força da sua
destra, que é o próprio Jesus Cristo, cujos olhos são
como chamas de fogo ardente, e cujo rosto me ilumina
dia após dia, mesmo em densas trevas.

v
“A vitória pertence ao mais perseverante”
Napoleão Bonaparte

vi
 Resumo

Este trabalho é dividido em duas partes: A primeira parte apresenta alguns dos
principais conceitos referentes ao gerenciamento de qualidade, gerenciamento do
relacionamento com o cliente, métricas e alguns dos principais conceitos sobre
gerenciamento de serviços em TI. A segunda parte apresenta um caso real de
gestão de Help Desk em uma companhia e identifica alguns dos principais
problemas que envolvem o gerenciamento da área e o cotidiano. O texto
considera que a gestão da área de suporte deve estar ligada aos objetivos
estratégicos da empresa. “Qualidade” significa atingir esta condição. O
pesquisador participou do estudo (observação participante) e foi elaborado como
estudo de caso. O texto considera “serviços de suporte” e “Help Desk” termos
similares. O foco do texto é como atingir e garantir a qualidade nos serviços de
suporte de TI no contexto atual.

Palavras-chave: Qualidade, cliente, gerenciamento, TI, suporte.

vii
 Abstract

This work is shared between two parts: the first part presents some of prime
concepts about quality management, customer relationship management, metrics,
and some of prime concepts about the TI services management. The second part
presents a real case about the Help desk management in a company and
identifies some of main problems that involve the help desk management and
everyday. The text consider the help desk management need to be linked by the
strategics goals of the company. “Quality” mean to achieve this condition. The
research has participated of the study (participatory observation) and the work has
elaborated by a case study. The text consider “support services” and “help desk”
similar terms. The text focus is how to achieve and to ensure the quality of TI
support services on the current context.

Key Words: Quality, customer, management, TI, Help Desk.

viii
 Sumário
1. INTRODUÇÃO..........................................................................................................13
1.1. ESCOPO ...........................................................................................................13
1.2. JUSTIFICATIVA ................................................................................................16
1.3. OBJETIVOS ......................................................................................................17
1.3.1. Geral ..........................................................................................................17
1.3.2. Específico ...................................................................................................17
1.4. FORMULAÇÃO DO PROBLEMA ......................................................................17
2. REVISÃO BIBLIOGRÁFICA E FUNDAMENTO TEÓRICO .......................................19
2.1. PROCESSO ......................................................................................................19
2.2. QUALIDADE ......................................................................................................19
2.2.1. Princípios de Gestão da Qualidade ............................................................21
2.2.1.1. Foco no cliente. ..........................................................................................21
2.2.1.2. Liderança....................................................................................................21
2.2.1.3. Envolvimento de pessoas ...........................................................................22
2.2.1.4. Abordagem de processo .............................................................................22
2.2.1.5. Abordagem sistêmica para gestão..............................................................22
2.2.1.6. Melhoria contínua .......................................................................................22
2.2.1.7. Abordagem factual para tomada de decisão ...............................................23
2.2.1.8. Benefícios mútuos nas relações com os fornecedores ...............................23
2.3. SERVIÇOS ........................................................................................................23
2.3.1. Defeitos na prestação de serviços ..............................................................25
2.3.2. Algumas ferramentas..................................................................................26
2.3.2.1. Diagrama de Pareto....................................................................................26
2.3.2.2. DIAGRAMA DE CAUSA E EFEITO.............................................................28
2.3.2.3. Histogramas ...............................................................................................29
2.4. O CONCEITO DE SATISFAÇÃO DO CLIENTE ................................................29
2.4.1. A pesquisa de satisfação ............................................................................30
2.5. ESTRATÉGIA EMPRESARIAL ..........................................................................31
2.6. GERENCIAMENTO DOS SERVIÇOS DE TI .....................................................32
2.6.1. Governança Corporativa ............................................................................32
2.6.2. Governança em TI ......................................................................................33
2.6.3. O Serviço de TI...........................................................................................34
2.6.4. O conceito de gerenciamento de serviços de TI .........................................35

ix
2.6.5. Boas práticas e recomendações .................................................................36
2.6.6. Principais frameworks e conjuntos de boas práticas ...................................37
2.6.6.1. PMBOK ......................................................................................................37
2.6.6.2. ITIL (Information Technology Infrastructure Library) ...................................40
2.6.6.3. COBIT ........................................................................................................47
2.6.6.4. Análise ITIL x COBIT ..................................................................................50
2.6.6.5. SOA (Service-Oriented Architecture) ..........................................................50
2.6.6.6. A norma ISO/IEC 20.000 (Information Technology – Service Management) ......54
2.7. A ÁREA DE SUPORTE .....................................................................................55
2.7.1. Histórico ......................................................................................................56
2.7.2. A área de suporte no contexto atual ...........................................................57
2.7.2.1. A TI no contexto atual. ................................................................................57
2.7.2.2. Alguns dados sobre a área de suporte no contexto atual ...........................58
2.7.2.3. A importância estratégica da área de suporte .............................................60
2.7.3. Medindo a qualidade da área de suporte ....................................................61
2.7.4. Como a área de suporte é afetada pelas outras áreas ...............................63
2.7.4.1. A área de suporte e a área comercial .........................................................63
2.7.4.2. A área de suporte e a área de desenvolvimento .........................................63
2.7.4.3. A área de suporte e a área de qualidade ....................................................64
3. METODOLOGIA .......................................................................................................65
3.1. INTRODUÇÃO ..................................................................................................65
3.2. TIPO DE PESQUISA .........................................................................................65
3.2.1. Conforme a natureza ..................................................................................65
3.2.2. Conforme a forma de abordagem do problema ..........................................66
3.2.3. Conforme os seus objetivos ........................................................................66
3.2.4. Conforme os procedimentos técnicos .........................................................66
3.3. LIMITAÇÕES DOS TIPOS DE PESQUISAS UTILIZADOS ................................67
3.4. O TIPO DE PESQUISA SELECIONADO: CONSIDERAÇÕES ..........................67
3.5. UNIVERSO E AMOSTRA ..................................................................................68
3.6. CARACTERIZAÇÃO DA AMOSTRA .................................................................68
4. RELATO DO OBSERVADO......................................................................................70
4.1. ESTRUTURA DA EMPRESA .............................................................................70
4.2. A SOLUÇÃO DESENVOLVIDA .........................................................................71
4.2.1. O Comércio Exterior ...................................................................................71
4.2.1.1. Importação .................................................................................................71
4.2.1.2. A solução informatizada .............................................................................72

x
4.2.1.3. Características técnicas .............................................................................73
4.2.1.4. Aspectos de negócio: visão geral ................................................................74
4.2.1.5. Exemplos de algumas falhas.......................................................................75
4.3. PERFIL DOS CLIENTES ...................................................................................77
4.4. PERFIL DOS USUÁRIOS ..................................................................................77
4.5. A ÁREA DE SUPORTE .....................................................................................77
4.5.1. Ferramentas utilizadas ...............................................................................78
4.5.1.1. Sistema de gerenciamento de incidentes ...................................................78
4.5.1.2. Portal de chamados ....................................................................................79
4.5.2. Perfil do analista de suporte .......................................................................79
4.5.3. Panorama observado .................................................................................79
4.5.3.1. Pontos positivos e negativos ......................................................................79
4.5.3.2. Alguns dos principais problemas ................................................................80
4.5.3.3. O uso de indicadores ..................................................................................80
4.5.3.4. A satisfação dos clientes ............................................................................82
4.5.3.5. O ambiente de trabalho ..............................................................................82
5. APLICAÇÃO DE ALGUNS DOS PRINCIPAIS FRAMEWORKS NA GESTÃO DA
ÁREA DE SUPORTE. ......................................................................................................83
5.1. APLICAÇÃO DE ALGUNS DOS PRINCIPAIS CONCEITOS DO PMBOK® .......83
5.2. APLICAÇÃO DE ALGUNS DOS PRINCIPAIS CONCEITOS DA ITIL ................86
5.3. APLICAÇÃO DE ALGUNS DOS CONCEITOS DO COBIT ................................91
5.4. APLICAÇÃO DE ALGUNS DOS PRINCIPAIS CONCEITOS DE SOA ...............93
6. ANÁLISE DO PANORAMA OBSERVADO................................................................95
6.1. ÁREA OPERA NO LIMITE DE SUA CAPACIDADE: MAL CONSEGUE SUPRIR
A DEMANDA ATUAL DE CHAMADOS. .......................................................................95
6.1.1. Principais fatores que podem influenciar a performance .............................98
6.2. NÚMERO ELEVADO DE REABERTURAS......................................................104
6.2.1. Uma possível solução ...............................................................................106
6.3. EMPREGO FREQUÊNTE DE SOLUÇÕES PALIATIVAS ................................107
6.4. DIVERSAS SOLUÇÕES OBTIDAS PELO MODO TENTATIVA-ERRO ...........108
6.4.1. O processo de solução de problemas .......................................................108
6.4.2. A situação da empresa .............................................................................109
6.4.3. Um outro modo de abordar o incidente .....................................................111
6.5. SUCESSIVAS INTERRUPÇÕES NO FLUXO DE TRABALHO ........................114
6.6. ANÁLISE DAS CARACTERÍSTICAS DA EMPRESA MEDIANTE ALGUNS DOS
PRINCIPAIS FRAMEWORKS ....................................................................................115

xi
6.6.1. A área de suporte da empresa e a ITIL.....................................................115
6.6.2. A área de suporte e o COBIT ...................................................................117
7. CONCLUSÕES.......................................................................................................118
8. REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................120

xii
 1. INTRODUÇÃO

1.1. ESCOPO

A garantia da qualidade na gestão de serviços em TI, mais

precisamente, na gestão de serviços de suporte técnico é o assunto que se
constitui o tema deste trabalho. O assunto será tratado sob dois aspectos. Um
deles diz respeito aos conhecimentos teóricos já formulados sobre o tema. Nesta
etapa serão levados em conta também fundamentos teóricos que não estão
diretamente ligados a TI, mas que são de primordial importância neste contexto.
O outro aspecto, complementar ao primeiro, consiste na análise de um caso real.
Conforme Bianchini e Paccola (1995, p.137), a análise combinatória
explica que há diversas maneiras de um evento ocorrer. Ao tomar como exemplo
uma determinada atividade X, é válido também considerar que há um número N
de modos para realizá-la.
Ao atribuir a cada um destes modos uma determinada “qualidade”, é
correto afirmar que há maneiras que são melhores ou piores do que outras para
se fazer algo.
Considerando a área de gestão de serviços em TI, muitos esforços tem
sido empreendidos ao longo dos anos para se concebê-la de modo que a área de
TI contribua para o negócio da organização. Dentro da gestão de serviços em TI,
o presente trabalho destacará a área de Central de Serviços, também conhecida
como Suporte ou Help Desk.
Neste contexto, a atividade principal X pode ser definida da seguinte
maneira:

X = Gerenciar a área de suporte da organização

13
 E considerando que há diversos modos de fazer isso, sempre há o pior
modo de fazê-lo, passando pelos modos intermediários até chegar na maneira
ideal ou melhor maneira.
Um ponto crucial é que ao falar sobre melhor ou pior maneira, é
necessário ter em mente um parâmetro, ou seja, é preciso questionar, por
exemplo, o que significa utilizar a melhor maneira para gerenciar a área de
suporte da empresa.
No contexto atual, a área de TI como um todo deve cooperar com a
estratégia de negócios da organização. Assim, a área de suporte, como sendo
parte da área de TI, deve assumir um papel estratégico na empresa e contribuir
para que toda a área de TI também assuma este papel, apoiando de maneira
eficiente e eficaz o negócio da organização.
Partindo desta premissa, quando alguém afirmar que está utilizando a
melhor maneira de gerenciar a área de suporte, isto significa dizer que a área de
suporte está sendo gerenciada do modo que melhor faz com que ela assuma seu
papel estratégico e contribua para alavancar o negócio da organização.
Ao falar em pior ou melhor maneira, estamos associando a cada modo
uma determinada qualidade. É claro que uma área de suporte gerenciada da pior
maneira, é, por conseguinte, gerenciada com pior qualidade.
Uma área de suporte gerenciada da melhor maneira é gerenciada com
mais qualidade. O conceito geral de qualidade é relacionado a um determinado
parâmetro ou uma condição ideal a ser atingida. Quanto mais próximo desta
condição, maior será a qualidade. Isto é corroborado pela afirmação de
Koscianski e Soares (2006, p. 26), “quanto mais longe estivermos das
especificações, pior será o produto”.
Neste caso, o elemento a ser avaliado é a gestão da área de suporte.
Se a gestão for concebida da melhor maneira possível, então terá mais qualidade,
pois se aproximará do objetivo, que é apoiar de modo eficiente e eficaz a
estratégia de negócio da organização. Quanto mais a área de suporte e a área de
TI como um todo se afastarem deste objetivo, pior será a qualidade da sua
gestão.
A qualidade deve ser constantemente medida para se avaliar se o
processo de gestão está cumprindo o seu papel. De acordo com Koscianski e

14
Soares (2006, p. 41), “um conjunto de dados obtidos por medidas é um recurso
de extrema ajuda para auxiliar a tomada de decisões gerenciais”. Falar em
qualidade é bastante simples quando o objetivo consiste em avaliar produtos
tangíveis. Entretanto, avaliar o processo de gestão da área de suporte de TI
significa avaliar os serviços oferecidos por ela. Neste caso, é necessário avaliar o
processo de gestão e o resultado advindo dele, ou seja, o produto “intangível”
chamado serviço.
Ao admitir que os processos relacionados à área de suporte tem como
produto intangível um ou mais serviços, é preciso considerar que estes devem ser
direcionados aos usuários e/ou clientes. Com isso, a qualidade do serviço deve
ser percebida, ou seja, o serviço deve trazer satisfação ao cliente.
Assim, a qualidade deve estar diretamente atrelada aos processos que
envolvem a gestão de TI, ao serviço prestado e a percepção que o cliente tem
deste serviço. Os processos devem ser constantemente revistos e melhorados,
ou seja, deve ser sempre posto em prática o conceito de melhoria contínua.
Para se oferecer um serviço de qualidade, portanto, é preciso saber
quem é o cliente e quais são as suas expectativas.
Em capítulos posteriores serão abordados com mais detalhes alguns
exemplos de frameworks relacionados à gestão de serviços em TI. Porém, para
delimitar o escopo deste estudo, a seguir está o Quadro 1, que representa
aproximadamente a posição da área de suporte em relação a dois frameworks
importantes: o ITIL e o COBIT:

15
 Quadro 1 - Intersecção ITIL x COBIT

Implementar
ITIL COBIT

Monitorar e
Entregar e
Planejar e
Organizar
Adquirir e

Suportar

Avaliar
Gerenciamento Financeiro
Gerenciamento de Portfólio de Serviço
Gerenciamento de Demanda
Gerenciamento do Nível de Serviço
Gerenciamento do Catálogo de Serviços
Gerenciamento do Fornecedor
Gerenciamento da Capacidade
Gerenciamento da Disponibilidade
Gerenciamento da Continuidade dos Serviços de TI
Gerenciamento da Segurança da Informação
Planejamento e Suporte da Transição
Gerenciamento de Liberação
Gerenciamento de Configuração
Validação e Teste do Serviço
Gerenciamento de Avaliação
Gerenciamento de Mudança
Gerenciamento do Conhecimento
Gerenciamento de Incidente
Gerenciamento de Problema
Tratamento de Requisições
Gerenciamento de Eventos
Gerenciamento de Acesso
Fonte: O autor

A ITIL concebe o gerenciamento de serviços de TI baseado em

processos (na vertical) e o COBIT divide o processo em domínios, e é fortemente
voltado para controles (horizontal). O trecho de intersecção entre os dois
representa o escopo de atuação da área de suporte e também a delimitação do
escopo deste presente estudo.

1.2. JUSTIFICATIVA

A qualidade na prestação do serviço de suporte não diz respeito

apenas ao aspecto técnico da resolução de problemas, mas envolve

16
relacionamento com o cliente e/ou usuário. Paralelamente a este fato, a
disseminação dos sistemas informatizados envolvem diversos ramos de atuação
e estão cada vez mais intrínsecos aos processos de negócios das empresas. Um
serviço de suporte de qualidade baixa, além de comprometer o relacionamento
com o cliente e a imagem da empresa, pode comprometer seriamente os
processos de negócios da companhia, tais como transações financeiras,
operações logísticas, transações que envolvem exigências legais, entre outros.
Mediante esta realidade, é necessário que muitas companhias atinjam um
amadurecimento no que se refere à gestão de suas áreas de TI.

1.3. OBJETIVOS

1.3.1. Geral

Apresentar um exemplo de empresa brasileira de tecnologia de médio

porte, traçando um retrato do panorama da sua área de suporte e contrapondo
sua realidade com a teoria apresentada.

1.3.2. Específico

A identificação dos principais problemas relacionados à gestão de

serviços de TI, no que se refere ao serviço de suporte técnico. Além disso,
mostrar como alguns dos frameworks podem ser aplicados à gestão da área de
suporte.

1.4. FORMULAÇÃO DO PROBLEMA

No contexto atual, a Tecnologia da Informação está amplamente

atrelada a diversos processos de negócios das empresas e instituições. O
aumento do uso da tecnologia nas corporações promoveu a diminuição da
distância entre os profissionais de diversas áreas e os sistemas informatizados.
Considerando-se o caráter crítico de determinados processos de negócio, é

17
primordial que as companhias que desenvolvem e fornecem serviços de TI
ofereçam serviços de suporte bem estruturados e dotados de qualidade.
Existe um grande número de organizações que precisam amadurecer
os seus processos de gestão de TI. Considerando a realidade da empresa
analisada e o panorama atual do papel da TI, a questão da pesquisa pode ser
formulada do seguinte modo: como garantir a qualidade na gestão dos serviços
de suporte técnico, de modo que esta gestão se traduza no aumento do nível de
satisfação do cliente e paralelamente atenda a estratégia de negócio da
organização?

18
 2. REVISÃO BIBLIOGRÁFICA E FUNDAMENTO TEÓRICO

Neste capítulo, buscou-se apresentar a fundamentação teórica que

servirá como alicerce para o presente estudo. Serão abordados alguns conceitos
principais relacionados aos conceitos de processos, qualidade, métricas e a
relação destes com o conceito de serviços. Além disso, será feita uma explanação
sucinta sobre alguns dos principais métodos, frameworks e conjuntos de boas
práticas relacionados com a gestão de TI (ITIL, COBIT, SOA, etc...). Convém
deixar claro que o propósito deste capítulo não é privilegiar uma determinada
técnica, nem falar de modo profundo sobre cada uma. A intenção é apenas
conceber o embasamento necessário para a realização da pesquisa.
Basicamente, alinhar os conceitos discutidos com a gestão de serviço de suporte
técnico, demonstrando a aplicação dos mesmos neste contexto.

2.1. PROCESSO

Numa definição geral, processo pode ser entendido como um conjunto

ordenado de atividades relacionadas que a partir de uma ou mais entradas deve
gerar uma ou mais saídas. Numa organização, existe um conjunto de processos
que possuem a finalidade de produzir saídas representadas por produtos e/ou
serviços ou elementos que sirvam como entradas para outros processos (por
exemplo: dados). De acordo com Magalhães e Pinheiro (2007, p. 41) “um
processo é uma série de ações, atividades, mudanças, etc..., conectadas entre si
e realizadas por agentes com o fim de satisfazer um propósito ou alcançar uma
meta”.

2.2. QUALIDADE

O termo Qualidade possui diversas definições. Uma possível definição

consiste em se afirmar que qualidade é um conjunto de atributos e características
de um produto ou serviço oferecido. Uma outra definição de qualidade é a
proposta por Koscianski e Soares (2006, p. 26), os quais afirmam que “a

19
qualidade de um produto é dada pela distância entre as características
observadas e as características que foram especificadas para a sua construção”.
Esta definição apesar de se referir a um produto tangível, pode ser seguramente
adaptada para se aplicar a um elemento intangível, tal como um serviço ou um
modelo de gestão.
Considerando a qualidade de um serviço, pode-se afirmar que
semelhantemente a um produto também existem “características que são
especificadas para a sua concepção” (KOSCIANSKI e SOARES, 2006). As
“características observadas” (KOSCIANSKI e SOARES, 2006) podem se referir
ao serviço estar ou não cumprindo o seu propósito inicial.
A qualidade não é um conceito absoluto. Para se admitir que algum
produto ou serviço possui alta ou baixa qualidade é preciso conhecer a
expectativa do cliente. Tanto um produto como um serviço deve ser concebido de
acordo com sua aceitação no mercado. Uma vez identificada a expectativa do
cliente, deve-se então estabelecer um parâmetro de qualidade a ser perseguido.
De nada adiantaria adotar o conceito de qualidade se não houver meios para
mensurá-la. Isto é particularmente fácil de se fazer no contexto de bens tangíveis,
como por exemplo parafusos, carros e outros produtos oriundos de atividade
fabril. O ponto central dessa questão consiste em estabelecer critérios de
qualidade para bens intangíveis ou abstratos. Por exemplo, como atribuir e medir
a qualidade de serviços? Ou então como atribuir e medir a qualidade de um
processo de gestão? Como saber se a gestão praticada por uma organização
possui qualidade e como medi-la? Tendo essas respostas, é possível empregar
meios de se melhorar os modelos de gerenciamento e consequentemente
melhorar a qualidade dos serviços.
A qualidade de um produto ou serviço está intimamente atrelada à
qualidade dos processos utilizados para concebê-los. Basicamente, se os
processos utilizados forem inadequados, o produto final (tangível ou intangível)
terá baixa qualidade. A partir desta premissa, pode-se afirmar que “a qualidade de
um produto é reflexo da qualidade e gerenciamento do processo utilizado em seu
desenvolvimento” (SCHILIEPER, p.24).
Ao considerar um conjunto de processos necessários para a fabricação
de um determinado produto, é necessário levar em conta também que esses

20
processos são gerenciados de alguma forma. O modelo de gestão empregado
para gerenciá-los também deve possuir qualidade, caso contrário o produto não
terá qualidade.

2.2.1. Princípios de Gestão da Qualidade

A seguir consta de modo sucinto uma explicação sobre os princípios de

gestão de qualidade baseados nas normas da família ISO 9000.

2.2.1.1. Foco no cliente.

A organização deve ter consciência de que depende do cliente. A partir

desta premissa, deve tomar ações para gerenciar o relacionamento com o cliente,
além de procurar conhecer suas necessidades e expectativas. Além disso, deve
promover meios para medir a satisfação do cliente e utilizar os resultados como
base para a tomada de ações. A empresa deve sempre procurar superar as
expectativas do cliente. De acordo com ABNT (2008), “a organização deve
monitorar informações relativas à percepção do cliente sobre se a organização
atendeu aos requisitos do cliente”.

2.2.1.2. Liderança

O gestor deve promover um ambiente propício para as pessoas

atuarem com liberdade e responsabilidade. De acordo com ABNT (2008), “a
organização deve determinar e gerenciar o ambiente de trabalho necessário para
alcançar a conformidade com os requisitos do produto”. A liderança deve ser
aplicada no sentido de se direcionar os esforços de cada um para o propósito da
organização. Os esforços devem ser pautados em princípios éticos e valores
estabelecidos. Deve-se considerar além da necessidade do cliente, as
necessidades de todas as outras partes interessadas: fornecedores, funcionários,
parceiros etc....

21
 2.2.1.3. Envolvimento de pessoas

O envolvimento de todas as pessoas participantes do negócio da

organização é fundamental. Este envolvimento deve ser promovido com a
finalidade de canalizar suas capacidades para o bem da organização. Conforme a
ABNT (2008), a organização deve “assegurar que o seu pessoal está consciente
quanto à pertinência e importância de suas atividades e de como elas contribuem
para atingir os objetivos da qualidade”.

2.2.1.4. Abordagem de processo

Esta abordagem consiste em se gerenciar as atividades e recursos da

organização como um processo. Os processos que participam do negócio devem
ser levantados e adequadamente documentados. A partir daí é mais fácil
estabelecer métricas e identificar possíveis melhorias. De acordo com ABNT
(2008), “para uma organização funcionar de maneira eficaz, ela tem que
determinar e gerenciar diversas atividades interligadas”.

2.2.1.5. Abordagem sistêmica para gestão

Abordar a gestão de modo sistêmico basicamente significa gerenciar

os processos e as relações entre eles como um sistema. Um sistema pode ser
definido como um conjunto de elementos organizados de modo harmonioso e que
atuam juntos para cumprir um objetivo. Se a gestão for observada dentro desta
abordagem é possível identificar como cada parte do sistema do negócio afeta o
resultado.

2.2.1.6. Melhoria contínua

O conceito de melhoria continua deve sempre ser aplicado sobre todos

os processos que envolvem o negócio da organização, bem como que afetem o
seu desempenho. Este conceito deve ser comunicado e promovido no sentido de
ser o objetivo de todos os colaboradores da organização. Conforme ABNT (2008),

22
“a organização deve continuamente melhorar a eficácia do sistema de gestão da
qualidade”.

2.2.1.7. Abordagem factual para tomada de decisão

As decisões devem ser tomadas com base na análise criteriosa de

dados consistentes e informações. Neste contexto, é necessário que os dados
coletados tenham a precisão adequada para o objetivo que a análise se propõe.
Além disso, o dado deve ser acessível e possuir confiabilidade. Nenhuma decisão
deve ser apoiada com base na subjetividade.

2.2.1.8. Benefícios mútuos nas relações com os fornecedores

O relacionamento da organização com os fornecedores deve ser

adequadamente gerenciado no sentido de se estabelecer ganhos mútuos.

2.3. SERVIÇOS

Magalhães e Pinheiro (2007) assim definem serviço:

(...) serviço é uma ação executada por alguém ou por alguma coisa,
caracterizando-se por ser uma experiência intangível, produzido ao
mesmo tempo em que é consumido, não podendo ser armazenado, e
apresentando sérias dificuldades para ser produzido em massa ou
atender mercados de massa (MAGALHAES e PINHEIRO, 2007, p. 45).

Com relação às características intrínsecas aos serviços, Normann

(1993) afirma que o serviço não pode ser estocado e nem revendido, e Casas
(2008, p. 15) caracteriza os serviços como intangíveis, inseparáveis,
heterogêneos e simultâneos.
O ponto fundamental consiste no fato de o serviço ser um elemento
abstrato. Acerca do valor percebido dos serviços, Freitas (2010) comenta:

23
 (...) para que os serviços possam ser entregues com valor percebido
pelos clientes, é necessário que o provedor de serviços tenha um
entendimento profundo de quem é o cliente, quando e por que ele
necessita de um serviço, quais são as suas necessidades, qual é a sua
expectativa de valor e como os serviços serão entregues (FREITAS,
2010, p. 105).

A qualidade do serviço é percebida somente no momento da utilização

do mesmo e em alguns casos somente após a entrega. Isto significa que ao
contratar um serviço, o cliente precisa lidar com a incerteza. Se um profissional ou
uma empresa prestou um número N de serviços de maneira satisfatória, existe
uma probabilidade alta de o serviço N+1 ser prestado com a mesma qualidade.
Porém, existe também a chance de isto não ocorrer.
Existem maneiras de se minimizar a incerteza em relação à qualidade
do serviço prestado. Considerando que o profissional ou a organização possui
know-how suficiente para prestar determinado serviço, o ponto crucial é conhecer
o cliente e conhecer profundamente suas necessidades e expectativas. Como
exemplos de maneiras, podem ser citadas:

 Fazer com que o cliente participe do processo de concepção do serviço.

Por exemplo, no caso de uma empresa de arquitetura ou de uma
companhia que desenvolve software. Neste caso, as expectativas do
cliente serão mais claras e qualquer necessidade de modificação e/ou
adaptação poderá ser tratada previamente.

 Fazer com que o cliente conheça os processos que envolvem a concepção

do serviço prestado. Já que ele não pode ver o serviço antes dele ser
finalizado, ele pode inferir que o mesmo possui qualidade por meio da
constatação de qualidade nos processos utilizados para concebê-lo. Se
uma empresa de serviços exibe uma certificação ISO, por exemplo, isto
contribui para aumentar a confiança nos seus clientes, já que demonstra
que a organização emprega normas padronizadas e reconhecidas nos
seus processos.

24
 Boa parte dos serviços é consumida no mesmo momento em que é
produzida. Isto significa que há interação entre o cliente e o prestador de serviço.
Mello, Neto, Turrioni e Silva (2010, p.132) afirmam que “em geral, processos de
serviços se dividem em atividades que acontecem na presença do cliente e em
atividades que acontecem sem a presença do cliente”. Apesar desta divisão,
todas as tarefas devem ser consideradas igualmente importantes, pois a
prestação de um serviço é um processo, ou seja, se uma das atividades falhar,
isto pode comprometer seriamente o resultado final e, por conseguinte, impactar
negativamente na satisfação do cliente. Em linhas gerais, é preciso considerar
que a organização:

 Deve conhecer profundamente quem é o seu cliente e também qual o

serviço que se propõe a oferecer.

 Deve conhecer a necessidade e expectativa do seu cliente. Isto fará com

que fique clara qual a qualidade que o serviço deve possuir e será mais
fácil direcionar os recursos no sentido de atingi-la.

 Deve haver um gerenciamento da interação entre o prestador de serviço e

o cliente, já que a percepção que o cliente terá do serviço irá refletir
positiva ou negativamente na percepção que ele tem da companhia.

2.3.1. Defeitos na prestação de serviços

A partir dos conceitos apresentados anteriormente, não é possível uma

organização conceber um serviço de qualidade sem medir se esta qualidade está
sendo atingida.
No caso da produção fabril, é possível medir a relação entre peças
defeituosas e peças sem defeito, e a partir daí verificar e corrigir problemas no
processo produtivo. Porém, no caso de serviços, como identificar e corrigir um
“defeito”? Foi dito que uma organização deve conhecer profundamente o serviço
que se propõe a oferecer. Isto significa conhecer profundamente qual é o objetivo

25
do serviço prestado, o qual deve estar alinhado com a expectativa do cliente. Se o
objetivo estiver bem definido, o próximo passo é procurar medir se o que está
sendo entregue está de acordo ou distante do que foi proposto.
Ao fazer uma analogia com o processo produtivo citado anteriormente,
se uma determinada expectativa previamente acordada não está sendo atendida,
isto pode ser classificado como um “defeito” no processo de prestação de serviço.
A partir daí, a organização deve verificar se este “defeito” é oriundo de um erro no
projeto do serviço ou de algum procedimento padrão que não foi seguido. A partir
desta premissa, existem duas situações a considerar:

 Um erro no projeto do serviço consiste em um erro na concepção dos

processos que envolvem o serviço. Neste caso, não se pode dizer, por
exemplo, que foi um erro cometido por um funcionário, já que ele seguiu os
procedimentos estabelecidos.

 Um erro operacional consiste em um procedimento correto que não foi

seguido ou seguido de maneira inadequada.

2.3.2. Algumas ferramentas

A seguir serão apresentadas algumas ferramentas empregadas para

se garantir ou medir a qualidade de um produto ou serviço.

2.3.2.1. Diagrama de Pareto

Antes de apresentar o Diagrama de Pareto propriamente dito, convêm

conceituar o Princípio de Pareto. Este princípio estabelece que aproximadamente
80% dos problemas são provocados por um conjunto de causas de
aproximadamente 20%. A conclusão imediata deste princípio é que se a
organização atuar sobre esta pequena quantidade de causas, a maioria dos
problemas será resolvida. É a partir deste princípio que foi concebido o Diagrama
de Pareto. Ele é uma ferramenta gráfica que mostra ordenadamente a frequência

26
de causas da ocorrência de um problema. A sua grande contribuição é mostrar
claramente qual causa deve ser atacada, numa escala de prioridade. Trata-se de
um gráfico de barras que prioriza problemas ou causas relativas a um problema
(NOCERA, 2009, p. 431). Ou seja, qual ou quais são as causas que estão sendo
mais determinantes na ocorrência do problema. Para exemplificar, segue a seguir
um diagrama (Fig. 1) que ilustra as causas de problemas num setor de cobrança
de uma companhia (fictícia):

Figura 1 – Exemplo de Diagrama de Pareto

Fonte: Godoy (2011)

Na figura anterior fica claro que a maior parte dos problemas é causada
por notas fiscais atrasadas como evidenciado na primeira coluna (NF Atras.).
Segundo Casas (2008, p. 83), o gráfico de Pareto é uma ferramenta bastante útil
para se avaliar os principais tipos de problemas na organização.

27
 2.3.2.2. Diagrama de Causa e Efeito

O Diagrama de Causa e Efeito também é conhecido como Diagrama

Espinha de Peixe ou Diagrama de Ishikawa. Ele consiste numa ferramenta gráfica
que permite visualizar as causas relacionadas a um problema, ou seja, a relação
entre o problema e as possíveis causas que contribuam para a sua ocorrência
(NOCERA, 2009). Casas (2008) enfatiza que é preciso tomar cuidado para não
confundir as causas do problema com seus sintomas.
As causas podem ser classificadas nos tipos a seguir:

 Método
 Máquinas/Equipamentos
 Materiais
 Meio Ambiente
 Medição
 Mão de Obra

Nas linhas diagonais, colocam-se as causas relacionadas, conforme a

classificação de cada uma delas. E a seguir, temos um exemplo de diagrama de
causa e efeito que ilustra as causas determinantes para a ocorrência de defeito
na fabricação:

Figura 2 – Diagrama de causa e efeito exemplificando as causas para o defeito na

fabricação de um produto

28
 2.3.2.3. Histogramas

Um histograma é uma ferramenta gráfica e estatística em que se pode

observar a distribuição das frequências de ocorrência de um fenômeno. O
Diagrama de Pareto é um tipo particular de histograma. A construção de
histogramas é um importante indicador da distribuição de dados (NOCERA,
2009).

2.4. O CONCEITO DE SATISFAÇÃO DO CLIENTE

Dizer que o cliente está satisfeito com o serviço prestado significa que,
no mínimo, o serviço prestado atendeu às expectativas dele. Magalhães e
Pinheiro (2007) abordam o termo satisfação do cliente como sendo um elemento
baseado na relação entre a qualidade percebida e a qualidade esperada. A
qualidade esperada ou prevista se refere ao nível de qualidade que o serviço se
propõe a oferecer. A qualidade percebida está ligada á sensação que o cliente
tem ao utilizar o serviço. Convém lembrar que a qualidade percebida é uma
informação subjetiva, ou seja, pode variar de cliente para cliente ou então estar
sujeita a diversos fatores que podem comprometê-la.
Por exemplo, supondo que um usuário está indignado devido aos
problemas que enfrenta com o uso de seu software e de repente a equipe de
suporte soluciona apenas um destes incidentes. É bem provável que ao
responder uma pesquisa de satisfação referente ao chamado solucionado, o
usuário por certo vai expressar sua indignação referente aos outros incidentes
ainda sem solução ao invés de elogiar o serviço prestado naquele que foi
solucionado.
Este e outros exemplos corroboram a afirmação de Casas (2008, p. 7),
o qual diz que “há uma fonte de estímulos físicos para a percepção, além de
fatores tais como necessidades, estado de ânimo etc.”. De fato, quando se tenta
identificar a percepção do cliente sobre um serviço prestado, é necessário ter em
mente que existem muitos fatores que podem comprometer a imparcialidade do
julgamento. No exemplo citado, a indignação do cliente com relação aos
incidentes irresolutos afetou o juízo que ele fez acerca de um único incidente que

29
foi solucionado. Pode-se inferir, por exemplo, que nesta situação hipotética talvez
o único incidente solucionado não tivesse tanta prioridade como os demais.
Como a qualidade percebida é algo subjetivo, ou seja, mais difícil de
mensurar do que a qualidade prevista, é necessário que a gestão tome medidas
para se gerenciar adequadamente o relacionamento com o cliente, a fim de
manter o serviço sempre alinhado com suas expectativas. Conhecendo-se
claramente as expectativas do cliente e cultivando de modo cuidadoso o
relacionamento com ele é mais fácil ter uma ideia do modo como o cliente
percebe o serviço. Segundo Magalhães e Pinheiro (2007, p. 57), “as expectativas
dos clientes estão continuamente aumentando e se alterando”.

2.4.1. A pesquisa de satisfação

Um exemplo de ferramenta que pode ser empregada para medir o nível

de satisfação do cliente é a pesquisa de satisfação. O objetivo de pesquisas deste
tipo não deve ser apenas para coletar dados, mas sim de a partir deles obter
informações úteis para se melhorar a qualidade do serviço oferecido, bem como
sempre adaptar o serviço às novas expectativas que surgem. Conforme ABNT
(2008), o “monitoramento da percepção do cliente pode incluir a obtenção de
dados de entrada de fontes, tais como pesquisas de satisfação do cliente”.
Quanto à elaboração de questionários, Casas (2008, p. 52) assim
sugere:

Para elaborar questionários é necessário que haja coerência. Deve-se

saber qual o objetivo da pesquisa. Somente a partir daí será possível
formular as perguntas que farão parte dos questionários (CASAS, 2008,
p. 52).

Prover o cliente de canais para que ele possa expressar sua opinião é
uma atitude que também contribui para uma percepção positiva do cliente em
relação à empresa, já que faz com que o mesmo perceba preocupação por parte
da organização. A pesquisa de satisfação deve ser feita de maneira periódica e os
resultados devem ser traduzidos em ações para sempre melhorar a qualidade do
serviço prestado.

30
 2.5. ESTRATÉGIA EMPRESARIAL

Com relação ao conceito de estratégia, Freitas (2010, p. 105) afirma:

O conceito de estratégia, originado no meio militar, significava a arte de

liderar exércitos para vencer os inimigos. Mais tarde seu contexto foi
levado para outros campos como política, economia e gestão
empresarial. (...) a estratégia ganhou significado no meio empresarial, de
gerenciar recursos para atingir um determinado objetivo (FREITAS,
2010, p. 105).

Todos os conceitos de qualidade, processos, serviços, satisfação do

cliente, entre outros abordados anteriormente de nada se aproveitam se não
estiverem harmoniosamente coordenados no sentido de se atender a estratégia
de negócio da empresa.
Uma organização nunca deve se acomodar, ou seja, adotar uma
postura estática. Isto porque o mercado no qual as empresas estão inseridas é
um ambiente altamente instável e dinâmico. Neste contexto, para uma
organização sobreviver é primordial que ela assuma esta realidade e adote uma
postura que permita a ela sempre adaptar-se às mudanças que o mercado
apresenta. Mais do que isso, ela deve sempre procurar ter uma perspectiva dos
fatos, a fim de ter condições de atuar de modo proativo.
Neste contexto é essencial para as empresas terem bem definidos a
sua missão e objetivos, ou seja, onde a empresa quer chegar. Partindo deste
ponto, a empresa deve tomar as ações gerenciais necessárias para se atingir os
objetivos. Mesmo que a empresa tome medidas baseadas nos conceitos
apresentados nos tópicos anteriores, é preciso que essas medidas sejam
alinhadas com os objetivos estratégicos da companhia. Por exemplo, de que
modo a pesquisa de satisfação atende o objetivo estratégico da companhia?
Numa situação hipotética, a empresa pode canalizar os resultados positivos para
a área de marketing, a fim de que ela os utilize para obter novos clientes. Numa
outra abordagem, a pesquisa pode servir como uma das ferramentas para se
gerenciar o relacionamento com os clientes.
Existem muitas definições para o conceito de estratégia empresarial,
uma possível definição consiste em se afirmar que é um conjunto de planos

31
elaborados pelos dirigentes da companhia para alcançar resultados que reflitam
os objetivos da organização.

2.6. GERENCIAMENTO DOS SERVIÇOS DE TI

2.6.1. Governança Corporativa

Antes de falar sobre o gerenciamento de serviços de TI, é necessário

abordar o conceito de Governança Corporativa. Este conceito tem por finalidade
conceber um sistema de gestão que faça com que as ações dos executivos e
gestores das companhias caminhem no mesmo sentido dos interesses dos
acionistas e donos. A Governança Corporativa cumpre este papel por meio da
concepção de meios de gestão que promovam controle e monitoramento. Além
disso, procura garantir sempre a transparência na prestação de contas junto aos
acionistas, governo e partes interessadas e garantir que fiquem claras as
responsabilidades de todos os participantes da companhia. A manutenção da
transparência e delimitação das responsabilidades fazem com que os conflitos de
interesses entre os gestores e os proprietários das companhias sejam
minimizados. De acordo com Gaspar, Gomez e Miranda (2010, p. 24), a
Governança Corporativa “é o sistema pelo qual as empresas são dirigidas e
controladas para especificar a distribuição de direitos e responsabilidades entre
os diferentes participantes de uma empresa (...)”.
Governança Corporativa tem sido um parâmetro utilizado inclusive para
avaliar o risco de investimento em determinada companhia. Ou seja, empresas
que adotam práticas e sistemas de gestão baseadas em Governança Corporativa
são bem mais atrativas para investidores, pois representam menor risco.
Um exemplo de medida que alavancou o advento da Governança
Corporativa foi a lei Sarbanes-Oxley ou SOX. Ela é de autoria de um senador
(Sarbanes) e de um deputado (Oxley) norte-americanos. Esta lei corresponde a
uma das medidas tomadas pelo Governo Norte-Americano diante da insegurança
gerada por diversos escândalos financeiros, os quais envolveram várias
multinacionais.

32
 Acerca de um exemplo de aplicação da Governança Corporativa,
Freitas (2010, p. 9) comenta:

Como exemplos de recomendações de boas práticas de Governança

Corporativa no Brasil, o Banco Central do Brasil criou a Norma 3.380 em
junho de 2006, onde prevê a implementação de Estrutura de risco
operacional para instituições financeiras no Brasil. (FREITAS, 2010, p.
9).

2.6.2. Governança em TI

No contexto atual, existe uma forte necessidade de se fazer com que a

Tecnologia da Informação esteja alinhada com a estratégia de negócio da
empresa. Considerando que o negócio esteja pautado em mecanismos de gestão
que promovam a Governança Corporativa, pode-se dizer que a TI deve então
estar alinhada com as práticas de Governança Corporativa da companhia.
Segundo Albertin e Albertin (2010, p. 47), a Governança de TI “precisa ser
estruturada de forma a atender as necessidades organizacionais”.
O gerenciamento de operações que envolvem manipulação de dados
financeiros, contábeis, além de geração de demonstrativos e relatórios depende
da aplicação de ferramentas de Tecnologia da Informação. A partir deste fato,
pode-se concluir que se a empresa não possui uma eficiente e eficaz estrutura de
TI, a qualidade e confiabilidade dos dados e informações produzidas certamente
ficarão prejudicadas. Assim, a TI exerce papel fundamental para promover a
Governança Corporativa dentro da organização. A Governança em TI, portanto
consiste em se empregar TI para apoiar a Governança Corporativa, mas também
possui como foco a constante melhoria dos processos que envolvem a própria
gestão de TI. Segundo Gaspar, Gomez e Miranda (2010, p. 24),
“necessariamente, a governança corporativa incorpora a governança de TI,
porque ela precisa estar totalmente alinhada com os negócios da organização”.
Freitas (2010, p. 11) sustenta que o termo Governança de TI tem por
finalidade “nomear as práticas de Gestão de TI realizadas para garantir o
alinhamento de TI às iniciativas de Governança Corporativa”. Com uma gestão
adequada dos recursos de TI, a empresa poderá pautar suas decisões e

33
fundamentar suas ações sobre dados e informações seguros e confiáveis, e, por
conseguinte, a companhia será menos suscetível a erros, o que significa também
ser menos suscetível a representar um risco para os investidores.
A conclusão sobre este assunto consiste em se admitir que se a
Governança Corporativa aponta para uma gestão empresarial mais madura e
transparente, é claro que para se atingir este patamar é necessário que os
próprios processos que envolvem a gestão da área de TI sejam também
amadurecidos.
A Figura 3 apresenta de modo sucinto um esquema que descreve a
estrutura conceitual da Governança de TI.

Figura 3 – Estrutura conceitual da Governança de Tecnologia de Informação.

Fonte: Albertin e Albertin (2010, p. 85).

2.6.3. O Serviço de TI

Anteriormente foi apresentado o conceito do termo serviço de maneira

geral. De fato, o que foi dito pode certamente ser aplicado a um serviço de TI. De
acordo com Magalhaes e Pinheiro (2007), um serviço de TI pode ser definido
como “um conjunto de recursos, TI e não-TI, mantidos por um provedor de TI,

34
cujo objetivo é satisfazer uma ou mais necessidades de um cliente (...)”. O cliente
pode ser entendido como uma empresa que utiliza os serviços ou uma área de
negócio da empresa.

2.6.4. O conceito de gerenciamento de serviços de TI

O conceito geral de gerenciamento de serviços de TI abrange não

somente a área de suporte técnico, mas todos os serviços prestados pela área de
TI da organização. Este conceito possui a finalidade de fazer com que a área de
TI:

 Atue de modo alinhado com os objetivos estratégicos da organização

(MAGALHAES e PINHEIRO, 2007).
 Utilize adequadamente os recursos financeiros, materiais e humanos e de
maneira eficiente e gerenciada.
 Direcione suas ações de modo que os resultados sejam percebidos
positivamente pelos usuários, clientes e demais partes interessadas.
 Assuma uma postura proativa mediante os problemas e necessidades da
organização, não apenas do aspecto de vista técnico para principalmente
estratégico.

O advento do conceito de gerenciamento de serviços de TI é uma

resposta à necessidade de mudança nos padrões atuais de modelo de gestão de
TI (FREITAS, 2010). Freitas (2010) também cita exemplos de problemas
relacionados às áreas de TI das empresas. Um exemplo refere-se à falta de
conhecimento do negócio da empresa por parte dos profissionais de TI. Outro
aspecto refere-se à tomada de decisões por parte dos dirigentes sem considerar a
capacidade tecnológica e a estrutura de TI da companhia. Olhando no sentido
contrário, muitas vezes a área de TI atua sem considerar se está agindo de modo
consoante com o plano estratégico da companhia. Cenários como estes levam a
organização a desperdiçar recursos. Além disso, esta situação promove um sério

35
risco de se comprometer a imagem da empresa, pelo fato de ela oferecer
soluções desalinhadas com a necessidade do cliente, além de comprometer os
prazos acordados.
Com relação ao Gerenciamento de Serviços de TI, Magalhães e
Pinheiro (2007, p. 59) definem:

O Gerenciamento de Serviços de TI é, de forma resumida, o

gerenciamento da integração entre pessoas, processos e tecnologias,
componentes de um serviço de TI, cujo objetivo é viabilizar a entrega e o
suporte de serviços de TI focados nas necessidades dos clientes e de
modo alinhado à estratégia de negócios da organização [...]
(MAGALHAES e PINHEIRO, 2007, p. 59).

2.6.5. Boas práticas e recomendações

A necessidade de se atingir a excelência e qualidade nos processos da

organização tem motivado a elaboração de diversas normas, manuais de boas
práticas entre outras publicações. Isto não é algo exclusivo da área de TI, já que
existem diversos exemplos aplicáveis a processos referentes a diversos
segmentos de atuação. Como exemplos, podem ser citados as normas ISO e o
PMBOK. As normas ISO consistem em padrões internacionais de qualidade
concebidos pela International Organization for Standardization. O PMBOK por sua
vez consiste numa publicação referente às boas práticas no que se refere à
gerenciamento de projetos, concebida pelo PMI (Project Management Institute)
Esses trabalhos em geral são desenvolvidos por instituições e grupos de
profissionais e são fruto da elaboração de estudos e trocas de experiências.
Com relação aos processos que envolvem a gestão de serviços em TI,
e na própria tentativa de se fazer com que a área de TI esteja alinhada com o
negócio da organização, podem ser citados o ITIL e o COBIT . O ITIL consiste
num framework voltado para o gerenciamento de serviços de TI. O COBIT por sua
vez consiste num modelo voltado para a melhoria da qualidade de controles em
gestão de TI, bem como o alinhamento adequado dos recursos aos requisitos do
negócio. Esses e outros frameworks representam justamente a tentativa de se
conceber a melhor maneira de se gerenciar TI, ou seja, são ferramentas que se

36
adequadamente aplicadas contribuem para a promoção de um eficiente e eficaz
gerenciamento dos serviços de TI. Essas recomendações e boas práticas foram
testadas, comprovadas e concebidas por meio de instituições que congregam
profissionais e estudiosos experientes.
Porém, tais práticas por melhores que sejam não estão ilesas de
esbarrarem em fatores como a própria cultura da organização.

2.6.6. Principais frameworks e conjuntos de boas práticas

A seguir, será feita uma explanação sucinta sobre os principais

frameworks e conjuntos de boas práticas. É importante deixar claro que o
propósito deste trabalho não é o de ensinar algum framework, por isso, será dada
apenas uma explicação geral sobre cada um.

2.6.6.1. PMBOK®

 Introdução

Para falar sobre o PMBOK® é primordial falar sobre o PMI. O Project

Management Institute (PMI), ou Instituto de Gerenciamento de Projetos é uma
entidade mundialmente reconhecida cujo trabalho consiste em se promover e
divulgar boas práticas no que se refere ao gerenciamento de projetos. Além disso,
certifica e congrega muitos profissionais afiliados de diversos ramos de atuação.
O PMI foi fundado em 1969 e possui sede na Filadélfia, Pensilvânia, nos EUA.
Não possui fins lucrativos e é referência na área de gerenciamento de projetos. O
instituto está espalhado geograficamente pelo mundo por meio de capítulos (Por
exemplo, existe o Capítulo São Paulo, Brasil)
O PMBOK (Project Management Body of Knowledge) é um conjunto de
boas práticas voltado para a gestão de projetos, publicado e editado pelo PMI. Em
1987 foi concebida a sua primeira versão oficial. As edições posteriores
contemplaram novos conteúdos, revisões e melhorias. O PMBOK®, sem exagero,
pode ser considerado a “Bíblia” da área de gerenciamento de projetos, pois
consiste na base sobre a qual se apoia o conhecimento do PMI. A sua evolução

37
demonstra que não se trata de um documento estático, mas dinâmico, o qual é
sempre adaptado e melhorado conforme as exigências da realidade e contexto
atual.

 Conceito de projeto.

Existem várias definições do conceito de projeto. O PMI define um

projeto como “um esforço temporário empreendido para criar um produto, serviço
ou resultado exclusivo”. A seguir, o comentário de Nocera (2009, p. 31) sobre a
definição de projeto:

Na sua forma mais pura, podemos definir projeto como um

empreendimento a ser realizado dentro de determinado esquema,
esboço ou risco de obra a realizar. Porém, com o uso o termo projeto
passou a englobar o conjunto de ações, atividades, recursos materiais e
humanos e tudo o mais necessário para a execução daquilo que foi
imaginado e desejado. (NOCERA, 2009, p. 31)

 Grupos de processos do PMBOK e áreas de conhecimento

De acordo com o PMI, o gerenciamento de projetos é promovido por

meio de cinco grupos de processos:

38
 Quadro 2 - Grupo de processos do PMI e suas finalidades

Grupo de Processos Finalidade

Grupo de Processos de Iniciação Formaliza o início do projeto

Grupo de Processos de Planejamento Planejamento das medidas a serem

tomadas para se atingir os objetivos
do projeto

Grupo de Processos de Execução Realização do que foi estipulado no

planejamento.

Grupo de Processos de Monitoramento e Monitora as ações garantindo que

Controle estão caminhando no sentido de
cumprir os objetivos do projeto e
consoantes com o planejamento
estabelecido.

Grupo de Processos de Encerramento Formaliza a aceitação do produto

resultante do projeto (pode se tratar
também de um serviço)

Fonte: Adaptado de Nocera (2009)

Estes grupos de processos estão distribuídos em nove áreas de

conhecimento:

- Gerenciamento de Integração do Projeto

- Gerenciamento do Escopo do Projeto
- Gerenciamento de Tempo do Projeto
- Gerenciamento de Custos do Projeto
- Gerenciamento da Qualidade do Projeto
- Gerenciamento de Recursos Humanos do Projeto
- Gerenciamento das Comunicações do Projeto
- Gerenciamento de Riscos do Projeto
- Gerenciamento de Aquisições do Projeto

39
 2.6.6.2. ITIL (Information Technology Infrastructure Library)

 Introdução

A ITIL (Information Technology Infrastructure Library) consiste num

conjunto de boas práticas para se promover o Gerenciamento de Serviços de TI.
O seu advento se deu na década de 1980 por meio da CCTA (Central
Communications and Telecom Agency), e tinha a finalidade de auxiliar na
comparação entre as propostas dos diversos prestadores de serviços de TI para
as agências e orgãos do governo britânico. O propósito era promover a
padronização do atendimento. Nos anos que se seguiram as boas práticas da ITIL
passaram a ser adotadas por companhias privadas. Hoje é adotada por
organizações do mundo todo.
As boas práticas pregadas pela ITIL podem ser consideradas flexíveis,
ou seja, a ITIL pode ser adaptada de acordo com a necessidade de cada
organização. Não se trata de uma lista de regras engessadas, mas pelo contrário,
a ITIL fornece informações e orientação para a concepção e melhoria dos
processos que envolvem os serviços de TI. Entre os benefícios resultantes da
adequada aplicação da ITIL na organização, é possível citar a melhoria na
qualidade dos serviços de TI, o aumento do nível de satisfação dos clientes e o
alinhamento das atividades do setor de TI com a estratégia de negócio da
empresa.

 Processos

A ITIL foi concebida para ter sua atenção voltada para o gerenciamento
dos processos. Foi definido anteriormente e de modo resumido o conceito de
processo no contexto geral. De acordo com Magalhães e Pinheiro (2007, p. 65) “o
Gerenciamento de Serviços em TI baseia-se em processo. Cada um deles é
constituído por um conjunto de atividades inter-relacionadas, a partir de um
objetivo estipulado, executadas para atingir os resultados desejados”.

40
  Ciclo de vida do serviço de TI

De acordo com a ITIL, o ciclo de vida do serviço é composto pelas

fases de:

Estratégia do serviço: Consiste na fase inicial e tem o objetivo de

alinhar o serviço com a estratégica de negócio da organização.

Desenho do serviço: A partir do alinhamento estratégico feito na fase

de estratégia o serviço passa então a ser desenhado. O serviço é tratado como
uma resposta à necessidade de negócio levantada, e o desenho desta solução
deve levar em conta o custo necessário, a infra-estrutura necessária e como a
solução irá agregar valor ao negócio da organização.

Transição do serviço: Nesta fase o serviço é colocado em operação.

O objetivo é minimizar os impactos e gerenciar adequadamente os riscos de
falhas.

Operação do serviço: Nesta fase serão tratados os processos

relacionados à operação cotidiana do serviço.

Melhoria de serviço continuada: Uma vez colocado o serviço em

operação, esta etapa deverá sempre monitorar se o serviço está alinhado com o
negócio da organização. Busca identificar oportunidades de melhorias.

Dentro destas fases temos os processos da ITIL, descritos a seguir:

 Descrição dos processos da ITIL

A fase de Estratégia de Serviço abrange os seguintes processos (ITIL,

2007):

41
 Gerenciamento Financeiro: O Gerenciamento Financeiro tem a
finalidade de determinar os custos associados aos serviços de TI, bem como
estabelecer justificativas coerentes para o investimento nesses serviços.

Gerenciamento de Portfólio de Serviço: O Gerenciamento de

Portfólio de Serviço tem o propósito de monitorar o serviço no sentido de se
verificar se ele está de fato se traduzindo em retorno para o negócio da
organização. No caso de o serviço não contribuir mais para o negócio, ele passa
a ser classificado como obsoleto e devem ser tomadas medidas para a sua
devida substituição ou retirada definitiva de produção.

Gerenciamento de demanda: O Gerenciamento de demanda tem o

propósito de realizar estimativas sobre o volume de demanda atual e futuro.
Alinhado com esta estimativa, os recursos de TI devem ser adequadamente
disponibilizados para suprir estas demandas.

A fase de Desenho de serviços abrange os processos seguintes (ITIL,

2007):

Gerenciamento do Nível de Serviço: O Gerenciamento do Nível de

Serviço tem o objetivo de garantir que os serviços de TI serão prestados em
conformidade com o que consta no Acordo de Nível de Serviço (ANS), cuja sigla
em inglês é SLA (Service Level Agreement). Um SLA basicamente consiste num
acordo feito entre o prestador de serviço de TI e os clientes. Neste acordo deve
ser definido qual o grau de prioridade de cada serviço prestado, o horário em que
é disponibilizado, como o serviço é disponibilizado, os prazos para solução, entre
outros itens.

Gerenciamento do Catálogo de Serviços: Um catálogo de serviços

basicamente é uma lista dos serviços disponibilizados aos clientes. O objetivo
deste processo é gerenciar e manter sempre atualizadas as informações contidas
neste catálogo.

42
 Gerenciamento do Fornecedor: No contexto da ITIL o fornecedor não
deve ser encarado como um mero provedor de produtos e/ou serviços, mas sim
um elemento estratégico. O gerenciamento do fornecedor tem a finalidade de
gerenciar adequadamente os contratos firmados com os fornecedores, no sentido
de se garantir que os serviços entregues estejam agregando valor ao negócio da
empresa.

Gerenciamento da Capacidade: O Gerenciamento da Capacidade

envolve o gerenciamento dos recursos técnicos necessários para a prestação do
serviço de TI, em termos de demanda. Esses recursos devem ser disponibilizados
tomando-se por base a demanda gerada pelo negócio, o custo associado e o que
está estabelecido no Acordo de Nível de Serviço (ANS).

Gerenciamento da Disponibilidade: O Gerenciamento da

Disponibilidade tem a finalidade de estabelecer e formalizar no Acordo de Nível
de Serviço (ANS) quais os níveis de disponibilidade que devem estar associados
aos serviços de TI. De acordo com Gaspar, Gomez e Miranda (2010, p. 185),
“disponibilidade é a capacidade em que os serviços, os componentes ou os itens
de configuração estejam disponíveis para os usuários conforme estabelecido nos
Acordos de Níveis de Serviços (ANSs)”.

Gerenciamento da Continuidade dos Serviços de TI: Considerando

que os serviços de TI devem ser alinhados com o negócio da empresa, o
gerenciamento da continuidade dos serviços de TI está incluído no gerenciamento
de continuidade do negócio da organização. O objetivo é garantir que a
organização possa ter suas operações restauradas rapidamente ao ocorrer um ou
mais eventos que interrompa total ou parcialmente um ou mais serviços de TI.
Este processo promove também ações preventivas, como por exemplo, análise
de risco.

Gerenciamento da Segurança da Informação: Basicamente, tem o

objetivo de garantir a segurança dos serviços de TI em termos de disponibilidade,
confidencialidade e integridade.

43
 A fase de Transição de serviço compreende os processos (ITIL, 2007):

Planejamento e Suporte da Transição: Este processo tem a

finalidade de assegurar que na fase de operação do serviço o mesmo seja
realizado conforme o que foi definido nas fases de estratégia e desenho de
serviço.

Gerenciamento de Liberação: O gerenciamento de liberação tem a

finalidade de gerenciar a colocação de um ou mais itens de configuração em
produção, após terem sofrido as mudanças necessárias.

Gerenciamento de Configuração: Os Itens de Configuração (ICs) são

componentes que são relacionados direta ou indiretamente com infra-estrutura de
TI da organização. Tratam-se de itens físicos ou lógicos, como por exemplo:
software, placa de rede, manual, incidentes etc... A finalidade do processo de
Gerenciamento de Configuração consiste em se conceber uma base de dados
para abrigar os dados referentes a estes itens. Trata-se do banco de dados de
gerenciamento de configuração (BDGC).

Validação e Teste do Serviço: Este processo tem a finalidade de

garantir a qualidade do serviço ou da alteração de serviço, no sentido de ele de
fato atender o propósito a que se destina.

Gerenciamento de Avaliação: O Gerenciamento de Avaliação tem o

objetivo de verificar o desempenho da mudança do serviço. Verifica se o serviço
oferecido é adequado e correto do ponto de vista da qualidade, performance,
preço, etc....

Gerenciamento de Mudança: O Gerenciamento de Mudança trata das

mudanças ocorridas em um ou mais Itens de Configuração (ICs). Uma mudança
em um item de configuração não deve ocorrer de modo indiscriminado, mas deve
ser motivada por uma necessidade concernente ao negócio da organização. Por

44
conseguinte, deve ser devidamente planejada, autorizada, testada e
documentada. Além disso, deve-se tomar medidas preventivas e contingenciais
para o caso de ocorrer alguma inoperância total ou parcial em um ou mais
serviços relacionados ao item de configuração em questão.

Gerenciamento do Conhecimento: O Gerenciamento do

Conhecimento tem a finalidade de fazer com que as empresas tomem decisões
baseadas em dados e informações confiáveis, precisos e seguros.

A fase de Operação de serviço abrange os seguintes processos (ITIL,

2007):

Gerenciamento de Incidente: Não podemos falar de gerenciamento

de incidentes sem falarmos sobre o conceito de Central de Serviços. Ela consiste
no ponto de interface entre os usuários e os serviços de TI, e é responsável pelo
adequado tratamento dos incidentes. Um incidente consiste numa interrupção
e/ou falha em um ou mais elementos que compõem um serviço de TI. Podemos
citar como exemplos a falha em um link ou a falha no serviço de correio
eletrônico.

Gerenciamento de Problema: Um problema é diferente de um

incidente, pois um incidente é causado por um ou mais problemas. A partir da
comunicação do incidente para a Central de Serviços, ela deve identificar qual ou
quais os problemas que ocasionaram o incidente. Uma vez identificado(s) o(s)
problema(s), deve-se atuar no sentido de se solucioná-lo(s) definitivamente. O
gerenciamento de problema tem também a finalidade de promover medidas de
prevenção a fim de que o problema não volte a ocorrer. O quadro 3 apresenta
exemplos de incidentes e os possíveis problemas causadores:

45
 Quadro 3 - Exemplos de incidentes e seus respectivos problemas causadores.

Incidente Problema

Divergência nos valores gerados Sistema está realizando

pelo sistema incorretamente os cálculos dos
valores gerados

Arquivo de integração não foi Sempre que o pedido possui mais

gerado de dois itens, o arquivo de
integração não é gerado.

Lentidão e travamento na gravação Uma das tabelas que o sistema

do pedido utiliza para gravar o pedido
sempre fica corrompida, quando
se trata de pedido faturado.

Fonte: O autor

Tratamento de Requisições: Este processo tem o propósito de

assegurar rapidez e eficiência no atendimento das requisições cotidianas.

Gerenciamento de Eventos: Este processo tem a finalidade de

promover o monitoramento de todos os eventos concernentes à infra-estrutura. O
foco deste processo compreende a análise do evento e a tomada de ações para
assegurar o andamento normal dos processos de infra-estrutura. Um evento pode
ser definido como uma sinalização por parte de algum serviço de TI, no que se
refere à infra-estrutura.

Gerenciamento de Acesso: Este processo tem o objetivo de controlar

a utilização dos serviços de TI e como os mesmos são utilizados. Deve promover
a tomada de ações alinhadas com o que foi definido nos processos de
gerenciamento de segurança e disponibilidade.

46
 2.6.6.3. COBIT

O COBIT (Control Objectives for Information and related Technology),

cuja sigla em português significa “Objetivos de Controle para a Informação e
Tecnologia Relacionada” é um modelo de referência concebido em 1994 por
estudiosos das universidades de Amsterdã, Califórnia e Austrália. Este modelo
aplica-se à gestão de TI e possui o foco voltado para controles. O termo controle
se refere ao fato de este modelo procurar assegurar que a empresa promova uma
gestão voltada para garantir que os recursos de TI sejam alinhados com o
negócio e sejam empregados de modo adequado e controlado. Neste contexto, o
termo “controle” também se aplica ao gerenciamento dos riscos. O COBIT, em
resumo, busca fazer com que a empresa implemente políticas para que a TI
esteja vinculada aos requisitos do negócio. Mais do que isso, o COBIT visa
garantir que estes requisitos sejam satisfeitos, também por meio do adequado
monitoramento e uso de indicadores de performance.
De acordo com a publicação Cobit 4.1 do IT Governance Institute a
missão do COBIT é “Pesquisar, desenvolver, publicar e promover um modelo de
controle para a Governança de TI atualizado e internacionalmente reconhecido
para ser adotado por organizações e utilizado no dia a dia por gerentes de
negócios, profissionais de TI e profissionais de avaliação”.
De acordo com Schlieper (2007, p. 14), “utiliza-se o COBIT para
controlar se os planos de TI estão aderentes à Governança Corporativa, que tem
como missão garantir que a estratégia da empresa esteja sendo seguida [...]”
O COBIT é dividido em 4 domínios, que são: “Planejar e Organizar”,
“Adquirir e Implementar”, “Entregar e Suportar" e “Monitorar e Avaliar”. Acerca
disso temos o comentário de Albertin e Albertin (2010, p. 76) sobre esses
domínios:

O planejamento e a organização incluem os processos de planejamento

de TI, seu alinhamento com a organização e a estrutura organizacional
da área de TI. A aquisição e implementação incluem tanto os processos
de aquisição de hardware, software quanto o de desenvolvimento de
aplicações, de suas implementações e instalações. A entrega e o
suporte incluem os processos de prestação de serviços de TI, desde a
entrega e o atendimento às solicitações, como manutenção e
continuidade dos serviços. O controle inclui os processos de controle de

47
 desempenho e qualidade dos produtos e serviços de TI. (ALBERTIN e
ALBERTIN, 2010, p. 76)

Dentro desses domínios, temos os processos. A saber:

 Planejar e Organizar

PO1 Definir um Plano Estratégico de TI

PO2 Definir a Arquitetura da Informação
PO3 Determinar as Diretrizes de Tecnologia
PO4 Definir os processos, a Organização e os Relacionamentos de
TI
PO5 Gerenciar o Investimento em TI
PO6 Comunicar Metas e Diretrizes Gerenciais
PO7 Gerenciar os Recursos Humanos de TI
PO8 Gerenciar a Qualidade
PO9 Avaliar e Gerenciar os Riscos de TI
PO10 Gerenciar Projeto

 Adquirir e Implementar

AI1 Identificar Soluções Automatizadas

AI2 Adquirir e Manter Software Aplicativo
AI3 Adquirir e Manter Infra-estrutura de Tecnologia
AI4 Habilitar Operação e Uso
AI5 Adquirir Recursos de TI
AI6 Gerenciar Mudanças
AI7 Instalar e Homologar Soluções e Mudanças

 Entregar e Suportar

DS1 Definir e Gerenciar Níveis de Serviços

DS2 Gerenciar Serviços Terceirizados

48
 DS3 Gerenciar o Desempenho e a Capacidade
DS4 Assegurar a Continuidade dos Serviços
DS5 Garantir a Segurança dos Sistemas
DS6 Identificar e Alocar Custos
DS7 Educar e Treinar os Usuários
DS8 Gerenciar a Central de Serviço e os Incidentes
DS9 Gerenciar a Configuração
DS10 Gerenciar Problemas
DS11 Gerenciar os Dados
DS12 Gerenciar o Ambiente Físico
DS13 Gerenciar as Operações

 Monitorar e Avaliar

ME1 Monitorar e Avaliar o Desempenho de TI

ME2 Monitorar e Avaliar os Controles Internos
ME3 Assegurar a Conformidade com Requisitos Externos
ME4 Prover Governança de TI

A figura 4 apresenta os princípios básicos do COBIT:

Figura 4 – Princípios básicos do COBIT

Fonte: IT Governance Institute (2007, p. 12)

49
 2.6.6.4. Análise ITIL x COBIT

É importante ressaltar que, apesar de ambos procurarem promover

Governança em TI, a ITIL e o COBIT são frameworks distintos. O COBIT é
voltado para qualidade dos controles de processos específicos. O seu foco, em
linhas gerais, é avaliar se o modo como os processos estão sendo controlados e
medidos é adequado, eficiente e eficaz, sob o âmbito dos requisitos do negócio. A
ITIL é voltada predominantemente para a operação de gestão em TI. Ou seja, ela
busca prover recomendações de boas práticas para que a gestão dos serviços de
TI seja eficiente e eficaz. O foco do COBIT está no gerenciamento dos controles
relacionados aos processos, enquanto a ITIL se volta para o gerenciamento dos
próprios processos.

2.6.6.5. SOA (Service-Oriented Architecture)

 O conceito de arquitetura

No contexto da Tecnologia da Informação, o termo arquitetura tem por

finalidade ilustrar de modo organizado todos os elementos que compõem um
sistema informatizado, bem como todas as interações entre eles. Por exemplo,
numa aplicação voltada para internet, os elementos que a compõem podem ser o
navegador, o servidor web, o servidor de banco de dados, o repositório de rotinas,
etc...

A figura 5 apresenta um exemplo simples de uma arquitetura:

50
 Figura 5 – Exemplo de arquitetura
Fonte: O autor

 Conceito de serviços de negócio

Segundo Hurwitz, Bloor, Kaufman e Halper (2009, p. 48), um serviço de

negócio é “o encapsulamento lógico da função do negócio”. Em termos
computacionais, um serviço de negócio pode ser entendido como um conjunto de
códigos de software que tem por finalidade automatizar uma função do negócio,
ou seja, os serviços correspondem à versão codificada de uma função do
negócio. Por exemplo, se uma determinada rotina do sistema possui a função de
validar um CPF, ela pode então representar o serviço de validação de CPF. Neste
exemplo, ele receberá o número do CPF e devolverá uma resposta dizendo se o
mesmo é válido ou não.

 Conceito de processos de negócios

Os serviços de negócios podem ser unidos e formar os processos de

negócio. Hurwitz, Bloor, Kaufman e Halper (2009, p. 65) definem um processo de
negócio como a “codificação de regras e práticas [...] que constituem o negócio”.
Um processo de negócio corresponde a um conjunto de serviços integrados.

51
  Conceito de acoplamento

Acoplamento pode ser entendido como o grau de independência dos

componentes de um sistema computacional. Se os componentes de um sistema
possuem baixo acoplamento, significa que cada componente que o constitui
possui grande autonomia.

 Arquitetura Orientada a Serviços (AOS ou SOA, em inglês)

O conceito de Arquitetura Orientada a Serviços (AOS ou SOA, em

inglês) consiste basicamente em se conceber sistemas computacionais
compostos por serviços conectados de modo independente uns dos outros. Os
serviços, portanto, são componentes autônomos que representam funções do
negócio (possuem baixo acoplamento) e podem ser reutilizados em outras
aplicações.
Numa arquitetura orientada a serviços é primordial a presença de um
meio pelo qual os serviços possam se comunicar. A resposta a esta necessidade
pode se traduzir na presença de um elemento chamado Barramento de Serviço
Corporativo ou Enterprise Service Bus (ESB). Conforme definição de Hurwitz,
Bloor, Kaufman e Halper (2009, p. 148), “o barramento de serviço corporativo é o
sistema nervoso das comunicações para serviços em uma arquitetura orientada a
serviço”. O ESB se encarrega de gerenciar a troca de mensagens entre os
componentes da arquitetura.

 A camada de negócio e a camada de plumbing

Numa rotina de geração de nota fiscal é possível ter uma instrução do

tipo “sinalizar valores divergentes”, e podemos também ter uma instrução do tipo
“verificar o compartilhamento das tabelas X e Y”. Neste exemplo, a primeira
instrução citada diz respeito a uma parte da lógica do negócio, e a segunda é
concernente à logica do próprio computador (plumbing). A abordagem orientada a
serviços promove a separação da arquitetura em duas camadas: a camada de
negócio, que congrega os serviços relacionados à lógica do negócio e a camada

52
de plumbing, que se compõe de serviços relacionados à lógica computacional. A
Fig. 6 apresenta alguns exemplos de elementos que compõem a camada de
serviços de negócio e a camada de plumbing:

Camada de Serviços de Negócio

Financeiro
Compras
Logística
CRM
Correio eletrônico
Controle de chamados

Camada de Plumbing

Service Desk
Administração da Rede
Gerenciamento de Configuração
Workflow
Segurança de dados

Figura 6 – Exemplos de elementos da camada de serviços e plumbing.

Fonte: Adaptada de Hurwitz, Bloor, Kaufman e Halper (2009, p. 164)

 A abordagem SOA e sua relação com ITIL

O conceito SOA tem o foco voltado para prover suporte ao negócio da

organização. Ao agrupar os serviços de negócio numa camada separada da
camada dos serviços de plumbing concebe-se uma arquitetura melhor
gerenciável. Isto significa que o gerenciamento dos serviços SOA pode ser
aplicado sob a perspectiva do negócio e sob a perspectiva do plumbing. Como
visto anteriormente, a ITIL descreve um conjunto de processos de gerenciamento
sobre os serviços de TI. Unindo os conceitos da ITIL com a abordagem SOA,
pode-se seguramente afirmar que os processos da ITIL devem ser aplicados
sobre cada um dos serviços SOA. Por exemplo, cada serviço SOA deve ter o seu
próprio nível de serviço.

53
 2.6.6.6. A norma ISO/IEC 20.000 (Information Technology –
Service Management)

De acordo com Magalhães e Pinheiro (2007), a norma ISO/IEC 20.000

é voltada para a garantia da qualidade dos serviços de TI que uma empresa
entrega a seus clientes. O seu conteúdo é totalmente alinhado com os conceitos
de gerenciamento de serviços do framework ITIL.
Porém, antes de falar sobre a norma ISO/IEC 20.000, é importante
mencionar a norma britânica BS 15.000 (British Standard). Trata-se da primeira
norma mundial voltada para o gerenciamento de serviços de TI. Em 2005, foi feita
a publicação da ISO/IEC 20.000, cuja elaboração foi baseada na norma BS
15.000.
Segundo Magalhães e Pinheiro (2007, p. 578):

A norma britânica BS 15.000 foi o primeiro padrão mundial orientado

especificamente para o Gerenciamento de Serviços de TI. Sua
publicação foi feita pela British Standards Institution (BSI) e define os
aspectos dos processos de gerenciamento de serviços que são
essenciais para o fornecimento de serviços de TI de elevada qualidade
(...). (MAGALHÃES e PINHEIRO, 2007, p.578).

A norma ISO/IEC 20.000 aborda o Gerenciamento de Serviços de TI

através de um conjunto de processos, os quais são todos baseados no framework
ITIL, conforme apresentado no Quadro 4:

54
 Quadro 4 - Conjunto de processos abrangidos pela ISO/IEC 20.000

Processo de Entrega de Serviços Gerenciamento de Capacidade

Gerenciamento da Disponibilidade
Gerenciamento da Continuidade dos Serviços
Gerenciamento do Nível de Serviço
Informe de Serviços
Gerenciamento da Segurança da Informação
Gerenciamento Financeiro
Processo de Controle Gerenciamento da Configuração
Gerenciamento e Mudanças
Processo de Liberação Gerenciamento de Liberações
Processo de Resolução Gerenciamento de Incidentes
Gerenciamento de Problemas
Processo de Relacionamento Gerenciamento de Relacionamento com o
Negócio
Gerenciamento de Fornecedores

2.7. A ÁREA DE SUPORTE

Um modo pelo qual se pode perceber sucintamente o propósito de uma

área de suporte é por meio do comentário de Cohen (2005, p. 3):

Como nenhuma tecnologia é infalível, as organizações provêm técnicos

para atender usuários que precisam de suporte técnico para problemas
ou que requisitam procedimentos (instalação de software, mudanças de
localização, melhorias, etc). Tais técnicos compõem os chamados
"departamentos de suporte técnico" ou, pelo jargão da indústria de
tecnologia da informação, os "departamentos de Help Desk e Service
Desk". (COHEN, 2005, p. 3).

55
 2.7.1. Histórico

Antes de analisar as características gerais de uma área de suporte,

convêm analisar de modo sucinto como foi a evolução da prestação do serviço de
TI ao longo dos anos. Hoje em dia, as empresas do ramo de TI possuem áreas de
suporte técnico, desenvolvimento, etc... porém, no passado toda a atividade
relacionada com TI era resumida no CPD (Centro de Processamento de Dados).
Na década de 70, todas as necessidades dos usuários eram
direcionadas ao CPD e o processamento era feito em lotes (batch). Ou seja, o
escopo de atuação do suporte era restrito apenas à sala do CPD. O
processamento era totalmente centralizado. No fim da década de 70, ocorreu o
advento dos chamados “terminais burros”, que eram nada mais do que terminais
de acesso utilizados pelos usuários por meio dos quais eles podiam interagir com
o computador central. A partir deste ponto não era mais necessário enviar
pedidos a pessoal do CPD. Os terminais eram apenas pontos de interface e não
tinham nenhum poder de processamento. É possível fazer uma analogia com os
thin-clients existentes hoje em dia. A partir deste momento, o escopo de atuação
do pessoal do CPD foi estendido também para prestar auxílio aos usuários na
operação destes terminais.
A partir da década de 80, ocorreu o advento dos computadores
pessoais, que deixaram de ser “terminais burros” e passaram a possuir
capacidade de processamento e dispositivos de armazenamento. Com isso, os
usuários passaram a ter possibilidade de manipular e processar dados
localmente. Ou seja, ocorreu uma descentralização na utilização dos
computadores, que anteriormente, era baseado apenas no computador central.
Na década de 90 ocorreu o advento da Internet. Isto aumentou ainda
mais a descentralização do processamento de dados e informações.
Neste histórico, o que se pode perceber é que ao longo do tempo o
escopo de atuação do suporte técnico caminhou no sentido do mais simples para
o mais complexo. Ou seja, conforme os usuários foram gradativamente tendo
acesso maior a utilização da tecnologia, é claro deduzir que a necessidade e a
abrangência de atuação do suporte aumentou paralelamente. No começo, o
usuário praticamente não tinha acesso à tecnologia já que poderia apenas

56
encaminhar pedidos aos operadores do CPD, pois o processamento era
centralizado (FREITAS, 2010, p. 15).
A complexidade do trabalho do suporte técnico aumentou no sentido
em que aumentou a interação das pessoas com a tecnologia. Profissionais que
não pertencem a área de TI passaram a interagir de modo muito mais intenso
com ela. Isto se deveu à descentralização da tecnologia e ao uso intenso de
sistemas informatizados para controlar os processos das companhias
(financeiros, compras, logística etc...). Westerman e Hunter (2008, p. 1), afirmam
que atualmente vivemos num “mundo em que a TI está não apenas presente por
toda parte, mas também difusa e complexamente interconectada dentro e fora
das empresas”. Com diversos processos de negócio atrelados a TI, logo se
concebeu a necessidade de se alinhar TI com o objetivo estratégico da
organização.
O ponto central desta questão é que a capacidade e o modelo de
gerenciamento dos serviços de TI não progrediu na mesma velocidade da
expansão da tecnologia e da interação dos usuários com ela. Isto gerou uma
lacuna. Na tentativa de se preencher esta lacuna, tem-se concebido diversos
modelos, boas práticas e frameworks tais como ITIL, COBIT, etc...

2.7.2. A área de suporte no contexto atual

2.7.2.1. A TI no contexto atual.

No tópico anterior foi percorrido um caminho para poder situar o

panorama atual do escopo de atuação da área de suporte técnico. Em linhas
gerais, hoje a realidade é pautada pelos seguintes elementos:

 A TI está disseminada e controla praticamente todos os processos que

envolvem o negócio da organização. Isto é confirmado pela afirmação de
Freitas (2010, p. 10): “Cada vez mais as empresas estão extraindo
funcionalidades da Tecnologia da Informação para suportar seus objetivos
de negócio”.

57
  A TI deixou de ser meramente operacional e se aproximou do negócio. Ou
seja, ela passou a influenciar o negócio, no sentido estratégico da palavra.
Isto significa que ela pode apoiar decisões estratégicas. A consequência
disto é que uma falha na área de TI pode prejudicar consideravelmente a
operação do negócio e trazer grandes prejuízos. Acerca disto, Westerman
e Hunter (2008) definem o “Risco de TI”, ou seja, a “possibilidade de que
algum evento imprevisto, que envolva falha ou mau uso da TI, ameace um
objetivo empresarial.”

2.7.2.2. Alguns dados sobre a área de suporte no contexto atual

Com o aumento da influência da TI sobre os negócios da companhia, a

prestação de serviços de suporte passou a ter um escopo de atuação mais amplo
como visto anteriormente.
A seguir serão apresentados alguns resultados provenientes de uma
pesquisa de âmbito nacional sobre gestores de help-desk, service-desk e suporte
técnico realizada entre os dias 08 e 15 de março de 2010. A pesquisa foi
realizada pela entidade 4HD. Trata-se de uma organização que promove o
conhecimento e aprendizado na área de gestão de suporte técnico por meio de
treinamentos, palestras e seminários.

 77 % dos gestores de suporte técnico admitem que sempre no final do dia

tem a sensação de que não conseguiram atender toda a demanda, ou seja,
sempre ficou faltando algo.
 68 % dos gestores admitem que suas empresas não deixam claro quais
resultados esperam do centro de suporte.
 41 % dos gestores não utilizam indicadores de desempenho.

Com relação à catálogo de serviços:

 32 % admite que não possui catálogo de serviços

 18,8 % possui catálogo de serviços, mas admite que ele é de baixa
qualidade.

58
 Com relação à base de conhecimento:

 28,1 % dos gestores admite que não possui uma base de conhecimento
 27,6 % possui uma base de conhecimento mas admite que ela possui
baixa qualidade.
 Apenas 18,9 % dos entrevistados que possuem uma base de
conhecimento admitem que ela possui qualidade “muito boa” ou
“excelente”.

Estes e outros fatos se refletem diretamente no grau de satisfação e na

qualidade de atendimento prestado aos clientes e usuários da tecnologia. Existe
um consenso de que os departamentos de suporte enfrentam problemas
semelhantes. De modo geral, o suporte é visto como algo distante do negócio da
empresa. Além disso, é comum diversos setores de suporte organizarem suas
atividades numa abordagem reativa, ou seja, atuar sobre os problemas ao invés
de implementar meios de se antecipar a eles. O fato é que a área de suporte não
pode se sustentar sozinha, já que depende de outras áreas da empresa, como
será visto nos tópicos seguintes. A seguir, serão apresentados alguns dos típicos
problemas relacionados a diversos departamentos de suporte das organizações,
segundo Magalhães e Pinheiro (2007, p.110):

 “Percepção de baixa qualidade dos serviços de TI”.

 “Dia-a-dia marcado por „incêndios‟ (situações de emergência)”
 “Problemas iguais resolvidos de modo repetitivo, sem que seja dada uma
solução definitiva”.
 “Interrupções contínuas na execução dos trabalhos”.
 “Dependências de pessoas-chave”.

A resposta para esta situação envolveria primeiramente o

entendimento claro da importância estratégica da área de suporte, e a partir disso,
a concepção de processos e ações coordenadas para ir ao encontro dos objetivos
concernentes ao negócio da empresa. Mais do que conceber e implementar

59
procedimentos, seria preciso também uma mudança de paradigma e do
comportamento das pessoas envolvidas (analistas, gestores e também os
clientes). Porém, muitas organizações possuem resistência a mudanças,
principalmente quando a área de suporte é vista como um mero provedor de
serviços e não um elemento estratégico da companhia.

2.7.2.3. A importância estratégica da área de suporte

O primeiro passo para se iniciar a caminhada no sentido de se

conceber uma nova realidade na área de suporte é a organização passar a
enxergar a área como um elemento primordial para a estratégia de negócio da
empresa. A partir disso, todas as ações deverão ser pautadas nesta consciência.
De acordo com Cohen (2011, p. 24), “todo departamento de suporte
deve ser pensado como uma empresa”.
Se a organização considerar a área de suporte técnico como o ponto
de interface entre a empresa e o cliente, ela pode implementar meios de se
aproveitar desta abordagem. O atendimento prestado pelo suporte ao cliente
reflete diretamente na percepção que o cliente tem da empresa inteira, ou seja, o
suporte é um elemento primordial na manutenção da imagem da companhia.
Num outro âmbito, a área de suporte pode ser encarada como um
valioso instrumento para se coletar dados e informações pertinentes para se
implementar melhorias tanto no produto como no próprio processo de
atendimento. Isto poderia ser feito, por exemplo, por meio das pesquisas de
satisfação.
Numa outra abordagem, a área de suporte pode ser vista como um
instrumento de retenção de clientes. Fatores como proatividade, postura e
comunicação são muitas vezes mais decisivos do que conhecimentos técnicos
para influenciar a satisfação do cliente ou usuário.

60
 2.7.3. Medindo a qualidade da área de suporte

O conceito de qualidade aponta para um parâmetro a ser perseguido.

No caso do suporte técnico, é comum se estabelecer uma meta (por exemplo:
solucionar um determinado número de chamados por dia). Porém, é necessário
ter cuidado porque nem sempre o resultado numérico sinaliza que a área está
tendo qualidade na prestação dos serviços. A qualidade deve sim ser apoiada por
indicadores numéricos, porém, estes resultados devem sempre ser confrontados
com diversos fatores. Se um chamado é solucionado, isto não significa que ele foi
solucionado com qualidade. Se o problema do cliente foi resolvido, é necessário
verificar alguns fatores como:

 O problema foi resolvido definitivamente, ou seja, a causa-raiz foi

solucionada?
 Foram necessárias quantas interações (ligações telefônicas, e-mails, etc...)
até o problema ser corretamente compreendido pelo analista?
 Teve algum momento em que o chamado foi dado como solucionado, mas
com uma solução que não resolveu o problema?
 O problema foi resolvido dentro de um prazo aceitável, ou seja, que não
prejudicasse a operação do negócio do cliente?
 O analista demonstrou empenho, boa comunicação e postura profissional
adequada diante do cliente?
 O cliente teve uma percepção positiva da qualidade do atendimento?

Para obter essas informações, é necessário que a área de suporte faça

um acompanhamento detalhado de cada chamado. O objetivo deve ser sempre
não apenas atender a necessidade do cliente, mas superar suas expectativas. É
certo que os analistas de suporte atendem diversos clientes/usuários diariamente,
porém, o cliente não tem esta percepção. Se uma pessoa é a décima paciente de
um médico, isto não justifica que ela receba um atendimento de má qualidade. Os
analistas devem ser treinados e incentivados a atender cada cliente e usuário
com a mesma atenção e empenho. Cada chamado deve ser tratado como único.

61
 Para acompanhar o nível de qualidade percebida dos clientes a
companhia pode implementar meios para que o cliente forneça informações
referentes ao atendimento, ao final de cada chamado. Quando um chamado é
solucionado, o cliente recebe um formulário com perguntas simples sobre como
foi o atendimento.
A Fig. 7 apresenta um exemplo de pesquisa de nível de satisfação do
usuário. Os aspectos avaliados são baseados nos comentários de Muns (1993).
Baseado neste autor, Magalhães e Pinheiro (2007) afirmam que o nível de
satisfação dos usuários “pode ser determinado pela aplicação de um conjunto de
perguntas, que cubra os aspectos específicos da prestação destes serviços (...)”.

Aspecto Avaliado Ruim Bom Muito Excelente

Bom
Habilidade do analista em compreender o
problema

Conhecimento demonstrado pelo analista

Qualidade da solução apresentada

Tempo gasto na solução do problema

Impressão geral da postura do analista

Comentários/Sugestões/Elogios/Reclamações

Figura 7 – Exemplo de pesquisa de satisfação

É necessário que a empresa desenvolva meios de incentivar o usuário

a responder estas pesquisas. Mais do que isto, é preciso mostrar ao cliente que
os dados e informações coletadas estão efetivamente utilizados. Se um usuário
fizer uma reclamação, a área deve atuar sobre ela até a percepção negativa do
usuário ser eliminada. Atitudes como estas irão incentivar ainda mais os usuários
a responder às pesquisas de satisfação, pois terão a certeza de que os seus
comentários não estão sendo desprezados.

62
 Um ponto central da qualidade do suporte é o relacionamento com o
cliente. Gerenciar a qualidade do suporte significa gerenciar o relacionamento
com os clientes, usuários e partes interessadas. É inevitável que ocorram erros
por parte da equipe, porém, mais relevante do que isso é o modo como a
empresa lida com os erros.

2.7.4. Como a área de suporte é afetada pelas outras áreas

Ao tentar conceber um modelo de gestão que assegure a qualidade do

processo de suporte técnico, não se pode esquecer que a área de suporte não é
independente de outras áreas da empresa. A tentativa de se garantir a qualidade
no serviço de suporte técnico, certamente é um processo que passa pelas outras
áreas.

2.7.4.1. A área de suporte e a área comercial

Ao considerar, por exemplo, uma empresa de software, a área

comercial deve ser bem criteriosa e clara na apresentação do produto ao cliente,
para não gerar dúvidas posteriores. O cliente deve ser informado claramente das
opções existentes e não existentes no sistema adquirido. As dúvidas que o cliente
ou usuário vier a ter durante o uso do sistema recairão sobre a área de suporte e
é bastante desagradável o analista dizer ao cliente que o sistema não possui
certa opção e ouvir dele que quando venderam o sistema disseram o contrário.
Isto vale também se forem desenvolvidas novas funções no sistema e
forem comercializadas separadamente.

2.7.4.2. A área de suporte e a área de desenvolvimento

Considerando a área de desenvolvimento como o setor da empresa

que desenvolve novas funções no sistema além de corrigir defeitos no produto, a
comunicação entre as duas áreas deve ser eficiente e eficaz, principalmente no
caso do desenvolvimento de novas funções no produto e na comunicação de
correções efetuadas. O desenvolvimento deve seguir um padrão adequado na

63
concepção e documentação dos códigos das rotinas, lembrando que o suporte
pode ser composto também de analistas que efetuam análises mais aprofundadas
de certos problemas relatados pelos usuários.

2.7.4.3. A área de suporte e a área de qualidade

A área de qualidade ou a área responsável pelos testes das rotinas do

sistema afeta diretamente o serviço dos analistas de suporte. Isto porque uma
rotina não testada ou testada de modo inadequado pode fazer com que “escape”
funções com erro para os clientes e usuários do sistema. Se considerarmos uma
empresa de software com 200 clientes, significa que serão 200 aberturas de
chamados para relatar o mesmo problema. É fato que se um analista de suporte
fizer um teste na rotina durante o atendimento de apenas um chamado ele
certamente constatará o erro. Porém, deve-se considerar que:

 Pode ser que não seja um erro simples de ser simulado. Ou seja, pode
levar tempo até o analista de suporte conseguir simulá-lo.
 Além dos 200 telefonemas, a área de suporte tem que lidar com a
demanda normal de chamados.
 Graças a um teste não feito ou feito de modo inadequado, a área de
suporte além de atender a demanda normal de chamados, deverá tentar
obter uma solução paliativa para não comprometer o negócio dos clientes.
 O erro pode não ser de fácil correção, ou seja, após identificá-lo será
preciso empregar tempo para corrigi-lo e depois o tempo necessário para
testar.

Nesta situação hipotética, se os analistas de suporte não conseguirem

uma solução paliativa para os clientes, eles terão apenas a alternativa de dizer-
lhes que o problema está sendo corrigido. Dependendo da gravidade do
problema, isto afetará negativamente o relacionamento da empresa com o cliente.

64
 3. METODOLOGIA

3.1. INTRODUÇÃO

Neste capítulo será apresentada a metodologia utilizada para a

concepção da pesquisa.
A empresa analisada possui um grande tempo de atuação no suporte
técnico que presta ao seu produto, um sistema de controle de operações de
comércio exterior. Apesar dos pontos positivos, durante um tempo longo, a
companhia lida com uma demanda alta de incidentes e com um grande número
de reincidências. Esta realidade tem se traduzido em um volume considerável de
reclamações por parte dos clientes. O pano de fundo da pesquisa abrange a
realidade da empresa analisada e o panorama atual do papel da TI. O trabalho de
observação, levantamento e anotações das informações foi feito num intervalo de
tempo de aproximadamente seis meses.

3.2. TIPO DE PESQUISA

Existem várias definições para o termo pesquisa. Uma possível

abordagem é a de Lakatos e Marconi (1992, p. 43) que afirmam que a pesquisa
“se constitui no caminho para se conhecer a realidade ou para descobrir verdades
parciais”.

3.2.1. Conforme a natureza

Conforme a natureza, o tipo de pesquisa empregada neste trabalho é a

pesquisa aplicada, pois possui como finalidade atuar sobre problemas
específicos. Não envolve interesses de cunho universal. De acordo com Danton
(2002, p. 10), a pesquisa aplicada tem por objetivo “a busca de soluções para
problemas concretos e imediatos”. No escopo do objeto de estudo, a pesquisa
procura atuar sobre os problemas que envolvem a área de suporte da empresa
num determinado espaço de tempo.

65
 3.2.2. Conforme a forma de abordagem do problema

Conforme a forma de abordagem do problema, a pesquisa empregada

neste trabalho é do tipo pesquisa qualitativa, pois praticamente não envolve o uso
de medidas estatísticas, salvo em pontos específicos. As informações coletadas
para a elaboração da pesquisa não são, em sua maioria, fruto de dados
estatísticos, mas oriundas de observação. Conforme Queiroz, Vall, Souza e Vieira
(2007, p. 276) “a pesquisa qualitativa tem como foco de estudo o processo
vivenciado pelos sujeitos”.

3.2.3. Conforme os seus objetivos

Conforme os seus objetivos, a pesquisa pode ser classificada como

pesquisa descritiva, pois tem como finalidade a descrição detalhada dos
fenômenos que envolvem a amostra analisada. No caso da empresa estudada, os
fenômenos envolvem os acontecimentos pertinentes ao cotidiano da área de
suporte técnico.

3.2.4. Conforme os procedimentos técnicos

Do ponto de vista dos procedimentos técnicos, a pesquisa pode ser

classificada como pesquisa participante, pois o pesquisador participou e interagiu
com todos os envolvidos e fenômenos que envolviam a amostra, além de se valer
da observação participativa, pois as informações coletadas são fruto da
observação e de levantamento sistemático. Danton (2002, p.16) utiliza o termo
“observação participante” e afirma que esta técnica consiste no “contato direto do
pesquisador com o fenômeno observado”.

66
 3.3. LIMITAÇÕES DOS TIPOS DE PESQUISAS UTILIZADOS

Com relação às limitações e falhas dos métodos e tipos de pesquisas,

Ruiz (2004, p. 37-47), afirma que “cabe ao pesquisador minimizar os problemas
ou falhas de cada um dos métodos”.
A técnica de observação participativa possui a vantagem de se estar
bem próximo do(s) fenômeno(s) estudado(s). Além disso, um ponto forte desta
técnica é o fato de o pesquisador ter maior acesso à informações e coleta de
dados. Queiroz, Vall, Souza e Vieira (2007, p.276) afirmam que um ponto positivo
da observação participante “é a possibilidade de obter a informação no momento
em que ocorre o fato na presença do observador”.
Apesar das vantagens, esta técnica possui algumas limitações. Entre
elas, o fato de ser mais suscetível a provocar juízo de valor por parte do
pesquisador. Além disso, o fato de o pesquisador participar dos fenômenos
ocorridos na amostra pode levá-lo a ter uma representação comprometida da
realidade. Trata-se de uma perspectiva muito diferente se comparado com
alguém que observa o fenômeno estando fora dele.
Com relação à pesquisa qualitativa, Ruiz (2004, p.) afirma que a
pesquisa qualitativa é passível de críticas pelo fato de propiciar "vieses na
interpretação dos resultados". Este argumento é feito em contraposição à
objetividade dos resultados da pesquisa qualitativa. Porém, é preciso lembrar que
cada tipo de pesquisa é adequado para uma realidade.

3.4. O TIPO DE PESQUISA SELECIONADO: CONSIDERAÇÕES

Considerando o problema da presente pesquisa, foi selecionado o tipo

descritiva, pelo fato de o trabalho ter tido como propósito conceber um estudo de
caso. O fato de o pesquisador estar inserido no contexto como um participante
dos fatos contribuiu de modo significativo já que houve total acesso à amostra que
é objeto deste estudo. É importante lembrar que apesar de participar dos eventos
ocorridos, o pesquisador não procurou interferir de modo a alterar o perfil da
amostra. Ou seja, a sua atuação foi como participante e apenas observador, o
que reforça ainda mais a característica descritiva da pesquisa.

67
 A pesquisa foi fundamentalmente fruto de observação participativa. Ela
foi oriunda do convívio do pesquisador com analistas de suporte, analistas
desenvolvedores, líderes e gerentes da área de TI (predominantemente, pessoas
da área de suporte da companhia). Com relação aos líderes, consistem em duas
pessoas que possuem pouco mais de 10 anos de empresa. O gerente possui
cerca de 7 anos de empresa, sendo que assumiu a área de suporte a pouco mais
de 1 ano. Antes atuava na área de desenvolvimento.
No espaço de tempo da pesquisa (cerca de 6 meses), foram feitas
perguntas informais para estes profissionais, as quais tinham como propósito
extrair deles as respostas para questionamentos referentes aos problemas
enfrentados pela área.
Esses questionamentos eram levantados, na maior parte das vezes,
em reuniões, as quais eram feitas semanalmente e não havia um roteiro pré-
definido.

3.5. UNIVERSO E AMOSTRA

Pode-se dizer que o universo da pesquisa consiste no conjunto de

todas as empresas brasileiras que prestam serviços na área de Tecnologia da
Informação atualmente. Será retirada deste universo uma amostra intencional
representada por uma empresa paulista de médio porte, que será denominada
XYZ.

3.6. CARACTERIZAÇÃO DA AMOSTRA

O objeto desta pesquisa é uma empresa privada a qual iremos

denominar XYZ. Trata-se de uma companhia paulista de porte médio que atua no
desenvolvimento de softwares para apoiar operações de comércio exterior. A
companhia possui aproximadamente 120 funcionários.
A empresa foi selecionada pela sua importância no mercado de
sistemas que apoiam operações de comércio exterior. Tendo pouco mais de vinte
anos no mercado, possui uma área de suporte bastante amadurecida em alguns
pontos, e bastante ingênua em outros. Essa diversidade de características

68
também foi um fator que motivou a escolha da empresa, pois assim não há
espaço para se fazer um veredicto, ou seja, o objetivo do trabalho não é concluir
se a empresa é definitivamente “boa” ou “ruim”.

69
 4. RELATO DO OBSERVADO

4.1. ESTRUTURA DA EMPRESA

A companhia é dividida nos seguintes departamentos:

Desenvolvimento: A área de desenvolvimento tem a finalidade de

corrigir erros no produto, além de desenvolver e implementar melhorias e
alterações. Frequentemente, é necessário promover alterações no sistema, de
modo a se adequar às modificações na legislação.

Qualidade: Responsável pela realização de testes nas rotinas

desenvolvidas. Esta atividade abrange testes para simulação de erros e testes em
rotinas novas.

Projetos: Apesar de a empresa possuir um produto padrão, existem

clientes que adquirem soluções customizadas em determinadas rotinas,
relatórios, etc... Para o desenvolvimento destas soluções, é preciso que haja um
levantamento de informações (requisitos) junto ao cliente. Esta é uma das
funções da área de Projetos, que também é responsável por desenvolver a
solução. Além disso, atua também na implantação dos módulos-padrão do
sistema nos clientes, bem como treinamentos aos novos usuários (in loco). Para
estas tarefas, a área conta com uma equipe de analistas externos, que também
são responsáveis pelos testes (in loco).

Suporte (Atendimento, Interfaces e Customizações): Responsável pelo

gerenciamento dos chamados abertos pelos clientes.

Comercial: Responsável pela prospecção de clientes e

comercialização de licenças. Além de realização de visitas a clientes e
demonstrações do produto.

70
 Ouvidoria: Responsável por receber reclamações dos clientes,
geralmente relacionadas a chamados críticos. Os chamados que constam na
Ouvidoria tem prioridade sobre os demais. Tem a finalidade também de promover
pesquisas de satisfação junto aos clientes.

Financeiro: Trata do gerenciamento financeiro da empresa.

Responsável, por exemplo, pela liberação de recursos financeiros para viagens
dos analistas externos.

4.2. A SOLUÇÃO DESENVOLVIDA

Neste tópico, serão descritas algumas das principais características

referentes à solução desenvolvida e cujas licenças são comercializadas pela
companhia. Porém, antes de falar sobre o sistema informatizado, convêm fazer
um breve comentário sobre o negócio que a aplicação gerencia.

4.2.1. O Comércio Exterior

O Comércio Exterior abrange as relações comerciais que ocorrem

entre os países. Existem diversos tipos de operações de comércio internacional,
porém, as duas grandes vertentes deste tipo de negócio são as operações de
importação e exportação de mercadorias. Como o propósito desta pesquisa não é
explicar detalhadamente a logística do comércio internacional será dada a seguir
uma explicação sucinta referente á operação de importação, a qual é uma das
operações controladas pela solução informatizada que a empresa desenvolve.

4.2.1.1. Importação

No caso da importação e considerando o contexto brasileiro, existem

diversos trâmites burocráticos que envolvem a entrada de mercadorias no país. O
controle da importação começa com a necessidade de uma empresa importar
algum bem. A partir daí começam as negociações com os fornecedores

71
estrangeiros. Uma vez definidos os itens, o fornecedor, os preços e critérios de
negociação, é necessário proceder com o embarque da mercadoria. Com relação
à entrada dela no Brasil, é preciso registrar a operação de importação junto ao
Governo Brasileiro, obter licença de importação caso necessário, recolher os
tributos e retirar a mercadoria do porto. O processo envolve geração de notas
fiscais de importação e pagamento ao fornecedor do produto e aos fornecedores
dos serviços de frete, etc...

4.2.1.2. A solução informatizada

Com relação à solução desenvolvida e acerca da qual a empresa

presta suporte, ela controla a operação de importação com base nas fases em
que o processo ocorre:

 Registro de solicitação de importação (representa a requisição de uma

mercadoria importada encaminhada ao departamento de compras ou de
importação)
 Registro do pedido de importação (o que representa o início das
negociações com o fornecedor)
 Registro da licença de importação (no caso de se tratar de um produto que
tenha esta necessidade)
 Registro do embarque de importação e geração de parcelas de câmbio a
serem pagas ao fornecedor.
 Cálculo dos impostos e geração da nota fiscal de importação
 Além destas rotinas, a aplicação permite que o usuário faça manutenção
em cadastros básicos, tais como: cadastro de clientes, condições de
pagamentos, portos e aeroportos, produtos, etc...

72
 4.2.1.3. Características técnicas

Sistema desenvolvido por uma empresa especializada. Pode ser

executado tanto em ambientes Windows como Linux e é apto para ser utilizado
com diversos tipos de gerenciadores de banco de dados (SQL Server , Oracle,
etc...). Isto porque a tecnologia abrange também um software (middleware) que
faz a conexão da aplicação com os gerenciadores de banco de dados.
A Fig. 8 mostra de modo resumido a arquitetura da tecnologia:

Figura 8 – Arquitetura da tecnologia desenvolvida

A aplicação pode ser entendida como um terminal thin-client, pois se

trata do programa que exibe a interface gráfica na tela. Este elemento envia
requisições para o repositório de objetos, o qual compreende as rotinas. A
aplicação pode se conectar á diversos tipos de gerenciadores de banco de dados,
pois existe um software do tipo middleware, que auxilia nesta interface. O
gerenciador de banco de dados por sua vez, acessa e manipula a base de dados.
O usuário “enxerga” apenas a aplicação, através da qual ele acessa as rotinas a
seguir (exemplos de funcionalidades principais):

73
  Manutenção de Solicitação de Importação
 Manutenção de pedidos de importação
 Manutenção de embarques
 Recebimento de Importação

4.2.1.4. Aspectos de negócio: visão geral

A aplicação que controla operações de importação possui integrações

com outros módulos. A Fig. 9 mostra uma visão geral para exemplificar algumas
destas integrações. A empresa que desenvolve o sistema de importação também
presta serviços de suporte referentes á problemas nestas integrações.

Figura 9 – Integrações entre o sistema de controle de importações e os

módulos de Compras e Financeiro.

74
 Com relação ao esquema anterior, as integrações mostradas
funcionam da seguinte maneira:

 O usuário inclui uma Solicitação de Compras no módulo de

Compras, indicando que se trata de uma compra de item
importado. Ela migra para o sistema de controle de importações
e se torna uma Solicitação de Importação (S.I.)

 Quando o usuário inclui esta S.I. num pedido de importação, o

sistema gera um pedido de compras no módulo de Compras.
Também são gerados títulos provisórios no módulo Financeiro.

 Após o usuário cadastrar um embarque para o pedido e gerar

notas fiscais de importação, estas migram para o módulo de
Compras e se convertem em notas fiscais de entrada.

4.2.1.5. Exemplos de algumas falhas

Neste tópico serão apresentados alguns tipos de falhas e dificuldades

acerca das quais a empresa presta suporte. Podemos dividir os incidentes em
falhas que abrangem aspectos de negócio e que abrangem aspectos técnicos da
aplicação.
Com relação ao negócio, alguns dos típicos incidentes compreendem:

 Dificuldade do usuário em realizar o processo de importação, o que

acarreta erros nos cálculos dos impostos que vão para a nota fiscal.

 Incidentes referentes a mudanças na legislação aduaneira, os quais quase

sempre são avaliados e encaminhados para o setor de desenvolvimento
Um exemplo disto é quando o cálculo do imposto de importação é alterado
pelo Governo. Neste caso, é preciso também alterar o sistema para que ele
fique alinhado com a legislação. Outro exemplo é quando uma modalidade

75
 de negociação passa a ser permitida pelo Governo. O sistema deve ser
alterado para que reflita esta nova realidade.

 Incidentes referentes á dados incorretos em relatórios (por exemplo:

relatório de custos da importação). Neste caso, é preciso verificar se se
trata de um erro do sistema ou se o usuário não executou os
procedimentos corretamente.

 Erros no sistema, os quais acarretam cálculos incorretos nos impostos e

erros em outros valores exibidos na tela.

 Falhas nas integrações entre o módulo de importação e outros módulos.

Quando o sistema deixa de gerar títulos no módulo Financeiro ou gera com
valores incorretos, por exemplo.

Com relação à aspectos técnicos, podem ocorrer incidentes de

diversos tipos, entre os quais:

 Erros conhecidos como “não-conformidades”, os quais sempre geram um

arquivo de log. Este arquivo deve sempre ser analisado durante o processo
de solução. São erros inesperados que surgem durante a execução de
alguma rotina. Geralmente, apontam erros no próprio código-fonte, erros
de inconsistências relacionadas às tabelas do banco de dados, etc...

 Incidentes relacionados á performance do sistema: abrangem lentidão

(geral ou em alguma rotina específica), travamentos sem causa aparente,
entre outros. Demandam análise profunda, envolvem testes, análise do
código da rotina e fatores relacionados ao banco de dados utilizado pelo
cliente, etc...

76
 4.3. PERFIL DOS CLIENTES

A empresa possui cerca de 500 clientes, os quais abrangem empresas

de pequeno, médio e grande porte. Apesar de oferecer uma solução padronizada
de controle de importações, há diversos clientes que possuem rotinas
customizadas (por exemplo, determinados relatórios), além de vários clientes que
utilizam a ferramenta de modo integrado com outros sistemas. Basicamente, são
empresas que realizam processos de importação de mercadorias (seja para
consumo, venda, amostras, etc...).

4.4. PERFIL DOS USUÁRIOS

Apesar de o sistema ser voltado para uma atividade específica, é

importante ressaltar que existem diversos tipos de usuários que o utilizam. Por
exemplo, usuários que atuam no departamento de Compras de suas empresas, e
não necessariamente possuem conhecimento sobre Comércio Exterior. Olhando
para a outra extremidade, há também usuários que são, de fato, analistas de
comércio exterior.

4.5. A ÁREA DE SUPORTE

Agora, será feita uma análise da própria área de suporte da

companhia. Como dito anteriormente, ela é composta de três subdivisões:
Atendimento, Interfaces e Customizações.

Atendimento: Responsável pelo gerenciamento dos chamados

abertos pelos clientes. Tem a finalidade de atender os clientes, registrar os
incidentes, compreender suas dúvidas e/ou problemas e providenciar solução (ou
direcionar os chamados para outras áreas). Os chamados são registrados pelo
próprio usuário através do site ou pelos analistas por meio de contato telefônico.

77
 Interfaces: Tem a finalidade de solucionar os chamados cujos
problemas relacionam-se com a integração dos módulos de comércio exterior
com outros sistemas utilizados pelo cliente.

Customizações: Responsável pelo suporte a dúvidas e problemas

relacionados à rotinas customizadas utilizadas pelos clientes.

4.5.1. Ferramentas utilizadas

A empresa utiliza os seguintes sistemas para gerenciar sua área de

suporte:

4.5.1.1. Sistema de gerenciamento de incidentes

O sistema utilizado para gerenciar os incidentes é desenvolvido por

uma empresa especializada e possui as principais funcionalidades:

 Registro de incidentes: onde o analista de suporte informa o

código do cliente, a descrição do incidente, entre outras
informações. Além disso, pode anexar arquivos, se necessário.
 Envio de e-mails para os clientes através do próprio sistema.
 Classificação dos incidentes com base no seu ciclo de vida
(aberto, alocado, encerrado, pendente para o analista, pendente
para o cliente).
 Possibilita o envio do incidente para outra área
(desenvolvimento, por exemplo).
 Possui uma desvantagem, pois não possui opções de gerar
relatórios de indicadores.

78
 4.5.1.2. Portal de chamados

 O portal de chamados consiste num sistema web desenvolvido

para que os clientes possam registrar e acompanhar o
andamento dos seus incidentes.

 A vantagem que este sistema proporciona reside no fato de os

analistas de suporte não precisarem incluir os incidentes, pois os
próprios clientes fazem isso.

 O portal é integrado com o sistema de gerenciamento de

incidentes, pois os dois sistemas apontam para a mesma base
de dados. Assim, todo incidente registrado no portal web é
gravado no sistema interno (evitando problemas de duplicidade).

4.5.2. Perfil do analista de suporte

No contexto da amostra estudada, o analista de suporte basicamente é

um profissional formado na área de TI que possui conhecimentos básicos em
comércio exterior. Além disso, conhece a estrutura do sistema (funcionamento
operacional, dicionário de dados, estrutura das tabelas, etc...).

4.5.3. Panorama observado

4.5.3.1. Pontos positivos e negativos

De acordo com as observações do pesquisador, foram identificados

alguns pontos positivos e negativos da empresa como um todo, e mais
especificamente, da área de suporte, apresentados no Quadro 5:

79
 Quadro 5 - Alguns pontos positivos e negativos

Pontos positivos Pontos negativos

Excelente ambiente de trabalho com Remuneração abaixo da média do

relação ao relacionamento interpessoal. mercado.

Abertura para sugestões dos Horas-extras não remuneradas.

colaboradores
Falta de plano de carreira.
Oportunidade de aprendizado
Descontinuidade nas reestruturações.
Contato com tecnologia de ponta no
que se refere à TI.

Fonte: O autor

4.5.3.2. Alguns dos principais problemas

Conforme as reuniões realizadas com o gestor da área, com os líderes

e analistas e conforme observações, foram levantados os seguintes problemas:

 Área opera no limite da sua capacidade

 Numero elevado de reaberturas de chamados pelos clientes.
 Emprego constante de soluções paliativas para um grande número de
chamados.
 Diversas soluções são obtidas pelo modo tentativa-erro.
 Sucessivas interrupções no fluxo de trabalho.
 Intervalo de tempo alto entre a abertura do chamado e a sua solução.

4.5.3.3. O uso de indicadores

Apesar dos problemas, a gestão da área de suporte lança mão de

alguns dados, tais como:

80
  Número de chamados abertos por mês
 Número de chamados solucionados
 Número de chamados aguardando resposta do cliente

A Fig. 10 mostra um exemplo de gráfico onde estes dados podem ser

visualizados (os dados deste gráfico são hipotéticos):

Figura 10 – Exemplo de gráfico “quantidade de chamados abertos x tempo”

Fonte: O autor

Com base nos dados que a área de suporte da empresa coletou, ela
procura sempre saber o porquê de os dados estarem daquela forma. Tomando o
gráfico como exemplo, podem ser feitos os seguintes questionamentos e
argumentações:

 Porque em fevereiro a área teve a demanda tão alta? Este fato pode ser
justificado, por exemplo, por uma funcionalidade nova no sistema que
provocou muitas dúvidas nos usuários, além de necessitar de diversas
correções e adaptações (por exemplo, no caso do nosso exemplo, a

81
 adequação do sistema às exigências governamentais referentes à Nota
Fiscal Eletrônica (NF-e).
 Porque a demanda caiu tanto em março? Pode ter sido porque a área de
qualidade conseguiu estabilizar as rotinas referentes ás novas
funcionalidades, fazendo com que elas deixem de apresentar tantos erros.

4.5.3.4. A satisfação dos clientes

Com relação ao nível de satisfação dos clientes, a área de suporte e a

empresa como um todo não estão numa situação ideal, mas há um relativo
equilíbrio. Isto porque boa parte dos clientes se declara satisfeita com o
atendimento e outra parte declara intensa insatisfação.

4.5.3.5. O ambiente de trabalho

No que se refere aos pontos positivos, a área de suporte e a

companhia como um todo oferece aos funcionários um excelente ambiente para
aprendizado e aquisição de experiência profissional. Além disso, propicia um
ambiente aberto para que os funcionários forneçam sugestões e opiniões a
respeito do ambiente de trabalho e sobre os pontos que poderiam ser
melhorados. De modo geral, o relacionamento entre os funcionários é bom.

82
 5. APLICAÇÃO DE ALGUNS DOS PRINCIPAIS FRAMEWORKS NA
GESTÃO DA ÁREA DE SUPORTE.

5.1. APLICAÇÃO DE ALGUNS DOS PRINCIPAIS CONCEITOS

DO PMBOK®

Embora as boas práticas recomendadas pelo PMBOK® sejam

concebidas especificamente para o gerenciamento de projetos, é possível extrair
elementos também aplicáveis à gestão dos processos de suporte técnico de uma
organização. Pode-se considerar, por exemplo, o próprio fato de se implantar uma
área de suporte, como sendo um projeto. Não apenas a área de suporte, mas o
próprio serviço em si pode ser desenhado e concebido como um projeto.
O ponto primordial desse argumento reside em admitir que embora a
atividade de suporte seja operacional, ou seja, algo que ocorre da mesma forma
constantemente (embora os chamados e ocorrências atendidas sejam diferentes),
a gestão dos processos que envolvem esta atividade deve ser algo dinâmico, e
neste contexto, surgem elementos que podem ser encarados como projetos.
Supondo hipoteticamente que uma determinada organização já possui um
departamento de suporte técnico implantado e em atividade. Numa determinada
ocasião, os indicadores mostram uma elevada e crescente quantidade de
chamados, nos quais os clientes repetem as mesmas dúvidas com uma certa
frequência. A partir desta necessidade, a empresa resolve desenvolver um site
que contenha explicações de soluções para dúvidas e problemas simples, que os
clientes podem consultar. Com isso, a equipe não precisa ter retrabalho com
estas dúvidas, mas sim se dedicar em problemas mais complexos.
Certamente, o desenvolvimento deste site pode ser encarado como um projeto, e
ser gerenciado sob os conceitos do PMBOK®.
O propósito aqui não é descrever todo o gerenciamento do projeto de
um portal web, por isso serão mostrados a seguir exemplos de como esta
situação hipotética pode ser acomodada dentro dos conceitos do PMBOK®.

83
Serão abordados apenas os processos referentes aos grupos de processos de
iniciação e alguns processos do grupo de processos de planejamento do projeto.

Grupo de processos de Iniciação

De acordo com o PMBOK (2008), os processos são:

Desenvolver o Termo de Abertura do Projeto

No Termo de Abertura do Projeto serão documentadas as seguintes

informações:

 Quais os objetivos do projeto: No exemplo, poderia ser “conceber um

sistema web no qual os usuários poderão consultar as soluções para
problemas e dúvidas simples”.

 Quem é o gerente do projeto: Ou seja, qual será o profissional que irá

assumir a responsabilidade pelo projeto do site e se empenhar por garantir
o sucesso do projeto.

 Qual a necessidade organizacional que motivou o início do projeto: No

caso, a necessidade é oriunda do aumento da quantidade de chamados
com dúvidas simples, o que começou a sobrecarregar a equipe que passou
a ter que desviar sua atenção de chamados mais complexos.

Identificar as partes interessadas

 Quem são as partes interessadas: Ou seja, quem será afetado positiva ou

negativamente pelo projeto do site. No caso, podem ser citados os
usuários, clientes e a própria equipe de suporte.

84
 Grupo de processos de planejamento

Neste grupo de processos, é definido o escopo do projeto, ou seja,

garantir que seja feito somente o que o projeto se propõe. Para o exemplo, serão
abordados somente os processos de desenvolvimento do plano de
gerenciamento, a coleta dos requisitos e a definição do escopo.

Desenvolver o plano de gerenciamento do projeto

O plano de gerenciamento do projeto tem por finalidade definir como

será a execução do projeto, e como ele será controlado, monitorado e encerrado.
Este processo define, por exemplo, como será feita a comunicação com as partes
interessadas e como será o ciclo de vida do projeto.
Dentro do planejamento das comunicações, a empresa poderia
promover reuniões envolvendo gestores de algumas empresas clientes e
usuários-chave (key users). A empresa poderia optar por conceber um projeto
piloto do site e disponibilizar primeiro para esses clientes selecionados, com a
finalidade de obter resultados sobre o impacto causado. Na fase posterior, o
protótipo seria então melhorado e seria concebida uma nova versão a ser liberada
para todos os clientes.

Coletar os Requisitos

Uma vez identificadas as partes interessadas, é preciso identificar suas

necessidades e expectativas. Nesta situação hipotética, a gerência da área de
suporte pode realizar reuniões com os analistas para obter informações sobre
como o projeto do site irá afetar as suas atividades cotidianas. No caso, o objetivo
do projeto seria assegurar que eles não fiquem mais sobrecarregados com
problemas e dúvidas simples. Assim, poderão se dedicar melhor aos chamados
mais complexos. Com relação aos clientes, a empresa poderia promover reuniões

85
com alguns clientes e usuários-chave (key users) para extrair deles suas
expectativas em relação ao projeto do site.

Definir o Escopo

Uma vez com os requisitos devidamente coletados e documentados,

eles serão matéria-prima para a concepção do escopo do projeto. O escopo do
projeto consiste em se identificar somente as atividades necessárias para a
entrega do projeto, ou seja, define os limites do projeto, evitando utilização
desnecessária de recursos. No exemplo, o escopo envolveria levantar qual o
trabalho necessário para a elaboração do site de acordo com os requisitos
levantados

Os outros grupos de processos

Como dito anteriormente, os outros grupos de processos não serão

abordados aqui, pois o propósito deste trabalho não é o de explicar
detalhadamente sobre as fases de um projeto. A finalidade deste exemplo é
demonstrar como o conceito de gerenciamento de projetos advindo do PMBOK®
pode ser aplicado na gestão do suporte, mesmo de modo indireto.

5.2. APLICAÇÃO DE ALGUNS DOS PRINCIPAIS CONCEITOS DA

ITIL

É possível abordar os conceitos da ITIL no contexto da área de suporte

técnico, começando pelo próprio conceito de serviço de TI. Um serviço de TI
consiste num conjunto de recursos (máquinas e equipamentos, profissionais,
recursos financeiros etc...) organizados entre si e que tem por finalidade atender,
em termos de TI, aos requisitos de negócio da organização, bem como a
satisfazer os clientes e partes interessadas. A partir desta premissa, pode-se
considerar que a área de suporte, ou a atividade de suporte técnico pode ser
considerada um serviço de TI, pois congrega diversos recursos e tem por
finalidade prover soluções a usuários e clientes. Ao admitir que a atividade de

86
suporte técnico é um serviço, é possível acomodá-la dentro da própria abordagem
de serviço concebida pela ITIL, ou seja, o serviço de suporte deve obedecer às
fases de estratégia, desenho, transição, operação e melhoria continuada do
serviço, como consta no ciclo de vida.

 Estratégia de serviço

A estratégia de serviço tem a finalidade de garantir que os serviços

sejam concebidos de modo a ir ao encontro das necessidades do negócio. Neste
contexto, é importante avaliar qual o papel do serviço de suporte para o negócio
da empresa, ou seja, de que modo o suporte atende à estratégia da organização.
Esta análise contribui para direcionar adequadamente as ações da organização
em relação a área de suporte. É possível afirmar, por exemplo, que o suporte
além de se ocupar de solucionar chamados, pode ser encarado como um canal
de contato com o cliente, através do qual a empresa pode transmitir uma imagem
positiva ou negativa.

 Desenho de serviço

Nesta fase, o serviço de suporte deve ser concebido conforme à

necessidade de negócio estabelecida na fase de estratégia. Dentro desta fase,
existem processos importantes que se relacionam facilmente com as atividades
da área de suporte, tais como gerenciamento de nível de serviço e gerenciamento
do catálogo de serviços.
Aqui cabe discorrer sobre o conceito de ANS (Acordo de Nível de
Serviço), também conhecido pela sigla em inglês SLA (Service Level Agreement).
Este documento consiste em um contrato feito entre o prestador de serviço de
suporte e seu cliente. Nele devem estar bem definidos e detalhados cada serviço
prestado, o impacto do serviço no negócio do cliente, como ele é oferecido, entre
outros detalhes. O processo de gerenciamento de níveis de serviço tem a
finalidade de gerenciar esses acordos, garantindo que os serviços prestados pela
área de suporte ao cliente sejam coerentes com o que consta no SLA. Este
processo também tem a finalidade de gerenciar a satisfação dos clientes. Deixar

87
formalizado legalmente os serviços que a área de suporte presta significa também
formalizar os serviços que ela não oferece, ou seja, o cliente não poderá cobrar o
que estiver fora do contrato.
Nesse contexto também possui importância o catálogo de serviços.
Trata-se de um documento onde a área de suporte lista todos os serviços
oferecidos e tem como finalidade servir de orientação para os clientes/usuários.
Podemos fazer uma analogia com um hotel, onde é oferecido um folder contendo
os serviços oferecidos (hospedagem, horário do uso da piscina, etc...). Para este
elemento, a ITIL estipula o processo de gerenciamento de catálogo de serviços. É
importante dizer que o catálogo não é um documento estático, mas dinâmico, ou
seja, se o suporte deixa de realizar um determinado serviço, ele fica obsoleto e
deve ser retirado do catálogo. O catálogo de serviços pode ser, por exemplo,
colocado no site da empresa para que o usuário possa consultar.

 Transição de Serviço

A fase de transição de serviço pode ser considerada a etapa de

implantação da área de suporte na empresa. Esta etapa tem a finalidade de
garantir que os objetivos estabelecidos na fase de estratégia sejam efetivamente
postos em prática na fase de operação, em termos de recursos.

 Operação de Serviço

Um elemento chave para expressar a relação entre as boas práticas da

ITIL e a prestação de serviço de suporte é o conceito de Central de Serviços.
Basicamente, a Central de Serviços é concebida pela ITIL como uma função que
se traduz no ponto de contato ou interface entre a área de TI e os usuários da
tecnologia. Ela tem a finalidade de entre outras coisas, solucionar problemas
relatados pelos usuários e esclarecer dúvidas no uso da tecnologia. Ela consiste
em um SPOC (Single Point Of Contact), ou seja, num Ponto Único de Contato
entre os serviços de TI e o cliente e segundo a ITIL, está diretamente relacionada
ao processo de gerenciamento de incidente. Apesar disso, vale lembrar que a

88
finalidade da Central de Serviços também abrange atender os usuários no que se
refere à requisições de mudanças, reclamações, etc...
Um incidente consiste num acontecimento que compromete totalmente
ou parcialmente a operação padrão de um serviço de TI. Por exemplo, se o
usuário aciona uma determinada opção do sistema e o mesmo responde com
uma mensagem de erro, impedindo a finalização da operação isto pode ser
considerado um incidente. A Central de Serviços é responsável pela recepção,
gerenciamento e tratamento dos incidentes relatados pelos usuários dos serviços
de TI. Durante o processo de resolução do problema, o incidente recebe diversas
classificações. Cada empresa adota o seu padrão. A seguir, um exemplo de como
um incidente pode ser classificado considerando a etapa na qual está o processo
de atendimento (Quadro 6):

Quadro 6 - Exemplo de classificação de incidentes conforme o ciclo de vida

Classificação Descrição

ABERTO O incidente foi registrado e não há ninguém

tratando dele ainda.

ALOCADO O incidente foi alocado para um determinado

analista tratar

PENDENCIA CLIENTE O incidente está aguardando resposta de um

questionamento feito ao usuário para que continue
a ser tratado.

PENDENCIA ANALISTA O incidente está pendente para o analista alocado

TRANSFERIDO O incidente foi transferido para outra área

SOLUCIONADO O incidente foi solucionado

ENCERRADO O incidente foi encerrado, após a confirmação de

solução pelo usuário.

CANCELADO O incidente foi cancelado

Fonte: O autor

89
 Um incidente também pode ser classificado conforme a prioridade
(algumas empresas utilizam o termo criticidade). Neste padrão de classificação, o
incidente recebe uma atribuição conforme o impacto que o mesmo tem no
negócio do cliente/usuário. Considerando uma área de suporte que atenda
usuários de um software, uma possível classificação pode ser (Quadro 7):

Quadro 7 - Exemplo de classificação dos incidentes conforme o impacto

Criticidade Descrição

CRÍTICA Impede operação crítica do sistema (sem solução de

contorno)

ALTA Impede a operação de rotina crítica (possui solução de

contorno)

MÉDIA Impede operação de rotina não-crítica do sistema

BAIXA Não impede operação do sistema

Fonte: O autor

Todo incidente possui uma causa e é ocasionado por um ou mais

problemas. Corrigindo-se a causa do problema, este é resolvido definitivamente e
o incidente não mais ocorrerá. Porém, isto pode demandar tempo e a demora
pode acarretar prejuízos para o usuário/cliente. Neste caso, a resposta mais
viável para o incidente a fim de não interromper a operação do serviço de TI
afetado é a obtenção de uma solução de contorno (workaround), ou seja, uma
ação paliativa para que a operação realizada pelo cliente/usuário não seja
interrompida. Trata-se de uma solução temporária a ser empregada até que a
solução definitiva seja disponibilizada.

 Melhoria de Serviço Continuada

A área de suporte nunca deve ficar numa zona de conforto. Isto

significa que além das atividades cotidianas, deve ser feito sempre um trabalho
paralelo para analisar os processos e verificar o que pode ser aperfeiçoado. A

90
melhoria deve refletir diretamente na percepção do cliente/usuário sobre o serviço
recebido.
As ações voltadas para melhoria sempre devem ser estabelecidas
pautadas em dados corretos, precisos e relevantes. A gestão da área de suporte
deve promover meios de poder medir quantitativamente os dados referentes à
atuação de sua equipe. Informações como quantidade média de chamados
atendidos diariamente são bastante úteis para, por exemplo, justificar a
contratação de mais analistas para a área. Através da análise criteriosa dos
resultados dos indicadores, o gestor pode perceber mais claramente quais são os
pontos sobre os quais se deve atuar a fim de obter as melhorias necessárias.

5.3. APLICAÇÃO DE ALGUNS DOS CONCEITOS DO COBIT

Com relação ao COBIT, a aplicação mais imediata dos seus conceitos

na área de suporte pode ser observada por meio do domínio “Entregar e Suportar
(DS)”. Dentro deste domínio, temos os seguintes processos:

- DS1 Definir e Gerenciar Níveis de Serviços

- DS2 Gerenciar Serviços Terceirizados
- DS3 Gerenciar o Desempenho e a Capacidade
- DS4 Assegurar a Continuidade dos Serviços
- DS5 Garantir a Segurança dos Sistemas
- DS6 Identificar e Alocar Custos
- DS7 Educar e Treinar os Usuários
- DS8 Gerenciar a Central de Serviço e os Incidentes
- DS9 Gerenciar a Configuração
- DS10 Gerenciar Problemas
- DS11 Gerenciar os Dados
- DS12 Gerenciar o Ambiente Físico
- DS13 Gerenciar as Operações

91
 Para ilustrar de modo sucinto como se pode empregar premissas do
COBIT na gestão da área de suporte técnico, é preciso atentar para os processo
seguintes:

- DS1 Definir e Gerenciar Níveis de Serviços

- DS7 Educar e Treinar os Usuários
- DS8 Gerenciar a Central de Serviço e os Incidentes
- DS10 Gerenciar Problemas

 Processo DS1-Definir e Gerenciar Níveis de Serviços

Este processo tem a finalidade de assegurar que os serviços

acordados estão alinhados com os requisitos de negócio da organização. Mais do
que isso, tem como propósito também garantir o alinhamento entre os serviços
acordados e a capacidade de entrega. O Acordo de Nível de Serviço (SLA, em
inglês) não deve ser tomado como um documento estático, mas sim como um
elemento dinâmico. Isto significa que ele deve ser constantemente monitorado e
adaptado, pois as necessidades de negócio mudam.

 Processo DS7-Educar e Treinar os Usuários

Este processo abrange a entrega de treinamento aos usuários a partir

da identificação da necessidade. No âmbito da gestão de suporte técnico, a
empresa pode propor um treinamento básico aos usuários no uso da tecnologia, e
conforme o serviço de suporte for sendo prestado, monitorar e identificar novas
necessidades de treinamento. Isto pode ser aplicado no caso de novas rotinas
implementadas ou se for constatado um número grande de incidentes reportando
dúvidas acerca de um mesmo assunto.

 Processo DS8-Gerenciar a Central de Serviço e os Incidentes.

Conforme visto anteriormente na ITIL, a Central de Serviços (Service

Desk) possui a finalidade de gerenciar e prover respostas aos incidentes enviados

92
pelos usuários. Este gerenciamento deve ser feito pautado em processos
adequadamente projetados. As respostas aos incidentes devem ser dadas de
modo preciso e dentro de prazos, pois o objetivo é sempre assegurar a
continuidade do serviço de TI, de modo que o negócio não sofra nenhum impacto
(ou na pior das hipóteses, que sofra o menor impacto possível). Além disso, deve-
se buscar conhecer a causa de dos problemas a fim de que sejam solucionados e
os incidentes relacionados a eles não voltem a ocorrer. Este processo deve ser
medido com base em índices de satisfação dos usuários e indicadores, como
número de incidentes resolvidos, etc... O processo é bastante semelhante ao
conceito análogo da ITIL.

 Processo DS10-Gerenciar Problemas

Considerando que um incidente possui um problema adjacente a ele,

pode-se afirmar que o processo de gerenciar problemas está intimamente ligado
ao processo de gerenciar a central de serviços e os incidentes. Todos os
problemas possuem uma causa, e esta deve ser rastreada e identificada. Todos
os problemas, bem como os impactos e o processo de resolução devem ser
monitorados.
Além destes processos, é fundamental atentar para o processo PO7 –
Gerenciar os Recursos Humanos de TI, o qual defende entre outras premissas, a
importância de se utilizar processos adequados para seleção, contratação e
manutenção da mão de obra de TI da empresa.

5.4. APLICAÇÃO DE ALGUNS DOS PRINCIPAIS CONCEITOS DE

SOA

A Arquitetura Orientada a Serviços promove a concepção de uma

arquitetura de sistema composta por uma coleção de serviços, os quais apesar de
serem inter-relacionados possuem autonomia entre si, por apresentarem baixo
acoplamento. Como dito anteriormente, esta abordagem pressupõe uma
arquitetura dividida entre a camada de serviços diretamente ligados ao negócio e

93
a camada chamada plumbing, que envolve apenas serviços ligados diretamente à
logica computacional.
Neste contexto, a área de suporte pode ser compreendida como o
elemento da empresa que zela pelo bom andamento destes serviços. Quando
ocorrer a falha num determinado serviço, a área então deve atuar sobre o
incidente levando-se em conta o impacto deste serviço sobre o negócio do cliente.
Além disso, deve ser levado em consideração o Nível de Serviço associado a ele.
Essas informações servem de base para a correta classificação do incidente,
conforme o grau de prioridade. A investigação do problema então pode descer até
a camada de plumbing, onde se identificará qual (is) o(s) serviço(s) que atuam
para manter o serviço de negócio que foi afetado.
A abordagem SOA, portanto, provê um meio de se mapear as relações
entre os serviços e pode seguramente facilitar a investigação da causa de um
incidente.
Outro exemplo de aplicação na gestão do suporte técnico seria a
equipe se dividir onde uma parte seria dedicada a atuar sobre os serviços de
negócio e outra parte atuaria nos serviços plumbing.

94
 6. ANÁLISE DO PANORAMA OBSERVADO

Nos tópicos a seguir, será feita uma análise detalhada dos problemas
apresentados e serão feitos comentários com base na teoria apresentada.

6.1. ÁREA OPERA NO LIMITE DE SUA CAPACIDADE: MAL

CONSEGUE SUPRIR A DEMANDA ATUAL DE CHAMADOS.

Este problema fica bastante evidenciado pelos indicadores que

mostram a quantidade de chamados solucionados, e também pelo número de
chamados que são reabertos pelos clientes e usuários. Periodicamente é
calculado o quociente entre o número de chamados solucionados e o número de
chamados abertos.

Taxa de chamados resolvidos = No de chamados solucionados / No de

chamados abertos

A demanda atual de chamados pode ser entendida como a média

aritmética da quantidade de chamados abertos num determinado intervalo de
tempo (por exemplo: três meses). Na tabela 1, temos um exemplo onde podemos
obter a média de chamados atendidos durante 3 meses, mas considerando
apenas os dez primeiros dias:

95
 Tabela 1 - Exemplo de volume de demanda por dia

dia 01 02 03 04 05 06 07 08 09 10 Totais

mês
Março 60 70 97 45 78 39 91 67 71 49 667
Abril 71 62 50 20 72 52 81 95 100 19 622
Maio 61 81 50 48 34 82 63 61 96 41 617
1906

Fonte: O autor

A partir dos dados da tabela:

Totais:

 Número total de chamados abertos nos dez primeiros dias de março:

667
 Número total de chamados abertos nos dez primeiros dias de abril:
622
 Número total de chamados abertos nos dez primeiros dias de maio:
617

Médias parciais:

 Média diária de chamados abertos nos dez primeiros dias de março:

667 / 10 = 66,7
 Média diária de chamados abertos nos dez primeiros dias de abril:
622 / 10 = 62,2
 Média diária de chamados abertos nos dez primeiros dias de maio:
617 / 10 = 61,7
 Média mensal de chamados: 1906 / 3 = 635,3

A partir das conclusões obtidas por meio da tabela, podemos afirmar

que considerando o intervalo de tempo proposto, a média da demanda diária de

96
chamados nos três meses é de: (66,7 + 62,2 + 61,7) / 3, ou seja, 63,53. Nesta
análise a demanda de chamados pode então ser expressa por meio da média
mensal (635,53) ou por meio da média diária (65,53).
Não faz sentido verificar se a área consegue suprir a demanda de
chamados se não quantificarmos este volume de demanda. Uma vez conseguida
esta informação, o próximo passo é quantificar a quantidade de chamados
solucionados no mesmo intervalo de tempo e obter o quociente entre os
solucionados e os abertos. No caso da empresa analisada, foi constatado por
meio de indicadores produzidos pela área (quantidade de chamados abertos,
solucionados, reincidências, etc) que ela não consegue suprir esta demanda, ou
seja, a quantidade de chamados solucionados num determinado intervalo de
tempo é muitas vezes inferior em relação à quantidade de chamados abertos. Na
maior parte das vezes, porém, a quantidade de incidentes resolvidos se iguala
com o número de incidentes abertos. Numa análise preliminar isto pode ser
considerado válido, porém, a área de suporte não possui nenhuma margem de
folga. Se por exemplo, algum funcionário faltar, ou se a demanda subir de modo
repentino a área não possui nenhuma margem de folga e certamente deixará
muitos incidentes pendentes. O ideal seria, por exemplo, a área ter medidas de
contingência pré-estabelecidas para suprir situações de pico de demanda. Porém,
a área de suporte da empresa não possui. O fato de a área estar nesta situação
denota que não é feito periodicamente um estudo sobre o índice de demanda
atual e tendências futuras de demanda, ou na melhor das hipóteses, é feito
apenas um estudo irrisório. O gerenciamento de demanda e de capacidade são
previstos no framework ITIL (2007). Avaliar as perspectivas de crescimento da
demanda de incidentes e se preparar previamente para períodos de pico são
medidas que afetam positivamente a satisfação dos clientes, o que se traduz no
alinhamento com o princípio fundamental de qualidade “foco no cliente” previsto
nas normas da família ISO 9000.
Outro ponto importante é que para se medir a demanda e a capacidade
da área em atendê-la é preciso empregar critérios e métricas adequadas e
compatíveis com os recursos disponíveis e com a estratégia da organização.
Como dito anteriormente, a qualidade deve ser baseada em parâmetros e estes
devem estar alinhados com a estratégia da empresa (Governança de TI). Para se

97
cumprir estas metas é preciso que os recursos sejam adequadamente
empregados (COBIT)
Uma vez constatado o fato de que a área não consegue suprir a
demanda de incidentes, o próximo passo é identificarmos as causas deste
problema. Uma possível abordagem, por exemplo, seria construir um diagrama
causa-e-efeito (CASAS, 2008). Após definir as causas, identificar quais são as
causas que são mais determinantes neste problema. Segundo o princípio de
Pareto (NOCERA, 2009), ao atuar sobre a menor parte delas (cerca de 20%) o
problema seria solucionado em cerca de 80%.

6.1.1. Principais fatores que podem influenciar a performance

Existem muitos fatores que podem influenciar a performance da área

de suporte no que diz respeito à demanda, porém, para este estudo e
considerando o panorama da empresa, foram observados e levantados os
seguintes:

 Faltas e atrasos por parte dos funcionários da área.

 Influencia de períodos específicos
 Funcionários mal treinados ou que detêm conhecimento insuficiente.
 Rotinas do sistema não documentadas
 Excesso de chamados reabertos (reincidentes)
 Quantidade insuficiente de funcionários

Ao admitir o fato de que a área de suporte opera no limite de sua

capacidade, é possível admitir também que os fatores citados anteriormente são
sérios candidatos a serem considerados as causas-raízes deste problema. O
propósito é primeiramente constatar a ocorrência do problema e depois identificar
os principais fatores motivadores da sua ocorrência. O próximo passo é fazer uma
análise de cada um desses fatores e implementar meios de atuar sobre eles,
eliminando-os total ou ao menos parcialmente. A seguir, uma análise destes
fatores considerando a situação da empresa:

98
  Faltas e atrasos por parte dos funcionários da área.

Considerando a empresa que é o objeto do estudo de caso, seria

prematuro admitir que isto ocorre por negligência dos funcionários. Isto porque
entre outros fatos subjacentes, as faltas e atrasos são um problema praticamente
crônico, e não abrange um ou outro funcionário específico, mas cerca de 70% dos
colaboradores. Além disso, vem ocorrendo por um grande intervalo de tempo,
portanto, não se trata de apenas duas semanas, ou um mês. A comprovação da
alta frequência de faltas e atrasos vem sendo constatada a cerca de pelo menos
nove meses e tem apresentado variações pequenas. Portanto, trata-se de um fato
que vem apresentando uma constância durante um espaço significativo de tempo.
Levando em conta esses fatos e fazendo uma análise profunda do assunto, foi
constatado que a alta frequência de faltas e atrasos tem como fator determinante
a alta taxa de desmotivação que tem acometido boa parte dos colaboradores da
área de suporte. Mesmo que nenhum deles tenha admitido abertamente, é bem
considerável a possibilidade de muitos deles faltarem para procurarem emprego
em outras empresas. A próxima questão seria verificar o porquê de tamanha
desmotivação. A área de suporte é apenas uma parte da companhia, portanto,
está sujeita ao modo como a empresa gerencia os recursos humanos.
Convêm lembrar que mesmo quando não ocorre faltas, a produtividade
cai, contribuindo para a continuidade da alta demanda de incidentes pendentes. O
problema todo reside no fato de que a área de suporte está tentando solucionar
um problema e provocando outro. Ou seja, como resposta para a alta demanda e
baixa performance da área, a gerência faz com que os colaboradores tenham que
cumprir horas-extras programadas e não remuneradas. Porém, ao trabalhar mais,
o funcionário sofre maior desgaste e ficando desmotivado, perde produtividade.
Com trabalho excessivo, paradoxalmente, a performance da área cai e a
demanda se mantêm alta. Soma-se a isso o fato de as horas-extras serem
computadas apenas no banco de horas, ou seja, não remuneradas do ponto de
vista financeiro. A seguir, a Fig. 11 ilustra este fato, e demonstra que a atitude da
companhia promove um ciclo vicioso.

99
 Figura 11 – Relação entre queda de produtividade e trabalho excessivo
Fonte: O autor

Para eliminar ou ao menos minimizar a frequência de faltas e atrasos,

portanto, é necessário atuar no sentido de se aumentar o grau de motivação dos
colaboradores. Esta necessidade se encaixa perfeitamente no processo PO7 do
COBIT: Gerenciar os recursos humanos de TI. Este processo pertencente ao
domínio “Planejar e Organizar” tem por finalidade “adquirir, manter e motivar uma
força de trabalho competente para criar e entregar serviços de TI para o negócio”
(IT Governance Institute). Além disso, agindo desta maneira, a empresa está em
desacordo com uma das premissas da família ISO 9000: O princípio fundamental
de gestão da qualidade relacionado ao “envolvimento de pessoas” (ISO 9000).
Envolver pessoas também significa implementar meios de motivá-las.
Porém, para solucionar o problema inicial que abrange melhorar a
performance da área em relação à demanda, é necessário verificar os outros
fatores, que serão vistos a seguir.

100
  Influencia de períodos específicos

A área de suporte possui uma taxa de demanda média padrão de

incidentes. Porém, em períodos específicos, como na época de fechamento
contábil a demanda sobe. Isto ocorre porque além da taxa padrão de incidentes, a
área precisa suportar uma taxa adicional referente aos incidentes relacionados ao
fechamento contábil. Um ponto primordial determinante do aumento de demanda
é porque além do número de incidentes deste tipo aumentar, eles representam
grande prioridade e, por conseguinte, são atendidos primeiro. Isto faz com que os
incidentes de menor prioridade se acumulem, gerando demanda adicional depois
que o período de fechamento contábil terminar. Diante desta situação, a área de
suporte promove horas-extras fazendo com que os colaboradores atuem cerca de
duas horas além do seu horário normal sempre nos últimos e nos primeiros dias
de cada mês. De acordo com a gerência da área, esta medida se justifica pela
necessidade de a empresa se antecipar ao fechamento contábil, para reduzir a
demanda. De fato, a intenção de agir proativamente é bastante adequada, porém,
o método utilizado acabou por provocar desmotivação nos colaboradores, como
visto no tópico anterior, além de ferir as premissas do COBIT e da ISO 9000,
como citado anteriormente.

 Funcionários mal treinados ou que detêm conhecimento

insuficiente.

A empresa possui uma modesta política de treinamento para novos

colaboradores. Apesar disso, uma parte ainda não possui todo conhecimento
necessário para poder atender a todos os incidentes que são abertos. Isto
impacta diretamente na performance da área, fazendo com que a demanda se
mantenha alta. É primordial que exista um alinhamento entre o conteúdo do
treinamento dado e os tipos de incidentes com os quais o colaborador deverá se
deparar. Novamente, este fato contempla o processo PO7 do COBIT:
“Implementar processos para assegurar que a organização tenha uma força de
trabalho de TI apropriada e com as habilidades necessárias para atingir os
objetivos da organização” (IT Governance Institute).

101
 De modo geral, é um grande ponto positivo o fato da empresa oferecer
treinamento. Porém, ao analisar de modo criterioso o fato, foi constatado que o
treinamento dado é bastante superficial se comparado com o grau de
conhecimento que é necessário aos analistas. Para suprir esta deficiência, os
colaboradores fazem uso de uma base de conhecimento e de documentações
sobre as rotinas do sistema, além de anotações que eles próprios fazem para
consultas posteriores. Além disso, é frequente a busca de informações através de
pessoas de outras áreas (desenvolvimento, qualidade, etc). É perfeitamente
válido que exista a troca de informações entre os colaboradores, mas a empresa
deve tomar cuidado para não ficar na dependência de pessoas-chave, ou seja,
pessoas que sejam as únicas a conhecer certas rotinas do sistema. Evitar esta
dependência é previsto no COBIT. É adequado que a área de suporte e a
empresa utilizem mecanismos para que toda a informação necessária seja
disseminada entre os analistas de suporte, e a elaboração de um programa de
treinamento adequado é um dos meios para isso. Certamente, a ausência de um
treinamento ou um treinamento insuficiente impacta na performance da área, pois
os colaboradores não conseguirão solucionar todos os incidentes e ainda correrão
o sério risco de se sentirem desmotivados. Novamente, o princípio de
envolvimento de pessoas da norma ISO 9000 foi desconsiderado.

 Rotinas do sistema não documentadas

Este tópico tem estreita ligação com a eficiente e eficaz manutenção de

uma base de conhecimento por parte não só da área de suporte, mas da empresa
como um todo. A necessidade de se ter rotinas, informações técnicas e
informações pertinentes ao negócio bem documentadas pode ser sustentada por
um argumento simples: tanto a tecnologia como o negócio são elementos
dinâmicos, e portanto, passíveis de sofrerem mudanças, seja por inovações
tecnológicas, correções, quanto por adaptações à novas legislações etc... Se
todas as informações estiverem bem documentadas e organizadas
adequadamente para a consulta dos analistas, isto facilitará muito o tratamento
dos incidentes, especialmente pelos analistas que estiverem no começo de
carreira. Se pensarmos numa situação inversa, ou seja, onde a documentação

102
esteja insuficiente, inexistente ou falha, não é difícil imaginar que isto impactará
fortemente na performance da área. Isto porque dependendo do tipo de incidente,
um analista iniciante levará muito mais tempo para conseguir reunir as
informações necessárias para resolvê-lo. Ou seja, entre outros pontos, a falta de
uma base de conhecimento afeta diretamente o intervalo de tempo para se
solucionar um incidente. Incidentes simples, que demandariam minutos para
serem resolvidos, podem levar até horas, e portanto, influenciar negativamente os
indicadores da área. No caso da empresa analisada, a área conta com uma
eficiente base de conhecimento, já que todos os incidentes são armazenados e
todos os dados referentes a eles ficam disponíveis para consulta pelos analistas.
Esta medida está de acordo com a recomendação da ITIL (2007) sobre a
importância de se manter uma base de dados de erros conhecidos (processo de
gerenciamento de problemas). Existem disponíveis também documentações e
boletins sobre rotinas e funcionalidades do sistema, o que é um fator bastante
positivo.

 Excesso de chamados reabertos (reincidentes)

É razoável a área de suporte estabelecer, com base em certos

critérios, medidas de tolerância para quantidade de incidentes reabertos. Um
incidente reaberto é, basicamente, um chamado que recebeu uma solução e esta
não resolveu o problema do cliente, ou ocasionou outro(s) problema(s). Estes
chamados devem receber tratamento diferenciado dos demais, uma vez que
dependendo do impacto do problema, pode provocar também impacto no
relacionamento da empresa com o usuário/cliente. Neste contexto, a área deve
ser cautelosa para não perder o “foco no cliente”, como previsto pelos princípios
de gestão da qualidade das normas da família ISO 9000, além dos comentários
sobre satisfação do cliente e “expectativa de valor” (FREITAS, 2010).
No caso da empresa que é o objeto deste estudo, a taxa de incidentes
reabertos é bastante significativa, considerando o intervalo de tempo observado.
Isto afeta diretamente a performance da área, que além de lidar com os incidentes
reabertos, precisa dar conta de solucionar os incidentes novos. Um ponto

103
primordial a ser trabalhado na empresa neste aspecto, é relativo ao modo como é
feito o tratamento dos incidentes.
Uma medida simples e adequada é estabelecer meios de procurar ter
certeza da solução que se está dando ao incidente. Uma medida complementar é
sempre procurar obter a confirmação do usuário/cliente se o problema foi
solucionado ou não. Isto é uma premissa da ITIL (2007), referente ao processo de
gerenciamento de incidentes. A área de suporte precisa se tornar proativa, ou
seja, não esperar que o cliente confirme se o problema foi resolvido, mas sempre
entrar em contato com ele para obter esta resposta. Na empresa analisada não
há esta cultura, prova disso é que existe uma alta taxa de chamados que está
esperando o retorno dos clientes. A área deveria enxergar estes incidentes como
um potencial risco, já que é perfeitamente possível que numa ocasião diversos
clientes retornem negativamente. Muitos destes chamados são candidatos a
serem encerrados por falta de retorno do cliente, e posteriormente reabertos.

 Quantidade insuficiente de funcionários

A área de suporte deve possuir uma quantidade de funcionários

compatível com a demanda que ela precisa atender. No caso da empresa
analisada, isto não ocorre. Soma-se a este fato a quantidade de faltas e atrasos,
impulsionada pela falta de motivação dos funcionários, como visto anteriormente.

6.2. NÚMERO ELEVADO DE REABERTURAS

Como foi dito anteriormente, é aceitável que exista um nível de

tolerância no que diz respeito à quantidade de incidentes que são reabertos pelos
clientes. Porém, este nível deve ser estipulado com base em critérios adequados
e levando-se em conta a capacidade da área e a demanda. No caso da empresa
estudada, foi constatado um número elevado de incidentes dados como
solucionados e que mais tarde são reabertos pelos clientes sob alegação de que
a solução dada não resolveu o problema. Como os outros problemas apontados,

104
este também ocorre de modo quase crônico. Entre os fatores que motivam esta
realidade na área de suporte da empresa, podemos citar alguns principais:

 Devido ao fato de a área não conseguir dar conta da demanda de

incidentes, a área de suporte possui o foco voltado para a “redução de números”.
Isto provoca o encerramento de diversos chamados sem ter a devida certeza de
que as soluções dadas resolvem de fato os problemas.

 A alta demanda e a própria cultura da empresa contribui para que a

área de suporte responda muitos chamados, porém, sem a preocupação de
conferir junto ao cliente se o problema de fato foi resolvido. Ou seja, o critério para
os incidentes serem encerrados não é a confirmação da solução por parte do
usuário. Veja o esquema a seguir, apresentado na Fig. 12:

Figura 12 – Relação entre cultura da área e alta demanda.

Fonte: elaboração própria

Segundo a Fig. 12, o fato da área de suporte ter uma alta demanda de
incidentes faz com que ela promova uma cultura na qual os chamados são
encerrados sem o aval do cliente (em desacordo com a ITIL). Com isso, ela
incorre no risco de ter diversas reaberturas de chamados, o que por sua vez
contribui para manter a demanda alta.

105
 6.2.1. Uma possível solução

O fato de a área de suporte ter um alto índice de reaberturas de

incidentes pelos clientes é um indicativo que as soluções estão sendo dadas sem
que haja um adequado estudo preliminar do incidente. É fato que há incidentes
que são bastante rápidos e não demandam uma análise (dúvidas simples, por
exemplo, ou erros já conhecidos). Porém, para incidentes complexos é necessária
uma análise adequada antes de se emitir o parecer ao cliente. Uma possível
abordagem para esses casos, seria considerá-los como um projeto (ou um mini-
projeto) e trata-los segundo algumas premissas do PMBOK (2008).

 Um projeto é um esforço que se realiza para conceber um

resultado, seja como produto ou como serviço, e consiste num
esforço temporário (PMBOK, 2008). A solução de um incidente
demanda um esforço temporário e pode ser considerada,
portanto, como um dos entregáveis do projeto.

 Para um incidente, é necessário que a solução seja entregue

dentro de um determinado prazo, que é estabelecido conforme o
impacto no negócio do cliente. Neste contexto é necessário que
se tenha um gerenciamento do tempo (PMBOK, 2008). Se a
área de suporte obter para o cliente uma solução de contorno,
este prazo pode ser renegociado.

 Para se entregar a solução de um incidente, dependendo da

complexidade do caso, é preciso mobilizar recursos humanos de
outras áreas (desenvolvimento, qualidade, etc). Isto envolve o
processo de gerenciamento de recursos humanos (PMBOK,
2008).

 Dentro do processo de gerenciamento do tempo (PMBOK,

2008), é preciso definir e estimar quais as atividades

106
 necessárias para se tratar o incidente e quais os recursos
necessários para cada atividade. Veja, por exemplo, o Quadro 8:

Quadro 8 - Exemplos de tarefas e recursos

Atividade Recurso
Solicitar o arquivo de log Sistema de gestão de incidentes, e-
completo ao cliente mail, telefone.
Solicitar ao cliente o roteiro Sistema de gestão de incidentes, e-
passo a passo que está mail, telefone
sendo feito até o momento
do erro.
Verificar no log se a rotina Arquivo de log obtido do cliente.
está atualizada
Verificar se há atualizações Repositório de fontes
mais recentes da rotina em
questão
Verificar se no ambiente de Arquivo do repositório de fontes do
homologação (testes) o ambiente de homologação
fonte está atualizado.
Realizar teste no ambiente Ambiente de homologação
de homologação seguindo parametrizado igual ao ambiente do
passo a passo o roteiro cliente
enviado pelo cliente.
Fonte: O autor

Quando o incidente é solucionado, ele é encerrado. Isto implica na

necessidade de se alimentar a base de conhecimento de erros conhecidos e de
outras informações concernentes á solução (Lições aprendidas).

6.3. EMPREGO FREQUÊNTE DE SOLUÇÕES PALIATIVAS

O emprego de soluções paliativas ou de contorno é uma alternativa

bastante válida. Porém, a sua finalidade deve consistir apenas em prover para o
cliente um meio para que ele não precise interromper a operação do seu negócio.
Deve-se, portanto, evitar incorrer no erro de assumir a solução paliativa como
definitiva. Na empresa analisada, foram observados numerosos incidentes que

107
receberam solução de contorno e foram finalizados. Ou seja, nestes casos a área
não empenhou um esforço para procurar a causa do incidente e solucioná-lo
definitivamente, ou mesmo direcionar o incidente para que o mesmo receba esta
solução. É adequado que a área de suporte tente encontrar a causa do incidente
e atue sobre ela, ou então reporte o problema para outra área se for necessário
(com a abertura de chamado interno, por exemplo).

6.4. DIVERSAS SOLUÇÕES OBTIDAS PELO MODO TENTATIVA-

ERRO

Este é um problema quase crônico observado para um grande número

de incidentes abertos. Antes de falar de modo mais profundo sobre a situação da
empresa analisada, convêm fazer um breve comentário sobre o processo de
resolução de problemas.

6.4.1. O processo de solução de problemas

Quando um incidente é aberto, a área de suporte deve ter consciência

que existe ao menos um problema que o provoca. O primeiro passo para a
resolução do incidente começa durante o próprio atendimento. O profissional de
suporte deve compreender qual o problema relatado pelo usuário/cliente e
procurar coletar junto a ele todas as informações necessárias para o tratamento
do chamado. Após isso, é feita uma investigação para localizar a causa do
problema. Um modo para se fazer isso, é primeiro identificar causas possíveis e
testá-las começando pela causa mais provável. Identificada a causa do problema,
a área atua sobre ela, ou então direciona o incidente para a outra área que
atuará. A seguir, a Fig. 13 mostra um exemplo de procedimento, de modo
resumido.

108
 Figura 13 – Exemplo de fluxo de solução de incidente
Fonte: O autor

6.4.2. A situação da empresa

Os comentários e o esquema mostrado anteriormente mostram que é

adequado ter um procedimento pré-definido para atuar sobre um incidente.
Porém, no caso da empresa analisada, existem diversos incidentes que são

109
tratados de modo aleatório e/ou desorganizado. O que tem caracterizado
fortemente esta realidade é o número de chamados tratados pelo modo tentativa-
erro. Utilizar este meio de modo excessivo pode acarretar nas seguintes
consequências, as quais foram observadas e constatadas no panorama da
empresa:

 Descontentamento do cliente, o que compromete o nível de satisfação dele

e o grau de qualidade percebida. Isto é contrário ao princípio de foco no
cliente previsto nas normas da família ISO 9000.

 Insegurança por parte do cliente em relação à área de suporte, e também

em relação à empresa como um todo. Novamente, o princípio de foco no
cliente é desprezado.

 O incidente fica em aberto por um tempo excessivo e desnecessário, o que

compromete os indicadores e a imagem da área perante a empresa.

 O incidente é solucionado sem que se verifique a causa do problema. Ou

seja, a solução se trata de apenas uma tentativa que acabou funcionando.
Sem uma análise do problema, da solução dada e dos impactos, é possível
que o incidente volte a ocorrer ou que outros pontos sofram efeitos
colaterais. De modo sucinto, a Fig. 14 mostra um esquema sobre algumas
consequências do excesso de tratamentos do tipo “tentativa-erro” dados
aos chamados:

110
 Figura 14 – Relação entre excesso de soluções “tentativa-erro” e satisfação do
cliente.
Fonte: O autor

6.4.3. Um outro modo de abordar o incidente

Os parágrafos seguintes mostram um roteiro básico, mas não

definitivo, que pode ser utilizado para se tratar um incidente (baseado na ITIL):

Parte 1 – compreensão do incidente: Nesta etapa, o profissional que

faz o atendimento precisa obter junto ao usuário/cliente todas as informações
necessárias relativas ao incidente relatado. O ponto primordial é compreender
claramente qual é o incidente que está ocorrendo. Mesmo que esta fase demande
um certo tempo, este tempo sempre é bem empregado. Dependendo do
incidente, é primordial fazer questionamentos ao cliente para poder restringir o
contexto no qual o fato ocorre. Por exemplo:

 Quando aproximadamente o incidente começou a ocorrer?

 O incidente ocorre de modo contínuo ou existem casos onde não ocorre?
 O incidente somente ocorre em um computador?

É importante também perceber o impacto que o incidente tem sobre a

operação do negócio do cliente. O grau de impacto irá definir a classificação do
chamado com relação à criticidade.

111
 Parte 2 – Registro do incidente: Uma vez compreendido o problema,
o profissional de suporte deve registrar o chamado de maneira clara, de modo
que até outra pessoa entenda ao ler.

Parte 3 – Verificação se já existe solução: Nesta etapa é primordial a

presença de uma eficaz e eficiente base de conhecimento. Deste modo, o
profissional pode fazer uma sondagem preliminar e verificar se o incidente já
ocorreu anteriormente. Caso já tenha ocorrido, verificar:

 A solução dada anteriormente resolveu o problema de modo definitivo ou

foi uma solução de contorno?
 A situação do cliente no que se refere à configurações, etc... é similar à do
cliente cujo problema foi solucionado?
 Qual o impacto da solução dada anteriormente no negócio do cliente?

Parte 4 – Simulação do incidente: Sempre que possível, é importante

tentar simular a situação relatada pelo cliente. Se o incidente não ocorrer num
contexto de teste, é provável que já exista solução para ele. Neste caso, é
fundamental verificar se as configurações e detalhes técnicos onde foi feito o teste
são similares às do usuário.

Parte 5 – Obtenção de solução de contorno (workaround): Esta

etapa deve ser seguida somente no caso de não se ter ainda uma solução
definitiva ou se ela levará um tempo crítico para ser aplicada. O importante neste
ponto é fazer com que a operação do negócio do cliente/usuário não seja
interrompida. A solução de contorno deve prover um meio para garantir a
continuidade do negócio, porém, sem provocar impactos em outros pontos ou na
pior das hipóteses provocar um impacto mínimo. Deve-se deixar claro para o
usuário que esta solução consiste apenas numa medida de contingência, e que
as causas do incidente serão identificadas e posteriormente a área disponibilizará
a solução definitiva.

112
 Parte 6 – Resolução do incidente: Esta etapa consiste em se prover
a solução do problema que provoca o incidente. Podemos enumerar algumas
fases. Nem todas as fases devem ocorrer obrigatoriamente somente na área de
suporte:

Identificar a(s) causa(s) do problema: Enumerar as possíveis causas

motivadoras do incidente relatado. Uma ferramenta que pode ser utilizada é o
Diagrama de Causa e Efeito. A partir daí, são realizados testes e uma vez
identificada a(s) causa(s) do problema, a área deve atuar sobre ela, ou então
direcionar o chamado para outra área (por exemplo.: se a área de suporte
identificar uma falha no software, deve direcionar o chamado para a área que
provê manutenção no código-fonte). É importante deixar claro que uma vez
identificado o motivo que provoca o problema, ele já pode ser considerado
parcialmente resolvido, pois o próximo passo é apenas fazer as correções,
ajustes, etc...

Conceber a solução: A solução deve ser concebida de modo a atuar

sobre a(s) causa(s) do problema. Esta etapa não é necessariamente restrita à
área de suporte, mas pode envolver a área de desenvolvimento, manutenção do
software, etc... Dependendo do problema, é possível conceber mais de uma
solução possível.

Avaliação e teste da solução: A solução ou as soluções possíveis

deve(m) ser(em) avaliada(s) conforme o impacto que provocará no negócio do
cliente. De acordo com estas informações, deve ser selecionada a solução mais
adequada. Uma vez feito isso, ela deve ser testada e devem ser verificados todos
os impactos inclusive em pontos que estiverem fora do escopo do problema.

Documentação da solução: A solução concebida deve ser

devidamente documentada no registro do incidente. A base de conhecimento
deve também ser atualizada com a nova informação e com todos os impactos (se
houver).

113
 6.5. SUCESSIVAS INTERRUPÇÕES NO FLUXO DE TRABALHO

Este problema é percebido de modo constante e intenso pelos

analistas de suporte. Com uma certa frequência, os analistas precisam se deparar
com incidentes onde é necessário realizar análises profundas que demandam
muito tempo. Em geral, esse trabalho envolve testes, análise de arquivos de logs,
tabelas, etc... Porém, é comum durante estas análises o telefone tocar e o
analista de suporte precisar interromper o processo para fazer o atendimento de
outro incidente. Para tentar atenuar este fato, os analistas em geral procuram
manter o cliente na linha até terminar toda a análise. Porém, isto também é
prejudicial para a área de suporte, pois há casos onde o analista chega a ficar até
quatro horas com o cliente na linha. Isto faz com que a equipe tenha praticamente
um analista a menos para fazer o atendimento de novos chamados. Se dois ou
três analistas ficarem numa situação desta, o volume de chamados pendentes irá
se acumular, contribuindo para o aumento excessivo da demanda.
Um ponto que possivelmente representa uma falha da área de suporte,
neste caso, é atribuir aos analistas a tarefa de atender os clientes e resolver
incidentes de todos os tipos de complexidade. A área de suporte não possui uma
subdivisão por nível de complexidade. Uma solução adequada seria, portanto,
dividir a área onde uma parte da equipe ficaria destinada para atuar em incidentes
que demandassem análise profunda e mais demorada. Esta recomendação é
prevista no framework ITIL (divisão da área de suporte em níveis). Ou então a
empresa poderia promover a criação de outra área para apoiar a área de suporte.
Esta outra área poderia ser composta não apenas de analistas de suporte, mas
de pessoas oriundas de outras áreas também (desenvolvimento, qualidade,
etc...). Uma outra abordagem, baseada em Arquitetura Orientada a Serviços
(SOA) seria dividir a área de duas equipes: uma que atue sobre a camada
plumbing e outra especializada nos aspectos do negócio. Esta divisão da infra-
estrutura de TI é mencionada por Hurwitz, Bloor, Kaufman e Halper (2009).

114
 6.6. ANÁLISE DAS CARACTERÍSTICAS DA EMPRESA
MEDIANTE ALGUNS DOS PRINCIPAIS FRAMEWORKS

Neste tópico será feita uma confrontação entre o panorama da

empresa, mais particularmente da área de suporte, com alguns dos principais
frameworks. É importante dizer que aqui não será feita uma comparação com
todos os preceitos de todos os frameworks, mas apenas com alguns dos
principais e que forem relevantes para o escopo deste trabalho.

6.6.1. A área de suporte da empresa e a ITIL

A seguir, é exibido o Quadro 9 com algumas recomendações da ITIL,

referentes à:

 Central de Serviços
 Processo de Gerenciamento de Incidentes
 Processo de Gerenciamento de Problemas
 Processo de Gerenciamento de Configuração

Apesar de alguns desses processos não serem ligados diretamente à

área de suporte, eles devem prover apoio ao processo de Gerenciamento de
Incidentes, e portanto, também são citados aqui:

115
 Quadro 9 - Situação da empresa mediante alguns processos do ITIL

Processos Não Atende Atende

atende parcialmente Totalmente
CENTRAL DE SERVIÇOS (SERVICE DESK)
Uso de uma Central de Serviços (Single Point Of
Contact)
Meio de auto-atendimento para os usuários podem
abrir, acompanhar e manipular registros de
incidentes (por exemplo: portal Web)
Uso de sistema de gerenciamento de chamados.
Sistemas de interação por meio de respostas
audíveis
Softwares/Ferramentas para realizar diagnóstico e
solução de incidentes remotamente.
GERENCIAMENTO DE INCIDENTE
Suporte dividido em níveis
Utilização de uma base de conhecimento para
armazenar os dados históricos sobre incidentes
solucionados
Processo estruturado de atendimento
Procedimento separado para tratamento de
incidentes críticos.
Os incidentes são encerrados com o a confirmação
do usuário.
Uso de critério de classificação do incidente
conforme o seu ciclo de vida (por exemplo: aberto,
encerrado etc)
Utilização de critérios de classificação para os
incidentes conforme o impacto causado no negócio
Emprego de soluções de contorno para os
incidentes enquanto a solução definitiva não está
disponível.
Definição de metas de curto prazo (quick wins)
Uso de indicadores de desempenho: quantidade de
chamados abertos, solucionados, etc...
GERENCIAMENTO DE CONFIGURAÇÃO
Uso de uma base de dados contendo dados sobre
os itens de configuração e os serviços que podem
ser afetados por eles.
GERENCIAMENTO DE PROBLEMAS
Uso de técnicas de resolução de problemas
Atuação proativa no gerenciamento dos problemas:
emprego de medidas para prevenir problemas nos
serviços de TI
Armazenamento de dados sobre os problemas
causadores dos incidentes: sintomas, causas,
soluções de contorno existentes, itens de
configuração envolvidos, impacto para o negócio,
etc...
Processos que viabilizem a disponibilização clara e
acessível das informações sobre problemas
resolvidos para as equipes do suporte técnico.
Fonte: O autor

116
 6.6.2. A área de suporte e o COBIT

Com relação ao COBIT, o Quadro 10 exibe o comportamento da

empresa no que se refere aos seguintes processos, pertencentes ao domínio
Entregar e Suportar (DS):

DS8 Gerenciar a Central de Serviços e os Incidentes

DS10 Gerenciar Problemas

Quadro 10 - Situação da empresa mediante alguns requisitos do COBIT

Domínio Não Atende Atende

atende parcialmente Totalmente
DS8 Gerenciar a Central de Serviços e os Incidentes
Estabelecimento de uma central de serviços
Classificação e priorização dos incidentes conforme
o Acordo de Nível de Serviço
Monitoramento da satisfação dos usuários finais
com relação á qualidade do atendimento
Registro dos chamados dos clientes
Escalonamento de incidentes
Implementação de soluções temporárias quando
necessário
Monitoramento periódico do encerramento de
chamados pelos clientes
Confirmação de que a resolução foi aceita pelo
cliente
Geração de relatórios e análise de tendências

DS10 Gerenciar Problemas

Identificação e classificação dos problemas
Rastreamento e resolução de problemas,
considerando erros conhecidos, tendências e itens
de configuração associados.
Procedimento de registro de encerramento de
problemas
Integração dos processos de gerenciamento de
configuração, problemas e mudanças.
Fonte: O autor

117
 7. CONCLUSÕES

Como o próprio mercado de T.I. é bastante dinâmico e além disso, o

próprio conceito de qualidade pode sofrer variações (as expectativas dos usuários
e clientes mudam), este trabalho não tem a pretensão de esgotar este assunto.
A garantia de qualidade na gestão de suporte técnico é baseada em
diversos conceitos, que abrangem estratégia, processos, indicadores,
frameworks, entre outros elementos. Estes conceitos, já abordados anteriormente
devem sempre convergir para a estratégia da companhia e podem ser ordenados
num conjunto de alguns passos explicados a seguir.

 Conhecer a estratégia da empresa: A área de suporte técnico está ligada

à satisfação do cliente e à estratégia da companhia. Portanto, é necessário
que a área conheça a estratégia de negócio da organização na qual está
inserida.

 Definir o papel da área de suporte na estratégia da organização: A

aplicação dos frameworks e conceitos apresentados é inútil se a empresa
não definir o papel da área de suporte na estratégia da organização. Foi
verificado pelo pesquisador que a empresa analisada não definiu este
papel.

 Definir um padrão atingível de qualidade: O conceito de qualidade deve

ser sempre alinhado a métricas e a parâmetros a serem perseguidos. É
preciso que o padrão de qualidade almejado corresponda á estratégia da
empresa e seja baseado em metas atingíveis.

 Estabelecer métricas e controles adequados: Para se verificar se a

gestão da área de suporte está próxima do padrão de qualidade desejado
é necessário estabelecer controles e métricas adequadas.

118
 Fotografar a situação atual: É preciso conhecer a situação atual da área.
Esta análise do panorama faz com que fique claro o quão distante a área
está do padrão de qualidade almejado.

 Rever cultura, processos, pessoas e recursos de TI: É preciso rever os

processos, a cultura da área, verificar como estão sendo empregados os
recursos, etc..., tendo sempre em vista a estratégia da empresa. A partir
deste diagnóstico, a gestão pode definir mais facilmente qual a melhor
forma de empregar os conceitos e frameworks apresentados.

 Após começar a caminhar: É preciso verificar periodicamente se a gestão

da área não está se desviando do rumo desejado. É preciso também ter
consciência de que o contexto é dinâmico, por isso sempre é necessário
rever o primeiro passo, pois a estratégia pode se modificar.

119
 8. REFERÊNCIAS BIBLIOGRÁFICAS

4HD. 1ª Pesquisa Nacional sobre Gestores de Help Desk, Service Desk e

Suporte Técnico. Disponível em: http://www.4hd.com.br/files/4HD-PESQUISA-
20100524.pdf. Acesso em: 22/05/2011.

ABNT. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 9001:

Sistemas de gestão da qualidade - Requisitos. Rio de Janeiro, 2008. 28 p.

ALBERTIN, R. M. M.; ALBERTIN, A. L. Estratégias de Governança de Tecnologia

da Informação. Rio de Janeiro. Elsevier. 2010.

BIANCHINI, E.; PACCOLA, H. Matemática 2° grau. Versão beta. São Paulo:

Moderna, 1995.

CASAS A.L.L. Qualidade Total em Serviços. 6 edição. São Paulo: Editora Atlas,
2008.

COHEN, R. Competências Preferidas para Help Desk e Service Desk. 2005. 67p.
Monografia (curso de Psicologia nas Organizações). PUC-RS – Pontifícia
Universidade Católica do Rio Grande do Sul, Porto Alegre.

COHEN R. Gestão de Help Desk e Service Desk: Ensaios e crônicas ao

supervisor de pequenos e médios centros de suporte técnico, Help Desk e
Service Desk. São Paulo: Novatec, 2011.

DANTON, G. Metodologia Científica. Pará de Minas - MG. Virtual Books Online

M&M Editores LTDA. 2000/2002.

FREITAS M. A. S. Fundamentos do Gerenciamento de Serviços de TI:

Preparatório para a certificação ITIL v3 Foundation. Rio de Janeiro: Brasport,
2010.

GASPAR M.; GOMEZ T.; MIRANDA Z. TI: Mudar e Inovar: Resolvendo conflitos
com ITIL V3 - aplicado a um estudo de caso. Brasília: Editora Senac. 2010.

GODOY, A. L. Gráfico de Pareto - Ferramenta da Qualidade. Disponível em:

http://www.cedet.com.br/index.php?/O-que-e/Gestao-da-Qualidade/grafico-de-
pareto-ferramenta-da-qualidade.html. Acesso em 10/06/2011

HURWITZ, J.; BLOOR, R; KAUFMAN, M; HALPER, F. Arquitetura Orientada a

Serviços: SOA para leigos. 2ª edição. Rio de Janeiro: Altabooks, 2009

IT Governance Institute. COBIT 4.1. Rolling Meadows, 2007

KOSCIANSKI, A.; SOARES M. S. Qualidade de Software. São Paulo: Novatec

Editora, 2006.

120
LAKATOS, E. M; MARCONI, M. A. Metodologia do Trabalho Científico. 4ª edição
Revista e Ampliada. São Paulo: Atlas, 1992.

MAGALHAES I.L.; PINHEIRO W.B. Gerenciamento de Serviços de TI na Prática:

uma abordagem com base na ITIL. São Paulo: Novatec, 2007.

MELLO, C. H. P.; NETO, P. L. O. C.;TURRIONI, J. B.; SILVA, C. E. S. Gestão do

Processo de Desenvolvimento de Serviços. São Paulo. Editora Atlas, 2010.

MUNS, R. The Help Desk Handbook. Colorado Springs: Help Desk Institute, 1993.

NOCERA, R. J. Gerenciamento de Projetos – Teoria e Prática. Santo André: Ed.

do Autor, 2009.

NORMANN, R. Administração de Serviços: estratégia e liderança na empresa de

serviços. São Paulo: Atlas, 1993.

PMBOK. PMBOK Guide: a guide to the project management body of knowledge.

Newtown Square: Project Management Institute, 2008

QUEIROZ, D. T.; VALL, J.; SOUZA, A. M. A.; VIEIRA, N. F. C. Observação

Participante na Pesquisa Qualitativa: conceitos e aplicações na área da saúde. R
Enferm UERJ, Rio de Janeiro, 2007 abr/jun; 15(2):276-83

RUIZ, F. M. Pesquisa qualitativa e pesquisa quantitativa: complementaridade

cada vez mais enriquecedora. Adm. de Emp. em Revista, Curitiba, n.3, p.37-47,
2004.

SCHLIEPER, Alexandre D. Aplicação da Metodologia Six Sigma na área de TI em

empresas de serviços. 2007. 70p. Monografia (pós graduação lato sensu MBIS –
Master Business Information Systems). PUS-SP – Pontifícia Universidade
Católica de São Paulo, São Paulo.

WESTERMAN, G.; HUNTER, R. O risco de TI: convertendo ameaças aos

negócios em vantagem competitiva. São Paulo. M. Books, 2008

121