Certificações em Gestão de TI valem a pena? Por onde começar?

Certificações em TIPara todos os recém-formados e profissionais da área de TI que almejam atuar com gestão/gerenciamento de TI, uma das grandes dúvidas é: em que certificações devo investir? Por onde devo começar?

Preparei algumas sugestões para você que está iniciando nesse mundo. Sugestões baseadas na minha própria história profissional e também no que o mercado costuma ver com bons olhos.


Se você pretende ter uma visão abrangente e estar por dentro das melhores práticas e das normas de mercado a curto prazo e com um investimento baixo-médio, a melhor opção é investir nas certificações “de entrada”, ou nível Foundation.

Duas destas certificações de entrada (Foundation) merecem atenção:

ITIL® Foundation

Esta certificação valida o conhecimento sobre terminologia, estrutura e conceitos e princípios fundamentais descritas pela ITIL®.

Para quem não conhece, a ITIL® é uma biblioteca de práticas de gerenciamento de serviços de TI (ou popularmente gestão de TI, como preferir) que condensa um amplo conhecimento sobre Gerenciamento de Serviços de TI como disciplina.

Recomendo que você considere esta certificação como a primeira opção de investimento, pelas seguintes razões:

  • É pré-requisito para a maioria das vagas em TI.
  • É adequada para diferentes perfis de profissionais de TI, como service desk, suporte técnico, operações, datacenter, desenvolvimento, consultoria, treinamento, etc.
  • Exige um investimento relativamente baixo
  • Pode ser conquistada em um curto período (2 semanas)
  • É pré-requisito para os programas mais avançados de certificação (ex: ITIL® Expert)
  • Facilita o preparo para outras certificações da área, como ISO2000 e COBIT

Pessoalmente, posso afirmar que a minha carreira nessa área começou a partir do momento em que eu tirei a minha certificação ITIL® Foundation, em 2006. A certificação abriu portas para que eu pudesse evoluir profissionalmente e atingir os resultados que eu esperava.  Para não criar falsas expectativas, recomendo que depois você leia este artigo que escrevi.

 

ISO/IEC 20000 Foundation

A ISO/IEC 20000 é a primeira norma que define requisitos de qualidade exclusivamente para o gerenciamento de serviços de TI. Na prática, esta norma certifica que a empresa utiliza as melhores práticas recomendadas pela ITIL®.

Recomendo esta certificação como um segundo objetivo de investimento, pelas mesmas razões que eu citei para a certificação ITIL®, e adicionalmente:

  • Se o candidato já for certificado em ITIL® Foundation, pode realizar o exame ISO/IEC20000 Foundation Bridge, que exige menos tempo de estudo e tem um exame mais simples (30 minutos de duração, 20 perguntas. Sendo necessário acertar 65%).
  • As grandes empresas de TI são certificadas, e consequentemente preferem contratar profissionais que tenham conhecimento da norma.
  • Diferencial competitivo com outros candidatos que tenham somente a certificação ITIL® foundation
  • Maior compreensão da disciplina de gerenciamento de serviços de TI, uma vez que a norma enfatiza a importância de um Sistema de Gerenciamento de Serviços (SGS) e do valor e da aplicação do ciclo PDCA.

 

COBIT 5 Foundation

Adicionalmente você pode estender seu horizonte para a governança de TI, através da certificação COBIT 5 Foundation. De forma complementar as duas outras certificações, aqui existe uma visão mais generalista da governança de TI , uma visão  executiva e focada em resultados (outcome measures).

Espero que este artigo tenha sido esclarecedor. Contudo, fique à vontade para comentar e tirar dúvidas.

Divirta-se.

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on LinkedIn

Comentários

commentarios

5 dicas para a Gestão de Problemas Proativa

banner-blog

Uma das principais atividades do processo de Gerência de Problemas é identificar tendências, através do sub processo de gestão proativa de Problemas. No dia a dia, esse conceito acaba se perdendo, pois a gestão de problemas acaba sempre demandando quase 100% de seu tempo a identificar a causa raiz dos problemas relacionados a incidentes críticos (super reativos!). Isso se dá de forma desesperada e sob forte pressão. A alta administração exige  que as causas e soluções de contorno sejam identificadas rapidamente e isso muitas vezes ocasionam respostas ineficazes,  de um processo onde tempo está diretamente relacionado a qualidade da investigação e solução proposta. Ou seja, não sobra tempo para analisar tendências de capacidade , de disponibilidade e de incidentes recorrentes. Fica quase impossível iniciar planos de melhorias e avaliar se a forma como estamos tratando os problemas maiores está sendo conduzida de maneira adequada. Os ganhos em realizar uma análise de problemas proativa podem ser:

  • Operacionais: ao analisar a tendência de incidentes e identificar que a solução de incidentes recorrentes irá beneficia o Service Desk e áreas de suporte especializados, solucionando incidentes repetitivos. Isso tratá  menos carga de trabalho e maior tempo para ser dedicado em melhorias (parar de apagar incêndio).

O detalhe é que isso acaba sendo um beneficio indireto para o negócio também. Por exemplo: Imaginem que o Service Desk gasta aproximadamente 10% de seu tempo, em uma pequena empresa, resolvendo incidentes em primeiro nível de senha bloqueada. A gerencia de problemas poderá investigar a causa raiz desses incidentes e resolve-los definitivamente. Com isso sobra mais tempo para o Service Desk atender ligações, maior disponibilidade para o usuário, aumento da eficiência e reflexo  na satisfação do usuário e do negócio.

  • Negócio: quando uma análise de tendências inibem e previnem incidentes que poderiam vir a acontecer e trazer impacto direto ao negócio. Por exemplo: junto com a disciplina de gerenciamento de capacidade, utilizar ferramentas para a identificação de tendências e atuar para evitar que  incidentes relacionados a capacidade ocorram.

A seguir, listo algumas sugestões para implementar esta atividade:

1 - Não é simples fazer uma análise proativa de problemas. Identifique as disciplinas parceiras:

  • Incidentes poderá apresentar tendencia de incidentes recorrentes que deverão ser investigados pela gestão de problemas.
  • Disponibilidade poderá identificar tendências de issues relacionados a disponibilidade e atuar em conjunto com o gerenciamento de problemas  para solucioná-los.
  • Capacidade também possui técnicas para que issues de capacidade sejam identificados e poderá contar com a gerencia de problemas para tratá-los.

Lembre-se : a gerencia de problemas sozinha não é nada. É um processo extremamente dependente dos outros.

2 - Defina os papeis e responsabilidades. Escolha sempre os técnicos mais experientes, que conheçam muito bem tanto o ambiente quanto o negócio da empresa. Nem preciso comentar que o Gestor de Problemas é o dono disso tudo, né? Documente as principais tarefas, e seus respectivos donos. Você pode usar uma matriz RACI para facilitar. Temos um modelo em nossa área de Downloads.

3 - Defina o que você quer fazer (e o que já consegue imediatamente) , a metodologia e periodicidade. Fará uma análise de incidentes recorrentes? Uma análise de tendências de relatórios de capacidade? Uma análise de issues de disponibilidade? Será aplicada alguma técnica ou metodologia  específica? Serão feitas reuniões com as equipes técnicas para discutir os problemas? Quantas vezes? Qual será o meio de comunicação?

4 - Definir quais serão os controles de performance e resultados desta atividade. Defina alguns controles para saber se as atividades estão sendo desempenhadas satisfatoriamente, e se os resultados esperados estão sendo atingidos. Ex: % de redução de incidentes recorrentes , # de incidentes evitados através da investigação e solução definitiva de problemas.

5- A quinta e principal dica é: Não acelere o processo e defina equipes separadas para a gestão proativa e reativa de problemas. A gestão proativa de problemas precisa de tempo para investigar, analisar cada variável envolvida no processo. A gestão reativa sofre pressões para explicações e soluções , sejam elas de contorno ou definitivas. O tempo da gestão de problemas reativa é mais curto, infelizmente. Se as duas equipes tiverem o mesmo papel dentro de uma organização, a gestão de problema proativa simplesmente ficará em segundo plano e deixará de ser feita.

banner-blog

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on LinkedIn

Comentários

commentarios

Como construir uma base de conhecimento

banner-blog

Todos querem ter. Quase ninguém sabe como começar. Eu , sinceramente, vi quase nenhuma ser efetiva por esse mundão afora. Estamos falando da “famosa”, porém “quase mística ” BASE DE CONHECIMENTO. Essa entidade “misteriosa” citada na ITIL® , que todos querem ter, conhecer, mas que ninguém sabe fazer.

Base de ConhecimentoComo eu costumo ser prática (quase sempre), vou simplificar. A pergunta é: o que você deseja com sua base de conhecimento? Aumentar a velocidade da solução de incidentes? Criar uma base de procedimentos operacionais, como guias e manuais de instalações? Sim, porque o termo é muito amplo e quase tudo pode vir a ser (ou se tornar ) uma  base de conhecimento.

Um conjunto de registros de incidentes, pode ser uma base de conhecimento. Uma base de erros conhecidos, com soluções de contorno, pode ser uma base de conhecimento. Um banco de dados onde estão armazenados todos os manuais e procedimentos operacionais de um determinado grupo de suporte técnico, também é uma base de conhecimento.

Agora a grande questão é: como tornar essa base de conhecimento eficiente? Como relacionar todas essas informações para que ela me dê a resposta que eu estou procurando?

Vamos a um exemplo prático: você deseja reduzir o tempo de solucão de incidentes. Quando seu analista estiver diante de um incidente ele precisa de um acesso rapido  e eficaz para buscar uma solução de contorno para ele.

Se atualmente seus registros de incidentes e problemas são imprecisos, você precisará primeiro focar em classifica-los corretamente – priorização, item afetado, tipo de incidente (temos um post sobre este assunto).

Em seguida identificar a forma como vocês estão descrevendo as soluções dos incidentes – ela também precisa ter um mesmo formato e modelo.

Posteriormente, é preciso pensar em uma forma de relacionar estes campos em um sistema de busca adequado.
Por exemplo:

Imaginem que estão ocorrendo muitos  incidentes no IC “X”. Quero criar uma base de conhecimento que aborde esse assunto e me ajude a solucioná-los mais rapidamente. Eles tem a classificação de  categoria  “hardware/impressora/papel preso”. Outras respostas que desejo: quais são os tipos de soluções que já dei até hoje para este tipo de classificação? Quais demoraram menos de 10 minutos para que fossem aplicadas? Qual o % de sucesso de cada solução?
Seu sistema que dará “corpo” a base de conhecimento deverá ser capaz de relacionar estas informações e organizá-las na forma de uma base , com esquemas de busca facilitados para a equipe de suporte. Poderá trazer também todos os manuais de hardware/impressora e por aí vai… tudo que é conhecimento pode estar (organizado) em uma base de conhecimento.

Não existe um modelo. São necessárias somente informações organizadas de forma adequada (e suficientes) e de um sistema de busca e relacionamento preciso.

Além disso, deve ser algo simples de manter, do contrário durante a inauguração a base estará linda e depois de um mês completamente desatualizada. Os ganhos que ela deve trazer devem compensar o trabalho de mantê-la. A equipe de suporte deve ENTENDER E ACEITAR ISSO.

Não é tarefa fácil, mas é possível, se resolvermos não complicar demais. Tenha sempre em mente seus objetivos e seja simplista (pequenas melhorias trazem grandes resultados).

Espero ter ajudado aqueles leitores que tem me escrito com dúvidas sobre este tema.

Até a próxima.

 

banner-blog

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on LinkedIn

Comentários

commentarios

Service Desk: a vitrine da TI

banner-blog

Há alguns anos o Service Desk, infelizmente, era tratado apenas como uma área secundária dentro da empresa. A TI costumava dar mais valor as equipes de suporte e outras áreas consideradas “mais nobres para o negócio”, deixando para a Central de Serviços um papel secundário. Com a implementação das melhores práticas em gerenciamento de serviços de TI, essa visão finalmente e de maneira muito justa foi alterada.

Service DeskO Service Desk é uma “entidade independente”, não apenas um processo dentro das melhores práticas. É uma função, um departamento, uma organização com importância estratégica para a prestação de serviços de TI. Por ser o ponto único de contato entre TI e usuários , ele  é diretamente responsável pela percepção e satisfação dos mesmos.

Antes de tudo, é preciso entender as diferenças entre os modelos existentes de centrais de atendimento. São três tipos:

1. CALL CENTER: modelo de atendimento que registra as solicitações e encaminha para o suporte específico. Seu principal objetivo é atender grande volume de chamadas e direcioná-las.

2. HELPDESK: modelo de atendimento que gerencia , coordena e resolve incidentes o mais rápido possível. Garantindo que requisições não sejam perdidas.

3. SERVICE DESK: Além de apresentar as duas características anteriormente apresentadas, oferece serviços com foco em TI e nos negócios, lidando com incidentes e provendo interfaces para outros processos, como requisições de mudanças, níveis de serviços, gerência de disponibilidade, dentre outros.

Resumindo, o Service Desk possui 3 características importantíssimas:

  • Representam o provedor de serviços.
  • Defendem pessoas, processos e tecnologia (os pilares do gerenciamento de serviço de TI)
  • Operam no princípio da satisfação do usuário.

Ele é responsável por gerenciar e acompanhar todas as questões (incidentes, mudanças, requisições, consultas, reclamações e etc).

É um departamento cobrado e medido por:

  • Tempo de atendimento;
  • Tempo de espera;
  • Tempo de registro de um chamado;
  • Taxa de abandono de ligações;
  • Conhecimento técnico do assunto;
  • Controle das solicitações atendidas dentro e fora do prazo (SLA);
  • Acompanhamento do incidente (ciclo de vida do incidente);
  • Classificação da solicitação, etc.

Implantar um service desk, na maioria das vezes, é uma das primeiras iniciativas de um projeto de implementação da disciplina de gerenciamento de serviços de TI. No início, significa concentrar todas as chamadas um único atendimento, abrindo se possível, outras formas de contato, como e-mail e também uma interface WEB do sistema de registro de chamados, permitindo ao usuário realizar o registro de forma independente.

Durante a implantação é preciso atentar-se aos seguintes pontos de atenção:

  • selecionar corretamente o pessoal para atendimento e treiná-los periodicamente: é importante  selecionar pessoas com conhecimento técnico, mas somente isso não é suficiente para garantir um bom atendimento. É preciso pessoas com os chamado “soft skills” : conhecimentos relacionados a capacidade  comunicação, raciocínio lógico e rápido,  presteza e postura adequada para que um bom atendimento seja realizado. Além disso, as equipes precisam ser treinadas quando a central de serviços for implementada e depois disso periodicamente para que o conhecimento não seja dissipado.
  • Definição correta de processos: é preciso definir como o será o atendimento, como a central de serviços se relacionará com os outros processos de gerenciamento. Resumindo, qual o verdadeiro papel e responsabilidade da central de serviços para a organização.
  • Seleção correta de ferramentas para suportar o service desk: uma boa ferramenta de gerenciamento de incidentes e uma boa central de distribuição de ligações são fatores chave para o sucesso de um Service Desk.
  • Deve haver comprometimento gerencial: os gerentes devem se comprometer inteiramente em tornar a central de serviços um sucesso, não abrindo exceções sobre ela ser o ponto único de contato e auxiliando na conscientização de suas equipes da importância e do valor agregado da central de serviços para uma organização.
  • Campanhas de conscientização para os usuários da Central de serviços: devem ser feitas apresentações, eventos, workshops e reuniões para que os usuários passem a enxergar o valor agregado de uma central de serviços para a organização e aceitem utilizar os serviços da central (aceitação que promoverá a mudança cultural para a implementação da Central de Serviços).

Não espere um Service Desk 100% eficaz e eficiente logo nos primeiros dias. É natural que o Service Desk com o tempo vá ganhando experiência (curva de aprendizado e maturidade).

banner-blog

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on LinkedIn

Comentários

commentarios

5 passos para definir um bom Acordo de Nível de Serviço (SLA)

banner-blog

Apesar do SLA ter se tornado um jargão bastante conhecido e utilizado, é comum encontrar documentos mal escritos, com falta de informações e definições confusas até para o próprio provedor de serviços. Isso não é bom nem para o provedor, e nem para o cliente, pois dá margem para discussões que podem comprometer o bom relacionamento entre as partes, e em casos mais graves até causar uma rescisão contratual (no caso de provedores de serviço externos) ou a decisão pelo outsourcing (no cado de provedores de serviço internos).

SLA

Acordo de Nível de Serviço

É preciso entender que um acordo de nível de serviço é muito mais do que um documento descrevendo prazos de atendimento e resolução de chamados. Trata-se de um acordo que deve deixar claro todas as garantias que o provedor de serviço oferece em relação aos serviços que foram contratados, e a forma como estes níveis de serviço serão medidos, reportados e melhorados continuamente.

Para resumir: o (bem) combinado não sai caro!

Se você nunca desenvolveu um SLA ou acha que o utilizado atualmente na sua empresa precisa de ajustes, responder as seguintes perguntas é um bom começo. Lá na ITIL (Service Design) você vai encontrar um modelo bastante robusto de um Acordo de Nível de Serviço. O que eu estou sugerindo adiante é uma abordagem mais simples e realista.

 

Pergunta 1: O que?

Qual o serviço que está sendo objeto deste acordo? Contextualizar o serviço já no primeiro capítulo é uma boa pedida. Aqui também pode-se fazer referência ao Catálogo de Serviços.

Importante incluir as exclusões, que são as situações em que este acordo de nível de serviço não é aplicável. Isto evita uma série de aborrecimentos futuros. Um dos assuntos mais comumente esquecidos é o “Stop SLA” (ou pausa no SLA), onde são considerados os períodos em que os casos estão sob tratamento de suporte do próprio cliente, ou seja, o provedor de TI não deveria assumir o ônus por este período de tempo.

Pergunta 2: Quando?

Quando o serviço deve ser fornecido? Deveria ser incluído  no mínimo, o percentual de disponibilidade do serviço, o horário do serviço (período em que deve estar disponível, por exemplo: em horário comercial, 24×7, etc), o horário do suporte ao serviço (Service Desk por exemplo). Importantíssimo também considerar condições de exceção, como feriados, finais de semana, etc.

Pergunta 3: Quanto?

Esta pergunta não tem relação com valor a ser pago pelo serviço, que normalmente já definido no Catálogo de Serviços, e sim em qual quantidade e com qual desempenho o serviço será entregue. Ou seja, requisitos de capacidade.

Pode-se incuir por exemplo: Taxas de resposta, número máximo de transações simultâneas, usuários concorrentes, etc.

Outra boa sacada é considerar “lotes” e “franquias” de requisições de serviços. Por exemplo: considerar um lote máximo de requisições simultâneas do tipo X. Caso a quantidade ultrapasse o limite, será necessário como uma mudança (exige aprovação e um projeto associado). Em outros casos é possível acordar cobrança adicional quando a franquia de requisições for atingida, como forme de influenciar o comportamento dos usuários.

AgreementPergunta 4: Como?

Talvez este seja o capítulo mais extenso, e com direito a incluir alguns tópicos:

Papeis e responsabilidades

Uma boa prestação de serviço exige que não somente o provedor, mas também o cliente, cumpram alguns deveres. Se engana quem acha que o cliente (e os usuários) não têm responsabilidades.

Suporte ao Cliente

Neste tópico, algumas informações importantes como os possíveis canais de contato do cliente com o Service Desk, os tempos de resposta para cada tipo de caso de acordo com os critérios de priorização, matriz de escalonamento, etc, podem ser incluídas.

Reporte e análise crítica do serviço

A maioria dos Acordos de Nível de Serviço não deixam claro a periodicidade e a forma como os níveis de serviço serão medidos, reportados,  analisados criticamente junto ao Cliente e continuamente melhorados. Este momento é uma excelente oportunidade não só para identificar os pontos falhos na entrega de serviços, mas também oportunidades de novos negócios. Vale lembrar que este item é, inclusive, um requisito da norma ISO/IEC 200000.

Canal de Reclamação

Seja lá qual for o nome mais adequado: ombudsman, ouvidoria, etc. O importante é mencionar um canal onde o cliente possa reclamar caso não esteja satisfeito com o serviço, e garantir que será dado um tratamento adequado a esta reclamação.

Pergunta 5: E se der $%@&… ??

Como dizem os americanos: “coisas” acontecem…

O provedor deve estar preparado para imprevistos de grande magnitude. O Acordo de Nível de Serviço pode deixar claro para o Cliente a existência de um plano de continuidade, ou considerações que evidenciem que o provedor gerencia os riscos de seus serviços, endereçando respostas adequadas para cada um deles.

 

Ao ler este artigo, definir um Acordo de Nível de Serviço pode parecer fácil  mas está longe disso. Estes são apenas alguns dos ingredientes básicos de uma atividade que leva tempo, e muita discussão.

Abraços e até a próxima!

 

banner-blog

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on LinkedIn

Comentários

commentarios

ITSM na Prática – O Livro (download gratuito)

Olá pessoal,

Depois de cinco anos de atividade aqui no blog, resolvi fazer uma compilação do que de melhor já passou por aqui em um e-book gratuito.O livro se chama ITSM na Prática – O Caviar de 5 Anos de Postagens e está disponível neste novo site.

capa-3dEle conta com a minha curadoria, inclui artigos de 12 autores, e mais de 60 artigos, sendo 13 exclusivos para livro.

Você pode baixá-lo agora gratuitamente (por enquanto) em http://mapadoitil.com.br/?src=140710

Estou ansioso para saber o que vocês acharam, deixem comentários aqui.

 

Grande abraço!

 

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on LinkedIn

Comentários

commentarios

Compreendendo a ITIL® a partir de uma perspectiva nada convencional: um show de rock!

A ITIL® traz uma série de boas práticas de gerenciamento, organizadas para cobrir todo o ciclo de vida de um serviço, focando em cinco fases:

  • Estratégia de Serviço: É a fase de concepção do serviço. A pergunta mais simples que poderia ser feita neste momento é: “O que sua organização quer ser?”.
  • Desenho do Serviço: Nesta fase, a estratégia do serviço começa a tomar forma. Tudo o que é necessário para os requisitos do serviço vai para o papel. É hora de planejar como a organização vai se transformar no que foi proposto durante a estratégia!
  • Transição do Serviço: Mãos na massa! Neste momento é preciso garantir que tudo o que foi desenhado na fase anterior se torne, de fato, um serviço disponível (ou “consumível”), com o mínimo de riscos/impacto.
  • Operação do Serviço: Só os fortes sobrevivem a esta fase. Uma vez disponibilizado o serviço, agora é momento de garantir que ele funcione de acordo com o que foi previsto na estratégia, com o mínimo de interrupções, e com o tratamento adequado para os imprevistos.
  • Melhoria Continuada do Serviço: Sempre há o que melhorar. Nesta fase há uma preocupação em garantir que todo o ciclo de vida do serviço passe por uma avaliação criteriosa, e lições sejam aprendidas (em qualquer das fases).

Ok, mas qual é a relação da ITIL® com um show de rock?

Tendo como verdade a ideia de que um show de rock é uma das ofertas disponíveis em um serviço de entretenimento, promovido por empresas de eventos (os provedores de serviço) ao público em geral (os clientes do serviço), vamos ao seguinte cenário:

Imagine o custo total do espetáculo de uma banda mundialmente conhecida. As toneladas de equipamentos, a logística e a enorme quantidade de profissionais envolvidos. A responsabilidade por garantir a satisfação de 50, 100, 200 mil pessoas que pagam para ver o melhor espetáculo possível ao vivo, em um tempo relativamente curto (de 1 a 3 horas). Apesar de um pouco específicos, estes desafios podem ser identificados em quaisquer outros serviços vistos no dia a dia, sejam eles de TI ou não.

Há algum tempo atrás, a banda U2 adotou uma forma diferente de se apresentar, em um palco de 360 graus. Toda essa inovação faz parte de uma estratégia definida para introduzir um novo conceito, uma nova experiência para o público. E sabemos que funcionou muito bem.

Provavelmente foram necessários muitos meses de estudo, cálculos, envolvimento de engenheiros de som, arquitetos, especialistas em efeitos visuais, etc. Além disso, considerar quantidade máxima de público por show, valores de ingressos, limitações de locais em que este show poderia ser instalado, segurança, etc. Tudo isso para desenhar como esta nova abordagem do espetáculo poderia ser viabilizada ao público.

Você já deve ter visto aqueles profissionais que vivem correndo de um lado para o outro, montando e testando os equipamentos das bandas ou artistas antes de um show, trocando os instrumentos em questões de segundos, arrastando cabos de lá pra cá, e quando ocorre algum imprevisto, atua na linha de frente na tentativa de resolvê-lo o mais rápido possível.

Outro exemplo: cada equipamento, desde a ordem de ligação, configuração de parâmetros e informações relevantes dos equipamentos como voltagem, modelo, etc. devem ser controlados minuciosamente para que o timbre característico do artista permaneça sempre o mesmo. Provavelmente, o artista deve sempre ser consultado, e aprovar quaisquer mudanças em seus equipamentos, avaliando o impacto que elas podem trazer em uma performance ao vivo.

E se tudo der errado? Qual é o plano caso ocorra um desastre e tudo pare de funcionar?

Pra finalizar, tudo isso deve estar explícito nos contratos milionários fechados com os organizadores do evento, juntamente com os níveis de serviço esperados (duração do show, músicas a serem tocadas, etc).

Apenas neste pequeno cenário, já foram citados ao menos 5 processos de gerenciamento de serviços sugeridos pela ITIL®.

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on LinkedIn

Comentários

commentarios

Habilidades essenciais para ser um consultor de Gestão de Serviços de TI bem sucedido em seus projetos

Nestes anos de consultoria na área de Gestão de Serviços de TI, utilizando o Framework de boas práticas ITIL, vejo a preocupação dos Gestores de TI com a integração com os negócios e o ROI(Return of Investiment).

É importante a habilidade de um consultor em boas práticas , falar a linguagem dos negócios, comunicar-se com os Gestores da organização, sem usar linguagens técnicas, vender gato por lebre na hora de falar sobre ROI.

A cada projeto que participei, reforço que a comunicação é vital para o sucesso de projetos que usam frameworks de forma eficiente e eficaz.

Com transparência na comunicação é possível ganhar a confiança das áreas de negócios e ter a multiplicação de sua atuação dentro da organização.

Percebo que certificações do profissional, não garante o sucesso do projeto, elas são importantes, pois demonstra o conhecimento teórico do profissional sobre os frameworks. Mas de fato, são suas habilidades e experiência práticas que enriquecem a entrega de qualquer projeto.
Para não haver desentendimentos e barreiras em qualquer projeto com uso de frameworks é necessário uma harmonia entre teoria e prática.

Em minhas consultorias em que tive barreiras na execução do projeto, percebi que sempre foram por causa da comunicação técnica versus linguagem de negócios. Por isso hoje resolvi fazer um curso voltado para Gestão de Processos Gerenciais para ter mais familiaridade com a linguagem de negócios.

Aprendi na prática que apenas apontar os problemas nos projetos, ao invés de ajuda-lo, traz uma insegurança tanto do terreno em que você esta entrando para trabalhar, quanto para as pessoas que o contrataram.  O motivo é que nem todos tinham a visão do que existia por baixo da ponta do iceberg! Por isso é necessário uma forma política de se apresentar falhas e problemas na gestão de serviços dos outros.

Uma coisa que sempre me incomodou nos projetos, é os gestores das áreas de negócios me tratarem como um simples agente de vendas de TI. Eu não sou da área comercial e invisto muito em conhecimento para poder agregar valor e trazer retorno sobre o investimento em todos os projetos em que atuo.

Importante o consultor e profissional de Gestão de Serviços de TI, deixar isso muito claro e transparente para quem ele presta serviços. Saber fazer o marketing de seus serviços de TI.

Um fato que me custou a saída de um projeto, foi que em uma situação inesperada,  onde eu necessitava de coleta de evidências após reuniões de diagnóstico do ambiente atual de TI, o cliente não estava colaborando e fazendo com que meu cronograma atrasasse gerando impactos na qualidade, prazo e custo do projeto. Então durante a reunião de Status Report juntamente com a CIO da organização após receber criticas de meu atraso no cronograma, não contive os ânimos e usei palavras e expressões não compatíveis com o local e pessoas presentes. Fica a dica nunca se exalte e perca a razão!!!

Em todos os projetos em que participei os que mais foram assertivos, foram aqueles em que souber fazer as perguntas certas e na hora certa.

Porém, deixo uma dica esteja pronto para ser questionado e seja humilde em reconhecer que não sabe tudo e que você também pode errar.

De nada adianta você mostrar que sabe tudo sobre boas práticas, que participou de grande projetos se não souber cativar seu público alvo e convencê-los que você agregou valor e trouxe retorno sobre investimento para a organização.

“O custo do cuidado é sempre menor do que o custo do reparo” Marina Silva – ambientalista, historiadora, pedagoga e política brasileira

E cuidado também ao tentar mostrar soluções que não sao viáveis para o cliente. Saiba tudo sobre seu cliente antes de iniciar qualquer projeto.

Abaixo uma história retirada da internet de autor desconhecido para demostrar o que eu quis dizer:

Uma dona de casa, num vilarejo, ao atender as palmas em sua porta…

 

- ‘Oh de casa, tô entrando!’

 

Ela se depara com um homem que vai entrando em sua casa e joga esterco de

cavalo em seu tapete da sala. A mulher apavorada pergunta:

 

- ‘O senhor está maluco? O que pensa que está fazendo em meu tapete?’

 

O vendedor, sem deixar a mulher falar, responde:

 

- ‘Boa tarde! Eu estou oferecendo ao vivo, o meu produto, e eu provo pra senhora que os nossos aspiradores são os melhores e mais eficientes do mercado, tanto que vou fazer um desafio: se eu não limpar este esterco em seu tapete, eu prometo que irei comê-lo!’

 

A mulher se retirou para a cozinha sem falar nada.

 

O vendedor curioso, perguntou:

 

- ‘A senhora vai aonde? Não vai ver a eficiência do meu produto?’

 

A mulher responde:

 

- ‘Vou pegar uma colher, sal e pimenta e um guardanapo de papel.

Também uma cachaça para te abrir o apetite, pois aqui em casa não tem

energia elétrica!’

 

Moral da história:

Conheça o seu cliente antes de oferecer qualquer coisa.

 

Com a história acima além de conhecer bem seu cliente, aconselho a não confiar demais no seu produto e serviço. Tenha sempre em mãos um Business Case, Plano de Negócios, faça Benchmarks e apresente números e evidências que o que você propõe a fazer pode agregar valor de maneira eficiente e eficaz e trazer ROI.

Uma dica que eu dou para quem trabalha com projetos de Gestão de Serviços usando a ITIL como framework por exemplo em seus projetos tentar incluir um treinamento de ITIL e o Jogo do Apollo 13.

Houston, we have a problem!

Uma das frases mais emblemáticas da história humana, se tornou significado de que alguma coisa, em algum lugar, por algum motivo, algo não está funcionando.

E se esta está situação estiver relacionada ao ERP, ao CRM, ao website, ao e-Commerce, ao Controle de Estoque, ao Faturamento, ao Inventário, etc, etc, etc….??????

O desafio constante de manter um ambiente de TI estável, integro  e confiável, que atenda as objetivos  de negócio e ao mesmo tempo seja flexível ao ponto de rapidamente absorver novas demandas e  aproveitar novas oportunidades, é a realidade dos profissionais e dirigentes de áreas de tecnologia  da informação de praticamente todas as empresas do globo.

Mas como tornar a TI mais confiável, mais ágil, mais fácil de usar e gerenciar? Como responder rapidamente às necessidades das áreas de negócio, mantendo a integridade e disponibilidade dos sistemas já existentes? Como mudar e aprimorar processos?

E principalmente como fazer isso envolvendo as pessoas em uma mudança cultural e comportamental que se mostre mais duradoura?

Que tal experimentar o desafio real de trabalhar em uma equipe multidisciplinar com um foco comum definido? Promover a melhoria da comunicação interna? Definir e usar controles e indicadores de desempenho para gerenciar a efetividade do trabalho e o atingimento de resultados? Que tal trabalhar arduamente para SALVAR a vida dos astronautas da Apollo 13, os seus principais CLIENTES, que precisam da sua equipe para manter e fazer os sistemas, a infraestrutura e os processos de TI funcionarem a contento para suportar o negócio?

Nesta dinâmica de simulação do Apollo13 – Uma experiência de Gerenciamento de Serviços de TI, é um jogo corporativo dinâmico e envolvente, onde os participantes poderão  obter ao seu final as respostas para estas e outras questões pertinentes.

Eu aqui no Brasil estou ajudando a disseminar as boas práticas da ITIL juntamente com outros consultores seniores e empresas.

Boa sorte em seus projetos e qualquer dúvida entrem em contato.

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on LinkedIn

Comentários

commentarios

Axelos solta o roadmap para melhorias da ITIL

Olá pessoal,

As ultimas semanas tem sido bastante intensas por conta da COMMUNIT, mas sobrando tempo sempre tento trazer novidades do mundo ITSM.

Já venho falando das mudanças que estão para surgir na ITIL. Recentemente, a Axelos (empresa formada pela Capita e a Cabinet Office) – que é a nova ‘dona’ do ITIL – disponibilizou o roadmap para o desenvolvimento do ITIL para 2014.

Confesso que não li as entrelinhas, mas ao que parece vem bastante novidade por ai, como um novo método de auto-avaliação de maturidade (até o momento o único que existe é o da antiga V2), criação de comunidades de prática e fóruns (será que agora vai?). Estou na torcida.

Para ver o roadmap completo, acesso link abaixo:

http://www.best-management-practice.com/gempdf/ITIL_Roadmap.PDF

 

**Aproveitando o post, em breve o ITSM na Prática vai mudar de cara (sim, de novo), e voltar a ser o que nunca devia ter deixado de ser: uma fonte de informações sobre ITSM, da comunidade, para a comunidade.

O novo layout vai favorecer as discussões produtivas e a contribuição de todos que tiverem algo a dizer (menos propaganda, of course).

 

Abraços!

 

 

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on LinkedIn

Comentários

commentarios

A relação entre ITIL e ISO/IEC20000

Atualmente, o ITIL é utilizado como referência para empresas desenvolverem estratégias de serviços envolvendo o planejamento e a gestão da demanda, gestão da qualidade, acompanhamento dos resultados financeiros para os serviços e a divulgação destas informações  em seus catálogos de serviços. Verifica-se também que adoção destas práticas abrange também o planejamento do serviço que considera aspectos importantes como o dimensionamento da capacidade, segurança, níveis de serviço visando assegurar a continuidade e sustentabilidade do processo.  Após realização do planejamento inicia-se a fase de implantação do processo para o ambiente de produção, incluindo os processos de ativos/configurações de serviços, mudanças, release, testes e avaliação. Quando um determinado serviço está pronto e devidamente testado e aprovado, é realizada uma passagem dos levantamentos realizados para o ambiente de  produção.  Os processos e funções como central de serviço, incidentes, requisições de mudança, eventos e acesso são utilizados durante este processo. Finalmente é apresentada uma referência para a melhoria contínua, considerando algumas práticas recomendadas por Deming o ciclo PDCA.

Tudo estaria correto, e funcionaria perfeitamente, se não fosse um detalhe: Como o ITIL é uma referência, de que formata garantir a efetividade, implantação e sua sustentação ao longo do tempo? A abordagem apresentada no ITIL não garante que os processos sejam efetivamente implementados em seus requisitos mínimos. O ITIL é descritivo, onde descrevemos as melhores ações a serem tomadas. Deveria existir algo que servisse como um guia, para determinações do tipo “deve existir um plano de capacidade!” que pudesse ser avaliada quanto à sua eficácia e eficiência. Neste aspecto, a ISO 20000 atua complementando o ITIL, o Cobit e seus processos de Delivery e Support, atua de forma parecida, porém seu foco é “o que fazer” sob a visão da Governança de TI e não em Gestão da Qualidade de Serviços de TI. Como o processo necessita ser implementado de forma organizada existe a ISO 20000 que é um padrão internacional de qualidade, projetado para gerenciamento de serviços de TI. Este framework certifica que a empresa utiliza as melhores praticas recomendadas pela ITIL. No Brasil temos poucas empresas certificadas até o momento, já no exterior está referência já é utilizada em maior escala, servindo como pré-requisitos para participação licitações de empresas como a NASA e o Governo Americano.

Pode-se observar que hoje o foco está em ‘fazer acontecer’, sem o devido cuidado com o melhor método ou com uma análise adequada. Quando um gerente de TI afirmar que já possui processos ITIL implantados porem não consegue garantir que este processo está seguindo os requisitos mínimos de qualidade. A ISO 20000 deve ser utilizada como um complemento do ITIL, pois atesta que as melhores práticas em gestão de serviços de TI estão efetivamente implantadas. A ISO 20000 garante também que os processos mínimos estão sendo aplicados e seguidos. O fato de ser auditado por uma entidade externa de forma contínua e periódica, bem como auditoria interna, garante que os processos e a qualidade de serviços de TI estão sendo seguidos.

Outro aspecto importante é que a ISO 20000 garante alguns complementos fundamentais para o ITIL, como, por exemplo, a responsabilidade e o comprometimento  da alta direção sobre o sistema de qualidade de serviços de TI, competência, treinamentos e requisitos de documentação para a devida  execução dos processos. Tudo isso é auditado quanto à sua eficácia. Outro aspecto fundamental é a inclusão dos processos do ciclo PDCA, incluindo auditoria, registros, evidências de não conformidades e oportunidades de melhorias com suas ações preventivas e corretivas. Processos importantes de relacionamento com o cliente (incluindo gestão de reclamações) e de gestão de fornecedores são auditados e escalados. Exige-se também um processo de melhoria de serviços com atividades bem definidas, incluindo determinações claras de entradas e saídas dos processos.

Devido a importância do ITIL em sincronia com o ISO 20000 recomenda-se que as empresas e provedores de TI juntamente com seus gestores considerem esta implantação conjunta. Sendo este processo voltado primeiramente para a obtenção de melhores níveis de qualidade na prestação de seus serviços.   Com base nesta argumentação, acredita-se que os benefícios de implantar a ISO20000 em conjunto com o ITIL serão superiores quando comparados a implantação do ITIL de forma isolada para a Gestão da Qualidade em Serviços de TI. Lembrando que o Cliente é quem sai ganhando com esta união.

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on LinkedIn

Comentários

commentarios