aplicaÇÃo da itil v3 utilizando prÁticas Ágeis … · monografia apresentada como requisito...
TRANSCRIPT
PONTÍFICIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL
CURSO DE ESPECIALIZAÇÃO EM GERENCIAMENTO DE PROJETOS COM ÊNFASE
EM TECNOLOGIA DA INFORMAÇÃO
BRUNO SOUZA DE OLIVEIRA
APLICAÇÃO DA ITIL v3 UTILIZANDO PRÁTICAS
ÁGEIS FOCADA NO PROCESSO DE OPERAÇÃO DO
SERVIÇO
Porto Alegre
2012
BRUNO SOUZA DE OLIVEIRA
APLICAÇÃO DO ITIL v3 UTILIZANDO PRÁTICAS ÁGEIS FOCA DA NO
PROCESSO DE OPERAÇÃO DO SERVIÇO
Orientador: Prof. Dr. Marcelo Hideki Yamaguti
Monografia apresentada como requisito para
obtenção de grau de Especialista em
Gerenciamento de Projetos com Ênfase em
Tecnologia da Informação pelo programa de
Pós-Graduação da Faculdade de Informática
da Pontifícia Universidade Católica do Rio
Grande do Sul.
Dedico esta monografia aos meus pais,
esposa, amigos e colegas de trabalho que
me apoiaram durante esta trajetória.
AGRADECIMENTOS
Ao meus pais pelo apoio, dedicação e incentivo para o meu crescimento pessoal e
profissional. A minha esposa pela compreensão e o apoio prestado durante a elaboração deste
trabalho. Ao meu orientador Marcelo Hideki Yamaguti pela sabedoria e o apoio dispensado
para realização deste trabalho e a toda equipe da célula de serviços do Projeto AGHU que
serviram de inspiração para elaboração desta monografia, além de terem prestado todo o
apoio necessário para o sucesso deste.
“Quanto aos métodos, pode haver mais de
um milhão deles, mas são poucos os
princípios. O homem que souber os
princípios pode selecionar com sucesso os
próprios métodos. O homem que testar os
métodos, ignorando os princípios,
certamente terá problemas”,
Ralph Waldo Emerson
RESUMO
No ano de 2009 nasceu o projeto chamado “Aplicativo de Gestão para Hospitais
Universitários” (AGHU) idealizado pelo Ministério da Educação do Brasil (MEC), pois foi
entendido que a situação dos Hospitais Universitários Federais (HUF) em nível de Tecnologia
da Informação (TI) e processos de gestão se encontravam em condições precárias. Com isso o
Projeto AGHU veio para mudar esta realidade, sendo que, para alcançar os seus objetivos foi
idealizada uma grande equipe de trabalho envolvendo profissionais de diversas áreas.
Com o passar dos anos e a constante evolução do desenvolvimento do AGHU iniciou a
necessidade de se estruturar, implantar e sustentar o Aplicativo de Gestão para Hospitais
Universitários em todos os 46 HUF’s do Brasil. Porém, para isso era necessária a construção
de uma célula de serviços de TI com equipes que tivessem a capacidade e a competência
necessária para realização deste trabalho. Em julho de 2011 foi montada apenas uma pequena
equipe, para sustentar parcialmente essas novas demandas. Essa estratégia acabou não sendo o
suficiente por uma série de fatores, tais como: poucos recursos humanos destinados a este
trabalho, a equipe não utilizava nenhum processo formalizado ou qualquer outra boa prática
conhecida para gerir serviços.
Sendo assim, este trabalho apresenta a estruturação de uma célula de serviços de TI
capaz de atender os HUF’s de forma a garanti-los o menor impacto possível, baseado em uma
pesquisa para elaboração de um processo fundado em boas práticas de gerenciamento de
serviços oriundas da Information Technology Infrastructure Library (ITIL) com foco na fase
de operação de serviço aliadas a algumas práticas ágeis. Com isto, será possível aumentar a
qualidade dos serviços prestados aos Hospitais Universitários Federais no que se refere ao
Projeto AGHU.
Palavras-chave: ITIL, gerência de serviços, práticas ágeis, Scrum, XP, Kanban,
qualidade de serviços.
ABSTRACT
In 2009, a project called Aplicativo de Gestão para Hospitais Universitários (AGHU,
which stands for Application for University Hospitals Management) was conceived by
Ministério da Educação do Brasil (MEC, which stands for Brazilian Ministry of Education),
where it was detected that the Hospitais Universitários Federais (HUF, which stands for
Federal University Hospitals) were in poor conditions in terms of Information Technology
(IT) and management processes. Therefore, AGHU project was started to change this context,
through the setup of a big team composed of professionals from several knowledge areas.
Through the years it was evident the constant evolution of the AGHU development, and
it was necessary to organize, install and maintain this product in 46 HUF in Brazil. However,
it was necessary to create an operation cell with the skills and competencies to complete this
task. In July 2011 there was only a small team to support these new demands. This strategy
ended to be insufficient due to various factors, such as low availability of human resources,
deficient formal processes or any other good practice to manage services.
In this context, this work presents the creation of an operation cell capable of dealing
with all HUF so as to maintain them with the lowest impact possible, based on a research to
create a process based on Information Technology Infrastructure Library (ITIL) good
practices during the operations phase in conjunction with agile methods. So, it is possible to
improve the quality of service offered to HUF by the AGHU project.
Keywords: ITIL, service management, agile, Scrum, XP, Kanban, quality service.
LISTA DE ILUSTRAÇÕES
Figura 1 - Desenho do Método de Pesquisa. ............................................................................18 Figura 2 - Resumo em Alto Nível das Interações entre os Grupos de Processos (PMI, 2008)...................................................................................................................................................24 Figura 3 - Ciclo de Vida da ITIL v3 (OGC, 2007a). ................................................................26 Figura 4 - Fluxo de Gerenciamento de Eventos (OGC, 2007e). ..............................................32 Figura 5 - Fluxo do Gerenciamento de Incidentes (OGC, 2007e)............................................34 Figura 6 - Fluxo do Gerenciamento de Problemas (OGC, 2007e). ..........................................37 Figura 7 - Responsabilidades Gerenciamento de Aplicações (OGC, 2007e)...........................41 Figura 8- Modelo de Melhoria Contínua de Processo (OGC, 2007f). .....................................43 Figura 9 - Quatro Razões para Monitorar e Medir (OGC, 2007f)............................................44 Figura 10 - Framework Scrum (Ken Schwaber e Jeff Sutherland, 2011). ...............................49 Figura 11 - Exemplo de Ambiente Informativo (KNIBERG, 2004)........................................51 Figura 12 - Exemplo de Kanban (RASMUSSON, 2010). .......................................................52 Figura 13 - Escopo Completo do AGHU (MEC, 2009). ..........................................................57 Figura 14 - Estrutura Organizacional (MEC, 2009). ................................................................59 Figura 15 - Gráfico de Respostas da Avaliação Agrupada por Nível de Maturidade. .............69 Figura 16 - Gráfico de Média da Pontuação do Instrumento de Avaliação. ............................70 Figura 17 - Estrutura para Equipes de Central de Serviços de TI. ...........................................73 Figura 18 - Estrutura de Equipes para Célula de Serviços de TI AGHU/POA. .......................74 Figura 19 - Workflow Níveis de Serviço. .................................................................................80 Figura 20 - Localização de Centrais de Serviço - Projeto AGHU (Fonte: O autor, 2012).......85 Figura 21 - Workflow Realizar Suporte Nível 1. ......................................................................86 Figura 22 - Workflow Processo de Realizar Encerramento do Atendimento. ..........................88 Figura 23 - Workflow Requisição de Serviço. ..........................................................................91 Figura 24 - Workflow Incidentes e Problemas..........................................................................96 Figura 25 - Calendário do Mês de Julho.................................................................................106 Figura 26 - Situação HUF's. ...................................................................................................107 Figura 27 - Kanban e Quadro de Lições Aprendidas. ............................................................108 Figura 28 - Planejamento da Sprint – Kanban. ......................................................................109 Figura 29 - Kanban Metade da Semana. ................................................................................110 Figura 30 - Kanban com início Nova Sprint. .........................................................................111 Figura 31 - Gráfico de Respostas da Reavaliação Agrupada por Nível de Maturidade.........115 Figura 32 - Gráfico Comparativo da Execução do Instrumento de Avaliação.......................117 Figura 33 - Workflow Completo Requisições de Serviço.......................................................129 Figura 34 - Workflow Completo Incidentes e Problemas. ......................................................130 Figura 35 - Número de Requisições Registradas por Sprint. .................................................141 Figura 36 - Número de Requisições Concluídas por Sprint. ..................................................142 Figura 37 - Número de Requisições de Tipo “Serviço” registradas por Sprint......................143 Figura 38 - Número de Requisições do Tipo “Incidente” registradas por Sprint...................144 Figura 39 - Número de Requisições por Item do Catálogo de Serviços.................................145 Figura 40 - Número de Requisições Registradas por HUF. ...................................................145 Figura 41 - Número de Requisições por Prioridade. ..............................................................146 Figura 42 - Calendário do Mês de Agosto..............................................................................147 Figura 43 - Calendário Meses de Setembro e Outubro..........................................................147
LISTA DE TABELAS
Tabela 1 - Responsáveis no Projeto AGHU. ............................................................................59 Tabela 2 - Instrumento de Avaliação........................................................................................65 Tabela 3 - Possíveis Respostas para o Instrumento de Avaliação............................................65
Tabela 4 - Relação do Instrumento de Avaliação com as Áreas Estudadas. ............................66
Tabela 5 – Relação do Instrumento de Avaliação com Pontos Negativos. ..............................67
Tabela 6 - Perfil dos Participantes da Avaliação Inicial...........................................................68 Tabela 7 - Respostas da Avaliação Agrupadas por Nível de Maturidade. ...............................69
Tabela 8 - Média de Pontuação por Área de Conhecimento. ...................................................70
Tabela 9 - Papéis Equipes de Central de Serviços....................................................................74 Tabela 10 - Responsabilidades das Equipes de Serviços de TI................................................76 Tabela 11 - Papéis equipes da Célula de Serviços de TI AGHU/POA. ...................................77
Tabela 12 - Fases dos Níveis de Serviço. .................................................................................81 Tabela 13 - Atividades Workflow de Níveis de Serviço...........................................................84
Tabela 14 - Atividades Processo de Realizar Suporte de Nível 1. ...........................................87
Tabela 15 - Atividades do Processo de Realizar Encerramento do Atendimento. ...................89
Tabela 16 - Fases Workflow de Requisições de Serviço, Incidentes e Problemas...................92 Tabela 17 - Atividades Workflow Requisição de Serviço. .......................................................94 Tabela 18 - Atividades Workflow Incidentes e Problemas. ......................................................97 Tabela 19 - Cronograma de Execução de Atividades de Implantação por Semana. ..............105
Tabela 20 - Perfil dos Participantes da Avaliação Final.........................................................114 Tabela 21 - Respostas da Reavaliação Agrupadas por Nível de Maturidade.........................115
Tabela 22 – Média Comparativa entre Avaliações por Área de Conhecimento. ...................116
Tabela 23 - Dados Primeira Execução do Instrumento de Avaliação. ...................................128
Tabela 24 - Catálogo de Serviços...........................................................................................140 Tabela 25 - Dados Segunda Execução do Instrumento de Avaliação. ...................................150
LISTA DE SIGLAS
AGH Aplicativo de Gestão Hospitalar
AGHU Aplicativo de Gestão para Hospitais Universitários
CCTA Central Computing and Telecommunications Agency
HCPA Hospital de Clínicas de Porto Alegre
HUF Hospital Universitário Federal
ITIL Information Technology Infrastructure Library
MEC Ministério da Educação
OGC Office of Government Commerce
POA
REHUF
Porto Alegre
Reestruturação dos Hospitais Universitários Federais
TCU Tribunal de Contas da União
TI Tecnologia da Informação
SUMÁRIO
INTRODUÇÃO........................................................................................................................13
1.1 Motivação ..................................................................................................................14 1.2 Solução Proposta........................................................................................................14 1.3 Objetivos....................................................................................................................16 1.4 Estrutura do Trabalho ................................................................................................16
2 MÉTODO DE PESQUISA...............................................................................................18 2.1 Fundamentação Teórica.............................................................................................18 2.2 Avaliação Inicial ........................................................................................................19 2.3 Definição....................................................................................................................20 2.4 Execução....................................................................................................................20 2.5 Análise dos Resultados ..............................................................................................20
3 FUNDAMENTAÇÃO TEÓRICA ...................................................................................22
3.1 Gerenciamento de Projetos ........................................................................................22 3.2 Gerenciamento de Serviços em TI.............................................................................25
3.2.1 Estratégia de Serviços (Service Strategy)...........................................................27 3.2.2 Desenho de Serviços (Service Design) ...............................................................27 3.2.3 Transição de Serviço (Service Transition) .........................................................28 3.2.4 Operação de Serviço (Service Operation) ..........................................................29
3.2.4.1 Gerenciamento de Eventos..........................................................................31
3.2.4.2 Gerenciamento de Incidentes ......................................................................33
3.2.4.3 Gerenciamento de Problemas......................................................................36
3.2.4.4 Cumprimento de Requisições .....................................................................38
3.2.4.5 Gerenciamento de Acesso ...........................................................................38
3.2.4.6 Central de Serviços......................................................................................39
3.2.4.7 Gerenciamento Técnico...............................................................................40
3.2.4.8 Gerenciamento da Aplicação ......................................................................40
3.2.4.9 Gerenciamento das Operações de TI...........................................................41
3.2.5 Melhoria Contínua de Processo (Continual Process Improvement) ..................42 3.3 Gestão Ágil de Projetos .............................................................................................44
3.3.1 Scrum..................................................................................................................47 3.3.2 XP (Extreme Programming)...............................................................................50
3.3.3 Kanban...............................................................................................................52 3.4 Síntese da Fundamentação Teórica............................................................................53
4 AVALIAÇÃO INICIAL ..................................................................................................56 4.1 Projeto AGHU ...........................................................................................................56 4.2 Descrição do Ambiente..............................................................................................57
4.2.1 Estrutura do Projeto AGHU ...............................................................................58
4.2.2 Estrutura da Célula de Serviços de TI ................................................................60
4.3 Instrumento de Avaliação ..........................................................................................62 4.4 Aplicação do Instrumento de Avaliação....................................................................67
5 DEFINIÇÃO.....................................................................................................................71 5.1 Avaliação das metodologias estudadas......................................................................71
5.2 Definição de Estrutura do Projeto..............................................................................72 5.3 Definição de Processos ..............................................................................................78
5.3.1 Central de Serviços.............................................................................................84 5.3.2 Catálogo de Serviços ..........................................................................................89
5.3.3 Workflows por Tipos de Requisição ...................................................................90
5.3.4 Método de Trabalho das Equipes da Célula de Serviços de TI ..........................97
5.3.5 Ferramenta de apoio .........................................................................................103 6 EXECUÇÃO ..................................................................................................................104
6.1 Planejamento da Implantação ..................................................................................104 6.2 Execução da Implantação ........................................................................................105 6.3 Reaplicação do Instrumento de Avaliação...............................................................112
7 ANÁLISE DOS RESULTADOS...................................................................................116 7.1 Análise de Pontos Positivos e Negativos.................................................................118
7.2 Análise de Pontos a Melhorar ..................................................................................119 8 CONCLUSÃO................................................................................................................121
8.1 Limitações do Trabalho ...........................................................................................122 8.2 Trabalhos Futuros ....................................................................................................122
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................................124 APÊNDICE A – Dados coletados no instrumento de avaliação ............................................126
APÊNDICE B – Fluxo completo de uma requisição de serviço ............................................129
APÊNDICE C - Fluxo completo de um incidente ou problema.............................................130
APÊNDICE D – Catálogo de serviços ...................................................................................131 APÊNDICE E – Métricas.......................................................................................................141 APÊNDICE F – Exemplos de Ambiente Informativo ...........................................................147
APÊNDICE G – Dados coletados na reavaliação do instrumento de pesquisa......................148
13
INTRODUÇÃO
Segundo van Bon (2002), ao longo das duas últimas décadas o mundo de Tecnologia da
Informação (TI) mudou drasticamente, com isso, surgiram diversas outras preocupações que
inexistiam anteriormente e, a partir dessas, nasceram várias boas práticas como sugestão para
encarar essa nova realidade.
Em um mundo de crescente complexidade, escolha e globalização, a TI precisou mudar
seus processos, perceberam que a maioria de seus projetos estava fracassando e que algo
precisava mudar. Entendeu-se que não se podia mais apenas se preocupar com o
desenvolvimento do software, mas também em como manter este em seu correto
funcionamento após a sua entrega e, principalmente, zelar pelo relacionamento com o cliente.
Sendo necessário garantir a qualidade dos serviços prestados para o cliente também após a
conclusão do projeto, pois é nesse momento que será observado o valor do serviço prestado
(BON, 2002).
Gerenciar esses serviços é a alternativa para garantir o melhor atendimento possível
aos clientes, com isso e seguindo no contexto a evolução do mundo, surgem diversas novas
ideias para serem aplicadas nas mais diversas realidades, como é o caso da Information
Technology Infrastructure Library (OGC, 2007a) focada em gerenciamento de serviços e as
práticas ágeis inicialmente com o foco em desenvolvimento de software.
Ambas as práticas sempre vão estar em constante evolução, pois é necessário
acompanhar o crescimento do mundo, sua velocidade e mudanças constantes o que o torna
cada vez mais complexo e é com esse entendimento que as organizações vêm evoluindo de
forma a garantir um diferencial competitivo.
14
1.1 Motivação
No início do ano de 2009 o Ministério da Educação (MEC), baseado em um evento
promovido pelo Tribunal de Contas da União (TCU) onde foi concluído que existiam
problemas estruturais recorrentes nas Instituições Federais de Ensino Superior, iniciou o
Programa Nacional de Reestruturação dos Hospitais Universitários Federais (REHUF) e a
partir deste nasceu o Projeto AGHU (Aplicativo de Gestão para Hospitais Universitários) que
tem como principal objetivo “Propiciar a transferência de tecnologia necessária à
implantação do sistema informatizado de gestão hospitalar desenvolvido pelo HCPA
fortalecendo as melhores práticas de gestão nos Hospitais Universitários Federais do
Ministério da Educação.” (MEC, 2009).
Neste contexto foi montada uma grande equipe em Porto Alegre alocada no Hospital de
Clínicas de Porto Alegre (HCPA), sendo que as primeiras implantações do AGHU tiveram
início em julho de 2011, onde uma célula de serviços de TI foi criada para manter o software
em seu correto funcionamento em 46 Hospitais Universitários Federais.
Entretanto, a equipe não utiliza nenhum processo formalizado ou qualquer outra boa
prática conhecida para gerenciamento de serviços. Não existe nenhum tipo de controle,
planejamento, indicadores e objetivos. Além disso, a estrutura apresenta apenas uma equipe
com conhecimento centralizado em seus membros, sendo que não existe um objetivo comum
entre esses. Os membros desta equipe não possuem conhecimento de boas práticas para
melhorar a qualidade do serviço prestado, sendo que cada um tem uma responsabilidade
técnica definida, não se caracterizando por uma equipe.
Por não existir nenhum tipo de processo, não se tem como controlar o trabalho que é
realizado e muito menos garantir acordos de nível de serviço com o cliente, sendo assim a
equipe não tem alcançado bons resultados gerando insatisfação dos clientes.
1.2 Solução Proposta
A ITIL nasceu para solucionar problemas de gerenciamento de serviços, assim como
outros modelos e boas práticas têm surgido com o passar dos anos. Considerando que a ITIL
pode ser utilizada para sustentação de problemas pós entrega do software e que um dos
movimentos que vem crescendo a cada ano é o Manifesto Ágil, sendo que seus valores
(BECK, 2001) apresentam uma relação com os objetivos dos processos descritos na ITIL v3,
15
entende-se que é possível adicionar práticas ágeis ao processo de operação de serviço
aumentando ainda mais a produtividade das equipes de operação minimizando o impacto para
o cliente e aperfeiçoando a qualidade dos serviços prestados.
Como solução, a proposta do trabalho de conclusão é utilizar boas práticas disponíveis
na ITIL v3 adotando algumas práticas ágeis focada no processo de operação do serviço. Será
necessária a realização de um estudo para validar a aplicabilidade das propostas existentes em
metodologias ágeis que possam agregar valor em uma equipe de operação, sendo que esse
trabalho será realizado no formato de monografia.
Baseado nesse estudo deve ser apresentado um conjunto de boas práticas ágeis que
devem ser aplicadas juntamente com a ITIL v3 em uma célula de serviços de TI focada no
processo de operação de serviços e por fim validar os resultados. A implantação dessa solução
deve mudar a situação desta célula, com um ambiente controlado, processos específicos para
atendimento, constituição de equipes autogerenciáveis, melhoria contínua e decisões baseadas
em indicadores aumentando assim a qualidade do atendimento.
16
1.3 Objetivos
O objetivo principal deste trabalho é a construção e implantação de um processo de
gerenciamento de serviços constituído com base na ITIL v3 focado na fase e operação de
serviços e práticas ágeis aplicados à realidade do Projeto AGHU, para assim, melhor atender
as necessidades dos HUF’s.
Alinhado a este objetivo, pretende-se atingir os seguintes objetivos secundários:
• Estudo de boas práticas (ITIL v3 e práticas ágeis): entendimento das boas
práticas sugeridas pela ITIL v3 e os métodos ágeis;
• Entendimento do contexto do Projeto AGHU: análise do contexto atual do
projeto para assim melhor aplicar o estudo realizado;
• Definição de um processo para gerenciamento de serviços: com a visão das
boas práticas e do cenário atual deve ser definido um processo de trabalho para
célula de serviços de TI;
• Implantação do processo definido na célula de serviços de TI: momento
onde deve ser implantado o processo definido;
• Avaliar o resultado do processo implantado: após a implantação será
reavaliado os resultados para assim verificar se houve o ganho esperado com o
novo processo.
Com estas metas atingidas pretende-se iniciar um processo de melhoria contínua do
trabalho realizado, sendo este baseado em indicadores extraídos de uma ferramenta que
permita um alto nível de controle, pois sempre é necessária a adaptação. Além disso, espera-
se incentivar outros trabalhos nesse sentido sugerindo melhorias neste processo.
1.4 Estrutura do Trabalho
Este trabalho está estruturado da seguinte maneira:
• Capítulo 2: descreve o desenho de pesquisa proposto para este trabalho. O
desenho tem o objetivo de formalizar a forma que será desenvolvido o estudo
proposto.
17
• Capítulo 3: apresenta a fundamentação teórica utilizada para construção deste
trabalho, onde será descrito de forma resumida todo o estudo realizado de boas
práticas da ITIL v3 para gerenciamento de serviços de TI, práticas ágeis que
venham a agregar valor nesta área da TI especificamente no processo de operação
de serviço e uma breve descrição do livro A Guide to Project Management Book of
Knowledge (PMBOK, 2008).
• Capítulo 4: descreve a situação do ambiente onde será aplicado este trabalho e
principalmente de onde se originou a motivação para a realização deste trabalho.
• Capítulo 5: apresenta a proposta da metodologia para gerenciamento de serviços
especificamente na fase de operação de serviço, sendo que essa proposta é baseada
no estudo descrito de forma resumida nos capítulos anteriores, bem como a
situação do ambiente relatado no capítulo 4.
• Capítulo 6: descreve o projeto piloto de execução da metodologia proposta, onde
será relatado a aplicação e análise de resultados.
• Capítulo 7: analisa resultados finais do trabalho, citando pontos positivos,
negativos e de melhoraria.
• Capítulo 8: relata as considerações finais do trabalho analisando limitações do
trabalho e possibilidade de trabalhos futuros.
No próximo capítulo será apresentado o método de pesquisa na qual esta monografia
deve seguir, bem como um pequeno resumo de cada um de seus capítulos.
18
2 MÉTODO DE PESQUISA
O desenho da pesquisa apresentado neste capítulo está alinhado com o objetivo deste
trabalho, sendo assim, é importante ressaltar que o mesmo não visa aplicar todas as boas
práticas possíveis e sim entender o contexto atual e aplicar apenas o que realmente deve
agregar valor a célula de serviços de TI do Projeto AGHU.
Nesse sentido abaixo segue um diagrama que ilustra a ordem que será construída este
trabalho:
Figura 1 - Desenho do Método de Pesquisa.
2.1 Fundamentação Teórica
Esta fase tem como objetivo identificar um conjunto de boas práticas que se apliquem a
realidade do cenário estudado agregando o valor desejado. Para isso é necessário, em um
primeiro momento, a identificação da literatura necessária para elaboração deste trabalho
buscando as principais referências teóricas dos assuntos abordados. Após a definição dessas
referências se inicia um estudo desse material para assim localizar as boas práticas desejadas
para a constituição de um processo que mantenha o Projeto AGHU dentro de suas metas.
Essa fase é fundamental para o sucesso da proposta, pois é nesse momento que deve ser
compreendido o que realmente pode fazer parte do método que será sugerido, por isso é
necessário buscar as melhores referências possíveis, ser realizado um estudo comparando com
outras boas práticas focando no contexto do Projeto AGHU.
19
O sucesso desta metodologia será avaliado através de sua aplicação durante algum tempo
e a coleta de dados oriunda de métricas e questionários, sendo estes, medidos antes do inicio
da implantação da metodologia e após sua implantação, assim nos fornecendo dados
comparativos. Então para sua melhor execução, esta fase está dividida em três grandes
atividades:
1. Estudo e identificação de literatura necessária para construção do trabalho:
nesta atividade deve ser pesquisado um conjunto de literaturas que devem ajudar
na concepção deste trabalho;
2. Estudo e identificação de boas práticas ITIL: esta fase deve iniciar o estudo de
boas práticas da ITIL com base na literatura selecionada na primeira atividade
realizada do método de pesquisa;
3. Estudo e identificação de boas práticas ágeis: esta fase deve iniciar o estudo de
boas práticas ágeis com base na literatura selecionada na primeira atividade
realizada do método de pesquisa.
2.2 Avaliação Inicial
Conforme relatado anteriormente, o entendimento do contexto atual é fundamental para
elaboração desta metodologia, pois somente assim é possível identificar os problemas
existentes, logo se faz necessário uma avaliação da situação atual. Entretanto, somente será
avaliado o ambiente de operação considerando algumas variáveis externas, sendo que, esta
célula será tratada como uma empresa que presta serviços para área de desenvolvimento,
transição e sustentação do Projeto AGHU.
Para execução desta fase foi definido as seguintes atividades:
1. Descrição do ambiente da área de serviços de TI: nesta atividade deve ser
relatado o ambiente da célula de serviços de TI, descrevendo como é montada a
equipe, suas metas, comunicação, tudo que pode ser melhorado com a aplicação
da nova metodologia;
2. Estudo e identificação de instrumento para avaliação: deve ser estudado o
ambiente descrito e, baseado neste, identificar um instrumento para avaliação do
cenário;
3. Execução do instrumento definido: o instrumento definido deve ser executado
com todos os integrantes da equipe de operação do AGHU e após isso os dados
20
devem ser coletados e armazenados para comparação após a implantação do
método.
2.3 Definição
Na fase de definição é onde deve ser montada a proposta de processo para a célula de
serviços de TI do Projeto AGHU, esta definição será guiada por todo o estudo realizado nas
fases anteriores, por esse motivo é imprescindível que as fases anteriores já estejam
concluídas antes de se iniciar esta. Com esse intuito esta fase apresenta uma grande atividade
nomeada de “Definição e desenvolvimento de metodologia para o processo de operação”
onde será finalizada a proposta do processo.
2.4 Execução
Com a metodologia definida é necessário aplicá-la, para isso essa fase foi dividida em
duas grandes atividades:
1. Implantação de metodologia definida para o processo de operação de serviço:
momento onde será implantado o processo proposto na célula de serviços de TI do
Projeto AGHU;
2. Nova execução do instrumento: o mesmo instrumento executado na fase de
avaliação inicial deve ser executado novamente após algum tempo depois da
implantação do método, desta forma será possível analisar os resultados comparando-
os com o antes e depois com a utilização do novo método.
2.5 Análise dos Resultados
Após a fase de execução e coleta dos dados, torna-se possível a análise dos resultados
obtidos com aplicação do método proposto, onde serão identificados pontos positivos e
negativos da metodologia. Com base nesta análise será identificado se os objetivos propostos
foram atingidos, sendo que os pontos negativos devem entrar em um processo de melhoria
contínua, para assim tornar esta cada vez melhor.
As atividades desta fase são:
21
1. Análise de pontos positivos e negativos: nessa atividade serão levantados com
toda a equipe da célula de serviços de TI todos os pontos positivos e negativos do
novo método;
2. Análise de pontos a melhorar: os pontos negativos devem ser analisados no
intuito de se identificar como melhorar o método, iniciando um processo de
melhoria contínua;
3. Documentação de resultados: todos os resultados e análises devem ser
documentados.
Este capítulo teve o objetivo de explicar como este trabalho será conduzido, no próximo
capítulo será apresentada a fundamentação teórica, primeira fase do método de pesquisa,
conforme ilustrado na figura 1.
22
3 FUNDAMENTAÇÃO TEÓRICA
Durante muitos anos, as organizações puderam continuar seus negócios, ainda que
tivessem pouco apoio da TI (Tecnologia da Informação). Hoje a realidade é diferente, a TI é
um fator crítico de sucesso para organização, por esse motivo, cada vez mais vem se tornando
um dos pilares estratégicos dessas instituições, sendo muitas vezes seu grande diferencial
competitivo.
3.1 Gerenciamento de Projetos
Em 1996 a instituição Project Management Institute (PMI) desenvolveu o guia Project
Management Body of Knowledge (PMBOK), este acabou se tornando um dos guias de
gerenciamento de projetos mais conhecidos no mundo. Seu principal objetivo é identificar o
subconjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido
como boas práticas assim fornecendo estes aos interessados no intuito de auxiliar nos
processos da área de gerenciamento de projetos (PMI, 2008).
De acordo com o PMI (2008), um projeto é um esforço temporário empreendido para
criar um produto, serviço ou resultado exclusivo, sendo assim, todo o projeto deve possuir um
início e um final bem definido. Nesse sentido vale destacar que este trabalho é focado
principalmente na área de gerenciamento de serviços, ou seja, caracterizado por um trabalho
contínuo que tem a responsabilidade de manter o negócio, entretanto, se entende que essa área
é composta de vários pequenos projetos e por esse motivo que houve a necessidade de se
estudar boas práticas de gerenciamento de projetos.
Para gerenciar projetos é necessário que se tenha conhecimento necessário, habilidades,
ferramentas e técnicas a fim de atender o objetivo desejado. Para o sucesso de um projeto a
equipe deve selecionar os processos adequados de acordo com sua realidade, utilizar uma
abordagem definida para adaptar os planos e as especificações do produto, atender os
requisitos para satisfazer as necessidades, desejos e expectativas das partes interessadas e
balancear as demandas conflitantes de escopo, tempo, custo, e outras áreas, para, assim
produzir um resultado de qualidade.
O PMBOK define cinco grupos de processos para o gerenciamento de projetos:
23
1. Grupo de processos de iniciação: onde deve ser realizada uma definição inicial
de um novo projeto ou nova fase de um projeto existente, sendo que este será
analisado e aprovado de acordo com a estratégia da organização;
2. Grupo de processos de planejamento: neste grupo deve ser definido o escopo
total do projeto bem como os objetivos desejados, assim elaborando um
planejamento para que seja possível alcançar estes objetivos dentro dos prazos
acordados;
3. Grupo de processos de execução: tem a responsabilidade principal de elaborar o
plano de gerenciamento do projeto além de integrar pessoas e recursos;
4. Grupo de processos de monitoramento e controle: compostos de processos
com a finalidade de monitorar e controlar métricas frequentemente para assim,
melhor avaliar o andamento do projeto e tomar alguma ação caso necessário;
5. Grupo de processos de encerramento: neste grupo é onde deve ser
encaminhado o encerramento formal do projeto de forma ordenada.
A seguir na figura 2 pode-se visualizar um resumo das iterações entre os grupos de
processos descritos acima, relacionados com as atividades realizadas entre um grupo e outro.
24
Figura 2 - Resumo em Alto Nível das Interações entre os Grupos de Processos (PMI, 2008).
25
3.2 Gerenciamento de Serviços em TI
Serviço de TI é um meio para entregar valor para os clientes, com o objetivo de que esses
alcancem os resultados desejados, sem que tais clientes precisem assumir custos e riscos
específicos inerentes a TI. Gerenciamento de Serviços de TI é o conjunto de capacidades
organizacionais (processos e métodos de trabalho, funções, papéis e atividades) realizadas
para prover valor sob a forma de serviços (OGC, 2007a).
Implementada no fim da década de 1980 pelo governo britânico, inicialmente pela CCTA
(Central Computing and Telecommunications Agency) e atualmente pelo OGC (Office of
Government Commerce), sendo que, o OGC é um órgão que tem como objetivo desenvolver
metodologias e criar padrões dentro dos departamentos do governo britânico (OGC, 2007a),
A ITIL ( Information Technology Infrastructure Library) nasceu como um catálogo de
melhores práticas para os departamentos de TI de seus órgãos governamentais, pois
perceberam que estavam gastando muito dinheiro para manter seus serviços em
funcionamento e decidiram criar uma biblioteca de boas práticas para melhorar sua gestão de
serviços.
Após o seu nascimento as empresas começaram a entender que as boas práticas descritas
poderiam ser utilizadas em seus departamentos de TI e em 1990 a ITIL acabou se tornando
um padrão de fato em todo o mundo (OGC, 2007a).
A TI se tornou uma grande dependência para os negócios, fazendo com que os gestores
busquem cada vez mais a adoção de melhores práticas com o objetivo de trazer resultados
positivos, reduzindo custos e aumentando a produtividade de seus processos. Com este fato, a
ITIL acabou despertando um grande interesse no mercado, pois as empresas começaram a se
preocupar com o Gerenciamento de Serviços de TI.
A ITIL oferece uma biblioteca de melhores práticas comum para todas as tarefas de uma
célula de serviços de TI, como a parte da operação dos serviços, baseada na infraestrutura de
TI. Estas tarefas são divididas em processos, que fornecem um framework eficaz para um
Gerenciamento de Serviços aprimorado. As melhores práticas descritas na ITIL têm como
objetivo (OGC, 2007a):
• Servir de inspiração para melhorar seus processos de TI;
• Sugerir onde é possível chegar;
• Sugerir para que servem os processos e práticas;
26
• Sugerir por que adotar os processos e práticas.
Uma observação importante é que a ITIL não pode ser considerada uma metodologia,
pois as melhores práticas são flexíveis a ponto de o usuário adaptar aos seus processos, já uma
metodologia possui uma implementação mais definida, com regras bem definidas, que é
exatamente a proposta desse trabalho.
Com o passar dos anos a ITIL teve melhorias e o acréscimo de mais práticas bem
sucedidas, desta forma este trabalho utiliza a terceira versão desta biblioteca que tem o foco
no ciclo de vida do serviço representando uma grande mudança estrutural entre as demais
versões.
Figura 3 - Ciclo de Vida da ITIL v3 (OGC, 2007a).
27
Conforme a figura 3 apresentada acima, o ciclo de vida de serviços da ITIL v3 é dividido
em cinco grandes processos, um para cada fase. O processo trabalhado neste trabalho será o
de Operação de Serviço, entretanto, a seguir segue uma explicação de cada um dos processos
a fim de contextualizar o trabalho.
3.2.1 Estratégia de Serviços (Service Strategy)
Pode se entender que este processo faz parte de uma análise de requisitos e definição
inicial, orientando o uso do Gerenciamento de Serviços como uma ferramenta estratégica para
satisfazer as necessidades do negócio, sendo que seu principal objetivo é identificar requisitos
e necessidades do negócio, que são acordados e documentados em um pacote de níveis de
serviço (OGC, 2007b).
A Estratégia de Serviço é a primeira fase do ciclo de vida de um serviço, e se caracteriza,
principalmente, por ser o eixo central que move todas as outras fases; tudo gira ao redor da
estratégia. Talvez um dos grandes diferenciais da ITIL e mais especificamente desta fase é a
proposta de integração entre as áreas de negócio e a TI de forma que cada um ressalte o que
há de melhor no outro focando mais no sucesso do cliente do que a eficiência e eficácia das
operações, qualidades estas, que apresentam uma relação com os valores das práticas ágeis.
Um dos propósitos desta fase é fazer com que os provedores de TI pensem de maneira
estratégica para que eles possam operar aumentando cada vez mais sua lucratividade, e
desenhar estratégias e modelos organizacionais baseados em serviços e com a visão da
organização.
Esta fase apresenta os seguintes objetivos:
• Identificar as necessidades do negócio;
• Desenvolver estratégias para satisfazer as necessidades do negócio;
• Ajudar a selecionar as melhores opções para o aperfeiçoamento do serviço;
• Analisar o uso dos serviços para criar valor para o negócio.
3.2.2 Desenho de Serviços (Service Design)
28
Nesta fase, como o próprio nome sugere, é onde os serviços devem ser desenhados
baseados nas estratégias definidas na fase anterior, a fim de atender as necessidades do
negócio. Seus principais objetivos são (OGC, 2007c):
• Elaborar processos para melhorar o gerenciamento do serviço;
• Desenhar serviços que estejam alinhados com a estratégia da organização, sendo
que, essa estratégia é elaborada na fase anterior;
• Elaborar uma documentação de políticas, planos, serviços, processos,
arquiteturas e treinamentos;
• Auxiliar no processo de melhoria contínua do serviço.
O Desenho do Serviço deve ser elaborado baseado no conceito dos 4 Ps (Pessoas,
Processos, Parceiros e Produtos), sendo que, a utilização deste conceito de forma eficiente e
eficaz minimiza consideravelmente a possibilidade de falhas de gerenciamento. Seus
processos são:
• Gerenciamento do Catálogo de Serviço;
• Gerenciamento de Nível de Serviço;
• Gerenciamento da Capacidade;
• Gerenciamento da Disponibilidade;
• Gerenciamento da Continuidade dos Serviços de TI;
• Gerenciamento do Fornecedor;
• Gerenciamento da Segurança da Informação.
3.2.3 Transição de Serviço (Service Transition)
Seu principal propósito é implantar os desenhos, elaborados na fase anterior, com sucesso
para que a área de operação possa gerenciar os serviços e a infraestrutura de maneira
controlada. Seus principais objetivos são (OGC, 2007d):
• Integrar as fases de Desenho de Serviço e Operação de Serviço;
• Garantir que os requisitos da Estratégia de Serviço estejam definidos no Pacote de
Desenho de Serviço;
29
• Gerenciar o processo de mudança de serviços, a fim de assegurar o menor
impacto possível ao cliente, aumentando assim sua satisfação.
• Assegurar recursos necessários para elaborar, planejar e implantar um novo
serviço.
Seus processos são:
• Gerenciamento de Mudança;
• Gerenciamento de Configuração e de Ativo de Serviço;
• Gerenciamento do Conhecimento;
• Planejamento e Suporte da Transição;
• Gerenciamento de Liberação e Implantação;
• Validação e Teste de Serviço;
• Avaliação.
3.2.4 Operação de Serviço (Service Operation)
Pode ser considerada uma das principais fases do ciclo de vida da ITIL v3, pois é nessa
fase onde é executado todo o planejamento estratégico e tático realizado nas fases anteriores,
sendo focada nas demandas do dia a dia e tem o dever de mostrar para o cliente o valor da TI.
Por essa característica, a fase de Operação de Serviço será o foco deste trabalho, sendo assim,
esta seção é descrita de forma mais detalhada. Segue uma descrição de relações importantes
que se tornam objetivos conflitantes:
• Visão interna (TI) versus Visão externa (negócio): um ponto importante de
ser relatado neste trabalho é o balanceamento entre a visão técnica e a visão de
negócio que deve ser trabalhada nesse momento, sendo que, de acordo com a ITIL v3,
recomenda-se que esse balanceamento tenha tendência para o lado do cliente (negócio)
(OGC, 2007e).
• Estabilidade versus Agilidade: O mundo tem se tornado cada vez mais
dinâmico, devido, principalmente, a velocidade de comunicação em consequência da
evolução da TI fazendo com que a globalização fosse acelerada. Tendo em vista esse
cenário e que essa realidade tende a aumentar com o passar dos anos a TI tem vivido
30
uma mudança de comportamento de seus clientes, pois as solicitações de mudança se
tornam cada vez mais frequentes. Logo se torna claro que as organizações que
responderem mais rapidamente a essas mudanças de escopo terão um grande
diferencial competitivo. Visando essa tendência a ITIL v3 sugere um balanceamento
entre estabilidade e agilidade, nem tão estável para não ser tão lento para adaptar-se e
nem tão ágil para não ser muito instável.
• Qualidade do serviço versus Custo do serviço: Existe ainda a relação de
qualidade do serviço e o custo do serviço, o cliente se torna cada vez mais exigente,
por outro lado não é simples ter qualidade a um baixo custo, logo é necessário
encontrar o equilíbrio ideal dessa relação com o objetivo de atender a requisição do
cliente dentro do prazo acordado ao menor custo possível e com alta qualidade.
• Reativo versus Proativa: Conforme descrito acima, o mundo pede cada vez
mais respostas rápidas a suas mudanças, para que isso se torne realidade é preciso ser
proativo em suas atitudes com o objetivo de minimizar ao máximo o impacto para o
cliente, não se pode mais se reativo, no sentido de somente atuar quando o problema já
existe.
Um fator fundamental para o sucesso dessa fase é a eficiência e eficácia da comunicação
entre equipes, essa característica fará toda a diferença nos resultados desse processo. É
necessário que exista um plano de comunicação bem elaborado e principalmente simples,
aumentando assim a produtividade e minimizando as falhas.
Em resumo, levando em consideração o que foi descrito até o momento neste capítulo,
pode se considerar os seguintes objetivos:
• Responder a necessidade do cliente dentro do prazo acordado com o menor custo
e alta qualidade;
• Encontrar o equilíbrio ideal entre as áreas de TI e Negócio;
• Gerenciar todos os recursos necessários para entregar e sustentar os serviços.
Para o sucesso desses objetivos, além das fases anteriores, a operação do serviço é
dividida em cinco grandes processos e quatro importantes funções:
Processos:
31
1. Gerenciamento de Eventos;
2. Gerenciamento de Incidentes;
3. Gerenciamento de Problema;
4. Cumprimento de Requisições;
5. Gerenciamento de Acesso.
Funções:
1. Central de Serviços;
2. Gerenciamento Técnico;
3. Gerenciamento da Aplicação;
4. Gerenciamento das Operações de TI.
Segue a descrição desses itens nos próximos capítulos descritos a seguir.
3.2.4.1 Gerenciamento de Eventos
Para compreender esse processo é necessário primeiramente entender o significado de um
evento, que pode ser traduzido como qualquer ocorrência detectável e discernível que tenha
significado para o gerenciamento da infraestrutura de TI ou a entrega de serviço de TI (OGC,
2007e). Os objetivos desse processo são:
• Monitorar tudo que pode influenciar na entrega de um serviço: para se ter
uma operação de serviço proativa e eficiente é necessário ter conhecimento da
situação dos serviços em tempo real e caso algum serviço saia do seu
funcionamento normal a ferramenta de monitoramento deve tomar uma atitude o
quanto antes, pois somente assim é possível ser proativo na solução de um
“possível” incidente.
• Gerar e detectar notificações, examina-las e processar a ação correta: além
de monitorar é necessário se analisar e executar o procedimento especificado a
fim de evitar o impacto ao serviço.
Os eventos são classificados nas seguintes categorias:
32
• Informativo: apenas mensagens com informações que não impactam no serviço
podem ser qualificadas como mensagens informativas ou de operação regular;
• Alerta: mensagens avisando que algum serviço está executando de forma anormal,
mas ainda está em funcionamento, operação usual;
• Exceção: alerta sobre uma anormalidade mais grave no serviço que pode ter
prejudicado o seu correto funcionamento.
Na figura 4 que segue é possível visualizar o fluxo de gerenciamento do evento.
Figura 4 - Fluxo de Gerenciamento de Eventos (OGC, 2007e).
33
3.2.4.2 Gerenciamento de Incidentes
Um incidente é uma interrupção não planejada de um serviço de TI ou uma redução da
qualidade de um serviço de TI. Falha de um item de configuração que ainda não tenha
impactado um serviço de TI é também um incidente (OGC, 2007e). A grande missão do
gerenciamento de incidentes é de minimizar o máximo possível o impacto ao cliente
corrigindo os incidentes o mais rápido possível, garantindo a qualidade do serviço.
Para que se consiga o objetivo descrito, segue a ilustração que apresenta todo o fluxo do
gerenciamento de um incidente:
34
Figura 5 - Fluxo do Gerenciamento de Incidentes (OGC, 2007e).
35
De acordo com a imagem (Figura 5) apresentada segue uma breve explicação das
atividades executadas:
• Identificação (Incident Identification): esse é o primeiro passo do fluxo,
somente quando a certeza de que se tem um incidente é que pode se iniciar o
processo;
• Registro (Incident Logging): é necessário ter um local onde são registrados todos
os incidentes com todas as informações relevantes para facilitar a correção do
mesmo;
• Categorização (Incident Categorization): todos os incidentes devem estar
classificados em uma categoria;
• Priorização (Incident Priorization): todo o incidente deve ter uma avaliação de
impacto versus urgência e dessa analise deve ser dado um código de prioridade
para cada incidente;
• Diagnóstico (Initial Diagnosis): é realizada uma avaliação inicial do incidente
em uma primeira tentativa de se descobrir a origem da falha e de se tentar corrigi-
la. Normalmente essa avaliação inicial é realizada pela central de serviços
(primeiro nível);
• Escalação (Escalation): caso no primeiro diagnóstico se conclua que a equipe de
central de serviços não está apta para resolver a requisição essa deve ser escalada
rapidamente para outro nível de suporte com maior capacidade para soluciona-lo;
• Investigação e diagnóstico (Investigation & Diagnosis): complementa demais
informações da requisição determinando sua natureza;
• Resolução e recuperação (Resolution and Recovery): encontra uma solução, o
incidente é corrigido e testado;
• Fechamento (Incident Closure): o incidente deve ter suas informações revisadas,
assim evitando erros de categorização. Essa etapa deve ser executada pela central
de serviços que, além disso, deve documentar o incidente e executar o processo de
encerramento do incidente.
36
3.2.4.3 Gerenciamento de Problemas
Um problema é a causa raiz de um ou mais incidentes. A causa geralmente não é
conhecida no momento em que o registro de problema é criado e o processo do gerenciamento
de problemas é responsável pela investigação adicional. O principal objetivo do
gerenciamento de problemas é de prevenir a ocorrência de incidentes minimizando o impacto
para o cliente (OGC, 2007e).
Um gerenciamento de problemas bem estruturado pode representar um grande ganho nos
serviços prestados, pois pode ser considerado um processo de melhoria contínua do serviço.
De acordo com sua proposta a cada problema corrigido são eliminados alguns incidentes que
ocorrem com certa frequência e aqui pode se perceber claramente a importância da
documentação dos incidentes, pois somente com informações bem organizadas e completas
pode se encontrar um problema.
Apenas para o melhor entendimento desse processo segue uma ilustração de seu fluxo,
sendo que, seu fluxo é muito parecido com o que foi apresentado na Figura 5.
37
Figura 6 - Fluxo do Gerenciamento de Problemas (OGC, 2007e).
38
Como alguns processos desse fluxo foram apresentados na seção anterior, serão descritos
apenas processos não vistos anteriormente.
• Solução de contorno (Workaround): este processo tem a finalidade de resolver o
incidente com uma solução de contorno enquanto ainda não se tem a solução final
do problema;
• Erro conhecido (Known error): como o próprio nome diz, o erro conhecido é
todo o problema na qual já possui sua causa raiz ou solução de contorno
documentado.
3.2.4.4 Cumprimento de Requisições
Uma requisição de serviço pode ser traduzida como uma solicitação de um usuário para
alguma informação, dúvida, sugestão, para uma mudança de rotina ou acesso a um serviço de
TI. Normalmente é o nome dado as demandas de um departamento de TI. Geralmente é
tratada pela central de serviço (OGC, 2007e).
Seus objetivos são (OGC, 2007e):
• Oferecer aos usuários um canal no qual eles possam requisitar e receber serviços;
• Fornecer aos usuários e clientes informações sobre a disponibilidade dos serviços
e procedimentos para obter estes serviços;
• Fornecer componentes de serviços-padrão (licença de software);
• Auxiliar em informações gerais, questionamentos e reclamações.
Analisando seus objetivos fica evidente a importância deste conceito, pois o usuário
somente pode requisitar uma demanda se existir um canal de comunicação entre o usuário e a
central de serviço. Logo, é necessário que se tenha um procedimento padrão para requisitar
serviços. As atividades desse processo são simples, porém fundamentais.
3.2.4.5 Gerenciamento de Acesso
É o processo responsável por permitir usuários a utilizarem um serviço de TI, dados ou
outros ativos. Gerenciamento de Acesso ajuda a proteger a confidencialidade, integridade e
disponibilidade de ativos através da garantia que apenas usuários autorizados sejam capazes
39
de acessar ou modificar os ativos (OGC, 2007e). Seu principal objetivo é fornecer aos
usuários o direito de utilizar um serviço, mas de recusar o acesso a usuários não autorizados.
Nesse processo é fundamental se ter em mãos a política de segurança da instituição,
somente com essa política bem definida é possível executar esse processo, logo esse método
deve ser planejado e criado durante a fase de desenho de serviço e testado durante a fase de
transição de serviço.
3.2.4.6 Central de Serviços
Central de serviços é considerada uma das funções do processo de gerenciamento de
incidentes, sua responsabilidade é servir como ponto único de contato entre o provedor de
serviços e o usuário, tendo a responsabilidade de gerenciar incidentes, requisições de serviço e
também a comunicação com os usuários (OGC, 2007e).
Também chamada de primeiro nível de atendimento, a central de serviços tem uma
função muito especial nesse processo, pois ela que, vai manter o contato com o usuário, zelar
pelas informações, corrigir requisições de primeiro nível e ter o conhecimento para escalar as
requisições para as equipes corretas, assim, maximizando o a velocidade da solução da
requisição.
Para essa função é fundamental que se tenha uma base de conhecimento bem completa e
simples de se utilizar, pois desta forma a central de serviços pode resolver um número de
requisições maior ainda. As principais atividades de uma central de serviços são:
• Cadastrar requisições importantes, categorizando-as e priorizando-as;
• Realizar um suporte de primeiro nível;
• Ter a habilidade de escalar as requisições para equipes especialistas;
• Monitorar a evolução das requisições;
• Solucionar incidentes quando tiver o conhecimento necessário;
• Manter os usuários informados em relação as suas solicitações;
• Encerra as requisições concluídas;
• Monitorar a satisfação dos usuários.
Para a execução dessas atividades a central de serviços pode ser de quatro tipos:
• Local: esse tipo de central de serviço fica alocada na própria unidade onde o
atendimento deve ser fornecido.
40
• Centralizada: esse modelo a equipe deve ficar centralizada em um única
unidade, podendo atender vários outros locais, entretanto as informação ficam
centralizadas em um único local;
• Virtual: pode-se ter uma ferramenta onde todas as requisições são cadastradas ter
equipes de atendimento em qualquer parte do mundo atendendo essas requisições;
• Siga o sol: é realizado um acordo entre as centrais de serviço através dos fusos
horários de cada uma. Sendo que cada central trabalha de acordo com o horário
comercial de seu país, dessa forma sempre que houver a luz do dia uma equipe vai
trabalhar e dessa forma garantindo um atendimento 24 horas.
3.2.4.7 Gerenciamento Técnico
Função responsável por manter e capacitar recursos necessários para prestar o melhor
suporte possível aos serviços de TI disponibilizados, sendo que, as decisões técnicas passam
por sua avaliação e decisão, como por exemplo, as ferramentas que devem ser utilizadas e as
equipes que devem ser montadas. Alguns de seus objetivos são (OGC, 2007e):
• Ajudar a planejar, implementar e manter estável a infraestrutura para apoiar o
negócio na organização dos processos;
• Uso adequado das competências técnicas para manter a infraestrutura em
condições ideias;
• Uso adequado das competências técnicas para solucionar o mais rápido possível
os incidentes que venham a ocorrer.
3.2.4.8 Gerenciamento da Aplicação
Essa função tem a responsabilidade de suportar e manter os aplicativos em seu correto
funcionamento durante todo o seu ciclo de vida, desde sua concepção até após sua
implantação conforme se pode visualizar na figura 7 que segue.
41
Figura 7 - Responsabilidades Gerenciamento de Aplicações (OGC, 2007e).
Seus principais objetivos são (OGC, 2007e):
• Suportar os processos de negócio da organização ajudando a identificar requisitos
funcionais para as aplicações;
• Implantação de aplicações;
• Suporte contínuo e melhoria desses aplicativos.
3.2.4.9 Gerenciamento das Operações de TI
Essa função tem a responsabilidade de controlar o dia a dia das atividades necessárias
para o gerenciamento dos serviços e da infraestrutura relacionada. Acumula também as
funções controlar as operações e gerenciar as instalações (OGC, 2007e).
O grande desafio desse papel é de encontrar um processo que chegue a um equilíbrio que
garanta o melhor serviço a um baixo custo, pois é nesse momento que o cliente vai visualizar
o valor do serviço, logo a qualidade do serviço fornecido é fundamental, porém ter qualidade
a baixo custo não é um simples. No próximo capítulo será explicado a ultima fase do ciclo de
vida da ITIL v3.
42
3.2.5 Melhoria Contínua de Processo (Continual Process Improvement)
A melhoria contínua de processo está relacionada em todas as fases de seu ciclo de vida.
A grande finalidade disto é de se identificar melhorias em qualquer uma das fases do
processo, sendo que sua responsabilidade é de gerenciar essas melhorias.
Para isso é necessário ter indicadores que forneçam a real situação do provedor de
serviços, com essas métricas deve ser possível entender o que está funcionando corretamente
e o que não está funcionando da forma esperada e com base nessa análise planejar novos
processos para melhorar o serviço. Seus principais objetivos são (OGC, 2007f):
• Encontrar e desenvolver melhorias;
• Monitorar continuamente os indicadores para assim descobrir maneiras de
melhorar a eficiência e eficácia do serviço entregue;
• Estar sempre alinhado com as estratégias da organização para não fugir do foco
da área de negócio.
A ITIL v3 sugere o seguinte modelo para melhoria contínua:
43
Figura 8- Modelo de Melhoria Contínua de Processo (OGC, 2007f).
Executando o processo apresentado na figura acima (Figura 8) com a frequência
necessária é possível melhorar o serviço continuamente. Ainda analisando esse processo é
possível perceber, conforme comentado anteriormente, a importância de ser medir para assim
poder controlar, pois somente controlando é possível gerenciar. Segundo ITIL v3 existem
quatro razões para se monitorar e medir (OGC, 2007f):
44
Figura 9 - Quatro Razões para Monitorar e Medir (OGC, 2007f).
• Para validar (To Validate): a única forma que se tem para verificar se o
processo está funcionando de acordo com o que é esperado se passa pela
validação de métricas e baseado nessa validação pode se entender se está sendo
realizado o que foi definido ou não, assim validando decisões prévias;
• Para direcionar (To Direct): somente assim se pode dar direção ao trabalho que
se deseja realizar, verificando o que é necessário mudar para se atingir as metas;
• Para justificar (To Justify): somente com dados ou evidências se pode justificar
a necessidade de uma mudança ou o motivo de um acerto;
• Para intervir ( To Intervene): tomar uma atitude no momento certo.
Existem diversas técnicas para aplicação de melhoria contínua, sendo que, as
organizações estão em busca constante de um diferencial competitivo e para isso precisam
estar em frequente adaptação com o objetivo de melhorar sempre que possível.
3.3 Gestão Ágil de Projetos
Com o passar dos anos e as constantes evoluções da TI, que acabou ajudando muito no
processo de globalização, o mundo começa a ter mais necessidades, as mudanças são mais
frequentes e quem responder mais rapidamente a elas deve se manter vivo nesse novo mundo.
Os projetos de TI, em sua maioria, não são finalizados dentro dos prazos estipulados se
45
apresentam cada vez mais instáveis e o cliente muitas vezes não sabe o que realmente deseja,
ou não tem tempo e nem capacidade para definir de forma clara o seu pedido.
Tendo em vista essa nova realidade, no dia 13 de novembro de 2001, um grupo de
profissionais da área de TI (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron
Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland e Dave Thomas) se reuniu para discutir como se poderia melhorar o desempenho
dos projetos de desenvolvimento de software (BECK, 2001). A partir desse encontro nasceu o
Manifesto Ágil, onde, os seguintes valores deveriam ser valorizados:
• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.
Percebe-se claramente a nova visão que esse grupo teve e que vem agregando muito em
diversas organizações de TI e seus clientes, demonstra-se uma evidente preocupação tanto
com o cliente, em lhe entregar um produto útil que vá agregar valor ao seu negócio e quanto
com a organização de TI em se entregar projetos no prazo, principalmente, respondendo a
mudanças da melhor forma possível, desta forma, é necessário que as empresas tenham
capacidade de se adaptar rapidamente as mudanças e isso é ser “ágil”. Por trás destes quatro
itens do manifesto ágil existem os seguintes princípios (BECK, 2001):
• Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e
contínua de software de valor;
• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos
ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens
competitivas;
• Entregar software funcionando com frequência, na escala de semanas até meses,
com preferência aos períodos mais curtos;
• Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto
e diariamente, durante todo o curso do projeto;
46
• Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e
suporte necessário, e confiar que farão seu trabalho;
• O método mais eficiente e eficaz de transmitir informações para, e por dentro de
um time de desenvolvimento, é através de uma conversa cara a cara;
• Software funcional é a medida primária de progresso;
• Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos
constantes;
• Contínua atenção a excelência técnica e bom design aumenta a agilidade;
• Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser
feito;
• As melhores arquiteturas, requisitos e designs emergem de times auto-
organizáveis;
• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se
ajustam e aperfeiçoam seu comportamento de acordo.
A partir da visão desses dezessete profissionais da área de TI começaram a surgir
algumas metodologias com o objetivo de sustentar esses valores, pois até então só se tinha a
ideia, mas como fazer isso tudo funcionar? Por esse motivo começaram a aparecer alguns
frameworks interessantes, tais como:
1. XP (Extreme Programming);
2. Scrum;
3. Lean;
4. Kanban;
5. DSDM (Dynamic Software Development Method);
6. FDD (Feature Driven Development);
7. OpenUP;
8. Crystal.
Como pode se verificar foram criados diversos frameworks para auxiliar na construção de
uma equipe ágil, entretanto, este trabalho vai abordar, nos próximos capítulos, apenas alguns
desses itens que serão utilizados no desenvolvimento deste.
47
3.3.1 Scrum
Um dos frameworks mais utilizados para métodos ágeis, Scrum, concebido por Ken
Schwaber e Jeff Sutherland, foi criado com o objetivo de desenvolver e manter produtos
complexos, sua definição consiste em papéis, eventos, artefatos e regras, sendo que, não deve
ser considerado um processo ou uma técnica e sim uma ferramenta onde você pode empregar
vários processos e técnicas (SCHWABER, 2011).
Talvez um dos pontos mais intrigantes desse método é que ele é muito leve e simples de
entender, entretanto é extremamente difícil de dominar, pois depende de pessoas, padrões
culturais da empresa, quebra de alguns paradigmas entre outros.
Toda a teoria do Scrum é fundamentada, baseada em teorias empíricas, em três pilares de
sustentação:
• Transparência: todos os resultados ou definições da equipe devem sempre ser
visíveis por todos os envolvidos;
• Inspeção: os envolvidos devem frequentemente inspecionar os artefatos do
Scrum, para avaliar se os resultados estão alinhados com os objetivos, assim
avaliando os riscos;
• Adaptação: basicamente pilar fundamental para execução de um processo de
melhoria contínua, os resultados devem ser analisados e debatidos pela equipe, os
pontos negativos devem ser adaptados para que não ocorram novamente.
Para a correta execução destes valores o Scrum sugere os seguintes papéis:
• Product Owner: é o responsável por maximizar o valor do produto e do trabalho
da equipe de desenvolvimento. Para isso essa função deve gerencia o artefato de
backlog do produto priorizando os itens com o objetivo de alcançar as metas
definidas;
• Scrum Master: exerce a função de liderança servidora, deve atender o time de
scrum, sendo que tem a responsabilidade de garantir que o Scrum seja aplicado e
entendido;
48
• Equipe de Desenvolvimento: time responsável por desenvolver o produto de
maneira incremental agregando valor para o cliente, sendo que essas equipes
devem ter a capacidade de se auto-organizarem além de serem multifuncionais.
Um ponto fundamental do Scrum é o conceito de equipe que deve ser seguido,
principalmente quando se refere a equipes multifuncionais onde não existem
responsabilidades individuais e sim papéis, sendo que, a responsabilidade é a mesma para
toda equipe. Por exemplo, em uma equipe de futebol de campo tem 11 atletas com papéis
diferentes, mas todos tem a responsabilidade de vencer o jogo. Por esse motivo o framework
foi chamado de Scrum, pois é o mesmo nome dado a uma jogada de Rugby onde oito
jogadores de cada time devem se unir com o objetivo de formar uma muralha sendo essencial
o trabalho em equipe para o sucesso da jogada. O Time Scrum é formado por todas essas
funções descritas acima (Product Owner, Scrum Master e Equipe de Desenvolvimento), esse
modelo de equipe e suas características são projetados para incentivar a flexibilidade,
criatividade e produtividade.
O Scrum é composto dos seguintes eventos sendo que esses devem ter um tempo máximo
de duração, onde deve ser inspecionado o trabalho realizado e adaptado caso necessário:
• Sprint: é o período necessário para se entregar uma versão de software
incremental potencialmente utilizável do produto, esse período pode ser de um
mês ou menos. Pode ser considerado o núcleo deste framework, pois é nesse
período onde são executados os eventos como reunião de planejamento da sprint,
reunião diária, revisão da sprint e retrospectiva da sprint, conforme descrito
abaixo;
• Reunião de Planejamento da Sprint: essa é a primeira reunião realizada na
sprint, pois é a partir desta que a equipe vai planejar o que deve ser feito na sprint,
basicamente a equipe define o que fazer e como vai fazer;
• Reunião Diária: esta deve ser realizada diariamente em pé com duração máxima
de 15 minutos, onde cada membro da equipe deve responder o que fez desde a
última reunião, o que vai fazer até a próxima reunião e se tem algum impedimento
no seu trabalho. Esse encontro oportuniza a equipe avaliar os riscos diariamente
possibilitando a tomada de decisões imediatas;
49
• Revisão da Sprint: executada sempre ao final de uma sprint com objetivo de se
apresentar para as partes interessadas o trabalho realizado;
• Retrospectiva da Sprint: é uma das cerimônias mais importantes em relação ao
pilar de adaptação, relatado anteriormente, pois é nesse momento que a equipe faz
uma análise de seus pontos negativos e como fazer para melhora-los, criando um
plano de ação para sua adaptação.
Figura 10 - Framework Scrum (Ken Schwaber e Jeff Sutherland, 2011).
A figura anterior expressa à ordem de execução do framework descrito. Para melhor
controlar os resultados o Scrum nos apresenta ainda alguns artefatos que garantem de certa
forma a transparência do trabalho realizado possibilitando assim a inspeção e adaptação
baseado nesses, para assim melhor alcançar os objetivos. Os artefatos são:
• Backlog do Produto: deve ser uma lista de itens de tudo que for necessário para
construção do produto, sendo que o responsável por controlar e, principalmente,
priorizar essa relação é o product owner;
• Backlog da Sprint: é a relação de itens selecionados do backlog do produto para
entrarem na sprint, sendo que a responsabilidade desses é da equipe de
desenvolvimento.
50
Ambos os artefatos podem ser acompanhados por gráficos de burndown ou burnup, são
práticas muito utilizadas que facilitam o acompanhamento e aumentam ainda mais a
transparência por facilitar a visualização.
3.3.2 XP (Extreme Programming)
O XP foi criado baseado nos valores do manifesto ágil, relatado no capítulo anterior,
sendo que, foi utilizada pela primeira vez em um projeto que se iniciou no dia 6 de março de
1996 chamado de C3 (Chrysler Comprehensive Compensation) da Chrysler. O resultado não
poderia ter sido melhor incentivou a criatividade e consequentemente a inovação. Kent Beck,
Wrad Cunningham e Ron Jeffries são os idealizadores desta metodologia, vira a necessidade
de se mudar para se atingir os objetivos, exploraram ao máximo as práticas de
desenvolvimento de software, chegando assim no XP (BECK, 2009). Essa prática apresenta
cinco principais valores:
• Feedback: em consequência da alta frequência de comunicação com o cliente,
tem-se feedbacks em um curto espaço de tempo, além disso, é fundamental ter
uma forma de se ter feedback de tudo que é feito, não apenas do cliente;
• Comunicação: dar preferência para conversas pessoais, evitando outros meios de
comunicação, pois quanto mais eficiente e eficaz for à comunicação melhor será o
resultado;
• Simplicidade: codificar de forma simples, minimizando a criação de classes
complexas. Fazer somente o que for estritamente necessário;
• Coragem: esse talvez seja o principio mais importante e mais difícil, pois esse se
refere a características pessoais dos membros da equipe no que se refere à
coragem de se comunicar quando necessário, de ser simples quando for preciso e
de garantir a frequência do feedback do cliente;
• Respeito: esse valor pode ser considerado a maturidade da equipe, que para
execução dessa metodologia se torna essencial, se o time não tem respeito um
pelo outro, não é possível garantir os demais princípios.
Com base nesses valores nasceram diversas práticas para aperfeiçoar o desenvolvimento
de software, entre elas:
51
• Integração Contínua: garantir que o código fonte da aplicação está consistente
após alterações, normalmente executado diariamente, afim de, encontrar erros o
mais rápido possível, nesse momento, além de atualizar os ambientes, deve ser
executado a bateria de testes automatizados e testes unitários;
• Ambiente Informativo: o local de trabalho da equipe deve expressar claramente
a situação do projeto, de forma, que uma pessoa de outra equipe consiga entender
rapidamente aprimorando assim a comunicação, como no exemplo apresentado na
figura abaixo:
Figura 11 - Exemplo de Ambiente Informativo (KNIBERG, 2004).
• Folga: nunca planejar pensando em 100% do tempo da equipe, a ideia é reservar
um tempo para riscos evitando assim eventuais atrasos.
É importante ressaltar que neste trabalho não será abordado todas as práticas do XP, por
esse motivo, acima foi descrito apenas o que fará parte de seu desenvolvimento. No próximo
capítulo será relatada a metodologia Kanban que apresenta uma relação com a prática de
Ambiente Informativo, visto recentemente.
52
3.3.3 Kanban
O Kanban teve origem na década de 50 logo após a segunda guerra mundial, fazendo
parte do STP (Sistema Toyota de Produção) ou Lean (Lean Production System) que foi criado
visando principalmente à eliminação de desperdícios e redução de estoque. Foi utilizado pela
primeira vez por David Anderson com a colaboração de Don Reinertsen que se esforçaram
muito para ampliar o conhecimento do Lean (BOEG, 2011). O termo Kanban significa
“quadro visual” ou “cartão visual” apresentando apenas duas restrições, como o próprio
nome diz, deve-se visualizar o fluxo de trabalho e as atividades em andamento devem ter
limites definidos.
O mais interessante deste método é que em um primeiro momento pergunta-se “O que
realmente um quadro de tarefas pode mudar no desempenho, cultura, capacidade e maturidade
de uma equipe?”. Mesmo parecendo uma mudança pequena o Kanban causa uma grande
mudança na organização.
Normalmente as equipes ágeis tem utilizado um quadro branco com as suas fases e
atividades lançadas neste, isso alavanca a transparência do trabalho realizado iniciando um
processo de mudança cultural.
Figura 12 - Exemplo de Kanban (RASMUSSON, 2010).
Na figura acima pode se ver um exemplo de Kanban, dividido em fases e com seus
limites definidos dando transparência ao processo e seu fluxo, assim expondo gargalos, filas,
variabilidade e desperdícios. Com essa exposição todos tem a oportunidade de visualizar o
53
trabalho realizado e tomar alguma ação caso o resultado não esteja de acordo com os
objetivos, ou seja, o método incentiva a colaboração de todos os envolvidos, podendo surgir
melhorias no processo iniciando assim uma proposta de melhoria contínua.
3.4 Síntese da Fundamentação Teórica
Esta seção tem o objetivo de apresentar um resumo do que foi descrito na fundamentação
teórica deste trabalho, sendo citados os itens mais relevantes para o desenvolvimento do
trabalho.
No estudo realizado foram analisadas três grandes áreas de conhecimento bem
conceituadas na área de TI:
• PMBOK: o guia de estudos PMBOK foi analisado com foco na área de
gerenciamento de projetos, onde se entendeu que mesmo em serviços
operacionais existem diversos pequenos projetos com início, meio e fim,
justificando a estudo deste guia. Esta seção abordou resumidamente os cinco
grupos de processos (Iniciação, Planejamento, Execução, Monitoramento e
Controle, e Encerramento) que contemplam a atividade de gestão e bem como
suas 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 de qualidade do projeto,
gerenciamento de recursos humanos do projeto, gerenciamento de comunicações
do projeto, gerenciamento de riscos do projeto e gerenciamento de aquisições do
projeto);
• ITIL v3: foi realizado um estudo nos cinco livros da biblioteca que contempla a
terceira versão da ITIL que é utilizada como referência de boas práticas na área de
gerenciamento de serviços, sendo esta dividida em cinco grandes fases: estratégia
de serviço, desenho de serviço, transição de serviço, operação de serviço e
melhoria continua de processo. Como o foco do trabalho será na fase de operação
de serviço, foi nesta fase onde houve um maior detalhamento de seus processos
sendo que a fase de operação de serviço conta com cinco processos e quatro
funções:
54
o Gerenciamento de Eventos: monitora tudo que possa influenciar na
entrega de um serviço para, no caso de algum evento, executar a ação
correta;
o Gerenciamento de Incidentes: deve corrigir falhas o mais rápido possível
minimizando o impacto ao cliente;
o Gerenciamento de Problemas: problema é a causa raiz de vários
incidentes, sua correção é fundamental para minimizar o número de
incidentes;
o Cumprimento de Requisições: seu principal objetivo é oferecer aos
usuários um canal de comunicação com a central de serviço;
o Central de Serviços: ponto único de contato entre o provedor de serviços
e o usuário;
o Gerenciamento Técnico: manter e capacitar recursos necessários para
prestar o melhor suporte possível aos serviços de TI disponibilizados;
o Gerenciamento da Aplicação: suportar e manter os aplicativos em seu
correto funcionamento durante todo o seu ciclo de vida;
o Gerenciamento das Operações de TI: controlar o dia a dia das atividades
necessárias para o gerenciamento dos serviços e da infraestrutura
relacionada além de controlar as operações e gerenciar as instalações.
• Práticas Ágeis: foram analisadas varias práticas ágeis, movimento esse que teve
início em novembro de 2001, onde dezessete profissionais da área de TI se
encontraram e criaram o Manifesto Ágil (BECKER, 2001) onde constava um
conjunto de valores essenciais para o sucesso de seus projetos (Indivíduos e
interação entre eles mais que processos e ferramentas, Software em
funcionamento mais que documentação abrangente, Colaboração com o cliente
mais que negociação de contratos, Responder a mudanças mais que seguir um
plano). Baseado nesses valores nasceu uma série de metodologias, entretanto este
trabalho vai focar apenas em três delas:
o Scrum: framework criado por Ken Schwaber e Jeff Sutherland, composto
de papéis (Product Owner, Scrum Marter, Equipe de Desenvolvimento),
eventos (Sprint, Planejamento da Sprint, Reunião Diária, Revisão da
Sprint e Retrospectiva da Sprint), artefatos (Backlog do Produto e Backlog
55
da Sprint) e regras sendo baseado em três grandes pilares: transparência;
inspeção; adaptação.
o XP (Extreme Programming): Kent Beck, Wrad Cunningham e Ron
Jeffries são os idealizadores desta metodologia sendo baseada em cinco
grandes valores: Feedback; Comunicação; Simplicidade, Coragem e
Respeito. Possui diversas práticas, porém foram citadas apenas as que
serão utilizadas no desenvolvimento deste trabalho, como por exemplo:
� Integração Contínua: garante que o código fonte da aplicação
está consistente após alterações;
� Ambiente Informativo: garante que o local de trabalho da equipe
expressa claramente a situação do projeto;
� Folga: nunca planejar pensando em 100% do tempo da equipe,
sempre deve ser reservado um espaço para riscos.
o Kanban: criado na década de 50 visa principalmente eliminar desperdícios
e reduzir estoque. Fornece transparência ao processo e seu fluxo expondo
gargalos, filas, variabilidade e desperdícios.
Após o resumo da fundamentação teórica, o próximo capítulo da inicio a fase seguinte
definida no método de pesquisa (figura 1) chamada de Avaliação Inicial, onde será realizada
uma avaliação do contexto atual do Projeto AGHU.
56
4 AVALIAÇÃO INICIAL
Para melhor avaliar o resultado da proposta da metodologia que será desenvolvida é
necessário entender o contexto e a realidade do cenário atual, pois somente assim é possível
fazer um comparativo da situação anterior e posterior à implantação do processo. Além disso,
não seria possível elaborar um processo que realmente agregue valor sem antes entender o
cenário atual, o ambiente, o projeto e outros fatores que são fundamentais para a melhor
utilização das boas práticas.
4.1 Projeto AGHU
Conforme comentado anteriormente, este trabalho será desenvolvido em um projeto
piloto chamado de AGHU, que teve origem após uma apresentação do primeiro relatório do
REHUF, onde o TCU determinou a criação de um modelo de gestão para a rede de hospitais
universitários federais. É nesse contexto, que o projeto AGHU foi criado com o objetivo de
“criar soluções perenes e concretas construídas a partir da participação ativa de todos
os atores” Dessa forma, o projeto AGHU ganhou duas grandes frentes de trabalho (MEC,
2009):
• Definição de um modelo de gestão que possa ser adotado por todos os HUF;
• Criação de um software capaz de apoiar esse modelo de gestão.
Depois de um grande trabalho de avaliação de vários hospitais no intuito de se escolher o
HUF que possuía o melhor modelo de gestão, o MEC indicou o HCPA como hospital modelo
e a partir disto se iniciou o trabalho migração de tecnologia do sistema antigo utilizado no
HCPA para tecnologias mais recentes e em software livre, para que este novo software não
tivesse custo para os HUF.
O Projeto AGHU acabou se tornando uma parceria entre o MEC e o HCPA que visa
disseminar o modelo de gestão hospitalar adotado por este hospital para os outros hospitais
universitários federais. Esse modelo é acoplado a um sistema, chamado AGH (Aplicativo de
Gestão Hospitalar), o que torna inviável transferir o modelo de gestão hospitalar sem
transferir também o software.
O sistema AGH é um software desenvolvido para suportar os processos assistenciais e
administrativos do HCPA. Utilizado por médicos, enfermeiras, demais profissionais de saúde,
57
administrativos e alunos. O sistema é composto de módulos totalmente integrados que
contemplam a identificação do paciente, atendimento ambulatorial e de emergência, serviços
auxiliares de diagnóstico e terapia, internação, prescrição, exames, cirurgias e outros. Além
destas aplicações, o sistema contempla ainda módulos administrativos, tais como estoque,
compras, faturamento e recursos humanos, completando desta forma as necessidades de apoio
aos processos da instituição. Abaixo é possível visualizar o escopo completo do aplicativo.
Figura 13 - Escopo Completo do AGHU (MEC, 2009).
O AGHU deve ser implantado nos 46 hospitais universitários do Brasil, hoje o aplicativo
está instalado em oito HUF’s.
4.2 Descrição do Ambiente
Nesta seção será apresentada a estrutura e de que forma se organiza o Projeto AGHU,
sendo que, inicialmente será apresentada a estrutura do projeto, como está dividido e
organizado e após será descrita a estrutura da equipe de operação que é o foco deste trabalho.
58
4.2.1 Estrutura do Projeto AGHU
O Projeto AGHU teve seu objetivo geral definido em reunião realizada em Brasília, no
dia 21 de maio de 2009 onde estavam presentes representantes do HCPA, da Diretoria de
Tecnologia da Informação do Ministério da Educação, da Coordenação dos HUF’s do
Secretário Executivo do MEC:
“Propiciar a transferência de tecnologia necessária à implantação do sistema
informatizado de gestão hospitalar (AGH) desenvolvido pelo HCPA fortalecendo as
melhores práticas de gestão nos Hospitais Universitários Federais do Ministério da
Educação.”
Este projeto busca, principalmente, a padronização de práticas administrativas e
assistenciais de todos os HUF’s, assim, será possível aperfeiçoar processos assistenciais e
administrativos através de benchmarks entre hospitais universitários, oportunizando uma
discussão em busca de novas ideias e sugestão de melhorias de forma a disseminar as
melhores práticas em todos os HUF’s do Brasil. Para atingir esse desejo o projeto apresenta
alguns objetivos específicos que seguem:
• Criar uma estrutura de desenvolvimento colaborativa de forma a permitir que equipes
de diferentes hospitais universitários possam aderir ao desenvolvimento;
• Desenvolver uma ferramenta de gestão hospitalar tecnicamente simples e passível de
ser implantada em qualquer HUF brasileiro;
• Desenvolver uma ferramenta de gestão hospitalar financeiramente viável e passível de
ser implantada em qualquer HUF brasileiro;
• Criar metodologia de dimensionamento de recursos computacionais exigidos para
executar o AGHU dentro de um hospital;
• Servir de instrumento para disseminar e evoluir a gestão hospitalar nos HUF’s,
propiciando melhorias consideráveis na Assistência, Ensino e Pesquisa nestas
instituições.
Por se tratar de um projeto de âmbito nacional possui como principais responsáveis:
59
Órgãos Proponentes MEC – Ministério da Educação
HCPA – Hospital de Clínicas de Porto Alegre
Patrocinadores Secretário Executivo - MEC
Diretor de Tecnologia da Informação - MEC
Presidente - HCPA
Facilitadores Chefe do Serviço e Suporte a Projetos - HCPA
Chefe do Serviço de Suporte à Rede – HCPA
Coordenadores do Projeto Assessor da Presidência – HCPA
Gerente de Executivo AGHU – MEC
Tabela 1 - Responsáveis no Projeto AGHU.
O projeto é organizado de acordo com o organograma que pode ser visualizado a seguir.
Figura 14 - Estrutura Organizacional (MEC, 2009).
60
Baseado nas prioridades que o Comitê Gestor define, as equipes realizam seu trabalho
sendo que suas responsabilidades estão divididas da seguinte forma:
• Time de Mapeamento de Processos: realiza todo o mapeamento de processos do
HCPA, integrado com uma visão nacional, tornando-o mais genérico para que esteja
de acordo com os demais HUF’s, com base nesse mapeamento, a equipe cria as
estórias de usuário para que as equipes de desenvolvimento possam planejar seu
trabalho;
• Time de Desenvolvimento: responsável por migrar o código escrito em tecnologia
antiga (AGH) para nova tecnologia (AGHU);
• Time de Qualidade: deve garantir a qualidade do software AGHU;
• Time de Arquitetura: construir e manter a arquitetura de software do sistema AGHU;
• Time de Infraestrutura: fornecer e manter toda a infraestrutura necessária para o
projeto AGHU;
• Time de Integração: responsável por trabalhos de integração de dados;
• Consultores: fornecem apoio as equipes em relação as regras de negócio do sistema
AGH.
4.2.2 Estrutura da Célula de Serviços de TI
O projeto AGHU possui equipes de operação separadas conforme se pode observar na
figura 14, sendo estruturada basicamente em duas equipes, uma de infraestrutura e outra de
integração, a equipe de infraestrutura está localizada na estrutura do MEC em Brasília e a
equipe de integração fica alocada no HCPA em Porto Alegre.
A equipe de infraestrutura é composta de três membros com habilidades e papéis
equivalentes divididos nos seguintes papéis:
1. Um Líder de Equipe;
2. Dois Analistas de Infraestrutura.
A equipe de integração é composta por cinco membros divididos nos seguintes papéis:
1. Líder de Equipe;
2. Analista de Integração;
61
3. DBA (Database Administrator);
4. Dois Desenvolvedores.
Em ambas as equipes não existem processos de trabalho definidos, as demandas são
atendidas aleatoriamente quando necessário, segue uma relação dos principais pontos fracos
da estrutura atual:
1. Não existe qualquer tipo de documentação de processos, padrões ou de
implantações;
2. A equipe possui o conhecimento interdisciplinar centralizado em seus membros;
3. Não existe controle de mudanças;
4. Não é realizado nenhum planejamento;
5. Não existem metas ou objetivos claros para equipe;
6. Não existe nenhum indicador ou métrica;
7. Os serviços prestados não estão catalogados;
8. Não existe nenhum processo de melhoria contínua aplicado a essas equipes;
9. Distância entre equipe de infraestrutura e integração;
10. A equipe não possui conhecimento de boas práticas de gestão;
11. Ferramenta para cadastro de requisição desatualizada.
Apesar de se ter pontos fracos muito graves, existem também alguns pontos positivos que
seguem:
1. Equipes comprometidas com o projeto;
2. Equipes dispostas a melhorar;
3. Boa comunicação entre os membros;
4. Alta maturidade das equipes;
5. Excelente nível de conhecimento técnico;
6. Possibilidade de novas contratações.
Devido à falta de gerenciamento deste trabalho, as equipes acabam tendo que fazer
constantemente horas extras, pois normalmente todo problema que ainda não possua sua
causa raiz identificada é atribuído a estas equipes. Com a causa raiz identificada a equipe
acaba atuando frequentemente na solução do problema mesmo que não seja de sua
responsabilidade.
62
4.3 Instrumento de Avaliação
O instrumento de avaliação é necessário para que se tenha convicção do sucesso ou
insucesso da aplicação do novo processo, sendo que o mesmo instrumento deve ser aplicado
antes e depois da implantação do processo desenvolvido neste trabalho. Após sua aplicação
serão avaliados seus resultados.
A elaboração deste instrumento foi baseada em dois modelos de maturidade, tais como:
• Morton-Evans (2011): criador do questionário de avaliação de maturidade da
aplicação da ITIL;
• Curt Hibbs (2009): criador do modelo de maturidade chamado de Agile Process
Maturity Model (APMM) onde se determina o nível baseado em dois aspectos:
técnico e gerencial. O aspecto técnico se divide em três níveis: não ágil, mínimo e
consolidado. Enquanto o gerencial é dividido também em três níveis: inicial,
organizado e disciplinado.
Seguindo a ideia desses modelos de maturidade, foi elaborado um instrumento para se
avaliar um processo composto de práticas ITIL e ágeis conforme segue.
Instrumento de Avaliação
1 - Nós sabemos quais são os nossos serviços?
2 - Nós temos funções e processos bem definidos através do ciclo de vida?
3 - Nós temos a possibilidade de mensurar os processos de maneira relevante?
4 - O motivo de existir um processo é entregar um resultado específico?
5 - As metas da Gerência de Serviços estão definidas?
6 - Os objetivos da Gerência de Serviços estão definidos?
7 - O propósito da Gerência de Serviços está definido?
8 - Nós temos um plano de Gerência de Serviços?
9 - Melhorias de serviço e seus benefícios estão claramente definidos?
10 - Nós temos justificativas de Gerência de Serviços para os dirigentes de negócio e
dirigentes de tecnologia?
63
11 - Os benefícios da Gerência de Serviços para a área de negócio e clientes estão
claramente definidos?
12 - Os benefícios da Gerência de Serviços internos à organização de TI estão claramente
definidos?
13 - Nós envolvemos a área de negócio e determinamos seus requerimentos em nível de
serviço?
14 - Nós definimos um portfólio interno de serviços: serviços que estão planejados; em
desenvolvimento e em produção?
15 - Nós definimos um Catálogo de Serviços orientados a clientes que detalha cada serviço
e pacote de serviço oferecido?
16 - Nós identificamos as relações internas do departamento de TI codificando-as em
Acordos em Nível de Operação?
17 - Nós usamos o Catálogo de Serviços como linha de base para negociar os Acordes em
Nível de Serviço com a área de negócio?
18 - Nós criamos um Plano de Melhoria de Serviço para monitorar continuamente e
aprimorar os níveis de serviço?
19 - Papeis e responsabilidades estão claramente definidos?
20 - Gatilhos, entradas e saídas de interface entre os processos estão definidos?
21 - O propósito, meta e objetivo do processo de Implantação estão definidos?
22 - O escopo do processo de implantação está definido?
23 - As políticas, princípios e conceitos básicos para a Implantação estão definidos?
24 - Modelos de implantação estão definidos?
25 - O planejamento de Implantação está gerenciado?
26 - A preparação para a construção, teste e implantação está gerenciada?
27 - A construção e teste estão gerenciados?
28 - Planejamento e preparação para implantação estão gerenciados?
29 - Verificação de implantação está gerenciada?
30 - Revisão e fechamento de implantação estão gerenciados?
31 - O processo de Operação está bem documentado?
32 - Nós temos definidos os princípios, políticas e conceitos básicos do processo de
Operação?
33 - Nós temos definidos os gatilhos, entradas, saídas e interfaces do processo de
64
Operação?
34 - Nós temos definidos os relatórios de gerência de informação do processo de
Operação?
35 - Nós temos definidos os desafios, fatores críticos de sucesso e riscos do processo de
Operação?
36 - Nós monitoramos eventos que possam prejudicar a entrega de nossos serviços?
37 - Existe alguma ação automática, no caso de acontecimento de algum evento, que venha
a prevenir um incidente?
38 - Existe um ponto único onde os usuários possam requisitar serviços?
39 - Existem níveis de serviço bem definidos?
40 - Os incidentes são priorizados baseados em impacto e urgência?
41 - Os incidentes são categorizados?
42 - Existe um processo para gerenciamento de problemas?
43 - Existe um controle de qualidade dos serviços realizados?
44 - É realizada a reunião de planejamento da sprint?
45 - A reunião de planejamento da sprint é realizada em no máximo 25 minutos?
46 - A equipe estima o esforço necessário para o desenvolvimento de uma tarefa?
47 - A equipe seleciona as tarefas que podem ser concluídas dentro da sprint?
48 - São realizadas reuniões diárias?
49 - As reuniões diárias realizadas duram no máximo 10 minutos?
50 - As reuniões diárias são realizadas em pé?
51 - São realizadas reuniões de revisão da sprint?
52 - As reuniões de revisão da sprint duram no máximo 20 minutos?
53 - As reuniões de lições aprendidas são realizadas?
54 - A equipe comenta na reunião de lições aprendidas o que correu bem durante a última
iteração?
55 - A equipe comenta na reunião de lições aprendidas o que não correu tão bem?
56 - A equipe identifica os itens mais importantes ou problemas na reunião de lições
aprendidas para focar na próxima iteração?
57 - O ambiente de trabalho expressa claramente a situação da célula no momento? (o
ambiente é informativo?)
58 - Existe uma visão de risco no planejamento, armazenando uma folga no tempo
65
planejado, não sendo planejado 100% do tempo da equipe?
59 - Existe o processo de integração contínua?
60 - Na integração contínua são executados testes automatizados?
61 - Na integração contínua são executados testes unitários?
62 - Existe integração contínua em ambiente de produção?
63 - Os processos estão devidamente documentados?
64 - As equipes praticam gestão do conhecimento? Não centralizam o conhecimento em
seus membros?
65 - As equipes são autogerenciáveis?
66 - Existe algum processo definido para mudanças?
67 - Existem indicadores ou métricas que permitam avaliação do trabalho realizado?
68 - Existe uma ferramenta para o gerenciamento de serviços?
69 - Nós utilizamos kanban?
70 - Existe transparência entre a equipe do trabalho realizado?
71 - O kanban é dividido em fases e possui limites?
72 - É possível identificar gargalos no kanban utilizado?
Tabela 2 - Instrumento de Avaliação.
O questionário apresentado na tabela 2 visa analisar a maturidade da célula de serviços de
TI em relação ao processo que será desenvolvido, sendo que, o entrevistado poderá respondê-
lo de acordo com os níveis apresentados na tabela 3 que segue.
Grau Descrição
1 - Inicial Processos e atividades são caóticos ou não definidos.
2 - Repetível Processos e atividades básicas são estabelecidos e existe um nível de
disciplina e aderência.
3 - Definido Todos os processos e atividades são definidos, documentados, padronizados
e integrados.
4 - Gerenciado Processos são mensurados através de coleta detalhada de dados e sua
qualidade é melhorada apropriadamente.
5 - Otimizado Melhoria contínua de processos é adotada e atividades e processos são
maduros.
Tabela 3 - Possíveis Respostas para o Instrumento de Avaliação.
66
Na tabela 4 é possível visualizar a relação dos questionamentos do instrumento de
avaliação com as áreas de conhecimento que foram estudadas e devem fazer parte do processo
que será implantado. As informações são relacionadas de acordo com os números das
questões.
Questões Relação
19, 20, 66 PMBOK
1, 5, 6, 7, 14, 21, 22, 23, 24, 32, 35 Estratégia de Serviço
2, 8, 11, 12, 13, 15, 16, 17, 19, 20, 33, 39, 42, 63 Desenho de Serviço
3, 4, 9, 10, 18, 34, 67 Melhoria Contínua de Processo
25, 26, 27, 28, 29, 30, 66 Transição de Serviço
31, 36, 37, 38, 40, 41, 43, 68 Operação de Serviço
44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 64,
65 Scrum
57, 58, 59, 60, 61, 62 XP
69, 70, 71, 72 Kanban
Tabela 4 - Relação do Instrumento de Avaliação com as Áreas Estudadas.
Conforme citado na seção de estrutura da célula de serviços de TI (4.2.2) existem alguns
pontos negativos no trabalho realizado pela equipe atual, sendo que, o instrumento de
avaliação também apresenta o objetivo de analisar alguns desses pontos. Na tabela 4 que
segue é possível visualizar a relação dos questionamentos do instrumento de avaliação com os
pontos negativos citados. As informações são relacionadas de acordo com os números das
questões.
Questões Pontos negativos
20, 31, 38, 39, 40, 41, 42, 43, 63, 69, 70, 71,
72 Não existe qualquer tipo de documentação de processos, padrões ou de implantações.
64 A equipe possui o conhecimento interdisciplinar centralizado em seus membros.
59, 60, 61, 62, 66 Não existe controle de mudanças.
8, 19, 22, 23, 25, 26, 27, 28, 29, 30, 32, 33,
44, 45, 46, 47, 58 Não é realizado nenhum planejamento.
67
1, 2, 5, 6, 7, 21, 35 Não existem metas ou objetivos claros para equipe.
3, 10, 34, 67 Não existe nenhum indicador ou métrica.
13, 14, 15, 16, 17 Os serviços prestados não estão catalogados.
9, 18, 53, 54, 55, 56 Não existe nenhum processo de melhoria contínua aplicado a essas equipes.
36, 37, 68 Ferramenta para cadastro de requisição desatualizada.
Tabela 5 – Relação do Instrumento de Avaliação com Pontos Negativos.
4.4 Aplicação do Instrumento de Avaliação
O instrumento de avaliação definido na seção anterior foi aplicado a três membros da
equipe de operação antes da fase de início de implantação do novo processo a ser definido,
sendo que, após a execução do novo processo o instrumento de avaliação deve ser reaplicado
a fim de avaliar de forma comparativa os resultados antes e depois da aplicação do processo a
ser proposto.
O autor desta monografia não participou da amostragem inicial, sendo que a avaliação foi
aplicada através da ferramenta Google Docs e a média de suas respostas poderá ser
visualizada no Apêndice A. Segue um pequeno resumo sobre o perfil de cada participante.
Participante 1
Tempo de experiência na área de TI: 19 anos
Tempo de experiência na área de serviços de TI: 11 anos
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de operação do AGHU:
• Lidera da equipe de operação;
• Monitora bancos de dados utilizados Projeto AGHU;
• Monitora ambientes utilizados para o Projeto AGHU.
Participante 2
Tempo de experiência na área de TI: 8 anos
Tempo de experiência na área de serviços de TI: 5 anos
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de operação do AGHU:
• Analista da equipe de operação;
68
• Administra bancos de dados utilizados Projeto AGHU;
• Administra ambientes utilizados para o Projeto AGHU;
• Controla implantações do software AGHU.
Participante 3
Tempo de experiência na área de TI: 7 anos
Tempo de experiência na área de serviços de TI: 5 anos
Tempo de experiência no Projeto AGHU: 1 ano e 8 meses
Atividades atuais na equipe de operação do AGHU:
• Analista de banco de dados da equipe de operação;
• Administra bancos de dados utilizados Projeto AGHU;
• Administra ferramentas de integração contínua do AGHU.
Tabela 6 - Perfil dos Participantes da Avaliação Inicial.
De acordo com as respostas obtidas com a primeira aplicação do instrumento de
avaliação (vide Apêndice A). Para aplicação desta avaliação não foi realizado nenhum
treinamento prévio entre os participantes a fim de nivelar conhecimentos sobre as boas
práticas estudadas neste trabalho, assim, os participantes responderam as questões
considerando apenas o conhecimento adquirido durante seus anos de experiência como
profissionais de TI.
Na tabela 7 que segue são apresentados os resultados das questões do instrumento de
avaliação aplicado, as informações estão agrupadas e somadas por grau de maturidade que
está ligado diretamente as possíveis opções de respostas apresentadas na tabela de número 3.
Após a tabela 7 pode ser visualizado os resultados representado graficamente através da
ilustração de número 16.
Gerência de
Serviços –
Projeto
AGHU
Inicial Repetível Definido Gerenciado Otimizado
Estratégia
de Serviço 15 18 0 0 0
Desenho de
Serviço 24 17 1 0 0
69
Transição
de Serviço 4 17 0 0 0
Operação de
Serviço 5 14 5 0 0
Melhoria
Contínua de
Processo
12 9 0 0 0
Scrum 27 17 1 0 0
XP 9 7 2 0 0
Kanban 8 3 0 0 1
Tabela 7 - Respostas da Avaliação Agrupadas por Nível de Maturidade.
A figura 15 demonstra que o processo em sua grande maioria está classificado com nível
inicial e repetível. O gráfico (figura 15) apresenta os números descritos na tabela 7 sendo que
os valores foram transformados para percentual.
Figura 15 - Gráfico de Respostas da Avaliação Agrupada por Nível de Maturidade.
A tabela 8 que segue apresenta a média das respostas obtidas por cada área de
conhecimento do instrumento de avaliação.
70
Gerência de Serviços – Projeto AGHU Média
Estratégia de Serviço 1,54
Desenho de Serviço 1,45
Transição de Serviço 1,80
Operação de Serviço 2
Melhoria Contínua de Processo 1,43
Scrum 1,42
XP 1,61
Kanban 1,58
Tabela 8 - Média de Pontuação por Área de Conhecimento.
Através dos dados apresentados na tabela 8 foi obtido o gráfico presente na figura 16. Ao
analisar este gráfico fica evidente a baixa qualidade do processo onde a área que mais se
destacou com média de 2 foi a de Operação de Serviço, foco principal deste trabalho.
Figura 16 - Gráfico de Média da Pontuação do Instrumento de Avaliação.
Após essa primeira avaliação realizada e seus resultados analisados o próximo capítulo
descreve a definição do novo processo a ser implantado na célula de serviços de TI do Projeto
AGHU, a fim de melhorar os resultados referentes à situação atual.
71
5 DEFINIÇÃO
Este capítulo descreve, principalmente, a definição de um processo embasado nos temas
estudados para este trabalho como PMBOK, ITIL v3, práticas ágeis e contexto atual do
Projeto AGHU, pois é importante conhecer a realidade antes de desenhar um processo.
Para iniciar a definição deste novo processo é necessário se entender onde os temas
estudados apresentam características em comum a fim de elaborar um processo lógico, correto
e com justificativas. A primeira seção deste capítulo tem o objetivo de apresentar tais
características em comum, para assim, justificar decisões tomadas nas próximas seções deste.
5.1 Avaliação das metodologias estudadas
A fim de avaliar as características em comum entre as áreas de conhecimento estudadas,
esta seção visa a um melhor esclarecimento dos pontos onde o objetivo de ambas (ITIL e
Agile) se encontram de forma equivalente.
Conforme citado na seção de Operação de Serviço, presente no capítulo 3, esta fase tem o
objetivo de mostrar para o cliente o valor da TI sendo necessário um balanceamento entre a
visão técnica e a visão de negócio, de acordo com a ITIL v3, recomenda-se que esse
balanceamento tenha tendência para o lado do cliente, ou seja, o serviço entregue deve
agregar valor para o cliente. Neste ponto surge uma forte ligação com um dos valores do
Manifesto Ágil (BECK, 2001), onde um de seus princípios é “Colaboração com o cliente
mais que negociação de contratos”. Práticas ágeis apresentam exatamente este espírito de
agregar valor ao seu cliente e não apenas fazer projetos, mas sim, conceber projetos que
agreguem valor ao negócio em um espaço de tempo pequeno.
Seguindo ainda o principio de colaboração com o cliente a ITIL v3 sugere, devido a um
mundo cada vez mais dinâmico, um balanceamento entre estabilidade e agilidade, onde se
deve ser ágil para responder de forma rápida as mudanças, entretanto tal resposta deve-se ser
eficaz ou estável, pois, hoje, com a velocidade da comunicação um erro pode se fatal para o
cliente. Este ponto apresenta um forte vínculo com outro princípio ágil conhecido como
“Responder a mudanças mais que seguir um plano” (BECK, 2001). Este princípio está
ligado com a forma de entrega (releases) proposta nas práticas ágeis, onde se entrega software
funcionando a cada iteração.
72
Um fator fundamental para o sucesso da fase de Operação de Serviço é a eficiência e
eficácia da comunicação entre equipes. É primordial a comunicação na área de gerenciamento
de serviços, logo o processo definido deve ter muita atenção neste ponto. E mais uma vez se
percebe uma forte relação com as práticas ágeis especificamente com o valor “Indivíduos e
interação entre eles mais que processos e ferramentas” (BECK, 2001). O valor da
comunicação para a ITIL v3 é bem próximo do valor citado nas práticas ágeis, onde não
significa de maneira alguma que não se devem ter processos e ferramentas, mas que, a
interação entre os envolvidos é o mais importante.
Uma das fases presentes na ITIL v3 é a Melhoria Contínua de Processo, descrita no
capítulo 3 deste documento, tal fase é essencial para a evolução do serviço conforme as
estratégias definidas. Novamente é possível perceber mais outra forte relação com as práticas
ágeis que de acordo com o guia do Scrum, um dos métodos ágeis, sugere que, um dos pilares
desse framework seja a “Adaptação” embasado totalmente no processo de melhoria contínua,
onde sugere uma reunião de retrospectiva, descrita no capítulo 3.
Conclui-se que a ITIL v3 e metodologias ágeis apresentam muitos princípios em comum.
O PMBOK também apresenta relação com algumas práticas dessas áreas, como por exemplo,
gerenciamento de riscos presente na fase de estratégia de serviços (ITIL v3) e diariamente no
Scrum através das reuniões diárias, gerenciamento de tempo (acordos de níveis de serviço e
sprint), gerenciamento de escopo (portfólio de serviços e planejamento de release), entre
outros. Isto deve facilitar bastante na definição do processo que poderá ser visualizado nas
seções que seguem.
5.2 Definição de Estrutura do Projeto
Com base nos estudos realizados, uma das primeiras ações a fim de tornar possível a
implantação de um processo fundado em valores diferentes dos atuais é a realização de uma
alteração na estrutura das equipes de serviço do Projeto AGHU, mudando sua forma de se
organizar. Desta forma a nova definição de processo deve ser sustentada bem como todos os
conceitos que serão aplicados.
A primeira alteração proposta é a constituição de equipes de Central de Serviços, função
necessária na fase de Operação de Serviços da ITIL v3, sendo que essas equipes devem estar
localizadas nos HUF’s, ou seja, se caracterizando por uma Central de Serviços Local a fim de
realizar o suporte de nível 1. Na figura 17 pode se visualizar a estrutura e os papéis
necessários para formação desses times.
73
Figura 17 - Estrutura para Equipes de Central de Serviços de TI.
Conforme pode se observar na figura acima (17), estas equipes de suporte nível 1 devem
estar formadas em todos HUF’s onde o AGHU se encontra implantado. Além disso, devem
escalar requisições de nível 2 ou 3 para equipe de serviços localizada em Porto Alegre (Célula
de Serviços de TI AGHU/POA). Na tabela 9 que segue, é descrito a função de cada um dos
papéis referenciados na figura 17.
Papel Função
Líder de Equipe
Deve exercer liderança servidora, seguindo os
padrões ágeis, bem como, garantir que o
processo foi entendido e está sendo aplicado
pela equipe. Pode atuar em qualquer outra
função da equipe.
Analista de Suporte
Apresenta como principal função a resolução de
requisições de serviço e incidentes de nível 1,
atuando de forma autogerenciável.
Célula de Serviços de TI
AGHU/POA
Apresenta como principal função a resolução de
requisições de serviço, incidentes e problemas
de nível 2 e 3. Sendo que esta função é
74
composta de varias equipes que pode ser
visualizada na figura 18.
Tabela 9 - Papéis Equipes de Central de Serviços.
Com as equipes de Central de Serviço definidas, o próximo passo é definir a estrutura da
Célula de Serviços de TI AGHU/POA. De acordo com a figura 18 que segue, pode se
perceber a nova proposta de estrutura para célula de serviços de TI do projeto AGHU/POA.
Nesta figura (18) fica claro a constituição de uma célula de serviços de TI com cinco equipes
sendo duas equipes para o gerenciamento de operação, duas equipes para o gerenciamento de
aplicação e uma equipe para função de gerenciamento técnico, de acordo com funções
definidas na ITIL v3.
Figura 18 - Estrutura de Equipes para Célula de Serviços de TI AGHU/POA.
75
Nesta proposta de reestruturação de organograma é possível perceber a presença dos
conceitos estudados, como por exemplo, a existência de cinco pequenas equipes variando de
quatro a cinco pessoas por equipe (Agile), cada equipe com responsabilidades definidas de
acordo com as funções presentes na Operação de Serviço (OGC, 2007e) bem como o nível de
suporte onde cada equipe atua. Na tabela 10, que segue, é apresentada a responsabilidade de
cada uma das equipes.
Equipe Responsabilidade
Delivery
Equipe de sustentação dos serviços de TI (nível
2) fornecidos pela célula de serviços de TI
AGHU/POA, deve trabalhar com uma matriz de
prioridades onde requisições relacionadas ã
implantação da aplicação AGHU devem ser
avaliadas com maior prioridade do que as
demais requisições.
Sustentação – Operação
Equipe de sustentação dos serviços de TI (nível
2) fornecidos pela célula de serviços de TI
AGHU/POA, deve trabalhar com uma matriz de
prioridades onde incidentes devem ser tratados
com maior prioridade do que as demais
requisições.
Sustentação – Aplicação
Equipe de responsável por manter todo o ciclo
de vida dos serviços de TI antes que esses
cheguem em ambiente de produção (nível 2),
deve trabalhar com uma matriz de prioridades
onde requisições de serviço devem ser tratadas
com maior prioridade do que as demais
requisições.
Infraestrutura
Equipe de responsável por manter todo o ciclo
de vida dos serviços de TI (nível 3) e
principalmente responsável por tomar as
decisões técnicas de infraestrutura do projeto,
deve trabalhar com uma matriz de prioridades
76
onde requisições de serviço devem ser tratadas
com maior prioridade do que as demais
requisições, entretanto deve focar no processo
de gerenciamento de eventos a fim de alertar as
equipes de operação caso algum incidente esteja
próximo de ocorrer, se tornando pró-ativo e não
mais reativo.
Arquitetura
Equipe de sustentação dos serviços de TI (nível
3) fornecidos pela célula de serviços de TI
AGHU/POA e principalmente responsável por
tomar as decisões técnicas de software do
projeto, deve trabalhar com uma matriz de
prioridades onde problemas devem ser tratados
com maior prioridade do que as demais
requisições, atendendo também outras áreas do
projeto através de requisições de serviço.
Tabela 10 - Responsabilidades das Equipes de Serviços de TI.
Na tabela 11, que segue, são apresentadas as funções de todos os papéis citados na figura
18.
Papel Função
Gerente de Serviços
Deve exercer liderança servidora e situacional,
sua principal função está no gerenciamento de
todos os serviços de TI prestados por esta
célula, incluindo o controle das operações e o
gerenciamento das instalações. Além disso,
deve ser um facilitador do trabalho realizado
por suas equipes.
Líder de Equipe
Pode atuar em qualquer outra função da equipe,
deve exercer liderança servidora, seguindo os
padrões ágeis, bem como, garantir que o
processo foi entendido e está sendo aplicado
77
pela equipe.
Desenvolvedor de Sistemas
Apresenta como principal função a resolução de
requisições de serviço e incidentes de nível 2
vinculados ao software AGHU, atuando de
forma autogerenciável.
Testador
Este papel deve atuar garantindo a qualidade do
produto que esta sendo instalado em ambiente
de produção. Uma de suas atividades é sempre
que houver uma correção de um incidente este
deve ser testado a fim de garantir que sua
correção está de acordo.
DBA
Deve garantir a disponibilidade, performance e
confiabilidade de todos os bancos de dados
existentes no Projeto AGHU.
Analista de Integração
Apresenta como principal função a resolução de
requisições de serviço e incidentes de nível 2
vinculados a problemas de integração ou
configuração, atuando de forma
autogerenciável.
Analista de Configuração
Deve realizar todo o gerenciamento de
configuração e controle de versões do projeto,
incluindo criação de branches, tags e merges.
Analista de Infraestrutura Deve estruturar, implantar e sustentar toda
infraestrutura necessária para o Projeto AGHU.
Arquiteto de Software
Este papel deve fornecer habilidades técnicas
para a melhoria contínua do suporte fornecido
pelas equipes de nível 2, bem como estruturar,
desenvolver e sustentar a arquitetura de
software do Projeto AGHU.
Tabela 11 - Papéis equipes da Célula de Serviços de TI AGHU/POA.
Para melhor organização e entendimento da estratégia destas equipes, foi elaborado um
planejamento estratégico para célula de serviços de TI do AGHU, pois somente assim será
78
possível a constituição de um novo processo que deve ser orientado também pela estratégia
desta célula:
• Missão: Estruturar, implantar e sustentar serviços de tecnologia da informação
relacionados ao Projeto AGHU, minimizando o impacto adverso aos Hospitais
Universitários Federais vinculados ao projeto, sempre aperfeiçoando a qualidade do
atendimento;
• Visão: Contribuir para reestruturação da tecnologia da informação de no mínimo 6
Hospitais Universitários Federais até o final do ano de 2013, se tornando referência na
prestação de serviços de TI;
• Valores:
o Transparência;
o Ética;
o Humildade;
o Consciência do Negócio;
o Comprometimento com a Estratégia;
o Buscar a Satisfação do Cliente;
o Indivíduos e interação entre eles mais que processos e ferramentas;
o Colaboração com o cliente mais que negociação de contratos;
o Software em funcionamento mais que documentação abrangente;
o Responder a mudanças mais que seguir um plano.
Com os organogramas, papéis e missão definidos é possível iniciar a descrição de todo o
processo que esta estrutura deve sustentar, sendo assim, na próxima seção será detalhada toda
definição do processo que deve funcionar com base nessa reestruturação.
5.3 Definição de Processos
Esta seção deve detalhar toda a proposta do processo para célula de serviços de TI do
Projeto AGHU com foco na área de operação de serviços. Vale lembrar os pontos negativos
que a equipe apresenta nos dias atuais, citado no capítulo 4:
79
1. Não existe qualquer tipo de documentação de processos, padrões ou de
implantações;
2. A equipe possui o conhecimento interdisciplinar centralizado em seus membros;
3. Não existe controle de mudanças;
4. Não é realizado nenhum planejamento;
5. Não existem metas ou objetivos claros para equipe;
6. Não existe nenhum indicador ou métrica;
7. Os serviços prestados não estão catalogados;
8. Não existe nenhum processo de melhoria contínua aplicado a essas equipes;
9. Distância entre equipe de infraestrutura e integração;
10. A equipe não possui conhecimento de boas práticas de gestão;
11. Ferramenta para cadastro de requisição desatualizada.
Revisando os pontos negativos e todo o estudo realizado é necessário iniciar essa
proposta definindo uma solução de Central de Serviços bem como uma ferramenta para gerir
estes serviços. Entretanto, para o melhor entendimento das próximas seções, na figura 19 é
apresentado o workflow completo em alto nível dos níveis de serviço definidos.
80
Figura 19 - Workflow Níveis de Serviço.
81
De acordo com a figura 19 apresentada é possível verificar quatro papéis atuantes neste
processo reconhecidos como: usuários, central de serviços ou suporte de nível 1 (fundo
verde), suporte de nível 2 (fundo azul) e suporte de nível 3 (fundo vermelho). As cores
referenciadas também estão presentes nos organogramas apresentados (figuras 17 e 18) a fim
de facilitar a compreensão.
O processo proposto é dividido em cinco fases, segue na tabela 12 a descrição de cada
uma dessas fases.
Fase Descrição
Iniciação
Fase onde é identificada pelo usuário a necessidade de solicitar
uma requisição de serviço, sendo que essa é finalizada quando
a equipe responsável toma o conhecimento da requisição
desejada pelo usuário, normalmente através do registro desta
em uma ferramenta de apoio.
Avaliação Fase onde a equipe responsável classifica e prioriza as
requisições abertas baseado em um catálogo de serviços.
Execução
Fase onde a equipe responsável inicia a construção da
requisição solicitada, sendo que nesta fase também devem ser
realizados testes a fim de verificar se a requisição foi atendida
e somente se encerra caso a requisição tenha sido construída e
verificada.
Validação
Fase onde a equipe de central de serviços deve solicitar que o
usuário realize uma validação a fim de verificar se sua
requisição foi atendida, caso positivo a fase se conclui.
Encerramento
Momento de finalização do atendimento. Inicia-se quando o
usuário finaliza a fase de validação e se encerra após a
atualização do registro na ferramenta de apoio e o envio da
pesquisa de satisfação para o requisitante.
Tabela 12 - Fases dos Níveis de Serviço.
Apresentada a descrição das fases, segue na tabela 13 a relação de todas as atividades
bem como a equipe executora destas atividades.
82
Atividade Descrição Responsável
Defeito encontrado
Atividade na qual o usuário
identifica uma requisição e
comunica a central de serviços da
situação encontrada.
Usuário
Registrar requisição
Central de serviços recebe a
requisição e registra em sua
ferramenta de apoio.
Equipe de Central de
Serviços
Classificar e
priorizar requisição
Central de serviços classifica e
prioriza a requisição baseado em
um catálogo de serviços.
Equipe de Central de
Serviços
Realizar suporte de
nível 1
No caso da equipe de central de
serviços ter o conhecimento da
solução da requisição e esta ser de
nível 1 o próprio membro desta
equipe atende a requisição,
normalmente através de
configurações na ferramenta
AGHU.
Equipe de Central de
Serviços
Escalar para
suporte de nível 2
Caso a equipe de central de
serviços não tenha o conhecimento
da solução da requisição ou a
mesma seja de um nível superior,
esta deve ser escalada para o
suporte de segundo nível que é
realizado via o registro da
requisição na ferramenta de apoio
utilizada pela célula de serviços de
TI AGHU/POA.
Equipe de Central de
Serviços
Investigar e
diagnosticar S2
Atividade na qual é investigado e
realizado um diagnóstico da
requisição registrada, a fim de
avaliar sua classificação e
Equipes de Suporte de
Nível 2
83
priorização a nível nacional.
Realizar suporte de
nível 2
No caso da equipe de suporte de
nível 2 ter o conhecimento da
solução da requisição, esta realiza o
atendimento necessário.
Equipes de Suporte de
Nível 2
Notificar central de
serviços S2
Após a conclusão do
macroprocesso de realizar o suporte
de nível 2, a equipe deste nível
deve comunicar, via ferramenta de
apoio, a central de serviços que
registrou a requisição para que esta
de continuidade, junto ao usuário
de seu HUF, na resolução de sua
requisição.
Equipes de Suporte de
Nível 2
Escalar para
suporte de nível 3
Caso a equipe de suporte de nível 2
não tenha o conhecimento da
solução da requisição ou a mesma
seja de um nível superior, esta deve
ser escalada para o suporte de
terceiro nível que é realizado via
reclassificação do registro da
requisição na ferramenta de apoio
utilizada pela célula de serviços de
TI AGHU/POA.
Equipes de Suporte de
Nível 2
Investigar e
diagnosticar S3
Atividade na qual é investigado e
realizado um diagnóstico da
requisição registrada, a fim de
avaliar sua classificação e
priorização a nível nacional.
Equipes de Suporte de
Nível 3
Realizar suporte de
nível 3
No caso da equipe de suporte de
nível 3 ter o conhecimento da
solução da requisição, esta realiza o
atendimento necessário.
Equipes de Suporte de
Nível 3
84
Notificar central de
serviços S3
Após a conclusão do
macroprocesso de realizar o suporte
de nível 3, a equipe deste nível
deve comunicar, via ferramenta de
apoio, a central de serviços que
registrou a requisição para que esta
de continuidade, junto ao usuário
de seu HUF, na resolução de sua
requisição.
Equipes de Suporte de
Nível 3
Validar junto ao
requisitante se a
requisição foi
atendida
Atividade na qual a central de
serviços requisitante homologa
junto de seu usuário se o
atendimento está de acordo com o
que era esperado, caso positivo, se
inicia o encerramento do
atendimento.
Equipe de Central de
Serviços
Realizar o
encerramento do
atendimento
Atividade na qual a central de
serviços encerra o atendimento da
requisição.
Equipe de Central de
Serviços
Tabela 13 - Atividades Workflow de Níveis de Serviço.
Com estas informações é possível ter uma visão em alto nível do processo que é o
objetivo deste trabalho. As próximas seções devem explicar de forma mais especifica cada
etapa deste processo.
5.3.1 Central de Serviços
De acordo com a fase de Operação de Serviço presente na ITIL v3, deve existir uma
equipe de central de serviços que atue como ponto único de contato entre o provedor de
serviços e os usuários a fim de gerenciar requisições de serviço, incidentes e a comunicação
com esses usuários.
Entendendo a realidade de um hospital e a exigência de disponibilidade de serviço que
esta área de negócio exige, tomou-se a decisão de que cada Hospital Universitário Federal
85
(HUF) que receber o AGHU deve formar uma equipe de central de serviços local, conforme
ilustrado na figura 20, estas pessoas serão treinadas pelos consultores técnicos do Projeto
AGHU, membros da célula de serviços de TI AGHU/POA, a fim de aperfeiçoar a qualidade
desta função.
Figura 20 - Localização de Centrais de Serviço - Projeto AGHU (Fonte: O autor, 2012).
86
Com esta decisão, significa que o atendimento de nível 1 sempre será realizado localmente pela própria central de serviços do HUF e
somente será escalado para célula de serviços de TI do AGHU caso a requisição seja de nível 2 ou 3, onde a equipe do HUF não possui o
conhecimento necessário para encaminhar a solução. Na figura 21 pode se visualizar como deve ser realizado o suporte de nível 1.
Figura 21 - Workflow Realizar Suporte Nível 1.
87
Neste workflow, apresentado na figura 21, é possível visualizar as atividades do macro
processo de Realizar Suporte de Nível 1, abaixo segue, na tabela 14, a descrição de cada uma
de suas atividades.
Atividade Descrição Responsável
Verificar se existe
requisição
semelhante
Atividade pela qual a equipe de
central de serviços inicia o suporte
de nível 1. Deve ser realizada uma
busca através da ferramenta de
apoio se não existe alguma
requisição semelhante já
cadastrada.
Equipe de Central de
Serviços
Vincular requisições
Caso exista uma requisição
semelhante, esta deve ser
vinculada, via ferramenta de apoio,
a requisição cuja solução será a
mesma.
Equipe de Central de
Serviços
Aplicar solução
Caso já tenha sido solucionada uma
requisição igual a que está sendo
atendida, deve ser aplicada a
mesma solução que resolveu o
problema da requisição anterior.
Equipe de Central de
Serviços
Aplicar solução
padrão
No caso da equipe de central de
serviços não ter solucionado
nenhum problema parecido com o
que está sendo atendido, então esta
equipe deve aplicar a solução
padrão para o tipo de requisição.
Equipe de Central de
Serviços
Tabela 14 - Atividades Processo de Realizar Suporte de Nível 1.
Além destas atividades, ainda é necessário detalhar o processo de Realizar encerramento
do atendimento, na figura 22 que segue pode se visualizar as atividades deste.
88
Figura 22 - Workflow Processo de Realizar Encerramento do Atendimento.
Abaixo segue tabela 14 onde são explicadas as atividades do processo de realizar
encerramento do atendimento.
Atividade Descrição Responsável
Atualizar ambiente
de produção
Caso seja necessário atualizar
dados em ambiente de produção
para concluir a resolução da
requisição a equipe de central de
serviços deve agendar uma janela
para atualização no ambiente de
produção.
Equipe de Central de
Serviços
Encerrar requisição
Atividade na qual a equipe de
central de serviços encerra a
requisição em comum acordo com
o usuário requisitante.
Equipe de Central de
Serviços
Atualizar registro
da requisição
Atualiza registro da requisição na
ferramenta de apoio indicando a
conclusão do atendimento.
Equipe de Central de
Serviços
Solicitar
preenchimento de
Ao final do atendimento a equipe
deve solicitar ao usuário o
Equipe de Central de
Serviços
89
pesquisa de
satisfação
preenchimento da pesquisa de
satisfação do atendimento.
Tabela 15 - Atividades do Processo de Realizar Encerramento do Atendimento.
Após a definição da função e processo do suporte de nível 1 é necessário a definição de
um catálogo de serviços que a célula de serviços de TI AGHU/POA deve atender. Na próxima
seção é detalhada a definição do catálogo de serviços.
5.3.2 Catálogo de Serviços
O catálogo de serviços é fundamental para organização e agilidade do atendimento,
facilitando a triagem, realizada pela equipe de central de serviços, das requisições solicitadas.
Neste catálogo deve conter informações de todos os serviços de TI disponibilizados para
o cliente, contendo dados como nome do serviço, equipe responsável, descrição do serviço,
etc. Seguindo este conceito, citado na ITIL v3, é necessário a criação de um catálogo de
serviços do Projeto AGHU, onde as centrais de serviços presentes em cada HUF do Brasil
deve se guiar quando for preciso escalar suas requisições para nível 2.
Segue no Apêndice D um levantamento realizado de todos os serviços que podem ser
prestados pelas equipes de níveis 1, 2 ou 3, assim formando o catálogo de serviços.
90
5.3.3 Workflows por Tipos de Requisição
Nesta seção serão apresentados os diferentes tipos de requisições que a célula de serviços
de TI AGHU/POA deve atender, bem como, os fluxos utilizados por cada tipo, assim
representando o macroprocesso de realizar suporte de nível 2 e 3, sendo que esses fazem parte
da fase de execução ilustrada no workflow de níveis de serviço (figura 19).
Qualquer solicitação que não se caracteriza por uma falha ou melhoria de aplicação pode
ser considerada uma requisição de serviço. A figura 23 apresenta o workflow do fluxo
principal de uma requisição de serviço desde seu registro na ferramenta de apoio até o
encerramento de seu atendimento, sendo que os estados representados na cor verde
representam o fluxo principal deste workflow, na cor azul são atividades implícitas ao
processo.
O fluxo completo pode ser visualizado no Apêndice B.
91
Figura 23 - Workflow Requisição de Serviço.
92
O workflow proposto é dividido em cinco fases, segue na tabela 16 a descrição de cada
uma dessas fases.
Fase Descrição
Iniciação
Fase onde o requisitante (equipe de suporte nível 1) identifica
a necessidade de escalar a requisição para o próximo nível e
formaliza sua necessidade através do registro desta na
ferramenta de apoio utilizada pela célula de serviços de TI do
AGHU. Esta fase se encerra no momento em que um membro
da equipe de nível 2 identifica e inicia a avaliação desta
requisição.
Avaliação Fase onde a equipe responsável classifica e prioriza as
requisições abertas baseado em um catálogo de serviços.
Construção
Fase onde a equipe responsável inicia a construção da
requisição solicitada, sendo que nesta fase também devem ser
realizados testes a fim de verificar se a requisição foi atendida
e somente se encerra caso a requisição tenha sido construída e
verificada.
Validação
Fase onde a equipe responsável notifica a central de serviços
que a requisição está concluída e que estes devem iniciar sua
fase de validação a fim de verificar se a requisição foi atendida,
caso positivo a fase se conclui.
Encerramento
Momento de finalização do atendimento. Inicia-se quando a
equipe de central de serviços finaliza a fase de validação e
confirmando que a requisição está de acordo com o solicitado a
fase se encerra para equipes de nível 2 ou 3 e continua para
equipe de central de serviços a fim de finalizar o atendimento
junto ao usuário.
Tabela 16 - Fases Workflow de Requisições de Serviço, Incidentes e Problemas.
Segue, na tabela 17, a relação das atividades apresentadas na figura 23, bem como, as
atividades que compõe os fluxos alternativos (Apêndice B), além de sua descrição e o
responsável de cada atividade.
93
Atividade Descrição Responsável
Nova
Atividade na qual a central de serviços escala a
requisição para o nível 2 de suporte,
registrando esta na ferramenta de apoio da
célula de serviços de TI AGHU/POA.
Equipe de Central de
Serviços (Nível 1)
Investigação
e Diagnóstico
Equipes de sustentação realizam investigação a
fim de categorizar e priorizar a requisição a
nível nacional, onde esta deve entrar em uma
fila de atendimento organizada por ordem de
prioridade de acordo com o diagnóstico
realizado.
Equipes de
Sustentação
(Operação e
Aplicação)
Lançar
Atividade no
Quadro de
Tarefas
Membro da equipe que realizou a atividade de
investigação e diagnóstico deve verificar se a
atividade demora mais de um dia para ser
concluída, caso afirmativo, esta deve ser
colocada no Kanban de sua equipe, caso
contrário, não é necessário colocar no Kanban,
visto que a mesma pode e deve ser alinhada na
reunião diária desta equipe.
Equipes de
Sustentação
(Operação e
Aplicação)
Avaliado
Este estado significa que a requisição se
encontra na fila de atendimento nacional,
categorizada e priorizada de acordo com os
vetores de impacto e urgência. É a partir desta
fila que as equipes devem iniciar a fase de
construção.
Equipes de
Sustentação
(Operação e
Aplicação)
Aguardando
Retorno do
Usuário
Este estado ocorre quando o membro, que esta
realizando a fase de avaliação, não
compreende a descrição da requisição ou ainda
a requisição não está de acordo com o padrão
de redação aceito pela célula de serviços de TI
do AGHU. Sendo que a responsabilidade da
requisição retorna para o requisitante a fim de
que este complemente as informações
Equipe de Central de
Serviços (Nível 1)
94
necessárias.
Impedido
Este estado representa que o atendimento de
uma requisição se encontra impedido por
depender de um serviço que não esta
disponível no momento.
Equipes de
Sustentação
(Operação e
Aplicação)
Rejeitado
No caso da equipe de sustentação em comum
acordo com a equipe de central de serviços
entenderem que a requisição não faz mais
sentido então esta deve ser rejeitada.
Equipes de
Sustentação
(Operação e
Aplicação)
Em
Construção
Após a fase de avaliação é possível iniciar a
construção de um serviço, onde é dado inicio a
implementação do serviço solicitado.
Equipes de
Sustentação
(Operação e
Aplicação)
Em
Homologação
Após a construção do serviço a equipe que
atendeu este deve solicitar que o requisitante
valide o serviço a fim de verificar se o serviço
atende ou não.
Equipe de Central de
Serviços (Nível 1)
Reaberto
Caso na fase de validação o requisitante
entenda que o serviço entregue não atende ao
que foi especificado este deve reabrir a
atividade para que as equipes de sustentação
possam avaliar e iniciar o atendimento
novamente.
Equipe de Central de
Serviços (Nível 1)
Concluído
Caso o serviço atendido esteja de acordo com
o solicitado pelo requisitante este é concluído
finalizando o atendimento por parte da célula
de serviços de TI AGHU/POA.
Equipes de
Sustentação
(Operação e
Aplicação)
Tabela 17 - Atividades Workflow Requisição de Serviço.
Normalmente, conforme o catálogo de serviços apresentado no Apêndice D, uma
requisição de serviço será atendida pelas equipes responsáveis pelo gerenciamento da
aplicação. Entretanto, no caso de um incidente, as equipes de operação têm a
responsabilidade.
95
Na figura 24 que segue pode-se visualizar o workflow do fluxo principal de um incidente
desde seu registro na ferramenta de apoio até a sua conclusão, sendo que os estados
representados na cor verde representam o fluxo principal deste workflow, na cor azul são
atividades implícitas ao processo.
O fluxo completo pode ser visualizado no Apêndice C.
96
Figura 24 - Workflow Incidentes e Problemas.
97
Na figura 24, conforme citado anteriormente, é apresentado o fluxo principal para realizar
atendimento de nível 2 e 3. Este esboça o workflow principal executado quando é registrado
um incidente ou problema na ferramenta de apoio da célula de serviços de TI AGHU/POA.
Segue, na tabela 18, a relação das atividades apresentadas na figura 24, bem como, as
atividades que compõe os fluxos alternativos (Apêndice C), além de sua a descrição e o
responsável de cada atividade, entretanto será descrito apenas as atividades que não foram
descritas na tabela 17.
Atividade Descrição Responsável
Pendente de
Merge
Este estado significa que a requisição foi
verificada em uma versão candidata a ir para
produção e se encontra de acordo. Logo o
responsável pela implementação deve passar
sua solução para uma versão de produção a
fim de iniciar as próximas fases.
Equipes de
Sustentação
(Operação e
Aplicação)
Aguardando
Liberação
para Staging
Este estado é iniciado quando se finaliza o
estado de pendente de merge, significa que a
solução da requisição se encontra em uma
versão de produção e é necessário colocar esta
em um ambiente idem ao ambiente de
produção a fim de iniciar a fase de validação.
Equipes de
Sustentação
(Operação e
Aplicação)
Aguardando
Liberação
para
Produção
Após a fase de validação o requisitante
(equipe de central de serviços) deve notificar
as equipes de nível 2 ou 3 caso seja necessário
uma atualização de versão de software em
ambiente de produção, sendo que, deve ser
negociada uma janela de atualização.
Equipes de
Sustentação
(Operação e
Aplicação)
Tabela 18 - Atividades Workflow Incidentes e Problemas.
5.3.4 Método de Trabalho das Equipes da Célula de Serviços de TI
Após a definição dos processos por tipo de requisição, esta seção descreve a definição do
método de trabalho das equipes da célula de serviços de TI do AGHU. De acordo com
organograma apresentado na figura 18, a célula será composta de cinco equipes de trabalho
98
separadas por responsabilidades e prioridades. Essas equipes apresentam o tamanho máximo
de cinco pessoas sendo que todas essas equipes possuem o papel de Líder, sendo que este
deve ser o facilitador e o responsável por fazer com que a equipe entenda e execute o método,
conforme o Scrum sugere.
Os membros das equipes devem ser maduros suficientes para trabalhar em grupo com alta
capacidade de comunicação e ser capazes de se autogerenciarem sem depender de uma pessoa
para dizer o que deve ser feito, sendo que as principais características exigidas são:
1. Maturidade;
2. Pró-atividade;
3. Transparência;
4. Flexibilidade;
5. Alta capacidade de comunicação;
6. Alta capacidade de trabalhar em equipe.
Estas características são fundamentais para o sucesso do método. Além disso, vale
lembrar que a ITIL v3 sugere um plano de comunicação que não seja complexo a fim de
agilizar o processo principalmente na fase de operação de serviço (OGC, 2007e).
Analisando o contexto de uma área de serviços de TI, fica claro que esta não possui
tempo hábil para reunir toda sua equipe a fim realizar reuniões de planejamento de sprint ou
revisão de sprint, conforme o sugerido no Scrum, essas cerimônias têm um tempo variável de
acordo com o tamanho da sprint, por exemplo, para uma sprint de duas semanas é sugerido
uma reunião de quatro horas para o planejamento da sprint (SCHWABER, 2011). Seguindo
essa lógica, caso fosse realizada uma sprint de uma semana seria necessário uma reunião de
planejamento de duas horas o que ainda se torna arriscado para uma equipe de serviços de TI.
Nesse momento surge a necessidade de unir os conceitos de ITIL v3, Kanban, Scrum e XP a
fim de solucionar pontos como:
1. Comunicação rápida e eficiente;
2. Capacidade de planejamento;
3. Rápida resposta a mudanças;
4. Priorizar serviços corretamente;
5. Trabalho em equipe;
6. Melhoria contínua;
99
7. Promoção da colaboração;
8. Processo deve estar vinculado ao planejamento estratégico.
Conforme citado anteriormente, é preciso realizar um planejamento priorizando
atividades de acordo com o planejamento estratégico da célula de serviços de TI do AGHU,
entretanto, é necessário realizar este de forma mais rápida e mantendo a mesma eficácia. É
importante ressaltar que requisições de serviço ou incidentes, em sua grande maioria, não
apresentam o mesmo grau de complexidade de uma estória de usuário, por exemplo, fato este
que possibilita a redução do tempo do planejamento sem perder a eficácia desta cerimônia.
Sendo assim segue as primeiras definições do método de trabalho das equipes:
1. Todas as equipes devem possuir um quadro de Kanban, sendo que suas fases
devem ser as mesmas apresentadas na figura 24, ou seja, devem seguir o mesmo
fluxo configurado na ferramenta de apoio a fim de facilitar o processo. Desta
forma é criado um ambiente informativo, conforme orientação do XP,
aumentando assim a capacidade de comunicação, pois esta passa a ganhar apoio
de forma visual e, além disso, expõe gargalos e falhas do processo para toda a
equipe, oportunizando a autogestão desta e a participação de todos na melhoria
contínua deste processo, pois cada membro desta equipe deve perceber seu valor
no resultado final e com isso sugerir melhorias para toda célula de serviços.
2. Cada equipe deve realizar uma reunião diária em pé, conforme sugerido no
Scrum, em frente ao Kanban com duração máxima de dez minutos. Nesta
cerimônia cada membro deve comunicar à equipe o que fez desde a última
reunião, o que pretende fazer até a próxima e se possuí algum impedimento
(SCHWABER, 2011). Em virtude do cenário de uma equipe de serviços de TI ser
muito dinâmico, esta cerimônia não deve ter um horário fixo para ser realizada,
apenas deve acontecer diariamente e seu tempo de duração foi reduzido pela
mesma característica;
3. Somente devem ser colocadas no Kanban atividades que demorem mais de um
dia de trabalho (8 horas) para serem solucionadas a fim de agilizar o atendimento,
sendo que atividades que não estão no Kanban devem ser alinhadas com a equipe
na reunião diária realizada;
100
4. As equipes devem trabalhar em sprints (conforme sugerido no Scrum) de uma
semana, pois as atividades, em sua grande maioria, não apresentam a mesma
complexidade de uma estória de usuário sendo assim á possível reduzir não
somente o tempo da sprint como os tempos das cerimônias;
5. Cada equipe deve realizar o planejamento da sua sprint no primeiro dia da
iteração, conforme sugerido no Scrum. Sendo que esta cerimônia deve ser
realizada de pé com duração máxima de 25 minutos e em frente ao Kanban, as
atividades devem ser movimentadas a fim de montar o planejamento. Após o
término desta, as atividades planejadas devem ser atualizadas na ferramenta de
apoio.
Nas cinco primeiras definições é possível visualizar de forma clara a união de diferentes
conceitos a fim de maximizar a produtividade e qualidade de todo processo, sendo que, o
Scrum contribuiu especificamente na inclusão de suas cerimônias (reunião diária,
planejamento da sprint e a própria sprint). Para dar seguimento às próximas definições é
necessário um melhor entendimento de como planejar e o que exatamente será planejado,
visto que se trata de uma célula de serviços de TI, onde apresenta atividades operacionais.
A célula de serviços de TI do AGHU deve atender três tipos de atividades: requisições
de serviço, incidentes e problemas (conforme descrito na seção 5.3.3). Entretanto, requisições
de serviços e incidentes são atendidas por ordem de prioridade, porém existem serviços
registrados pela própria equipe que possibilitam a melhoria contínua no atendimento, como
por exemplo, a instalação de uma ferramenta de monitoramento ou a atualização de versão de
qualquer outra ferramenta. Estes serviços são priorizados pela própria equipe a fim de atingir
o planejamento estratégico da célula de serviço de TI do AGHU, bem como outros tipos de
requisições. Sendo assim segue mais algumas definições, principalmente em relação à
cerimônia de planejamento:
1. Requisições de serviço e incidentes de alta prioridade devem ser atendidas de
forma operacional, ou seja, não fazem parte do planejamento, devem entrar nas
demandas operacionais do dia a dia. Vale salientar que mesmo não sendo
planejada, caso a atividade demore mais que um dia para ser concluída, esta deve
estar no Kanban;
101
2. As atividades que não forem de alta prioridade devem ser planejadas a fim de ser
executadas dentro da sprint;
3. Requisições do tipo problema ou atividades para melhoria continua devem entrar
no planejamento da sprint, sendo que, devem ser priorizadas de acordo com o
planejamento estratégico da célula;
4. Toda equipe deve possuir métricas (vide Apêndice E) a fim de entender quanto
tempo à equipe gasta com demandas operacionais, para assim ser possível a
realização de um planejamento mais coerente com sua realidade. Devido a esta
variável de demandas operacionais as equipes devem trabalhar com o conceito de
folga, sugerido no XP.
Com boa parte do método das equipes definido, ainda sobre a sprint, o Scrum sugere uma
reunião de revisão da sprint, com a finalidade de inspecionar o que foi feito e caso necessário
adaptar o backlog do produto (SCHWABER, 2011). Porém, no cenário de serviços de TI, essa
reunião não se faz necessária, pois não está sendo construído um produto e sim entregando
serviços. Entretanto, a fim de promover a colaboração entre equipes e alinhamento entre
essas, define-se que:
1. Deve ser realizada uma reunião de revisão de sprints com todas as equipes a cada
três semanas, sendo que esta deve ser realizada em pé e deve ter duração máxima
de 20 minutos. A intenção principal, além de promover a colaboração e o
alinhamento, é que todos saibam se o trabalho realizado está de acordo com o
planejamento estratégico da célula de serviços, caso não esteja, todos os membros
terão a liberdade de colaborar com novas ideias para que o trabalho realizado
tome o rumo correto.
Definida mais uma das cerimônias, existe um conceito que, apesar de ser comentado,
ainda não foi definido que é a melhoria contínua do trabalho realizado. Um dos pilares do
Scrum, adaptação (SCHWABER, 2011), na qual equipe precisa ser transparente para que na
inspeção se encontre pontos falhos e a partir destes a equipe deve ter a capacidade de adaptar-
se para assim melhorar de forma contínua. Uma das fases da ITIL v3, melhoria contínua de
processo, também se refere à necessidade de sempre estar melhorando.
Talvez uma das grandes vantagens da união da ITIL v3 com algumas práticas ágeis seja
na promoção da colaboração, ou seja, não deve existir mais uma pessoa responsável pela
102
melhoria contínua do trabalho e sim todos os membros da célula de serviços do AGHU
apresentam o mesmo grau de responsabilidade por melhorar continuamente todos os serviços
prestados, pois as práticas ágeis incentivam a colaboração e isto acelera a melhoria continua.
Pela importância destacada no parágrafo acima, define-se que:
1. Devido ao dinamismo das equipes de serviço e com isso a dificuldade de se
realizar uma reunião com todos durante um tempo considerável, cada uma das
equipes deve montar um quadro de lições aprendidas, onde deve ser possível
colocar pontos positivos e pontos negativos em papéis adesivos e lançar estes no
quadro a qualquer momento, ficando visível para todas as equipes;
2. O quadro de lições aprendidas deve ter quatro colunas, peso (1 a 3 para pontos
fortes e -1 a -3 para pontos fracos), ponto forte ou fraco, causa raiz e plano de
ação, sendo que qualquer uma das colunas pode ter uma atividade lançada a
qualquer momento;
3. Deve ser realizada uma revisão do quadro de lições aprendidas no intervalo
máximo de 3 semanas, ou seja, a equipe pode realizar a revisão a qualquer
momento, mas não deve demorar mais do que 3 semanas para realizar esta
revisão. Nesta revisão serão analisados e discutidos brevemente os pontos em
destaque e em comum acordo será definido o plano de ação necessário para
solução destes. Cada plano de ação definido deve ser transformado em atividades
planejáveis que farão parte do Kanban da equipe. Esta cerimônia deve ter duração
máxima de 30 minutos e pode ser realizada em frente ao quadro de lições
aprendidas.
Com estas últimas definições conclui-se a forma de como as equipes devem trabalhar,
com grande foco no trabalho em equipe e na promoção da colaboração entre todos os
membros desta célula. O grande objetivo destas definições esta na tentativa de seguir os
valores ágeis, ou seja, ser ágil e não apenas seguir suas práticas. Obviamente, já descrito neste
trabalho, existe um elo entre os conceitos e o contexto atual que possibilitaram a união destes
a fim de melhorar a realidade atual.
Na próxima seção serão apresentadas adaptações realizadas na ferramenta de apoio
escolhida para o gerenciamento dos serviços de TI prestados pela equipe do AGHU.
103
5.3.5 Ferramenta de apoio
Devido ao Projeto AGHU ser construído com tecnologias de software livre e utilizar o
Redmine (LANG, 2006) como ferramenta de gerenciamento de projetos, entende-se que é
possível utilizar a mesma ferramenta, com algumas customizações e atualizações, para gestão
de serviços. Entretanto, o Redmine apresenta algumas limitações em nível de gestão, mas que,
devido à dificuldade de adquirir uma nova ferramenta e a facilidade para customizar o
Redmine, tomou-se a decisão de utilizar este aplicativo para controle de todas as requisições
de serviço. Para utilização do Redmine será necessário a execução das seguintes tarefas:
1. Atualização da versão: a nova versão apresenta uma série de novas funcionalidades
que podem ajudar bastante às equipes de serviço no controle das requisições,
principalmente, no levantamento de métricas. Também é uma versão mais estável que
garante maior disponibilidade da ferramenta;
2. Inclusão de tipos de serviço: devem ser incluídos tipos como: Requisição de Serviço,
Incidente, Problema e Evento;
3. Inclusão de campos: devem ser incluídos alguns campos para disponibilizar
informações como: catálogo de serviços, categoria do serviço, causa raiz do incidente,
sprint da correção, prioridade, satisfação do atendimento;
4. Disponibilizar acesso ao Redmine para que os HUF’s possam abrir suas
requisições de serviços: deve ser liberado o acesso para os HUF’s.
Com a execução destas atividades eliminamos o ponto negativo “Ferramenta para
cadastro de requisição desatualizada” entre outros que não foram citados. Vale lembrar que a
ferramenta de apoio deve executar os workflows apresentados, principalmente na seção 5.3.3,
por esse motivo será necessária algumas customizações a fim de sustentar o processo
definido.
Após a definição do processo, no próximo capítulo será apresentado a execução destas
definições com um equipe piloto.
104
6 EXECUÇÃO
Com o processo definido, foi iniciada a sua implantação. Este capítulo está dividido em
três seções, são elas: Planejamento da Implantação onde será apresentado um pequeno plano
de implantação; Execução da Implantação onde será apresentado o dia a dia da execução com
fotos e comentários da evolução da implantação; Reaplicação do Instrumento de Avaliação
onde será reaplicado com mais participantes o instrumento de avaliação executado antes da
implantação do novo processo.
6.1 Planejamento da Implantação
Para iniciar a execução da nova proposta de processo é necessário preparar um
planejamento para sua correta implantação, segue o a relação de atividades necessárias para
implantação do novo processo em ordem de prioridade:
1. Modificação da estrutura de equipes do projeto;
2. Mover todas as equipes para mesma sala;
3. Apresentar planejamento estratégico da célula de serviços;
4. Estruturar equipes de central de serviço nos HUF’s;
5. Treinar todas as equipes nos conceitos (ITIL v3, Scrum, XP, Kanban) do novo
processo;
6. Apresentar a ferramenta de apoio para todas as equipes;
7. Apresentar catálogo de serviços para todas as equipes;
8. Apresentar novo processo para todas as equipes;
9. Apresentar método de trabalho para todas as equipes;
10. Acompanhar nos três primeiros sprints o dia a dia de todas as equipes a fim de
ensinar e inspecionar se o processo foi compreendido por todos e está sendo
seguido conforme o definido.
Com a relação de atividades definida, as mesmas devem ser executadas de acordo com o
seguinte cronograma:
105
Atividade Semana
1, 2 e 3 1
4 2
5 3
6 e 7 4
8 5
9 6
10 7, 8 e 9
Tabela 19 - Cronograma de Execução de Atividades de Implantação por Semana.
Na tabela 19, é apresentada a relação de atividades para implantação do novo processo
divididas em semanas, sendo que, de acordo com esta tabela a implantação deve ter duração
de nove semanas. Na próxima seção será apresentada a execução do planejamento de
implantação conforme cronograma visualizado na tabela 19.
6.2 Execução da Implantação
Esta seção tem o objetivo de descrever o andamento da atividade de número 10, citada na
seção anterior, que acompanha nos três primeiros sprints o dia a dia de todas as equipes a fim
de ensinar e inspecionar se o processo foi compreendido por todos e está sendo seguido
conforme o definido. As demais atividades do planejamento foram executadas conforme o
cronograma e são essenciais para o sucesso desta implantação.
Nas semanas anteriores à execução da atividade 10 iniciou-se a construção dos artefatos
de gerenciamento visual, a fim de se criar um ambiente informativo, conforme orientação do
XP. Na figura de número 25, é apresentado um calendário do mês de julho de 2012, onde
todas as equipes deveriam compartilhar da utilização deste, sendo que, foram criados
calendários para todos os demais meses até o final do ano de 2012 (vide Apêndice F).
A finalidade destes calendários é sincronizar e planejar as principais atividades que
devem ocorrer durante os meses do ano de 2012, com isso, as equipes se mantêm
devidamente alinhadas entre si, pois existem dependências entre o trabalho de cada uma
dessas equipes. Assim uma equipe consegue prever, com certa antecedência, atividades na
qual deve estar envolvida. Desta maneira, a comunicação ganha um reforço simples e visual.
106
Figura 25 - Calendário do Mês de Julho.
Ainda sobre a construção de um ambiente informativo que agregue valor no trabalho das
equipes da célula de serviços de TI do AGHU, foi elaborado um quadro para representar a
situação dos HUF’s, este segue na figura 26. Esta figura apresenta a situação em relação à
implantação de todos os HUF’s do Brasil, sendo que estes estão divididos por porte de 1 (para
hospitais menores) a 4 (para hospitais maiores).
Abaixo segue a legenda da figura 26:
• HUF’s escritos em vermelho representam hospitais de porte 4;
• HUF’s escritos em preto representam hospitais de porte 3;
• HUF’s escritos em verde representam hospitais de porte 2;
• HUF’s escritos em azul representam hospitais de porte 1.
107
Figura 26 - Situação HUF's.
Após a construção dos materiais citados anteriormente (figuras 25 e 26), iniciou-se a
montagem do Kanban, conforme definido no capítulo anterior.
A figura 27 apresenta o quadro de Kanban junto com o quadro de lições aprendidas, onde
pode-se perceber que o quadro foi dividido em cinco fases: iniciação; avaliação; execução;
validação; encerramento (conforme a definição descrita no capítulo anterior).
As fases de execução, avaliação e validação apresentam dois momentos, um
representando que está pronto para ser consumido pela próxima fase e outro representando
que está sendo consumido, conforme orientação da metodologia Kanban.
108
Figura 27 - Kanban e Quadro de Lições Aprendidas.
Segue a explicação de cada uma das etapas do Kanban (figura 27):
• Para Fazer (Iniciação): nesta etapa devem ser listadas as atividades mais
prioritárias a fim de ser realizadas nas próximas sprints, em uma comparação com
o Scrum, poderia ser chamada de Backlog do Produto;
• Avaliado (Avaliação): nesta etapa devem ser listadas as atividades que foram
avaliadas e serão executadas na sprint corrente, em uma comparação com o
Scrum, poderia ser chamada de Backlog da Sprint;
• Resp. (Responsável - Execução): esta etapa representa o membro da equipe
responsável pela execução de uma atividade. Como se pode ver na figura 27, cada
um dos papéis (em cor laranja) fixados nesta coluna representa um dos membros
desta equipe.
• Em Construção (Execução): nesta etapa devem ser fixadas atividades que
iniciaram sua construção;
• Construído (Execução): somente é considerado como “construído” a atividade
que estiver no estado “Aguardando Liberação para Staging”, conforme figura 24;
109
• Em Homolog. (Homologação - Validação): após liberação para o ambiente de
staging, pode se iniciar a homologação junto a central de serviços e está etapa
representa a execução da homologação;
• Homologado (Validação): neste deve ser listada todas as atividades que já estão
homologadas e prontas para ser colocada em ambiente de produção;
• Em Transição (Encerramento): atividades que iniciaram o processo de transição
a fim de disponibilizar estas em ambiente de produção;
• Pronto (Encerramento): representa que a atividade se encontra disponível em
produção.
Com o ambiente informativo e o Kanban construídos, é possível iniciar a execução de
todo o processo definido neste trabalho. Assim segue, na figura 28, a primeira reunião de
planejamento da sprint da equipe piloto.
Figura 28 - Planejamento da Sprint – Kanban.
Nessa primeira reunião de planejamento, houve um acompanhamento da equipe a fim de
explicar e entender se o processo está sendo executado de acordo com o que foi definido. Por
110
ser a primeira reunião de planejamento, apesar de ter sido efetuado os treinamentos
planejados na seção anterior, a equipe foi interrompida diversas vezes para uma melhor
explicação em alguns pontos. Pode-se perceber, através da figura 28, que os membros da
equipe já estavam executando algumas atividades e estas foram fixadas no Kanban seguindo
as definições.
Foi definido junto com a equipe um limite de três atividades por pessoa na fase de
execução, seguindo orientação da metodologia Kanban. Sendo que, esta limitação, além das
vantagens citadas na metodologia, deve promover uma melhor gestão do conhecimento bem
como a construção da ideia de um time, onde todos tem a mesma responsabilidade, porém
divididos em papéis diferentes, mas no final da sprint o time deve entregar tudo que se
comprometeu no planejamento.
Na figura 29, segue foto tirada do kanban na metade da semana.
Figura 29 - Kanban Metade da Semana.
Na figura apresentada (29) é possível verificar que o fluxo está sendo executado, restando
apenas uma atividade que ainda não iniciou sua execução. Também pode-se verificar que a
atividade definida como “Folga”, conforme orientação do XP, ainda não iniciou sua execução.
111
No decorrer da semana a equipe seguiu exatamente o processo definido, inclusive
respeitando o tempo máximo de cada reunião, ainda foi possível perceber alguma dificuldade
de alguns membros da equipe em trabalhar com o Kanban, por se tratar de uma mudança de
cultura. Entretanto todos se demonstraram motivados e acreditando nesse novo processo.
Durante a semana a equipe teve diversas conversas entre si com a finalidade de melhorar
o processo e nessa mesma semana já foi possível identificar algumas falhas internas através
de alguns gargalos apresentados no Kanban. Foi possível perceber de forma clara a promoção
da colaboração dessa equipe com todo o processo, que é um dos grandes objetivos do
processo descrito neste trabalho.
A próxima figura (Figura 30) nos apresenta a situação do Kanban após o planejamento da
segunda sprint de execução da implantação do novo processo.
Figura 30 - Kanban com início Nova Sprint.
Na figura 30 é interessante analisar alguns pontos, como por exemplo, nem todos os itens
da planejados na sprint anterior foram concluídos, alguns ficaram trancados na fase de
transição e outros na fase de homologação. Seguindo este exemplo é possível identificar
112
gargalos nesses pontos do fluxo de trabalho e a partir disso a equipe percebeu um ponto a
melhorar e iniciou a utilização do quadro de lições aprendidas. Ainda nesta figura é possível
perceber uma atividade lançada dentro do contexto de “folga” do XP e, além disso, a ideia de
limites por membro da equipe a fim de promover a troca de conhecimento, ninguém da equipe
está trabalhando em mais de três atividades.
O quadro de lições aprendidas que aparece nas figuras 28, 29 e 30, deve alavancar de
maneira colaborativa a melhoria contínua do processo executado pela equipe, os pontos fracos
devem estar relacionados a uma causa raiz e baseado nesta deve ser elaborado um plano de
ação ou atividade que será planejada pela equipe para ser executada dentro de uma sprint,
assim tem-se um processo melhoria cíclica.
Ao final da terceira semana de execução do novo processo foi reaplicado o instrumento
de avaliação a fim de validar os resultados obtidos, na próxima seção será detalhada essa nova
execução do instrumento.
6.3 Reaplicação do Instrumento de Avaliação
Nesta seção apresenta o resultado da reaplicação do instrumento de avaliação, definido no
capítulo 4 (tabelas 2, 3, 4 e 5), a fim de comparar os resultados obtidos antes a implantação do
processo descrito neste trabalho para que se tenha convicção do sucesso ou insucesso da
aplicação deste.
A primeira execução do instrumento de avaliação foi aplicada a dois membros da antiga
equipe de operação, entretanto a nova execução foi aplicada com seis membros na nova célula
de serviços de TI do AGHU, assim aumentando a amostragem do resultado.
O autor desta monografia não participou da amostragem inicial e nem da amostragem
final, sendo que a reaplicação do instrumento foi realizada novamente através da ferramenta
Google Docs e a média de suas respostas podem ser visualizados no Apêndice G.
Segue um pequeno resumo sobre o perfil de cada participante.
Participante 1
Tempo de experiência na área de TI: 19 anos
Tempo de experiência na área de serviços de TI: 11 anos
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de aplicação do AGHU:
113
• Líder de equipe de aplicação;
• Monitora bancos de dados utilizados Projeto AGHU;
• Monitora ambientes utilizados para o Projeto AGHU.
Participante 2
Tempo de experiência na área de TI: 8 anos
Tempo de experiência na área de serviços de TI: 5 anos
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de operação do AGHU:
• Líder de equipe de operação;
• Responsável pela sustentação e implantação do Projeto AGHU.
Participante 3
Tempo de experiência na área de TI: 6 anos
Tempo de experiência na área de serviços de TI: 1 ano
Tempo de experiência no Projeto AGHU: 1 ano e 3 meses
Atividades atuais na equipe de operação do AGHU:
• Desenvolvedor de sistemas;
• Resolução de incidentes e problemas relacionados ao Projeto AGHU;
• Instalações vinculadas ao Projeto AGHU.
Participante 4
Tempo de experiência na área de TI: 8 anos
Tempo de experiência na área de serviços de TI: 2 anos
Tempo de experiência no Projeto AGHU: 1 ano e 3 meses
Atividades atuais na equipe de operação do AGHU:
• Desenvolvedor de sistemas;
• Resolução de incidentes e problemas relacionados ao Projeto AGHU;
• Instalações vinculadas ao Projeto AGHU.
Participante 5
Tempo de experiência na área de TI: 9 anos
Tempo de experiência na área de serviços de TI: 2 anos
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de operação do AGHU:
• Desenvolvedor de sistemas;
114
• Resolução de incidentes e problemas relacionados ao Projeto AGHU;
• Instalações vinculadas ao Projeto AGHU.
Participante 6
Tempo de experiência na área de TI: 12 anos
Tempo de experiência na área de serviços de TI: 1 ano
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de operação do AGHU:
• Analista de Qualidade;
• Responsável pela garantia de qualidade do produto AGHU.
Tabela 20 - Perfil dos Participantes da Avaliação Final.
Para reaplicação desta avaliação foram realizados treinamentos, previstos no
planejamento de implantação, entre os participantes a fim de nivelar conhecimentos sobre as
boas práticas estudadas neste trabalho.
Na tabela 21 que segue são apresentados os resultados da reaplicação do instrumento de
avaliação, as informações estão agrupadas e somadas por grau de maturidade, conforme
realizado na avaliação inicial.
Gerência de
Serviços –
Projeto
AGHU
Inicial Repetível Definido Gerenciado Otimizado
Estratégia
de Serviço 1 4 17 27 17
Desenho de
Serviço 6 13 30 26 9
Transição
de Serviço 0 7 21 8 6
Operação de
Serviço 2 2 15 14 15
Melhoria
Contínua de
Processo
2 7 13 13 7
115
Scrum 3 10 13 32 32
XP 5 9 12 5 5
Kanban 0 0 3 3 18
Tabela 21 - Respostas da Reavaliação Agrupadas por Nível de Maturidade.
A figura 31 que segue apresenta os números descritos na tabela 21 sendo que os valores
foram transformados para percentual.
Figura 31 - Gráfico de Respostas da Reavaliação Agrupada por Nível de Maturidade.
Esta seção encerra este capítulo. No próximo capítulo será realizado uma análise dos
resultados obtidos.
116
7 ANÁLISE DOS RESULTADOS
O gráfico apresentado na figura 31 no capítulo anterior apresenta uma melhoria
significativa em relação ao resultado obtido na primeira execução do instrumento de avaliação
(figura 15). Neste é possível perceber que a média da maturidade ficou entre 3 e 4, apesar do
Kanban ter apresentado um excelente resultado.
A tabela 22 que segue apresenta a média da avaliação inicial comparada com a média
obtida na avaliação final separada por área de conhecimento de acordo com o instrumento de
avaliação.
Gerência de Serviços – Projeto AGHU Média (Inicial) Média (Final)
Estratégia de Serviço 1,54 3,83
Desenho de Serviço 1,45 3,22
Transição de Serviço 1,80 3,30
Operação de Serviço 2 3,8
Melhoria Contínua de Processo 1,43 3,38
Scrum 1,42 3,88
XP 1,61 2,88
Kanban 1,58 4,62
Tabela 22 – Média Comparativa entre Avaliações por Área de Conhecimento.
Através dos dados apresentados na tabela 22 foi obtido o gráfico comparativo (avaliação
inicial versus final) presente na figura 32.
117
Figura 32 - Gráfico Comparativo da Execução do Instrumento de Avaliação.
O gráfico comparativo apresentado na figura 32 resume em alto nível o resultado gerado
pela implantação do processo definido neste trabalho. A barra em azul corresponde à primeira
execução do instrumento de avaliação realizada com três participantes, membros da antiga
equipe de operação do projeto. A barra em vermelho corresponde a segunda execução do
instrumento de avaliação executado com seis participantes sendo todos membros da célula de
serviços.
Ficou claro, pela percepção da própria equipe da célula, que houve a implantação de um
processo que aproximou, o trabalho realizado por está célula, das boas práticas citadas neste
trabalho. Com isso o trabalho atinge seus objetivos e seguindo as boas práticas deve mudar a
situação desta célula, com um ambiente controlado, processos específicos, melhoria contínua
e promoção da colaboração aumentando assim a qualidade do atendimento.
Pela análise realizada, principalmente na figura 32, é possível perceber uma grande
melhoria no processo de acordo com a percepção dos próprios membros desta célula de
serviços. No intuito de relatar e analisar os resultados obtidos, este capítulo esta divido em
duas seções, onde serão relacionados os pontos positivos e negativos da implantação do novo
processo, e, além disso, também deve ser explicado como melhorar os pontos fracos
relacionados.
118
7.1 Análise de Pontos Positivos e Negativos
Após a execução final do instrumento de avaliação, mesmo que esse tenha obtido um
resultado satisfatório, foi possível identificar pontos positivos e negativos no novo processo
definido. Segue uma relação dos pontos positivos levantados durante a execução deste novo
processo:
1. Promoção da colaboração: durante a execução dos sprints ficou visível a
melhoria do comportamento das equipes, claro que ainda de uma forma cautelosa,
mas percebeu-se que uma certa motivação em querer melhorar;
2. Comunicação: um ponto fundamental e, junto com a promoção da colaboração, o
grande foco do novo processo. Este item demonstrou uma melhoria significativa
em relação ao entendimento da responsabilidade da equipe. Os membros
demonstraram preocupação no sucesso da conclusão da sprint e não apenas de
suas atividades.
3. Ambiente Informativo: ficou evidente a melhora na comunicação e alinhamento
entre equipes com a construção do ambiente informativo, as discussões passaram
a ser realizadas em frente ao quadro de Kanban ou no calendário, fazendo com
que a equipe tomasse decisões rápidas e em conjunto.
4. Melhoria Continua: aliado a essa mudança de cultura surge a melhoria continua,
fundamental nessa nova proposta de processo, entretanto a sugestão de melhoria
deve partir das equipes, no sentido da promoção da colaboração.
5. Organização: o novo processo organizou o trabalho realizado pela célula de
serviços, principalmente por seguir orientações da ITIL v3.
6. Trabalho em equipe: construção de um modelo de equipe de se trabalhar onde a
equipe toda possuí a mesma responsabilidade, o que acaba promovendo a troca de
conhecimentos a fim de atingir o objetivo da equipe.
Além dos pontos positivos, também foi possível identificar alguns pontos negativos:
1. Ferramenta de gerenciamento de serviços ainda não contempla todas as
necessidades;
2. Manter o controle do trabalho em duas ferramentas (Kanban e ferramenta de
apoio);
119
3. Workflow de incidentes e problemas ainda não contempla todas as necessidades
da célula de serviços de TI do AGHU;
4. Pouco foco no processo de gerenciamento de eventos da ITIL v3;
5. Falta de uma padronização de métricas.
Na próxima seção será realizada uma pequena análise dos pontos fracos citados.
7.2 Análise de Pontos a Melhorar
Baseado nos pontos negativos citados na seção anterior será realizado uma análise de
como aperfeiçoar tais pontos:
1. Ferramenta de gerenciamento de serviços ainda não contempla todas as
necessidades: deve ser levantado os pontos ainda pendentes e verificar a
possibilidade de customização da ferramenta ou a compra de outra;
2. Manter o controle do trabalho em duas ferramentas (Kanban e ferramenta
de apoio): no inicio a equipe não gostou muito da ideia de ter o controle do fluxo
de trabalho em dois locais, para solução deste ponto deve ser realizado
treinamentos para o entendimento dos conceitos entre todos da equipe;
3. Workflow de incidentes e problemas ainda não contempla todas as
necessidades da célula de serviços de TI do AGHU: ainda existem algumas
atividades não contempladas pelo o workflow definido, entretanto a ideia é focar
na melhoria continua e que todos da equipe contribuam para melhoria deste
workflow entendendo os pontos fracos e criando planos de ação para solução
destes;
4. Pouco foco no processo de gerenciamento de eventos da ITIL v3: mesmo
focado na fase de operação de serviço, este trabalho não abordou muito o
processo de gerenciamento de eventos. Este ponto é importante para que a célula
de serviços seja cada vez mais proativa e menos reativa na correção de incidentes,
para isso será necessário a elaboração de um planejamento a fim de solucionar
este ponto;
5. Falta de uma padronização de métricas: apesar de existir métricas (vide
Apêndice E) ainda falta uma padronização no processo de coleta e das próprias
métricas, no sentido de alinhar estas com o planejamento estratégico da célula.
120
Para melhorar este ponto, deve ser realizado um trabalho para se ter o
entendimento dos objetivos e baseado nestes criar as métricas a fim de verificar se
os resultados estão de acordo com o planejamento estratégico.
Com o detalhamento dos pontos, este capítulo se encerra. No próximo capítulo será
concluído este trabalho.
121
8 CONCLUSÃO
A oportunidade de realização deste trabalho nasceu devido ao Projeto AGHU e a
necessidade de constituir uma célula de serviços de TI a fim de sustentar este projeto em 46
Hospitais Universitários Federais. Esta célula de serviços já possuía uma estrutura, no
entanto, esta era insuficiente para os planos desejados para o projeto. Além disso, a equipe
não possuía maturidade em nível de processo ou qualquer outra boa prática conhecida para
gerenciamento de serviços.
Este trabalho se iniciou com o objetivo principal de definir e implantar um processo de
gerenciamento de serviços constituído com base na ITIL v3 com foco na fase de operação de
serviço e práticas ágeis aplicadas à realidade do Projeto AGHU, para assim, melhor atender as
necessidades dos HUF’s. Considera-se que o objetivo principal foi alcançado, pois hoje a
célula de serviços funciona com o processo definido neste trabalho.
Além disso, este trabalho possibilitou um melhor entendimento das boas práticas
sugeridas pela ITIL v3 e os métodos ágeis, o que norteou a definição do novo processo, bem
como o entendimento do contexto da área de serviços de TI para o Projeto AGHU, ponto
fundamental para estruturação deste. Após a execução, foi realizada uma reavaliação dos
resultados para assim verificar se houve o ganho esperado com o novo processo. Com isso
entende-se que o trabalho alcançou todos os objetivos inicialmente definidos.
O novo processo apresentou resultados positivos em comparação com a avaliação
realizada antes de sua implantação, sendo que, as duas avaliações foram realizadas por
membros da própria equipe de serviços de TI que já nas primeiras semanas de execução
levantaram pontos positivos e negativos. Os pontos negativos geraram atividades que deram
início ao ciclo de melhoria contínua sendo possível visualizar claramente a promoção da
colaboração.
Vale salientar também que este trabalho foi selecionado para a sessão de pôsteres do IX
Seminário de Gerenciamento de Projetos. Durante sua finalização foi enviado seu conteúdo
em formato de pôster para o IX Seminário de Gerenciamento de Projetos e este se deu por
vencedor (PMI, 2012).
Por fim, considera-se que um dos pontos mais relevantes deste trabalho, além das
melhorias que o novo processo trouxe para esta célula, foi o entendimento de que os
princípios ou valores são fundamentais para construção de qualquer processo, visto que este
122
trabalho uniu várias boas práticas a fim de constituir um processo que sempre esteve
preocupado com seus valores.
8.1 Limitações do Trabalho
Nesta seção serão comentadas algumas das limitações deste trabalho.
Uma das primeiras limitações que pode ser citada é em relação ao número pequeno de
pessoas que executaram o instrumento de avaliação. Com uma amostragem maior seria
possível ter números mais próximos da realidade.
Outra limitação enfrentada foi a falta recursos humanos que impossibilitou a formação do
número de equipes desejado neste trabalho. Devido a este problema a célula de serviços de TI
teve que ser formada inicialmente com três equipes que contemplaram a proposta do novo
processo, mas não da maneira desejada.
E por último, a necessidade do uso de ferramentas livres aliada à dificuldade de aquisição
de outra ferramenta, fez com que se tivesse poucas opções de ferramentas para gerenciamento
de serviços. Assim foram necessárias diversas alterações na ferramenta escolhida para que
esta atendesse às necessidades exigidas pelo processo definido neste trabalho e mesmo assim
não contemplou todo o necessário. Por este motivo ainda existe uma busca por outras
ferramentas que venham a suprir as necessidades restantes.
8.2 Trabalhos Futuros
Sempre existe a possibilidade de melhorar, e no caso deste trabalho, não seria diferente.
A proposta deste trabalho foi da aplicação da ITIL v3 utilizando práticas ágeis focada apenas
no processo de operação do serviço, ou seja, além da possibilidade de melhorar esta proposta,
ainda existe mais quatro fases da ITIL v3 que podem gerar trabalhos futuros.
Especificamente, no tema deste trabalho, seria possível explorar ainda mais a
metodologia Kanban aliada a metodologias ágeis como Scrum e XP para a execução de
serviços de TI baseada na ITIL v3, e na fase de operação de serviço ainda seria possível
aprofundar mais no processo de gerenciamento de eventos. Sugire-se ainda foco na fase de
melhoria contínua de processo, por considerar uma das principais fases da biblioteca da ITIL
v3.
123
Independente do trabalho que for realizado é fundamental que se tenha cuidado com o
número de pessoas que poderão participar da avaliação do instrumento de pesquisa, pois uma
das limitações deste trabalho foi exatamente o baixo número de pessoas que responderam o
instrumento. Além do instrumento de avaliação, seria interessante a comparação de métricas
ou indicadores antes e depois da implantação do trabalho para melhor entender os resultados.
124
REFERÊNCIAS BIBLIOGRÁFICAS
BECK, Kent et al. Manifesto Ágil. Disponível em <http://agilemanifesto.org>, 2001. Último
acesso em: 23/08/2012.
BECK, Kent. Extreme Programming. Disponível em <http:// extremeprogramming.org>,
2009. Último acesso em: 23/08/2012.
BOEG, Jasper. Priming Kanban - A 10 step guide to optimizing flow in your software
delivery system. Denmark: Chronografisk A/S, 2011.
BON, Jan van. IT Service Management: An Introduction. Van Haren Publishing, 2002.
LANG, Jean. Redmine. Disponível em <http://redmine.org/ >, 2006. Último acesso em:
23/08/2012.
KNIBERG, Henrik. Scrum e XP direto das Trincheiras. United States of America:
C4Media Inc., 2004.
MEC, Ministério da Educação. Projeto AGHU. Disponível em <http:// aghu.mec.gov.br>,
2009. Último acesso em: 23/08/2012.
OGC, Office of Government Commerce. ITIL v3 The Official Introdution to the ITIL
Service Lifecycle. United Kingdom: The Stationery Office, 2007a.
OGC, Office of Government Commerce. ITIL v3 Service Strategy. United Kingdom: The
Stationery Office, 2007b.
OGC, Office of Government Commerce. ITIL v3 Service Design. United Kingdom: The
Stationery Office, 2007c.
125
OGC, Office of Government Commerce. ITIL v3 Service Transition. United Kingdom: The
Stationery Office, 2007d.
OGC, Office of Government Commerce. ITIL v3 Service Operation. United Kingdom: The
Stationery Office, 2007e
OGC, Office of Government Commerce. ITIL v3 Service Improvement. United Kingdom:
The Stationery Office, 2007f
PMI, Project Management Institute. IX Seminário de Gerenciamento de Projetos.
Disponível em <http://www.seminario.pmirs.org.br/site/home>, 2012. Último acesso em:
24/09/2012.
PMI, Project Management Institute. Um Guia do Conjunto de Conhecimentos em
Gerenciamento de Projetos Quarta Edição (PMBOK). Pennsylvania: Project Management
Institute Inc., 2008.
RASMUSSON, Jonathan. The Agile Samurais - How Agile Masters Deliver Great
Software. United States of America: Susannah Davidson Pfalzer, 2010.
SKARIN, Mattias et al. Kanban e Scrum - obtendo o melhor de ambos. United States of
America: C4Media Inc., 2009.
SCHWABER, Ken et al. Guia do Scrum. Disponível em <http://scrum.org/scrumguides/>,
2011. Último acesso em: 23/08/2012.
126
APÊNDICE A – Dados coletados no instrumento de avaliação
Questão Participante 1 Participante 2 Participante 3
1 2 1 2
2 2 1 1
3 1 1 1
4 2 2 2
5 2 2 2
6 1 2 1
7 1 1 1
8 1 1 1
9 2 2 2
10 1 2 2
11 1 2 1
12 1 2 1
13 2 2 2
14 2 2 2
15 1 2 1
16 1 1 1
17 1 1 1
18 1 1 1
19 2 2 2
20 1 2 2
21 2 2 2
22 2 2 1
23 1 2 1
24 1 2 1
25 2 2 2
26 2 2 2
27 2 2 2
28 2 1 2
127
29 2 1 2
30 1 1 2
31 1 1 1
32 1 1 2
33 1 2 2
34 1 1 1
35 1 1 2
36 2 2 2
37 1 2 1
38 2 3 3
39 1 1 2
40 2 3 2
41 2 3 2
42 1 3 1
43 2 2 2
44 2 1 2
45 2 1 2
46 2 1 2
47 2 1 2
48 1 1 1
49 1 1 1
50 1 1 1
51 2 1 2
52 2 1 2
53 1 1 1
54 1 1 1
55 1 1 1
56 1 1 1
57 1 3 1
58 1 1 2
59 2 2 2
60 1 3 1
128
61 2 2 2
62 1 1 1
63 1 2 2
64 2 2 2
65 2 3 2
66 2 2 2
67 1 1 2
68 2 3 2
69 1 2 1
70 2 5 2
71 1 1 1
72 1 1 1
Média 1,46 1,68 1,58
Tabela 23 - Dados Primeira Execução do Instrumento de Avaliação.
129
APÊNDICE B – Fluxo completo de uma requisição de serviço
Figura 33 - Workflow Completo Requisições de Serviço.
130
APÊNDICE C - Fluxo completo de um incidente ou problema
Figura 34 - Workflow Completo Incidentes e Problemas.
131
APÊNDICE D – Catálogo de serviços
Nível 1 Nível 2 Nível 3 Descrição do serviço Equipe
Como
solicitar o
serviço
1º Nível
Atendimento
prove
suporte
inicial?
Banco de Dados
Alteração Estrutural
Qualquer mudança de estrutura nos bancos suportados pelo time do AGHU.
Sustentação - Aplicação
Ferramenta de Apoio.
Banco de Dados
Configuração Manutenção de configuração nos bancos suportados pelo time do AGHU.
Sustentação - Aplicação
Ferramenta de Apoio.
Banco de Dados
Carga de Dados
Manutenção dos dados nos bancos suportados pelo time do AGHU.
Sustentação - Aplicação
Ferramenta de Apoio.
Banco de Dados
Esperanto Carga de Dados Manutenção das tabelas do banco de dados denominado Esperanto.
Sustentação - Aplicação
Ferramenta de Apoio.
Banco de Dados
Parametrização Manutenção da tabela AGH_PARAMETROS.
Sustentação - Aplicação
Ferramenta de Apoio.
Banco de Dados
Versionamento Aplicação de Objetos de Banco. Versionamento do banco conforme a aplicação.
Sustentação - Aplicação
Ferramenta de Apoio.
132
Banco de Dados
Publicação Aplicação de mudanças no banco de dados em ambientes.
Sustentação - Aplicação
Ferramenta de Apoio.
Banco de Dados
Backup "Criação de scripts para agendamento de backup de dados. Validação periódica dos agendamentos de backup."
Sustentação - Aplicação
Ferramenta de Apoio.
Banco de Dados
Restore Restaurar o backup da base de dados.
Sustentação - Aplicação
Ferramenta de Apoio.
Banco de Dados
Sequence Manutenção de sequence de banco de dados.
Sustentação - Aplicação
Ferramenta de Apoio.
Banco de Dados
Permissões Manutenção de permissões de banco de dados.
Sustentação - Aplicação
Ferramenta de Apoio.
Software Aplicação Publicação Compilar aplicação no ambiente solicitado e publicar no respectivo servidor.
Sustentação - Aplicação
Ferramenta de Apoio.
Software Integração Contínua
Novo serviço Solicitar automação de processos.
Sustentação - Aplicação
Ferramenta de Apoio.
Software Integração Contínua
Manutenção dos serviços existentes
Alterar serviços existentes na ferramenta de automação.
Sustentação - Aplicação
Ferramenta de Apoio.
Software Qualidade Automatização de Testes - Execução
Execução de Testes Automatizados para liberação de nova versão.
Sustentação - Operação
Ferramenta de Apoio.
Software Configuração Criação de branch / Tag
Criar novo repositório de desenvolvimento.
Sustentação - Aplicação
Ferramenta de Apoio.
133
Software Configuração Manutenção de branch / Tag
Restaurar, alterar e excluir repositórios de desenvolvimento.
Sustentação - Aplicação
Ferramenta de Apoio.
Software Configuração Realização de Merge
Realizar a manutenção de revisions entre respositórios diferentes.
Sustentação - Aplicação
Ferramenta de Apoio.
Software Configuração Liberação de Versão
Criar versão definitiva de ambiente.
Sustentação - Aplicação
Ferramenta de Apoio.
Software Manutenção Perfis Configuração de Perfis do AGHU.
Sustentação - Delivery
Ferramenta de Apoio.
Sim
Software Manutenção Impressoras Configuração de impressoras para impressão no AGHU.
Sustentação - Delivery
Ferramenta de Apoio.
Sim
Software Manutenção Usuários Configuração dos usuários cadastrados no AGHU.
Sustentação - Delivery
Ferramenta de Apoio.
Sim
Software Manutenção Unidades Funcionais
Cadastrar, vincular impressoras, editar e excluir unidades funcionais.
Sustentação - Delivery
Ferramenta de Apoio.
Sim
Software Manutenção Parâmetros Configuração de parâmetros de sistema.
Sustentação - Delivery
Ferramenta de Apoio.
Sim
Software Manutenção Reindexação Reindexação de tabelas como: AipCidades, AipTipoLogradouros, AipSinonimosOcupacao, AipOcupacoes, AipLogradouros.
Sustentação - Operação
Ferramenta de Apoio.
Sim
Software Manutenção Refonetização Refonetizar software de busca Lucene.
Sustentação - Operação
Ferramenta de Apoio.
Sim
Software Manutenção Microcomputadores Cadastrar, editar, Sustentação - Ferramenta Sim
134
associar ou excluir microcomputadores.
Operação de Apoio.
Software Manutenção Arquitetura Qualquer problema identificado na arquitetura da aplicação.
Arquitetura Ferramenta de Apoio.
Software Manutenção Pacientes Serviços, Incidentes ou Problemas encontrados na aplicação no módulo de Pacientes.
Sustentação - Operação
Ferramenta de Apoio.
Software Manutenção Internação Serviços, Incidentes ou Problemas encontrados na aplicação no módulo de Internação.
Sustentação - Operação
Ferramenta de Apoio.
Software Manutenção Prescrição Médica Serviços, Incidentes ou Problemas encontrados na aplicação no módulo de Prescrição Médica.
Sustentação - Operação
Ferramenta de Apoio.
Software Manutenção Indicadores Hospitalares
Serviços, Incidentes ou Problemas encontrados na aplicação no módulo de Indicadores.
Sustentação - Operação
Ferramenta de Apoio.
Software Manutenção Farmácia Serviços, Incidentes ou Problemas encontrados na aplicação no módulo de Farmácia.
Sustentação - Operação
Ferramenta de Apoio.
Software Manutenção Registro Colaborador
Serviços, Incidentes ou Problemas encontrados na aplicação no módulo de Registro Colaborador.
Sustentação - Operação
Ferramenta de Apoio.
Software Manutenção Ambulatório Serviços, Incidentes ou Problemas encontrados
Sustentação - Operação
Ferramenta de Apoio.
135
na aplicação no módulo de Ambulatório.
Software Manutenção Estoque Serviços, Incidentes ou Problemas encontrados na aplicação no módulo de Estoque.
Sustentação - Operação
Ferramenta de Apoio.
Software Manutenção Exames Serviços, Incidentes ou Problemas encontrados na aplicação no módulo de Exames.
Sustentação - Operação
Ferramenta de Apoio.
Software Manutenção Controle de Pacientes
Serviços, Incidentes ou Problemas encontrados na aplicação no módulo de Controle de Pacientes.
Sustentação - Operação
Ferramenta de Apoio.
Software Manutenção SICON Serviços, Incidentes ou Problemas encontrados na aplicação no módulo SICON.
Sustentação - Operação
Ferramenta de Apoio.
Software Manutenção Outros Serviços, Incidentes ou Problemas encontrados na aplicação.
Sustentação - Operação
Ferramenta de Apoio.
Implantação Inspeção Viagens, Relatórios, Reuniões, etc. Tudo que for referente a etapa de inspeção de HUF’s.
Sustentação - Delivery
Ferramenta de Apoio.
Implantação Instalação Toda a instalação necessária para implantar o AGHU.
Sustentação - Delivery
Ferramenta de Apoio.
Implantação Treinamento Treinamentos em geral. Sustentação - Delivery
Ferramenta de Apoio.
136
Implantação Testes Automatizado Testes automatizados para garantir a qualidade da versão que se deseja implantar.
Sustentação - Delivery
Ferramenta de Apoio.
Implantação Testes Regressional Testes regressionais para garantir a qualidade da versão que se deseja implantar.
Sustentação - Delivery
Ferramenta de Apoio.
Implantação Suporte Suporte ou apoio em atividades do planejamento de implantação.
Sustentação - Delivery
Ferramenta de Apoio.
Redmine Inclusão Inclusão de novos usuários, projetos, tipos de tarefas, etc.
Sustentação - Delivery
Ferramenta de Apoio.
Redmine Alteração Alteração de dados de usuários cadastrados, projetos, tarefas, etc.
Sustentação - Delivery
Ferramenta de Apoio.
Redmine Exclusão Exclusão de dados de usuários cadastrados, projetos, tarefas, etc.
Sustentação - Delivery
Ferramenta de Apoio.
Redmine Treinamento Treinamento de como solicitar um serviço para equipe de suporte do AGHU pelo Redmine.
Sustentação - Delivery
Ferramenta de Apoio.
Redmine Coaching Coaching de como melhor utilizar a ferramenta para solicitar um serviço para equipe de suporte do AGHU pelo Redmine.
Sustentação - Delivery
Ferramenta de Apoio.
137
Redmine Dúvida Diversas Dúvidas em relação a ferramenta, desde que tenham relação com o AGHU.
Sustentação - Delivery
Ferramenta de Apoio.
Infraestrutura Instalação SVN Instalar SVN. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Jboss Instalar Jboss. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Postgres Instalar PostgreSQL. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Redmine Instalar Redmine. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Maven Instalar Maven. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Archiva Instalar Archiva. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Jenkins Instalar Jenkins. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação CUPS Instalar CUPS. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Pentaho Instalar software de business intelligence - Pentaho.
Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação LDAP Instalar LDAP. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Servidor Instalar Servidor. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Rede Instalar Rede. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Storage Instalar Storage. Infraestrutura Ferramenta de Apoio.
138
Infraestrutura Instalação Firewall Instalar Firewall. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Monit Instalar Monit. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Gateway SSH Instalar gw ssh. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Apache Instalar Apache. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação XenServer Instalar XenServer(appliances).
Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação DNS Instalar DNS. Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação Monitoramento Instalar ferramentas para monitoramento.
Infraestrutura Ferramenta de Apoio.
Infraestrutura Instalação SO Instalar Sistema Operacional.
Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Jboss Manutenção do Jboss. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção PostgreSQL Manutenção do PostgreSQL.
Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Redmine Manutenção do Redmine.
Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Maven Manutenção do Maven. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Archiva Manutenção do Archiva. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Jenkins Manutenção do Jenkins. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção CUPS Manutenção do CUPS. Infraestrutura Ferramenta de Apoio.
Sim
139
Infraestrutura Manutenção Pentaho Manutenção do Pentaho. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção LDAP Manutenção de LDAP. Infraestrutura Ferramenta de Apoio.
Sim
Infraestrutura Manutenção Servidor Manutenção de Servidor.
Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Rede Manutenção de Rede. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Storage Manutenção de Storage. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Firewall Manutenção de Firewall.
Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Monit Manutenção Monit. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Gateway SSH Manutenção gw ssh. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Apache Manutenção Apache. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção XenServer Manutenção XenServer (appliances).
Infraestrutura Ferramenta de Apoio.
Sim
Infraestrutura Manutenção DNS Manutenção DNS. Infraestrutura Ferramenta de Apoio.
Sim
Infraestrutura Manutenção SO Manutenção SO. Infraestrutura Ferramenta de Apoio.
Infraestrutura Manutenção Monitoramento Manutenção das ferramentas de monitoramento.
Infraestrutura Ferramenta de Apoio.
Sim
Suporte Dúvidas Diversas Dúvidas sobre o AGHU. Todas Ferramenta de Apoio.
Suporte Dúvidas Usabilidade Dúvidas sobre usabilidade do AGHU.
Todas Ferramenta de Apoio.
Sim
140
Suporte Dúvidas Negócio Dúvidas sobre negócio do AGHU.
Todas Ferramenta de Apoio.
Sim
Suporte Informações Diversas Informações sobre o AGHU.
Todas Ferramenta de Apoio.
Tabela 24 - Catálogo de Serviços
141
APÊNDICE E – Métricas
O gráfico que segue (figura 35) representa o número total de requisições (serviços,
incidentes e problemas) que são registradas por sprint para célula de serviços de TI do
AGHU. Com essa informação é possível analisar a demanda operacional existente e com isso
entender quais os momentos aonde será necessário maior ou menor capacidade a fim de
melhor sustentar as demandas registradas.
Figura 35 - Número de Requisições Registradas por Sprint.
Segue, na figura 36, o número total de requisições (serviços, incidentes e problemas) que
são concluídas por sprint pela célula de serviços de TI do AGHU. Com essa informação é
possível analisar a capacidade de resposta da equipe a cada sprint.
142
Figura 36 - Número de Requisições Concluídas por Sprint.
A próxima ilustração (figura 37) representa o número total de requisições de tipo
“Serviço” que são registradas por sprint para célula de serviços de TI do AGHU. Com essa
informação é possível analisar a demanda operacional existente especificamente para o tipo
“Serviço”.
143
Figura 37 - Número de Requisições de Tipo “Serviço” registradas por Sprint.
Na figura 38, o gráfico apresentado representa o número total de requisições de tipo
“Incidente” que são registradas por sprint para célula de serviços de TI do AGHU. Com essa
informação é possível analisar a demanda operacional existente especificamente para o tipo
“Incidente”.
144
Figura 38 - Número de Requisições do Tipo “Incidente” registradas por Sprint.
Segue, na figura 39, ilustração que representa o número total de requisições por item do
catálogo de serviços que são registradas por sprint para célula de serviços de TI do AGHU.
Com essa informação é possível analisar toda demanda existente especificamente por item do
catálogo de serviço. Possibilitando o conhecimento dos serviços mais solicitados bem como
os menos solicitados.
145
Figura 39 - Número de Requisições por Item do Catálogo de Serviços.
No gráfico que segue, representado na figura 40, representa o número total de requisições
que são registradas por HUF para célula de serviços de TI do AGHU. Com essa informação é
possível analisar toda demanda registrada por Hospital Universitário Federal.
Figura 40 - Número de Requisições Registradas por HUF.
146
Na figura 41 que segue, é apresentado um gráfico com o número total de requisições que
são registradas por prioridade de atendimento para célula de serviços de TI do AGHU. Com
essa informação é possível analisar toda demanda registrada dividida por prioridade e com
isso melhor entender a qualidade do serviço entregue.
Figura 41 - Número de Requisições por Prioridade.
147
APÊNDICE F – Exemplos de Ambiente Informativo
Figura 42 - Calendário do Mês de Agosto.
Figura 43 - Calendário Meses de Setembro e Outubro.
148
APÊNDICE G – Dados coletados na reavaliação do instrumento de pesquisa
Questão Part. 1 Part. 2 Part. 3 Part. 4 Part. 5 Part. 6
1 3 3 4 4 4 5
2 3 3 5 5 4 4
3 4 3 3 3 4 3
4 4 4 5 5 5 4
5 4 3 5 5 4 5
6 4 4 5 5 4 5
7 4 4 5 5 4 5
8 3 3 4 4 4 3
9 2 2 5 3 4 2
10 2 4 5 4 3 2
11 2 4 3 3 4 2
12 2 4 3 3 4 3
13 2 4 3 4 3 1
14 4 4 5 5 4 3
15 5 4 1 3 5 3
16 2 2 2 3 3 1
17 3 2 1 1 5 1
18 2 1 4 4 5 3
19 3 4 5 5 4 3
20 2 3 2 2 4 3
21 3 3 5 4 4 3
22 3 1 5 5 4 2
23 2 3 4 4 4 4
24 3 2 3 3 3 3
25 3 2 4 4 4 2
26 3 2 5 3 5 3
27 3 4 4 4 5 3
28 3 2 5 3 4 3
149
29 2 3 3 3 3 3
30 3 3 4 3 3 3
31 3 3 5 4 4 3
32 3 4 5 5 4 4
33 3 3 3 4 4 4
34 3 3 1 3 3 3
35 3 3 4 4 4 2
36 3 3 4 3 4 2
37 1 3 1 3 3 2
38 4 4 5 5 5 5
39 4 2 5 5 4 4
40 3 4 5 5 5 4
41 3 4 5 5 5 4
42 3 4 3 4 4 3
43 3 4 3 5 4 3
44 3 4 5 5 5 4
45 3 4 5 5 4 5
46 3 1 1 2 4 1
47 3 4 5 5 4 4
48 2 3 5 5 4 5
49 2 2 5 3 3 5
50 3 4 5 5 4 4
51 3 4 5 5 4 4
52 2 4 5 5 4 4
53 2 4 5 5 4 5
54 2 4 5 5 4 5
55 2 4 5 5 4 5
56 2 4 5 5 4 4
57 2 5 5 5 4 5
58 2 4 5 4 4 4
59 3 2 3 2 3 2
60 2 2 3 3 3 1
150
61 3 2 3 3 3 3
62 1 2 1 1 3 1
63 2 3 4 3 4 3
64 2 3 5 3 4 3
65 3 4 5 4 4 4
66 2 3 5 5 3 2
67 2 4 5 4 4 3
68 3 4 5 5 5 4
69 3 4 5 5 5 5
70 4 5 5 5 5 5
71 3 5 5 5 5 5
72 3 5 5 4 5 5
Média 2.76 3.29 4.11 4 4.01 3.375
Tabela 25 - Dados Segunda Execução do Instrumento de Avaliação.