Gerência de Projetos

Ξ 1 comentário

Projetos e boas práticas, será que realmente sabem o que estão implantando?

publicado por Tiago Santos

Falando de Implantação podemos dizer que executar a ‘melhor’ prática significará que a empresa como um todo será mais eficiente e bem sucedida? Significará que reduziremos custos, venderemos mais e lucraremos mais? Significará que vamos satisfazer nossos clientes e produzir produtos cada vez melhores? Será mesmo? A resposta depende de vários fatores. A começar do próprio entendimento do que é ITIL.

Sob uma perspectiva bastante realista, ITIL é um conjunto de livros que um grupo de consultores experientes escreveu e que, na perspectiva do grupo, consolida um conjunto de conceitos e boas práticas para ‘gerenciar serviços de TI’. Esse conjunto de práticas não é uma receita de sucesso pronta para uso, mas uma referência que pode e deve ser adaptada à realidade de cada organização para o atingimento de objetivos específicos. Além disso, mesmo considerando que diversas passagens foram baseadas em estudos acadêmicos e que eles passaram por uma extensa revisão por profissionais de TI de todo o mundo, ITIL não é uma compilação acadêmica ou um conjunto de regras que todos são ‘obrigados’ a seguir, mas uma referência de práticas, construída por profissionais qualificados e experientes.

O lado bom (ou não) dessa história é que para o domínio de IT Service Management há poucas alternativas tão consistentes e completas como o conjunto de práticas do ITIL. Isso o torna, no mínimo, uma referência para qualquer organização de TI. Para domínios como Enterprise Architecture e controles de governança corporativa de TI existem outras referências como TOGAF e COBIT. No caso do ITIL, temos uma referência de ‘boas práticas’ diga-se, porque sem uma comparação rigorosa com outra referência, não há como dizer que é a ‘melhor’ prática. Evidentemente, isso não diminui a sua importância, mas apenas reforça que devemos ter uma abordagem muito pragmática e orientada a resultados, evitando cair na armadilha de usar a biblioteca para ditar ‘regras’ ou exigir que se implemente modelos rígidos de como somos ‘obrigados’ a operar. ITIL não exige nada, ITIL apenas orienta. E o objetivo não é implementar um modelo acadêmico, mas simplesmente melhorar a prestação de serviços.

Chegamos então a outro ponto chave: ninguém deve implementar ITIL como um objetivo por si só. Pense bem, na realidade o objetivo não é ‘implementar ITIL’, mas sim, melhorar o serviço que se presta ao negócio, tornar TI mais estratégica para o negócio, integrar a operação de TI a necessidades específicas do negócio. O objetivo é esse. Não é ‘implementar ITIL’. Notem que o livro verde da versão 2 se chamava ‘Planning to Implement Service Management’ e não ‘Planning to Implement ITIL’. E não é por acaso. Implementações de ITIL são na verdade projetos dentro de programas de melhoria do serviço. Isso significa que estamos, na verdade, implementando um conjunto de práticas que terão impacto positivo na prestação de serviços e não ‘implementando ITIL’.

Paradoxalmente, um dos primeiros passos de programas como esse costumam ser assessments de nível de maturidade de processos, mesmo que o objetivo final seja prestar melhores serviços. Assessments ITIL costumam usar a avaliação inicial como baseline, em seguida realizam o programa de melhoria com um determinado objetivo de evolução e em um momento posterior refazem o assessment para determinar a evolução de fato. Na teoria, essa estratégica parece bastante lógica e consistente. Na prática, assessments focados APENAS em níveis de maturidade do processo formam, no mínimo, um retrato incompleto. A versão 3 da biblioteca trouxe uma visão mais ampla das dimensões que compõe o serviço de TI, mas muitos ainda continuam usando apenas os níveis de maturidade de processo como referência. O problema é que não há como saber, por exemplo, se uma organização com nível de maturidade X no processo Y terá a mesma qualidade de serviço de outra organização com o mesmo nível de maturidade. Ou mesmo se atingir o nível de maturidade esperado automaticamente significará uma melhora na prestação do serviço.

O fato é que ‘qualidade na prestação de serviços’ ainda é um conceito subjetivo, apesar dos esforços na criação de referências de qualidade. Assessments de nível de maturidade de processo dificilmente conseguem estabelecer algum tipo debenchmarking de qualidade de serviço (talvez qualidade de processo?). Um dos principais motivos é justamente o fato de que a correlação entre maturidade de processo e qualidade de serviço pode ser nebulosa, principalmente se não houver uma correlação explícita. A certificação ISO 20000 (que certifica um ou mais ‘serviços prestados’) é uma possível referência, mas o resultado final de ‘certificado’ não garante que um serviço terá a qualidade necessária aos olhos do negócio e dos usuários.

A conclusão que chegamos é que é preciso complementar baselines de maturidade de processos e certificações de qualidade, com informações de como as práticas e entregáveis de programas de ITSM suportam objetivos de negócio. Nem sempre os ganhos práticos de se chegar a um nível de maturidade 3 no processo X são deixados claros e a explicação pode ser um processo tão tortuoso que me faz perguntar se estamos realmente falando a linguagem do negócio ou estamos criando uma linguagem própria, apenas inteligível para os conhecedores de ITSM. E não estou falando de coisas muito diferentes do que já fazemos. Tarefas tão simples como ‘fazer uma reunião de revisão de nível de serviço’ ou ‘fornecer um relatório de disponibilidade’ podem continuar fazendo parte dos nossos assessments. Só não podemos deixar de vincular essas práticas com a qualidade final do serviço prestado, com eventuais ganhos financeiros ou com qualquer outra forma de influência no sucesso da empresa. Esse racional nem sempre é montado ou porque apenas um escala numérica de maturidade é utilizada ou porque se considera que os benefícios para o negócio serão ‘automáticos’, sem um trabalho explícito de vinculação de práticas específicas a objetivos de negócio. Em casos extremos, o cliente acaba tendo a sensação que foi implantada uma névoa sem forma ou valor definido e que ‘implantação de ITIL’ é um longo e tortuoso caminho para…nada. Ou quase nada.

Assim, uma ‘implantação de ITIL’ deve ser um programa de melhoria dos serviços, suportado por um ou mais projetos, cujo objetivo final é implantar práticas que terão impacto direto em objetivos de negócio específicos. ITIL será simplesmente um conjunto de práticas de referência para montar o baseline atual e futuro, mas não será o objetivo em si. Isso desmistifica a noção de que podemos comprar um ‘conjunto básico’ de implantação de ITIL ou mesmo um ‘ITIL out-of-the-box’. Esses termos são usados por alguns fabricantes de software que tentam vender o conceito de que ao implantar o software você terá magicamente implantado um ‘ITIL básico’, for beginners. Pois mesmo que a ferramenta possa embutir workflows, papéis ou mesmo funcionalidades que a biblioteca cita, se isso não irá ajudar a empresa em objetivos específicos, porque implantar? Se não há um mapeamento claro de como uma implantação dessas vai ajudar, os benefícios nem sempre ficarão evidentes. Em alguns casos, podem nem existir.

E sem querer jogar a culpa em apenas uma parte: essas implantações podem começar tortas por causa do próprio cliente. Se o cliente não tem objetivos muito claros em mente, demonstrar o valor da implantação pode ser um jogo sem fim. O problema é deixar de questionar isso e vender a implantação sem explorar junto ao cliente quais são seus objetivos finais. É preciso questionar porque o cliente quer, qual o objetivo de negócio associado, quais os objetivos de curto e longo prazos. O próprio objetivo do cliente pode refletir o seu nível de maturidade. Um cliente que diz que quer implantar ITIL simplesmente porque o mercado está fazendo ou porque precisa emitir ‘relatórios’, ainda não compreendeu o que representa um projeto como esse. Um cliente que diz que ‘precisa se aproximar do negócio e não funcionar de forma isolada’ está definitivamente no caminho certo. Evidentemente, existem casos em que o cliente quer simplesmente implantar uma ferramenta. Se for esse o caso, é nosso papel deixar claro o que exatamente ele vai obter no final.

A estratégia de implantação é outro ponto que exige atenção. É preciso entender que programas de melhoria não costumam envolver apenas um projeto. O que se convencionou chamar de ‘implantação de ITIL’ é geralmente o projeto inicial de implantação de alguns grandes milestones, como a criação de um ponto único de contato para o atendimento ao usuário, a nomeação de donos de processos e a implantação de ferramentas de Service Desk ou CMDB. Esse poderia ser o programa pai, mas ele representa apenas um começo. Para realmente colher os frutos, é preciso ter um foco especial na melhoria contínua e no acompanhamento das práticas. É sempre possível melhorar, seja atualizando as práticas atuais, implantando novas ou fazendo automações em áreas como monitoração e reporting. Esses novos projetos devem ser implantados através de programas de melhoria que seguem o mesmo racional do programa pai. A cada nova prática implantada, um baseline preciso deve ser definido, com objetivos de negócio claros e acompanhamento rigoroso. Como exemplo, mostro um baseline de práticas e entregáveis para uma pequena parte dos processos que suportam o serviço de faturamento de uma empresa:

Objetivo de negócio 1: Melhorar a confiabilidade do processo de faturamento, diminuindo a quantidade e duração das indisponibilidades do sistema que afetam a capacidade dos usuários de completar uma transação de faturamento.

Serviço de negócio: Faturamento

Melhoria proposta 

Gerenciamento de Disponibilidade
Prática atual Prática / entregável futuroImpacto na prestação de serviço
1Não há relatório de disponibilidade do serviço de faturamento.Definir critério para medição da disponibilidade do serviço e confeccionar relatório sob a perspectiva do usuário final, incluindo duração e quantidade de ocorrências em que foi impossível completar uma transação completa de faturamento.Os índices de disponibilidade total e confiabilidade serão conhecidos e será possível estabelecer obaseline inicial para melhoria.

Gerenciamento de Capacidade

Prática atualPrática / entregável futuroImpacto na prestação de serviço
1Monitoração incompleta de capacidadeMonitoração da capacidade dos componentes que compõe o serviço e vinculação entre métricas de capacidade de componentes e serviçosSerá possível entender como a volumetria de transações afeta a utilização dos componentes de infraestrutura, abrindo a possibilidade para realizar um planejamento de capacidade baseado no número de transações.
2Não há avaliações de demanda e capacidade baseadas em padrões de atividade de negócioRealização periódica do planejamento de capacidade baseado nos padrões de atividade do faturamento.Otimização dos gastos em infraestrutura, de acordo com a necessidade de negócio.
Gerenciamento de Nível de Serviço
Prática atualPrática / entregável futuroImpacto na prestação de serviço
1Não há SLAs acordados.SLA definido e acordado para o sistema de faturamento.Um critério de qualidade para o sistema de faturamento é acordado entre as partes.
2Não há reuniões de acompanhamento de SLA.Reuniões periódicas de revisão do SLA acordado.O atingimento e o próprio critério de qualidade é continuamente revisto para verificar se os índices esperados de disponibilidade e confiabilidade são adequados e estão sendo atingidos.

Gerenciamento de Configuração

Prática atualPrática / entregável futuroImpacto na prestação de serviço
1A configuração do serviço não é conhecida e nem controlada.Os itens de configuração que suportam o serviço, seus atributos e relacionamentos serão armazenados em uma base controlada.Componentes e atributos que impactam a prestação do serviço dentro dos índices de qualidade esperados serão conhecidos e controlados.
Gerenciamento de Mudanças
Prática atualPrática / entregável futuroImpacto na prestação de serviço
1Mudanças são realizadas sem que as áreas de negócio sejam envolvidas.Haverá envolvimento das áreas de negócio que participam do processo de faturamento.Janelas de mudança serão acordadas de forma a minimizar o impacto no processo de faturamento.

Notem como o valor de cada nova prática está claramente definido e o entendimento do impacto na prestação de serviço é feito de forma natural. Também parece óbvio, mas o primeiro passo para a melhoria foi justamente criar uma referência de qualidade (a quantidade e duração das quedas do sistema) para, em um momento posterior, avaliar a evolução. Esse é uma forma de resolver ‘problemas genéricos de insatisfação com TI’ e torná-los mais tangíveis tanto para o negócio quanto para a própria organização que presta os serviços. Outra informação relevante seria um cálculo de ROI baseado no custo aproximado das indisponibilidades do sistema de faturamento. Essa informação é provavelmente a mais relevante ou ‘inteligível’ para as áreas de negócio, mas não é necessariamente a única fonte de valor para o serviço. O nosso objetivo é deixar claros os ganhos na perspectiva que o cliente entenda, seja ela financeira ou qualitativa, mas ao mesmo tempo incitar uma transformação que torne a referência de valor cada vez mais multifacetada, complementando os ganhos financeiros com indicadores de qualidade e satisfação que tragam uma noção cada vez mais completa do valor a ser perseguido.

Ao final, mais do que ‘implantando ITIL’ ou ‘boas práticas’, estaremos implantando um programa com ganhos reais e visíveis para o negócio.

Autor

Ha mais de 8 anos gerindo projetos de Infraestrutura e Sistemas à empresas renomadas de outsourcing como a IBM, Microsoft e Stefanini .Responsável pelo gerenciamento de niveis de acordo de serviço, contratos e melhorias de processos implantando políticas e fluxos com base nas boas práticas ITIL & COBIT entre outros frameworks de mercado.

Tiago Santos

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes