Posts Tagged "IT Service Management"

Comunicação em TI : 11 Fatores Críticos de Sucesso

Contexto

A falta de comunicação em projetos e processos de TI é largamente reconhecida. Não lembro de ter passado por nenhuma reunião de assessment /avaliação de TI sem que o entrevistado não mencionasse suas frustrações e preocupações por conta deste tema. Também nas reuniões de planejamento e priorização de melhorias da área de  TI este é um dos tópicos unânimes entre os gestores.

Por que é tão difícil comunicar?

Se todos nós sabemos da importância da comunicação nas operações de serviço, assim como em qualquer projeto ou atividade produtiva e, ainda assim, sofremos com os efeitos negativas da má qualidade da nossa comunicação, qual a dificuldade para reverter este cenário?

Alguns dificuldades percebidas são :

1.Comunicação de qualidade dá trabalho mesmo. Há fatores objetivos mas muitos outros, subjetivos a serem tratados. A capacidade de interpretação do seu interlocutor é um deles;

2.A natureza humana parece ser de comunicação limitada; Além disso ela é cultural, regional, tribal.

3.A era da super conectividade trouxe facilidades mas problemas também, como por exemplo, uma variedade muito grande de interlocutores cada um com um background diferente e às vezes vivendo em culturas desconhecidas para o emissor da mensagem;

4.Será que conseguimos dar atenção ao que é relevante tendo em vista o bombardeio de dados/mensagens/informações todos os dias?;

5.Na era da internet, quais fontes são fidedignas?

6.As forma de trabalho colaborativas ajudam muito mas será que não nos fazem perder foco também? Qualquer um pode opinar em nosso trabalho quando estamos colaborando na intranet da empresa? Quais são os interesses dos colaboradores, todos estão alinhados em relação ao objetivo maior do negócio?

Propondo melhorias

Elencamos 11 fatores que podem ajudar a melhorar a comunicação na prestação de serviços de TI.

1.Qualificação dos Stakeholders dos Serviços

Compreender quem são os diferentes interessados, participantes, envolvidos com um serviço é fundamental para adequar a comunicação com cada um deles. Geralmente seus objetivos e interesses com relação àquele serviço são muito diferentes. Claro, para isso um modelo de operação orientada a serviços facilita o trabalho de mapeamento.

2.Stakeholders típicos são : (1) clientes, (2) usuários, (3) diretor de área cliente, (4) pessoal da operação, (5) gestor do serviço, (6) terceiros, (7) auditores do serviço, (8) agentes externos como governo e a própria mídia, (9) gerentes de projeto, (10) parceiros de negócio, (11) centrais sindicais.

Pode-se então agrupar os stakeholders por áreas de interesse visando boa comunicação, como por exemplo : (a) informações estratégicas, (b) informações financeiras, (c) informações operacionais, (d) informações sobre interface com clientes, (e) informações de interesse público, (f) informações privilegiadas para concorrências.

3.Estratégia de Comunicação

Toda comunicação deve ter um objetivo e, claro, com direcionamento do que a empresa considera mais relevante para seu negócio.

Alguns pilares de um plano de comunicação podem ser, por exemplo :

(1) Estabelecer uma visão clara sobre os objetivos e prioridades do negócio;

(2) Esclarecer as políticas da empresa;

(3) Identificar e manter patrocínio dos envolvidos com os objetivos da empresa;

(4) Remover barreiras internas;

(5) Construir parcerias.

Ou seja, como tudo na vida, a comunicação também é política!

4.Plano de Comunicação

Pela diversidade de stakeholders de um serviço pode-se imaginar que somente com um plano de comunicação para aquele serviços e seus processos de gestão, pode-se adequadamente realizar a comunicação efetiva durante todo o ciclo de vida do serviço.

Muito vago? Que tal você chegar ao banco em seu horário de almoço, com tempo contado e raro, para fazer um depósito de suma importância e, somente aí, na porta do banco, descobrir que houve mudança no horário de atendimento? Algum impacto negativo na sua rotina?

5.Um bom plano de comunicação de serviços deve conter :

(1) Quem é o mensageiro?

(2) Qual é a mensagem? Qual seu objetivo? Qual o Estilo? Quais os fatores críticos de sucesso?

(3) Quem é o público alvo?

(4) Qual o melhor meio de comunicação para aquele objetivo e público?

(5) Sincronismo e frequência da comunicação.

(6) Método de comunicação.

(7) Fornecer um mecanismo de feedback.

6.A comunicação como Processo

Dentro de cada processo de gerenciamento de serviços de TI deve haver um fluxo claro de comunicação.

Quem precisa saber do que em cada momento? As matrizes RACI ajudam bastante neste sentido.

7.Gente especializada faz diferença

Sempre que, em nossos projetos, envolvemos as áreas de marketing interno, os resultados foram muito bons.

É importante reconhecer nossa limitações e nós, de TI, não temos a mesma especialização que estes profissionais.

Lembro bem de um gerente de TI que estava avaliando qual MBA deveria fazer. Pois ele estava entre finanças, marketing e comunicação. Inteligente a meu ver.

8.Verificação sobre a Efetividade da Comunicação

Apesar de todos os esforços, somente quando perguntamos do outro o que ele entende das nossas mensagens é que podemos avaliar nossa efetividade.

Feedback é fundamental.

9.Adequação das ferramentas de Monitoração

Este é um trabalho a parte. O caso típico são as implantações de ferramentas de gerenciamento de eventos (monitores) que geram milhões de eventos de tipos diferentes sem que se possa dar um significado adequado para todos estes dados.

Aqui se faz necessário filtro sobre o que se vai monitorar e dar significado aos conjuntos de dados através de sua correlação e tradução. Cuidado com o gerente caixa cheia, que mencionamos anteriormente.

10.Adequação do dashboard de TI

O mesmo vale para indicadores de desempenho (KPIs). Precisam de filtro, análise e tradução para fazerem sentido para a maior parte de seus interessados.

11.Segurança da Informação

Toda comunicação deve respeitar os princípios básicos da segurança da informação : confidencialidade, integridade e disponibilidade.

Boa comunicação (Ανακοίνωση, em Grego) a todos!

Serviços ILUMNA associados :

Consultoria : Gerenciamento de Serviços de TI e Governança de TI

Treinamento : ITIL MALC (Managing Across the Lifecycle)

Para Descontrair

Assista ao vídeo, muito engraçado, do grupo inglês Monty Phyton sobre comunicação.

IT Service Fatal Error – Code : Ανακοίνωση

Comunicação : Chave do Fracasso!

Contexto

A falta de comunicação em projetos e processos de TI é largamente reconhecida. Não lembro de ter passado por nenhuma reunião de assessment /avaliação de TI sem que o entrevistado não mencionasse suas frustrações e preocupações por conta deste tema. Também nas reuniões de planejamento e priorização de melhorias da área de  TI este é um dos tópicos unânimes entre os gestores.

Então está tudo resolvido, certo? Não! O que mais vemos são situações como abaixo :

Cenário 1 : CIO caixa cheia.

Uma vez estava eu ministrando um treinamento de ITIL onde havia um CIO entre os alunos. O celular dele não parava de receber SMS (não havia whatsapp na época!). A cada olhada disfarçada para o aparelho ele franzia as sobrancelhas com aquele ar indefinido entre indignação e preocupação. No intervalo não resisti e perguntei-lhe se estava tudo bem com a operação e ele simplesmente respondeu : “Adoraria saber mas apesar de ter recebido dezenas de mensagens nas últimas horas não consigo decifrar o que nosso sistema de alertas quer dizer. Mensagens do tipo “189.171.19.30 – 500 Internal Server Error” lotam minha caixa de entrada e no final eu ligo pra meu pessoal para saber se está tudo bem. Finalmente ele concluiu : “Parece que está tudo bem sim, graças a Deus.”

Cenário 2 : Gerente de TI assustado.

Estávamos no meio de uma reunião apresentando nossos serviços a um possível cliente quando repentinamente o gerente de TI levanta-se e diz : “Desculpem pessoal, temos um problema sério aqui para resolver. Acabaram de me mandar um whatsapp com a mensagem “Parada SAP”. Deixa eu ver o que é.” Este gerente estava no cargo fazia 1 mês e com o SAP sob sua responsabilidade, embranqueceu diante da mensagem. O gerente de projetos ao lado, que já estava na empresa fazia anos, não foi diferente. Resultado, alguns telefonemas sobressaltados mais tarde e o gerente descobre que era uma mensagem de rotina “informando” uma parada de manutenção do SAP. Ufa!

Cenário 3 : Coordenadores de TI telefonistas.

Estávamos para iniciar uma reunião rotineira do Comitê de Gestão de TI. Cheguei na sala e lá estava o coordenador de sistemas, responsável pelo SAP, com cara de poucas horas de sono. O SAP tinha estado “fora do ar” no dia anterior. “A bruxa está solta, disse pra mim”. Dez minutos depois liga alguém do e-commerce : “Nossos sites estão fora do ar e com isso todos os sistemas de e-commerce”. Neste momento já estavam na sala outros 2 coordenadores de sistemas e ninguém de infra. A partir daí se formou uma verdadeira central telefônica e os 3 coordenadores “dispararam para todos os lados”. “Liga pro cliente e diz que volta hoje ainda!” “Estou tentando falar com o pessoal de infra mas não consigo”. “Ah, liga pro pessoal do Service Desk também e deixa todo mundo avisado”. Quem mais? Nessa hora liga o CIO, “o que está acontecendo, estão me ligando desesperados, é o e-commerce ou o SAP?”. Outro coordenador ao telefone : “estava tentando falar com vocês (de infra) desde cedo, sabem se algo aconteceu com o servidor de rede? Ah, então foi o pessoal do Global que aplicou patches sem avisar”….Bom, o resto da história podemos abreviar. Muita confusão até que tudo volta ao normal e nada se faz para impedir novas situações como esta.

Resumindo, os exemplos falam por si só. Somos péssimos comunicadores por natureza. Quando não deixamos de nos comunicar totalmente, o fazemos com má qualidade.

O efeito negativa na prestação de serviços de TI é muito grande!

Por que é tão difícil comunicar?

Se todos nós sabemos da importância da comunicação nas operações de serviço, assim como em qualquer projeto ou atividade produtiva e, ainda assim, sofremos com os efeitos negativas da má qualidade da nossa comunicação, qual a dificuldade para reverter este cenário?

Alguns dificuldades percebidas são :

1.Comunicação de qualidade dá trabalho mesmo. Há fatores objetivos mas muitos outros, subjetivos a serem tratados. A capacidade de interpretação do seu interlocutor é um deles;

2.A natureza humana parece ser de comunicação limitada; Além disso ela é cultural, regional, tribal.

3.A era da super conectividade trouxe facilidades mas problemas também, como por exemplo, uma variedade muito grande de interlocutores cada um com um background diferente e às vezes vivendo em culturas desconhecidas para o emissor da mensagem;

4.Será que conseguimos dar atenção ao que é relevante tendo em vista o bombardeio de dados/mensagens/informações todos os dias?;

5.Na era da internet, quais fontes são fidedignas?

6.As forma de trabalho colaborativas ajudam muito mas será que não nos fazem perder foco também? Qualquer um pode opinar em nosso trabalho quando estamos colaborando na intranet da empresa? Quais são os interesses dos colaboradores, todos estão alinhados em relação ao objetivo maior do negócio?

Propondo melhorias

Elencamos alguns fatores que podem ajudar a melhorar a comunicação na prestação de serviços de TI.

Qualificação dos Stakeholders dos Serviços

Compreender quem são os diferentes interessados, participantes, envolvidos com um serviço é fundamental para adequar a comunicação com cada um deles. Geralmente seus objetivos e interesses com relação àquele serviço são muito diferentes. Claro, para isso um modelo de operação orientada a serviços facilita o trabalho de mapeamento.

Stakeholders típicos são : (1) clientes, (2) usuários, (3) diretor de área cliente, (4) pessoal da operação, (5) gestor do serviço, (6) terceiros, (7) auditores do serviço, (8) agentes externos como governo e a própria mídia, (9) gerentes de projeto, (10) parceiros de negócio, (11) centrais sindicais.

Pode-se então agrupar os stakeholders por áreas de interesse visando boa comunicação, como por exemplo : (a) informações estratégicas, (b) informações financeiras, (c) informações operacionais, (d) informações sobre interface com clientes, (e) informações de interesse público, (f) informações privilegiadas para concorrências.

Estratégia de Comunicação

Toda comunicação deve ter um objetivo e, claro, com direcionamento do que a empresa considera mais relevante para seu negócio.

Alguns pilares de um plano de comunicação podem ser, por exemplo :

(1) Estabelecer uma visão clara sobre os objetivos e prioridades do negócio;

(2) Esclarecer as políticas da empresa;

(3) Identificar e manter patrocínio dos envolvidos com os objetivos da empresa;

(4) Remover barreiras internas;

(5) Construir parcerias.

Ou seja, como tudo na vida, a comunicação também é política!

Plano de Comunicação

Pela diversidade de stakeholders de um serviço pode-se imaginar que somente com um plano de comunicação para aquele serviços e seus processos de gestão, pode-se adequadamente realizar a comunicação efetiva durante todo o ciclo de vida do serviço.

Muito vago? Que tal você chegar ao banco em seu horário de almoço, com tempo contado e raro, para fazer um depósito de suma importância e, somente aí, na porta do banco, descobrir que houve mudança no horário de atendimento? Algum impacto negativo na sua rotina?

Um bom plano de comunicação de serviços deve conter :

(1) Quem é o mensageiro?

(2) Qual é a mensagem? Qual seu objetivo? Qual o Estilo? Quais os fatores críticos de sucesso?

(3) Quem é o público alvo?

(4) Qual o melhor meio de comunicação para aquele objetivo e público?

(5) Sincronismo e frequência da comunicação.

(6) Método de comunicação.

(7) Fornecer um mecanismo de feedback.

A comunicação como Processo

Dentro de cada processo de gerenciamento de serviços de TI deve haver um fluxo claro de comunicação.

Quem precisa saber do que em cada momento? As matrizes RACI ajudam bastante neste sentido.

Gente especializada faz diferença

Sempre que, em nossos projetos, envolvemos as áreas de marketing interno, os resultados foram muito bons.

É importante reconhecer nossa limitações e nós, de TI, não temos a mesma especialização que estes profissionais.

Lembro bem de um gerente de TI que estava avaliando qual MBA deveria fazer. Pois ele estava entre finanças, marketing e comunicação. Inteligente a meu ver.

Verificação sobre a Efetividade da Comunicação

Apesar de todos os esforços, somente quando perguntamos do outro o que ele entende das nossas mensagens é que podemos avaliar nossa efetividade.

Feedback é fundamental.

Adequação das ferramentas de Monitoração

Este é um trabalho a parte. O caso típico são as implantações de ferramentas de gerenciamento de eventos (monitores) que geram milhões de eventos de tipos diferentes sem que se possa dar um significado adequado para todos estes dados.

Aqui se faz necessário filtro sobre o que se vai monitorar e dar significado aos conjuntos de dados através de sua correlação e tradução. Cuidado com o gerente caixa cheia, que mencionamos anteriormente.

Adequação do dashboard de TI

O mesmo vale para indicadores de desempenho (KPIs). Precisam de filtro, análise e tradução para fazerem sentido para a maior parte de seus interessados.

Segurança da Informação

Toda comunicação deve respeitar os princípios básicos da segurança da informação : confidencialidade, integridade e disponibilidade.

Boa comunicação (Ανακοίνωση, em Grego) a todos!

Serviços ILUMNA associados :

Consultoria : Gerenciamento de Serviços de TI e Governança de TI

Treinamento : ITIL MALC (Managing Across the Lifecycle)

Para Descontrair

Assista ao vídeo, muito engraçado, do grupo inglês Monty Phyton sobre comunicação.

Service Availability Check

Contexto

Sempre que iniciamos um trabalho para implantar gerenciamento da disponibilidade de serviços de TI (service availability management) em um cliente, nos perguntamos de imediato se estamos falando sobre a mesma coisa com o nosso interlocutor.

Algumas frases de “efeito” são usadas, então, para “quebrar o gelo”, tais como :

1.Disponibilidade está no centro da percepção do cliente sobre a qualidade do serviço prestado (essa vem do ITIL e todo mundo concorda, menos aqueles que prezam mais por questões financeiras e, realmente este é um ponto importante);

2.Disponibilidade não se compra, se planeja, implanta, conquista e mantém (esta, também do ITIL com pitadas de sofrimento vivido, já causam aquele minuto de silêncio para meditação); e finalmente,

3.Não me venha dizer que aquele relatório tirado do servidor da aplicação com medição igual a 99,999% availability implica necessariamente na disponibilidade do serviço todo (essa vem de um usuário “aborrecido” e muitas vezes gera aquele comentário no pessoal de TI : — Como assim?).

Sintomas

Para aquecer a discussão trazemos à tona alguns exemplos do dia a dia que tangenciam o tema da disponibilidade de um serviço. Algumas  “historinhas” são :

1.Lembra daquela estádio de futebol (caríssimo) que construíram para a Copa do Brasil de 2014 e que após toda a pompa na inauguração gerou algumas surpresas como : (1) inauguraram mas sem que a parte externa, que possibilita o acesso adequado das pessoas ao estádio, estivesse pronta, (2) inauguraram mas com falta d’água nos banheiros e (3) inauguraram mas sem a infra adequada para as lanchonetes; Ou seja, você até consegue ver o jogo de futebol pois os 22 jogadores, bola e arbitragem estão lá, mas será que o serviço “um dia prazeroso de torcida e futebol com a família” estava disponível?

2.Ciclovia na orla marítima do Rio de Janeiro, pronta, prontíssima, mas não em dia de ressaca (do mar) hein!

3.Atendimento do SUS (Sistema Único de Saúde) em hospitais públicos brasileiros, mesmo quando há atendimento não se sabe se haverá esparadrapo ou soro para o paciente…

Service Availability Check

Feito o aquecimento podemos então partir para o nosso checklist sobre a disponibilidade dos serviços prestados (Service Availability Check).

Nesta primeira parte do checklist, tema deste artigo, identificamos as principais perspectivas que devem ser levadas em consideração ao se planejar a disponibilidade de um serviço, conforme abaixo:

1. Qualificação do serviço e seus componentes;
2. Qualificação dos clientes do serviço;
3. Qualificação dos processos de negócio sustentados pelo serviço;
4. Qualificação dos requisitos de disponibilidade (SLA) baseado nos clientes e processos sustentados;
5. Qualificação dos riscos associados ao serviço; Aqui vale a pena abordar com enfoque da Segurança da Informação no sentido amplo, ou seja, em termos de ativos de informação e critérios de CID (Confidencialidade, Integridade, Disponibilidade);
6. Identificação das estruturas de suporte ao serviço (organização e processos); Por exemplo Service Desk e procedimentos para tratamento de Emergências;
7. Avaliação sobre Confiabilidade e Durabilidade dos componentes do serviço;
8. Qualificação das rotinas e políticas para manutenção de componentes e gerenciamento de ativos e spares, associados aos componentes do serviço;
9. Qualificação dos projetos de redundância de componentes e pessoas associadas ao serviço;
10. Qualificação e quantificação do custo do serviço; ROI também;
11. Qualificação dos fornecedores do serviço, internos e externos, dependências da disponibilidade do serviço com os mesmos e acordos de nível de serviço operacionais e contratos vigentes;
12. Qualificação das capacidades de monitoramento sobre componentes do serviço;
13. Qualificação das capacidades, confiabilidade, amplitude e custo da geração das medições sobre a disponibilidade do serviço;
14. Identificação de gargalos de capacidade sobre os componentes do serviço;
15. Identificação dos períodos críticos e sazonalidade das demandas sobre o serviço;
16. Qualificação das pessoas ligadas ao suporte e gerenciamento (service owner) do serviço;
17. Qualificação das bases de conhecimento associadas ao serviço;
18. Identificação dos históricos de gerenciamento associadas ao serviço : ataques, indisponibilidades, incidentes críticos, etc.
19. Qualificação do nível de conhecimento dos usuários sobre o correto funcionamento e utilização do serviço;
20. Identificação de requisitos de compliance do serviço : ex. normas ISO 20000, ISO 27001, Regulatório associado ao ramo de atuação da empresa;
21. Qualificação dos processos para controle de mudanças e release para o serviço.

Conclusão

É importante perceber que a questão da disponibilidade de um serviço é um tema amplo e requer bastante maturidade da organização prestadora de serviços em termos de gerenciamento.

Na verdade, o domínio dos ítens acima leva tempo e por isso tratamos a disponibilidade realmente como uma coisa a ser conquistada.

Ao término desta primeira fase de avaliação temos os ingredientes para realizar o planejamento da disponibilidade de um serviço de forma a aumentar enormemente as possibilidades de garantir o nível de serviço acordado ou justo pelo que se pretende investir.

Serviços ILUMNA relacionados

1.Consultoria em Gerenciamento de Serviços de TI

2.Treinamento ITIL Intermediate PPO

Procura-se profissional de TI : gestor de transição de serviços

Contexto

Geralmente, quando avaliamos a área de TI de uma empresa, seja ela prestador de serviços interno ou ao mercado, uma questão sobre sua organização e equipe sempre vem à tona : “temos o ataque e a defesa mas cadê o meio de campo?”.

Trocando em miúdos, identificamos claramente o pessoal de desenvolvimento e a equipe de operação e suporte mas raramente vemos profissionais alocados para fazer a transição de serviços de TI, ou seja, alguém especializado em garantir que os novos serviços, aplicações por exemplo, ou mudanças em serviços existentes, sejam levados de forma adequada à produção.

Será que não há profissionais capacitados ou não há lugar para eles nas organizações de TI atuais?

Sintomas

Antes de mais nada vamos refletir um pouco sobre essa tal de transição de serviços de TI e sua relevância.

Vocês já ouviram coisas como essas, abaixo, em suas empresas?

1.”Colocamos o aplicativo em produção mas deu tanto erro que precisamos voltar a traz e corrigir todos aqueles BUGs! Haja retrabalho“;

2.”Entrou mas derrubou outros serviços e foi pane geral. Até colocar tudo no ar de novo já era madrugada”;

3.”Bom dia, estou com um problema no aplicativo X, vocês podem me ajudar? — Desculpe senhor mas este aplicativo não consta aqui na minha lista de softwares suportados pelo Service Desk, qual é mesmo o nome, Y?

4.”Ô ciclano! Sabe se esse tal de Voip que colocaram aí tem algum manual? Não falaram nada, já tá funcionando?

5.”Nossa, falei agora com o beltrano, aquele do comercial, e ele disse que venderam mais 4 projetos de outsourcing este mês. Será que vamos dar conta de colocar tudo isso em operação nos próximos 3 meses? Seria melhor não ter vendido!”

Contratando um Service Transition Manager

Se qualquer semelhança com o exposto acima foi mera “coincidência” com sua empresa talvez esteja na hora de contratar um gestor para transição de serviços. Ou talvez alocar alguém para este papel.

Claro, precisamos de processos bem definidos mas sabemos também que um bom profissional pode influenciar e servir de pedra fundamental para que alguns processos saiam da gaveta (ou dos livros do ITIL).

E por falar nisso, vamos ao “pai dos burros” ( ITIL, ISO 20000, CobiT) para qualificar este profissional.

É aí que surge o problem, dificilmente se encontra um único profissional que consiga desempenhar todos os papéis apontados nas boas práticas de gerenciamento de serviços para a “fase” de transição de serviços.

O mais adequado, em nossa opinião, seria criar uma equipe de transição de serviços, assim como temos uma equipe para desenvolvimento, outra para operação e suporte e outra para gerenciamento de projetos.

Agora sim, parece mais realista.

A equipe de transição de serviços deve atuar ativamente em pelo menos 6 processos cruciais para garantir que um novo/modificado serviço seja colocado em produção de forma adequada :

(a) com mínimo impacto não previsto à operação (ou seja, não abalando sua disponibilidade),

(b) de forma segura (sem gerar mais riscos à segurança da informação),

(c) com boa comunicação aos usuários, service desk e demais equipe e fornecedores envolvidos,

(d) com o controle adequado sobre novos componentes (Itens de Configuração) ativos;

(e) com toda a documentação em dia para facilitar suporte e uso pelos funcionário.

Os processos a serem orquestrados pela equipe de transição de serviços são, principalmente :

1.Planejamento e Suporte à Transição : algo mais gerencial inclusive em termos orçamentários;

2.Gerenciamento de Mudanças : aqui temos que incluir o CAB (Change Advisory Board) e uma visão mais de avaliação e autorização sobre as transições em pauta;

3.Gernciamento de Configuração e Ativos : controle sobre ativos gerenciados;

4.Gerenciamento de Validação e Testes : verificação de requisitos;

5.Gerenciamento de Liberação e Implantação : mão na massa da implantação;

6.Gerenciamento de Conhecimento : base de conhecimento sobre os novos / modificados serviços.

Conclusão

Percebemos um GAP enorme das empresas/áreas de TI nas suas estruturas no que tange à transição de serviços.

A falta de profissionais praticantes é uma consequência e realimenta a imaturidade das organizações.

Fato é que os nossos serviços de TI, na sua maioria, ainda são caros, inseguros no sentido amplo(CID – Confidencialidade, Integridade e Disponibilidade), e estão longe de entregar ao negócio a dinâmica que gostaria de ter.

Por outro lado, há muitas oportunidades para que profissionais e empresas de TI evoluam sua prestação de serviços e se diferenciem no mercado por conta de uma melhor capacitação de transição de serviços.

Normas como a ISO 20000, em seu capítulo sobre  Transição de Serviços Novos e Modificados, assim como a norma ISO 27001, na exigência de controle sobre mudanças, ressaltam a necessidade de boas práticas em transição de serviços.

Justificando o Investimento na ISO 20000

Geralmente, em nossos projetos de apoio à preparação para certificação, a fase inicial é a justificativa do projeto aos executivos da empresa. Vale tanto para empresas Provedoras de Serviços de TI quanto para empresas cujo negócio não é TI, apenas depende dele.

O fato é que a adoção de um Sistema de Gestão, seja ele baseado na norma ISO / IEC 20000 ou qualquer outro modelo de mercado, ITIL, CobiT, ISO / IEC 27000, traz resultados efetivos.

Mas nem sempre é fácil justificar, dado que o investimento irá concorrer com outros projetos em voga na empresa. Outro fator que dificulta é o fato de tal investimento ser do tipo “saneamento básico”, aquelas coisas estruturais de altíssimo valor mas que não geram “votos” imediatos aos “políticos”.

Sendo assim montamos uma associação fácil entre processos da norma e áreas da empresa e os benefícios que cada área diretamente pode ter com a adoção daqueles processos. Seria o primeiro passo para a construção de um business case da ISO 20000. Identificamos estas associações em nossos inúmeros projetos de ISO 20000 e estes incluíram empresas de vários portes tanto do lado fornecedores de TI quanto consumidores de TI.

Vamos aos dados.

Para Fornecedores de Serviços de TI

Quadro de associação entre Áreas da Empresa e Processos da Norma ISO / IEC 20000

Quadro de associação de Benefícios de Negócio por Área da Empresa

Para Empresas cujo negócio não é TI, ou seja, Consumidores de Serviços de TI 

Quadro de associação entre Áreas da Empresa e Processos da Norma ISO / IEC 20000

Quadro de associação de Benefícios de Negócio por Área da Empresa

Primeiro Curso ITIL Oficial Brasileiro faz 10 anos de Idade !

No dia 1 de Maio de 2004 a Ilumna ITSM recebia uma carta de acreditação histórica.

O remetente foi o EXIN (Examination Institude, da Holanda) que sacramentava então o trabalho de meses de desenvolvimento do primeiro curso oficial de ITIL Fundamentos brasileiro.

Esta carta de acreditação nos é muito querida pois reflete, além  do nosso pioneirismo na área de ITSM (IT Service Management), também a paixão e crença no Gerenciamento de Serviços de TI enquanto área de conhecimento, prática e desenvolvimento profissional e empresarial.

Traçando um breve paralelo de uma década atrás com os dias atuais, no contexto de ITSM, podemos identificar algumas diferenças e outras semelhanças.

Diferenças / Semelhanças de 10 anos atrás com os dias atuais

1.O tema era muito desconhecido na época e havia poucos profissionais brasileiros certificados.

Hoje bem mais difundido e com milhares de profissionais certificados.

2.Somente algumas empresas, geralmente multinacionais, esboçavam iniciativas mais estruturadas de investimento em gerenciamento de serviços. O Banco Real foi um dos pioneiros, por exemplo. Os grande fornecedores de TI do mercado já tinham suas próprias versões do ITIL no seu modus operandi. Mas aos poucos migraram para os processos de forma mais standard.

Hoje, mesmo sem iniciativas bem estruturadas, a maioria das áreas de TI tentam se organizar dentro de uma visão de processos e indicadores. Os profissionais já ouviram falar de ITIL e o tema está muito mais próximo do seu dia a dia.

3.O primeiro encontro (fórum) aconteceu em 2003 e o itSMF (IT Service Management Forum) capítulo Brasil era uma aposta para representar os interesses dos profissionais envolvidos e que defendiam maiores investimentos em ITSM.

Hoje as iniciativas de organização dos interessados no tema se dispersou até porque o ITIL não é mais uma bandeira em si. Vemos muito mais bandeiras associadas à qualidade, performance organizacional e governança de TI que mobilizam iniciativas tentando resolver questões do dia a dia.

4.A ISO/IEC 20000 não existia e o único certificado possível era o profissional.

Hoje a ISO/IEC 20000 é uma realidade principalmente para fornecedores de serviços de TI e a possibilidade de certificar a empresa / uma operação é bastante motivadora.

5.Saíamos da versão 1 e já estávamos na versão 2 do ITIL onde havia 10 processos organizados em 2 livros, principalmente, o Service Support (Incident, Problem, Configuration, Change, Release, Service Desk) e o Service Delivery (SLM, Capacity, Availability, Financial, Continuity).

Hoje, com o ITIL na versão 3 2011 trazendo o conceito de ciclo de vida, vemos muito mais integração de frameworks como o CobiT, TOGAF, Six Sigma, etc. O próprio dono do ITIL, através do seu operador, a AXELOS, está disponibilizando várias frameworks e processos nas área de gerenciamento de projetos, portifolio, risco, etc.

6.Resultados de negócio com ITSM estavam muito distantes, e continuam, mas os gestores de TI e de governança das empresas, assim como os diretores (CIOs, CFOs, CTOs) que pagam as contas dos investimentos em ITSM estão muito mais focados em financiar projetos que efetivamente agreguem algo para a empresa.

Bom, é isso. Um pouco de revival.

Parabéns à equipe ILUMNA por manter a chama ITSM acesa.

Fazendo boa Gestão de Demandas de TI, sem bola de cristal ?

Ideia Central

“Diga-me o que demandas que te direi quem és”.

Esta paródia do célebre dito popular toca, a meu ver, no cerne do gerenciamento de demandas, qual seja, conhecer o gerador das demandas. 

Muitos gestores de TI relatam o sentimento de serem “pegos de surpresa” pelas demandas do negócio à sua área e gastam efetivamente a maior parte do seu tempo se contorcendo no “apaga incêndio” para conseguir dar vazão ao que precisariam suprir com tranquilidade e eficiência.

Será que os gestores precisam mesmo de uma bola de cristal para equilibrar suas contas neste jogo contínuo de Demanda versus Suprimento?

Pois uma boa ajuda pode vir das práticas de marketing.

Não aquela visão tosca de que o “marketeiro” quer nos vender aquilo que não precisamos mas sim em uma de suas vertentes mais puras, aquela de conhecer profundamente o seu consumidor.

Nas palavras do próprio Philip Kotler, um dos papas do marketing : ” Marketing has evolved to be not only product centered but customer centered“.

Sintomas

A falta da prática do gerenciamento de demandas traz efeitos colaterais danosos ao ecossistema de prestação de serviços :

(1) Primeiramente há uma sensação de risco iminente pois a qualquer momento pode “faltar” capacidade para atender aos clientes e usuários. Um pouco do que sentimos com os apagões de energia elétrica ultimamente. A imprevisibilidade é tão grande que não se tem como fazer qualquer planejamento, a não ser aquele célebre “chute para cima” que na maioria das vezes sai bem caro;

(2) Se do lado de TI há insegurança, imagine do lado do cliente / usuários. Houve casos de usuários contratando serviços de TI “por fora” para servir como “backup” aos ofertados pela empresa, para se protegerem daqueles picos de demanda onde ocorre o “salve-se quem puder”;

(3) A conta não demora a chegar, e é alta. Já vimos gestores de TI assinando contratos de suporte extra absurdamente caros só para ter uma alternativa aos serviços prestados por eles mesmos, desconfiados da sua própria capacidade de entrega em momentos de alta demanda; Além disso as compras de última hora são “apreciadas” somente pelos fornecedores de hardware, software e serviços, que lucram bastante;

(4) Fica a sensação de que TI realmente não é sensível aos eventos mais importantes da empresa, como picos de vendas, datas críticas no calendário de negócio do cliente, períodos de geração de informações para auditoria externas ou requisitos das agências reguladoras de cada segmento.

Será que tem jeito?

Continue lendo e também verifique em nosso Calendário de Treinamentos a próxima turma do treinamento :

ITIL® Intermediário PPO – Planning Protection and Optimization, onde estas questões são abordadas a fundo.

Acesse nossos demais artigos exclusivos seguindo-nos nas redes sociais :  linkedin, twitter ou facebook.

Serviços de Consultoria Relacionados

Consultoria em Gestão de Demandas de TI

Iniciativas

Uma boa forma de organizar iniciativas para tirar valor do gerenciamento de demandas é conjugar 3 verbos:

(1) Compreender. Ponto de partida crucial é a compreensão dos padrões de consumo do nosso cliente.

É necessário se fazer um estudo e acompanhamento aprofundado sobre, pelo menos,  (1) Padrões de Atividade de Negócio  e (2) Perfis de Usuários.

O primeiro diz respeito ao comportamento do negócio em termos de consumo de serviços.

Períodos do ano, mês, semana e até dentro do dia, de maior atividade de negócio (vendas, produção), datas críticas para disponibilidade de algum serviço em específico (por exemplo a folha de pagamento). Este estudo pode e deve ser quebrado dentro da cadeia de valor do cliente.

Lembre-se que para alguns negócios, por exemplo vender flores, existem duas grandes datas no ano, Dia da Mães e Finados. Ou a páscoa para quem vende chocolates.

O segundo diz respeito aos tipos de usuário (consumidores ) com quem lidamos na empresa. Por exemplo temos o perfil Executivo, faz tudo no smartphone (ai minha segurança!) e está sempre viajando (será que a VPN vai funcionar ou já sou cloud?). Quem não se lembra também do comportamento típico dos contribuintes brasileiros ao fazerem suas declarações e submetê-las à receita no último dia, às vezes na última hora. Haja processamento por parte da Receita!

(2) Antecipar. A partir do conhecimento profundo dos padrões de consumo por serviços de TI da minha empresa (padrão de atividades e perfis de usuários, mencionados acima) é possível, finalmente, fazer algum planejamento, principalmente no que tange a capacidade e disponibilidade, pois haverá um “baseline” sobre a demanda média e suas principais variações. E todos sabemos que planejar traz estabilidade, confiança, menor custo e menos “stress”. E claro, a tomada de decisão é muito mais assertiva.

(3) Influenciar. Finalmente chegamos ao “fine-tuning” do gerenciamento de demandas. Muitas vezes a solução para atender algumas demandas não é gastar mais com investimentos em infra-estrutura, software ou serviços, mas simplesmente criar um ambiente em que os geradores de demandas se sintam confortáveis para mudar seu padrão de consumo (mais próximo do geral) sem afetar o resultado final e trazendo para o provedor de serviços maior tranquilidade para prover o serviço.

Um exemplo simples é colocar no mural do cafezinho a lista das áreas da empresa que mais imprimem e claro, com algum slogan sobre proteção à natureza. Geralmente aquelas pessoas que imprimem seus currículos e TCCs nas instalações da empresa ficam mais comedidas.

Oferecer bônus para quem consumir em horários diferenciados dos picos conhecidos também é uma forma interessante e eficaz de influenciar. Aqui a engenhosidade pode ser bastante bem remunerada.

Processos de Apoio

Os processos que estão mais intimamente ligados ao gerenciamento de demandas são :

(1) Gerenciamento de Capacidade e Disponibilidade, que ao receberem informações sobre os estudos de demandas podem fazer seus planejamentos com muito mais acuracidade e gastando menos;

(2) Gerenciamento de Portifolio de Serviços, que pode oferecer ao Gerenciamento de Demandas uma visão sobre os novos serviços que o negócio está demandando e por conseguinte precisam ter seus padrões de consumo estimados e avaliados;

(3) Gerenciamento de Nível de Serviço e Catálogo de Serviços, que podem servir como fonte de informação mas também como instrumentos para influenciar padrões de consumo dados acordos prévios sobre responsabilidades e incentivos aos consumidores em troca de lealdade a determinados padrões. Por exemplo, se os usuários “preferirem” consumir smartphones do mesmo padrão na empresa isto reduzirá bastante os custos com suporte.

Resultados

Os investimentos em gerenciamento de demandas demostram seu retorno de várias formas mas principalmente : (1) Reduzindo interrupções críticas nos serviços prestados, seja por falta de capacidade ou por planejamento inadequado de disponibilidade, (2) Redução dos custos da operação e finalmente (3) Maior confiança de usuários e clientes sobre os serviços prestados.

Sim, seria mais fácil usar uma bola de cristal mas se ela funcionasse mesmo será que não teríamos um problema de escassez deste produto?

Serviços de Consultoria Relacionados

Consultoria em Gestão de Demandas de TI

Cursos de Especialização

Na linha dos cursos do ITIL® pode-se obter maior especialização neste processo com o curso :

ITIL® Intermediário PPO – Planning Protection and Optimization, onde estas questões são abordadas a fundo.

Consulte nosso  Calendário de Treinamentos para saber quando será a  próxima turma aberta ou solicite informações para turmas in-company.

Para maiores informações fale com nossa área de treinamentos em treinamentos@ilumna.com.

Para consultoria mande email para ilumna@ilumna.com.

Receba nossos artigos exclusivos seguindo-nos nas redes sociais :  linkedin, twitter ou facebook.

ITIL® is a registered trade mark of AXELOS Limited

O Melhor Gestor de Nível de Serviço do Mundo, meu mecânico?

A ideia central

Faz um tempo, quando conheci o meu mecânico atual, ele, após ouvir atentamente as minhas reclamações sobre todos os barulhos, engasgos e alto consumo do meu carro, olhou pra mim e com olhar firme, vaticinou : “Rapaz, este serviço aqui vai ser rápido, bom e barato”. Surpresa, espanto e alívio foi o que senti na hora, até ele finalizar, “o Sr. escolhe 2. Rápido e barato, num vai ficar bom, rápido e bom, num vai ficar barato e barato e bom, num sei quando entrego”.

Esta fábula, a meu ver, vai direto ao cerne da questão do Gerenciamento de Nível de Serviço (SLM em inglês), a expectativa.

Sabemos que a missão, nada fácil,  do Gestor de Nível de Serviço (Service Level Manager) é costurar acordos internos e externos para que a produção de TI consiga entregar, dentro das suas reais limitações, os serviços, conforme o negócio precisa, também dentro das suas limitações de investimento, dentro do dinamismo do negócio.

MAS, a experiência mostra que grande parte das relações conflituosas com as quais este processo se vê embrenhado, são advindas da mais pura falta de comunicação e acerto da tal expectativa, tanto do lado de quem consome os serviços (clientes e usuários) como do lado que quem produz os serviços, fornecedores internos e externos.

A vida ensina

Ainda não está convencido da importância de adequar a expectativa das pessoas?

Então diga para sua namorada que vai levá-la para jartar fora para comemorar 1 ano de namoro. Na hora “H” leve-a a uma lanchonete. Pronto, noite perdida!

Agora experimente dizer a ela que vai levá-la para jantar, mas que terá que ser algo muito simples pois você, muito bem intencionado, está juntando dinheiro para o futuro do casal. A coisa vai mudar de figura!

Sintomas 

Agora faça uma auto análise do seu ambiente e procure por sintomas como os descritos abaixo.

Eles indicam a falta e / ou descaso, em maior ou menor grau,  com o processo de SLM (service level management, no termo em inglês):

(1) Clientes bastante insatisfeitos e com aquela sensação que estão sendo enganados; Mesmo que o fornecedor esteja fazendo de tudo para “acertar”;

(2) Pessoal da operação e de projetos exauridos e com aquela sensação de que por mais que se esforcem, não há reconhecimento por parte dos clientes e usuários;

(3) Usuários com sensação de abandono e tendo que lidar com o mesmos velhos “problemas”;

(4) Fornecedores fugindo dos gestores ou pensando em “entregar a toalha”;

(5) Gestores e Gestores de Nível de Serviço atualizando seus currículos e verificando a carência de seus planos de saúde.

É, se você respondeu a sim para 3 ou mais das questões acima, cuidado, pode ser “SeLeMite aguda”.

Será que tem jeito?

Continue lendo e também verifique em nosso Calendário de Treinamentos a próxima turma do treinamento :

ITIL® Intermediário SOA – Service Offerings and Agreements, onde estas questões são abordadas a fundo.

Acesse nossos demais artigos exclusivos seguindo-nos nas redes sociais :  linkedin, twitter ou facebook.

Iniciativas

Dependendo do estágio de degradação em que esteja o relacionamento entre cliente e fornecedores de serviços de TI as iniciativas para corrigir a situação tomarão mais tempo e exigirão muita perseverança do Gestor de Nível de Serviço.

No entanto algumas medidas são importantes:

(1) Primeiro, deve haver um reconhecimento político, por parta da área de TI / fornecedor de TI, de que o SLM (processo e responsável) são um fator crítico de sucesso dentro de uma abordagem de relacionamento com o cliente visando longo prazo. Neste sentido precisa haver um empoderamento do processo/gestor. Veja, não faz sentido para o cliente, negociar com alguém que literalmente não manda em nada.

(2) Segundo, deve haver um esforço orgânico do prestador de serviços envolvendo todas as suas camadas de pessoas para assumir-se uma postura comprometida com o cliente mas realista com as capacidades de investimento de ambos. Precisa-se estabelecer a tal da confiança entre as partes e esta conquista, difícil, pressupõem uma série de atitudes de ambos os lados tais como : pacto com a verdade, jogo limpo, responsabilidades para ambos bem definidas, escopo claro do serviço/projeto, atitudes acertivas em momentos de crise e boa comunicação, dentre outras.

(3) Terceiro, precisa-se trabalhar com fatos, números e indicadores. O achismo só traz incertezas. Neste sentido o SLManager precisa do apoio dos demais processos de gestão principalmente para aglutinar os indicadores operacionais, as limitações da operação e até a estratégia de vendas/relacionamento naquele cliente.

(4) Quarto, claro, o perfil do SLManager (negociador) e sua capacidade de comunicação e de “ouvir” o cliente também ajudam muito.

Processos de Apoio

Muitos processos precisam munir o SLM para que a coisa funcione bem :

(1) Um bom Catálogo de Serviços pode servir como primeiro passo para acerto de expectativas; Ops, a área comercial / qualidade também conhece este documento?

(2) O Gerenciamento de Incidentes e Disponibilidade devem oferecer indicadores importantes sobre como está de fato a entrega de serviços segundo seus parâmetros de qualidade;

(3) O Gerenciamento de fornecedores deve apoiar na “costura”dos acordo de nível de serviço externos (contratos);

(4) Segurança da Informação deve apoiar o SLManager a trazer a tona ao cliente o nível de risco atual do operação;

(5) E finalmente o Gerenciamento Financeiro de Serviços de TI que deve trazer um entendimento sobre os impactos das decisões sobre a qualidade exigida / desejada sobre os serviços, diretamente para o bolso do cliente.

Resultados

Em nosso entendimento, o maior resultado do processo SLM, além da convergência dos níveis de qualidade dos serviços entregues para   as reais necessidades do cliente, dentro de um equilíbrio de retorno sobre investimento, é o estabelecimento de uma relação de confiança e com expectativas corretas entre cliente e fornecedor(interno ou externo).

Todos deveriam ganhar com isso !

Cursos de Especialização

Na linha dos cursos do ITIL® pode-se obter maior especialização neste processo com o curso :

ITIL® Intermediário SOA – Service Offerings and Agreements, onde estas questões são abordadas a fundo.

Consulte nosso  Calendário de Treinamentos para saber quando será a  próxima turma aberta ou solicite informações para turmas in-company.

Para maiores informações fale com nossa área de treinamentos em treinamentos@ilumna.com.

Para consultoria mande email para ilumna@ilumna.com.

Receba nossos artigos exclusivos seguindo-nos nas redes sociais :  linkedin, twitter ou facebook.

ITIL® is a registered trade mark of AXELOS Limited

O Service Desk entra em Campo, de Rugby !

A ideia central

O Service Desk, antigo Help Desk, muito antigo “Atenda ao Telefone quem, do Suporte, puder!”  têm visto a sua função expandir fronteiras de forma vertiginosa.

Partindo de um aglutinador de ligações solicitando suporte técnico à área de TI assume hoje, em muitas empresas, a posição de canalizador mor para todas as demandas  (TI e não TI, mais recentemente com o CSC – Central de Serviços Compartilhados) de usuários internos e também clientes externos.

A partir de sua posição “estratégica” servindo de “ponto de encontro” de usuários e áreas de fullfilment, passando pelas áreas de projetos e até de marketing, RH e Qualidade, o Service Desk tem apoiado decisivamente :

(1) a comunicação na empresa, quando por exemplo avisa usuários sobre a futura interrupção planejada de serviços;

(2) a redução de riscos em projetos, quando sinaliza para a área de projetos e transição de serviços horários de pico de utilização de serviços pelos usuários;

(3) a melhoria continuada da qualidade, quando sintetiza as reclamações dos usuários sobre falhas e degradações recorrentes dos serviços;

(4) os ganhos de eficiência da empresa, quando identifica processos internos passíveis de automação e fullfilment através de sua própria engrenagem de tratamento de solicitações e integração com fornecedores.

Sintomas

O reposicionamento é muito bom mas trouxe dores de cabeça.

Mais do que nunca, o Service Desk precisa lidar com uma questão difícil e intrínseca de sua atividade, ela é “People Inside e People Outside”. Mexe com gente, em bom português.

Muitos gestores de Service Desk estão atentos para resolver questões operacionais como : (1) falta de infraestrutura adequada, (2) falta  de habilidades interpessoais, de comunicação, (3) de conhecimento técnico e até de (4) postura e educação primária no trato com as pessoas, culminando com (5) falta de ferramentas de software para automação e apoio ao seu dia a dia.

Também encontramos gestores de Service Desk tratando questões mais gerenciais como : (1) falta de planejamento de capacidade (quantidade de atendentes e mensurarão da sua produtividade média), (2) falta de ações para retenção de recursos e desenvolvimento profissional (skills técnicos) (3) culminando com falta de definição da melhor arquitetura para a organização (central, local, virtual).

No entanto é notória a presença de sintomas como : (1) sentimento de isolamento com relação às demais áreas de suporte, (2) falta de força política para intervir em processos de fullfilment, (3) sentimento de último a saber sobre novos projetos, serviços e SLAs negociados, (4)  falta de informações sobre eventos geradores de picos de demandas, (5) falta de transferência de know-how para aumentar sua alçada de suporte e (5) falta de respaldo frente às responsabilidades não cumpridas dos usuários no uso dos serviços.

Iniciativas

Fora as iniciativas tradicionais no campo da educação, comportamento e processual, o gestor de Service Desk precisa entrar em “campo” para conquistar espaço em pelo menos duas novas frentes de “batalha”, condizentes com seu novo posicionamento, a (1) frente política e a (2) frente de integração.

Na frente política, algumas exigências são cabíveis, tais como :

(1) Ter um assento no CAB (Change Advisory Board), para saber/votar sobre mudanças que impactarão seus usuários;

(2) Fazer coligação com os SLMs (Service Level Managers) na hora de fechar acordos sobre SLA com justa causa para as responsabilidades dos usuários;

(3) Que defina-se o ownership dos tipos de atendimento e que naqueles sob responsabilidade do Service Desk, este seja “empoderado” para representar a direção da empresa frente a fornecedores e demais área de suporte e fullfilment.

Na frente integração, algumas exigências também são cabíveis, tais como :

(1) Que haja uma definição sobre sua alçada de atendimento e dependendo disso que as áreas de suporte mais especializadas efetivamente fechem a retaguarda do “time” através do fornecimento de transferência de know;

(2) Que todos os fluxos de comunicação desde a transição até a operação de serviços envolvam o Service Desk;

(3) Que as áreas de marketing, qualidade e RH participem o Service Desk sobre suas estratégias e decisões.

Processos de Apoio

O “novo” Service Desk, tende a canalizar todas as demandas e por isso precisa atuar diretamente com vários processo e indiretamente com vários outros.

Diretamente temos o Gerenciamento de Incidentes (para resolução de falhas), o Cumprimento de Requisições (para dar vazão às solicitações de serviço catalogadas) e o Gerenciamento de Mudanças (para dar vazão às solicitações de serviços não catalogadas).

Indiretamente temos o Gerenciamento de Catálogo de Serviços e Gerenciamento de Nível de Serviço (para estabelecer as regras do jogo, quais serviços serão atendidos e com que graus de qualidade), o Gerenciamento de Conhecimento (para fornecer as bases de dados de scripts e soluções), o Gerenciamento de Problemas (para fornecer as bases de erros conhecidos) , o Gerenciamento de Mudanças (para comunicar os impactos das novas transições de serviço) e o Gerenciamento de Ativos e Configuração (para oferecer a base de dados de configuração dos equipamentos e serviços atendidos).

Resultados

Três bons resultados de um Service Desk maduro seriam a centralização efetiva das demandas, oferencedo bem estar ao usuário e grande potencial de planejamento para os gestores dado o controle obtido, a automação de processos internos no tratamento das solicitações, aumentando eficiência operacional como um todo (redução de custos) e a redução de riscos associados a mudanças mal planejadas (do ponto de vista dos usuários principalmente).

O ápice seriam os órgãos públicos captarem esta disciplina e nos atenderem pensando em nossa satisfação enquanto cidadãos.

Muitos gestores de Service Desk reclamam da “pancadaria” sofrida tanto do lado dos usuários e clientes como das áreas de suporte mais especializadas.

No rugby também temos pancadaria mas há regras claras que oferecem limites e nunca entra-se sozinho em campo, há uma formação de grupo pensada para quebrar os bloqueios e correr firme, mesmo que passando a bola para trás, até a linha de chegada do GOAL.

Cursos de Especialização

Na linha dos cursos do ITIL® pode-se obter maior especialização neste processo/função com o curso :

ITIL® Intermediário OSA – Operational, Support and Agreement.

Veja o calendário de cursos ILUMNA.

Para maiores informações fale com nossa área de treinamentos em treinamentos@ilumna.com.

Para consultoria mande email para ilumna@ilumna.com.

Siga-nos no linkedin, twitter ou facebook.

ITIL® is a registered trade mark of AXELOS Limited