A Gestão do Portfólio de Serviços é mais importante que a Gestão do Portfólio de Projetos

de IT Skeptic

Há uma visão essencial que poucas vezes é referenciada na ITIL e ainda menos vezes compreendida que é a Gestão do Portfólio de Serviços.

Como trabalhamos numa área em que defendemos, vendemos e implementamos processos e soluções de Gestão de Portfólio e de Projetos este artigo saltou-nos à vista e decidimos traduzi-lo com mínimas adaptações. Corresponde a uma visão integrada destes fenómenos que partilhamos.

Demasiadas organizações têm uma visão portfólio em que apreciam apenas programas e projetos, enquanto negligenciam os sistemas em operação. Este é uma ordem removida de uma visão verdadeiramente holística. A Gestão de Portfólio e de Projetos só olha para a mudança, e não para o status atual. A Gestão de Portfólio de Serviços (SPM) olha para os serviços em produção bem como às propostas mudanças de serviço. 

SPM olha para os serviços em produção, bem como as alterações propostas ao serviço. Olha para a distribuição de recursos entre ambos o Construir (Build) e o Executar (Run), e não apenas Construir. O SPM considera o impacto sobre os nossos serviços existentes quando tentamos introduzir novos serviços. Esta é uma abordagem brilhante. É essencial. Não fazer isso é a razão por que muitos departamentos de TI estão sempre afogados em projetos.

A incapacidade de gerir todo o portfólio de serviços correntes e planeados - concentrando-se apenas na carteira de mudança - significa que haverá um dilúvio contínuo das despesas de investimento (CAPEX) sobre os novos serviços com zero de consideração da capacidade de RUN para os absorver (e muitas vezes, orçamento de zero para os fazer).
Este martelar teimoso é agravado pela prática moderna de retirar os recursos para fora do RUN e atribuí-los aos projetos sem considerar adequadamente o impacto sobre o RUN. Nós entramos em autofagia e consumimos os nossos recursos, destruímos a nossa capacidade de realizar os serviços, porque estamos tão ocupados em construir e mudar os serviços.

O balanceamento de prioridades e recursos em todo o portfólio de mudança, de projetos e de programas, não é suficiente. Temos de equilibrar entre todas as atividades, através BUIL e RUN em conjunto. A Estratégia de Serviço ITIL diz-nos isso através do SPM. É uma pena, poucas pessoas o leiam e menos ainda o tenham obtido. A gestão do Serviço de TI é um equilíbrio constante entre o BUILD e o RUN, ou como eu gosto de definir para proteger e servir (OK OK talvez isso não seja o melhor slogan para usar agora, mas aceitem a ideia). 

Em muitas organizações, o PPM é tratado como uma prática estratégica e ferramentas de PPM são vendidas para os executivos. PPM não é estratégico: é uma tática para o PMO da Empresa gerir as tarefas que lhe foram dadas com as técnicas que criaram. Por outro lado, a Gestão do Portfólio de Serviço, este é que é estratégico.

Espere! Ainda há mais. A Gestão do Portfólio de Serviços oferece uma visão holística de tudo o que acontece na área de TI. Pense nisto: isso faz com que o SPM seja um dos principais mecanismos de comunicação entre a empresa e as TI. O SPM é como nas TI articulamos a nossa posição, a nossa capacidade, os nossos desafios, as nossas necessidades em termos de negócio. O SPM é como solicitamos decisões e direção do executivo e da governação e seus pares sobre como alocar o nosso esforço e os nossos recursos. É como justificamos mais recursos. 

Qual é o mais importante desafio para as TI no momento? Sem dúvida que é a falta de uma boa governação de TI (a menos que seja um fornecedor a contar a história, caso em que o maior problema é, naturalmente, qualquer que seja que a sua ferramenta resolve ou pode ser feito para parecer resolver). Esta é uma questão tão importante!

Se a governação das TI é o desafio e questão mais importante, então o SPM é uma das mais importantes práticas e o portfólio de serviços um dos artefactos mais essenciais. Então porque é tão raro?
Ver em Inglês aqui.

Não culpem as pessoas! Culpem os processos!

Ter bons processos confiáveis ​​é a pedra de toque para um negócio com sucesso. Os processos estão lá para garantir que há consistência e robustez para as actividades repetitivas.

No entanto, nem todos os processos são bons processos e, no pior dos casos, podem realmente fazer recuar o negócio. Isso ficou claro num projecto em que trabalhei recentemente ...

O projeto bloqueou porque o processo de implementação da infra-estrutura de TI não tinha sido devidamente comunicado e os decisores não foram identificados. O departamento de TI ofereceu uma ajuda muito reduzida nas fases iniciais do projecto. Logo, ficou claro que algo estava errado, especialmente porque os membros da equipa, que pretendiam o sucesso do projecto estavam a ser fortemente condicionados pelo próprio processo. Um caso claro de um processo mal pensado e pesado que atrasa um projecto importante para o negócio. Então que lições podemos aprender com isso?

 

O processo demorado

Não culpe as pessoas, porque você tem processos grandes e pesados​​. Pergunte se os processos estão adequados à finalidade. Se você estiver obrigar as suas pessoas a ultrapassar muitos obstáculos e eles resistem, então você está preso num "processo de corrida de obstáculos".

O que fazer: Rever e simplificar seus processos. Verifique se não há papéis e responsabilidades que sejam claros e você preste contas em todos os cenários e não apenas o principal. Teste a execução dos seus processos em papel com as pessoas que vão usá-los e melhorá-los a partir do seu feedback.

Como sabemos, bons processos são um caminho para o sucesso. Por outro lado, os processos mal concebidos são um caminho para o fracasso. Processos pobres são muitas vezes escondidos se os "heróis" da organização continuam a entregar projectos apesar dos processos. Não presuma que o sucesso do projecto é igual a bons processos, há sempre espaço para melhoria.

O que fazer: Converse com as pessoas para entender onde estão os pontos quentes e bloqueios, e atualize os processos para os remover.

 

Processo de impasse

Se um processo resulta num impasse que você deve considerar se está apto para o efeito para que foi criado.

O que fazer: Com qualquer processo, deve certificar-se que nunca alcança um ponto em que se fica incapaz de continuar.
 

Keep it Simple

Você pode ter ouvido a sigla 'Kiss' quando se trata de práticas e processos de trabalho. Ela representa, 'Keep It Simple Stupid " e enquanto eu não defenderia o uso deste com os seus colegas e clientes, você pode mantê-lo em mente ao criar novos processos ou melhorar os já existentes.

Os melhores processos são aqueles que são mantidos simples. Elas são fáceis de entender e de ter etapas e resultados claros.

O que fazer: Olhe para cada etapa de um processo e pergunte se é mesmo necessária. Ela pode ser removida? Será que ajuda a mover em direção ao objetivo? Quanto menos etapas de um processo melhor, então acho que é 'Kiss'.
 

Em resumo

Se se tornar demasiado orientado para os processos arrisca-se a perder de vista o objetivo do negócio. Certifique-se de mantem os seus processos simples, verifique-os com as pessoas que irão utilizá-los e evite processos que podem resultar acabar num impasse. Bons processos irão conduzir o seu negócio em direção aos seus objetivos, mas os processos pobres podem e irão atrasar o negócio.

Se as coisas não estão a funcionar, não culpe as pessoas, culpe os processos e tome medidas para os melhorar.

Proteger e servir

Vem esta conversa a propósito de estar 3 dias a falar sobre a auditoria das TI e a dificuldade de manter o investimento quando a auditoria é utilizada para garanntir que é suficiente a proteção em posição.

Este lema é certamente bom para as TI, como para outras actividades mais ‘bélicas’. Ouvimos dizer muito este lema, por que parece ser o lema da polícia dos EUA e soa como uma coisa das «berças» que se usa nos filmes.

Quando olhamos para as TI parece-nos que estas só existem para criar novas respostas de TI para satisfazer as necessidades do negócio. De facto, isto não é verdade!

Servir sabemos que é o seu propósito mas também protegem.

O Departamento Financeiro não existe somente para encontrar dinheiro para quaisquer que sejam as necessidades do negócio. O departamento financeiro também existe para se preocupar com a saúde e a segurança da organização. Por vezes o departamento financeiro irá resistir a novas iniciativas simplesmente porque a organização não tem possibilidade para as custear. Esta então faz tudo para que a sua posição seja escalada para o Executivo ou para o Conselho de Administração para este decidir se prossegue ou não contra a opinião do responsável financeiro.

Da mesma forma, o departamento de TI existe para proteger os interesses das TI, dos responsáveis da organização, ao mesmo tempo que servem os seus clientes e os utilizadores. Os dois interesses algumas vezes não se alinham. A fixação corrente no Cliente – o culto do Cliente – pode ser errada e perigosa. O departamento de TI deve proteger os activos de TI da organização. Esta actividade inclui:

· A própria informação, a sua confidencialidade, integridade e disponibilidade;

· O investimento nos sistemas existentes para gerir, suportar e usar a informação;

· A capacidade para implementar sistemas novos e alterados: arquitectura, análise, desenho, desenvolvimento e implementação.

Algumas vezes, não é do melhor interesse da organização abandonar estes investimentos ou aumentar os riscos para a confidencialidade, integridade e disponibilidade da informação, de forma a responder a novas necessidades para novas TI para os clientes ou, por outro lado, por que o departamento financeiro considera que não há dinheiro para os custear.

Em qualquer dos casos, as TI devem resistir (aconselhar em desfavor) à mudança e escalar para o Executivo ou para o Conselho de Administração para este decidir se prossegue ou não.

As TI não podem ser encaradas só como um centro de custo, pelo contrário, se as suas principais actividades têm a ver a defesa da informação avultam sempre as destinadas ao prosseguimento do investimento e em apoio e resposta às necessidades dos seus clientes – o negócio. Sem este esforço de investimento, a resposta do negócio ao ambiente seria inadequada e impediria a obtenção dos resultados positivos que permitem a afirmação e desenvolvimento da organização.

Luis Quintino

Planear projectos no ambiente de Help Desk de TI

Tradução de post de Anna Halstead, PMP

Os serviços de Help Desk, no domínio do Suporte de TI, têm muitas vezes de proceder a preparações para fornecer suporte para uma nova ferramenta, aplicação, tecnologia ou produto que serão implementados para os seus utilizadores finais. Embora este tipo de projectos sejam normalmente pequenos e não complexos, todos os projectos de help desk devem ter um planeamento adequado e seguir uma estrutura de projecto, deforma a manter a satisfação do cliente e garantir que quaisquer mudanças no ambiente suportado, não tem um impacto negativo no serviço que o help desk fornece. Afinal, um dos propósitos chave do help desk na sua operação diária é garantir a satisfação do cliente através do fornecimento consistente do serviço acordado. Isto poderá estar em risco quando o suporte para uma nova tecnologia, ferramenta, aplicação ou produto é introduzido e o cliente fica insatisfeito com o serviço.

Estamos a falar de que tipo de projectos?

O projecto pode ser, por exemplo, entrada em produção uma aplicação de negócio para a companhia, migração de utilizadores finais para um cliente de email diferente ou actualização de uma nova versão de uma aplicação existente ou de uma tecnologia já em uso. Se forem estes os casos, as possibilidades são de que o suporte do Help Desk é só uma parte de um projecto maior e trans-departamental. Muitas vezes é onde as questões podem começar se o Gestor deste Projecto não está totalmente consciente da função que o Help Desk irá desempenhar ou assumir que não é necessário planeamento. Nestas circunstâncias, a prontidão do Help Desk pode ser sobrestimada, o que será extremamente frustrante para o pessoal envolvido e para os clientes. O gestor de projecto do Help Desk deverá assegurar-se que a globalidade da organização de TI está consciente doq eu faz ocall center e a função que desempenha quando fornece o suporte ao utilizador final.

Temos de fazer as perguntas certas desde o início. Para avaliar o âmbito e o impacto que o projecto vai ter no Help Desk e nos utilizadores finais.

Como desenhar processos – Versão completa

A versão total do artigo sobre o desenho de processos ITIL.

1. Como desenhar Processos

A prática da ITIL não faz simplesmente atrás de uma secretária. Antes que possa melhorar um processo, tem de compreender o processo existente. Tem de sair de detrás da secretária e percorrer o processo, o que até parece simples, mas como muitas outras coisas, fazê-lo não é tão imediato… >>>

2. As verdades do controlo do Processo

Aquilo que deve aceitar, em primeiro lugar, é ninguém realmente conhece o que se está a fazer e como é que as pessoas realizam o seu trabalho, nem os trabalhadores nem os gestores…. >>>

3. Fluxo real versus fluxo imaginário

Já que temos que aceitar que nem você nem a sua equipa compreendem realmente o processo que quer redesenhar, então o primeiro passo é aprender de novo o que se consegue determinar do processo. >>>

4. Andar o caminho

O seu propósito é observar o fluxo total e isso toma tempo. >>>

5. Modelar o Workflow

Chegou a altura de fazer um gráfico de fluxo. Agora vê o que não pode fazer um gráfico de fluxos num gabinete ou sala de reuniões. >>>

6. Cuidados finais com o processo

Desenhar um processo exige trabalho e observação directa sobre um ou mais especialistas. Requer ainda atenção ao detalhe. Para o realizar temos de nos levantar e sair do gabinete para então realizar a análise das tarefas. >>>

Estou à vossa disposição para esclarecimentos ou dúvidas. Em breve, continuamos com este tema.

Luís Quintino

Cuidados finais com o processo

Continua de ‘Modelar o Workflow’)

Desenhar um processo exige trabalho e observação directa sobre um ou mais especialistas. Requer ainda atenção ao detalhe. Para o realizar temos de nos levantar e sair do gabinete para então realizar a análise das tarefas.

A parte que é talvez mais difícil é aceitar que não sabemos realmente o que se passa à nossa volta. Também é muito difícil observar imparcialmente uma pessoa a fazer alguma coisa que se julga que pode ser feita melhor sem se intervir – mas o objectivo é ser um observador imparcial. Se não consegue fazer isto então necessita de um profissional sem envolvimento para documentar os processos. O objectivo durante a análise das tarefas é documentar e não melhorar.

Parte da aprendizagem do que se faz na realidade é coleccionar todas as formas usadas por qualquer pessoa envolvida no processo que se está a estudar. Deve capturar ecrãs ou cópias físicas de dados de formulários usados. Tomar boas notas sobre a forma como são usados. Faça o mesmo para quaisquer «ferramentas» ou sistemas em uso.

Um princípio chave da ITIL é a eficiência – trabalhar melhor, não mais. Assim, a melhoria no tempo que leva a fazer as coisas é uma medida importante. Isto é muito conhecido na indústria e nos círculos dos recursos humanos, mas é também muitas vezes subestimado pelos gestores de TI que procuram a melhoria do fluxo do processo.

Para além da recolha das ferramentas em uso, é necessário capturar quanto tempo leva o trabalho a ser feito. Precisa de estar apto a responder à pergunta «quanto tempo leva a fazer isto?» antes de responder à questão «será que devo alterar isto?»

O valor de um modelo de processo exacto não pode ser incompreendido. Não se pode melhorar nada sem o compreendermos

Modelar o Workflow

Chegou a altura de fazer um gráfico de fluxo. Agora vê o que não pode fazer um gráfico de fluxos num gabinete ou sala de reuniões.

Pode modelar o fluxo de trabalho (análise da tarefa) através de um desenho ou utilizando símbolos de gráficos de fluxos.

Os símbolos comuns são:

	Início/Fim – Uma oval indica o início de uma tarefa ou uma conclusão. Um fluxo deve possuir só um ponto de partida mas poderá ter muitos pontos de fim. Como por exemplo o início do processo de Gestão de Problemas.
	Input/Output – Um paralelograma indica um input ou um output. Seguindo o exemplo da Gestão de Problemas um input é o Registo de um Incidente. Um output pode ser o Registo de um Erro Conhecido. Normalmente, um output torna-se o input de outro processo ou cadeia de eventos.
	Processo/Procedimento – Um rectângulo indica um procedimento simples. Isto é, tecnicamente, denominado um processo, mas não fique confuso com o processo ITIL e o símbolo de processo num gráfico de fluxos. Estes processos não incluem decisões. Seguindo o exemplo, um processo de gráfico de fluxos pode ser a revisão de Incidentes associados com o registo de problemas.
	Decisão – Um losango indica uma decisão e o fluxo de saída deste símbolo pode ser outra cadeia de Início/Fim, input/output, processo/procedimento e símbolos de decisão.

Pode simplesmente usar um desenho com texto se quiser. O que é importante é documentar o que acontece tão completamente quanto possível e produzir o seu modelo tão cedo como possível depois de recolher todos os dados possíveis.

Agora precisa de criar o modelo e deve fazê-lo no mesmo dia em que recolheu a informação. Isto é devido a não termos, de facto, conseguido apontar toda a informação! O que tem em mente é exactamente a cola que permitirá documentar o que aprendeu – se esperar para escrever irá perder detalhes vitais do processo.

Quando cria o seu modelo, faça-o utilizando ‘blocos’ simples e compreensíveis. O que permitirá que qualquer pessoa siga o fluxo do processo, especialmente os que não estão familiarizados com este. Para já, não inclua tempos no fluxo, concentre-se no trabalho, já que os tempos podem ser adicionados depois.

Tente desenhar o modelo da esquerda para a direita, com outras actividades dentro do processo ‘a descer’ dos blocos do topo. Tente evitar, na medida do possível, a duplicação e os cruzamentos.

Faça a revisão do seu gráfico com o especialista e, depois, reveja de novo o gráfico. Quando se sentir satisfeito e que o gráfico representa com exactidão o que se passa (não aquilo que você pretende), pode voltar e adicionar os tempos.

Esteja pronto para uma surpresa – ficará provavelmente, espantado com a quantidade de trabalho e o tempo envolvido. Só agora pode pensar acerca da ITIL, e agora pode melhorar o seu fluxo do processo.

Andar o caminho

(Continuação de ‘Fluxo Real versus Fluxo Imaginário’)

O seu propósito é observar o fluxo total e isso toma tempo. Por exemplo, consideremos o Service Desk, pode necessitar de algumas horas para observar como são respondidas as chamadas, as tarefas envolvidas, os atrasos, períodos de espera, uso de ferramentas, documentação acedida, movimentos físicos, etc. Outros processos podem ainda levar mais tempo. O objectivo exige exactidão e detalhe, leve algum tempo.

Observe o especialista seleccionado. Aproveite algumas destas dicas:

Assegure-se de que quem está a ser observado sabe o que você está a fazer e porquê – eles são os especialistas e você quer fazer como eles fazem as coisas funcionar,

• Foque-se no normal ou no trabalho de rotina e não nas excepções
• Observe mais do que uma repetição do trabalho
• Escreva imediatamente as coisas importantes
• Seja meticuloso e atento com os detalhes
• Não interrompa o especialista, não o critique ou tente corrigir.

Necessita capturar o ’quem, quê, como e quando’ do processo e deve deixar passar o ‘como e porquê’ para já. Tente então registar durante análise de tarefas:

• Quem está a fazer o trabalho e como muda cada vez que a pessoa deixa de trabalhar
• O que é feito em cada passo do processo
• Quando o processo se inicia, qual é o tempo necessário para realizar cada tarefa principal e quais os atrasos
• Onde está localizado o trabalho no início do processo e para onde vai
• Quando tiver todos os factos precisa desenvolver um gráfico de fluxos do processo para modelar o workflow.

Fluxo real versus imaginário

(Continuação de ‘As Verdades do Controlo de Processos’)

Já que temos que aceitar que nem você nem a sua equipa compreendem realmente o processo que quer redesenhar, então o primeiro passo é aprender de novo o que se consegue determinar do processo.

A única forma de descobrir o que está a fazer é sair de detrás da secretária, sair do gabinete e passear, observar e tomar notas. Não se pode praticar ITIL atrás de uma secretária. Esta afirmação parece simples e alguns até pensam que já actuam assim, mas como em muitas outras coisas, fazer isto não é tão directo. Para praticar ITIL você tem de caminhar, literalmente, através do processo.

Para ter sucesso tem de compreender a diferença entre o que é esperado e o que acontece na realidade para perceber os factores e variáveis envolvidas. Só quando compreender o fluxo real do processo pode melhorá-lo e alterá-lo.

A sai missão aqui é não impor a conformidade, mas antes compreender porque é que o trabalho está ser realizado desta forma. Note que não estou a dizer “porque é que o trabalho está a ser feito da forma errada” – e aqui está a chave – o trabalho está a ser feito de acordo com aquilo que tem de ser feito, não com aquilo que você pensa que deve ser. Nesta etapa, não é produtivo atribuir culpas e etiquetas como «certo» ou «errado».

Muitos gestores sentem que devem reunir um grupo de colaboradores e construir ou documentar o fluxo do processo como um grupo de processos. Ora, isto não está certo, porque é só um exercício de imaginação. A experiência e as boas práticas mostram que este método leva sempre muito mais tempo e resulta numa compreensão incompleta.

Contudo você pode ter um cúmplice interessado na sua avaliação do processo – um perito da área em questão. É muito mais fácil modelar um processo com base na observação de um participante motivado. O especialista pode ajudar a reduzir a quantidade de informação que é necessário registar e pode validar e/ou explicar a lógica por detrás de muitas acções. Lembre-se que a maioria dos especialistas não sabem por eles porque é que fazem as coisas que fazem.

Aprenda a realizar uma análise de tarefas, se possível localize e seleccione um especialista e de seguida percorra o processo, tome notas acerca do fluxo e das actividades. Comece esta avaliação com o processo mais comum. Anote as excepções àquilo que você pensa que é «correcto» mas não pare nem interrompa o especialista enquanto este trabalha, em vez disso tome notas e reveja as excepções mais tarde com o especialista.

Lembre-se sempre que o seu propósito é coleccionar e modelar o processo existente como funciona hoje; não aquilo que você imagina que deve ser, mas antes as tarefas reais e o fluxo que está a trabalhar.

(Continua)

As verdades do Controlo de processo

Aquilo que deve aceitar, em primeiro lugar, é ninguém realmente conhece o que se está a fazer e como é que as pessoas realizam o seu trabalho, nem os trabalhadores nem os gestores.

Pode parecer óbvio que quanto mais alta é a função de gestão menos se como compreende verdadeiramente como é realizado o trabalho. Contudo, não só os gestores muitas vezes não têm ideia como os processos são realizados, como muitos dos trabalhadores também não vos conseguem dizer quando lhes é perguntado.

Centenas de anos de melhorias nos processos de fabrico permitiram realçar dois factos acerca do fluxo de trabalho (workflow). Primeiro, só aqueles que realizam as tarefas de trabalho têm as competências para realizar o trabalho; e, segundo, não pode perguntar ao trabalhador o que está a fazer, já que ele interiorizou muitas das competências das tarefas.

Por outras palavras, só aqueles que estão a fazer o trabalho sabem como fazê-lo e não lhes pode perguntar acerca do trabalho porque não estão conscientes de todos os pequenos passos. Esta questão fundamental de desconexão vem ocorrendo em todos os programas de melhorias de processos desde o princípio do controlo dos processos.

Os profissionais de Recursos Humanos denominam documentação à análise de tarefas realizada por um profissional de análise de funções. Nesta análise profissional das tarefas observa-se o perito do assunto em questão e regista-se o que ele está a fazer. Não se pergunta o que ele planeia fazer, mas antes se regista o que ele, na realidade, fez.

Se lhes pedimos para escreverem o que estão a fazer isto irá resultar em processos incompletos e fraca documentação de fluxo de trabalho.

Verificamos depois que estes passos «perdidos» são elementos chave do fluxo de trabalho e esconderam verdadeiras questões ou oportunidades. Comece por pôr de lado ideias pré-concebidas sobre o que está «certo» e «errado», antes clarificando os propósitos e o que se espera ser realizado no resultado final.

Independentemente do pensa que sabe, o trabalho que realmente está a ser feito e como é realizado é diferente. Esteja preparado para grandes surpresas!

Como desenhar processos

A prática da ITIL não faz simplesmente atrás de uma secretária. Antes que possa melhorar um processo, tem de compreender o processo existente. Tem de sair de detrás da secretária e percorrer o processo, o que até parece simples, mas como muitas outras coisas, fazê-lo não é tão imediato…

Sabemos que a IT Infrastructure Library® ITIL® descreve o que é necessário fazer. A ITIL só descrever os modelos de processos e não oferece direcção passo a passo. A ITIL é uma orientação que deve ser interpretada e adaptada antes da utilização.

Os processos descrevem o trabalho realizado por pessoas. Praticar a ITIL assim torna-se uma ideia simples: compreender os processos existentes (workflow), compará-los com os modelos ITIL, adaptar, improvisar e ultrapassar!

Os processos de TI são muitas vezes transversais a mais do que um silo e, assim, é muito difícil encontrar um colaborador ou um gestor que conheça de verdade o fluxo fim-a-fim do processo.

Esta realização é fundamental para o vosso sucesso na prática da ITIL – como funciona o processo corrente é muitas vezes diferente de como pensamos como é (ou deveria) trabalhar.

Proximamente indicarei alguns passos que podem ajudar no desenho ou redesenho dos vossos processos.

Precisamos de compreender os nossos processo!

Os fracassos nas Transformações nas TI

Estou a iniciar um processo de formação de recursos humanos para uma organização pública em África, com o intuito de permitir a iniciação de um processo de transformação da gestão do serviço de TI. O que vou fazer é só o início de um processo de transformação e nem sequer o seu lançamento, somente a realização das condições prévias.

Eu cuidados teremos para evitar o fracasso nos processos de transformação?

Os processos de implementação de boas práticas em gestão de TI devem ser ponderados e compreendidos para garantir efeitos efectivos. O que acontece, na realidade, é que estes processos são muitas vezes mal preparados, pior acompanhados e pouco verificados e então falham. Vamos abordar alguns desses factores.

Porque é que as organizações decidem transformar os seus processos de TI? É quase sempre devido a um evento externo (i.e., regulação, competição, nova liderança) que desencadeia a transformação, mas independentemente da causa, todas as transformações têm as mesmas premissas básicas:

• O que é que é necessário mudar?
• Porque é que é necessário mudar?
• Quem sofrerá o impacto da mudança?
• Quando estará concluída a mudança?

Mas, quais são as razões comuns de falha nas transformações de TI?

Visão Partilhada do Sucesso

Uma das primeiras razões é a falta de uma visão partilhada comum. Esta visão inclui objectivos de negócio, estado final desejado e como esta mudança irá melhorar o negócio. Muitas vezes o líder possui uma visão clara e concisa das mudanças requeridas, mas não é capaz de as articular para a organização. As comunicações entre o líder e as suas “tropas” ficam perdidas no meio das camadas intermédias de gestão.

Quando se pretende modificar significativamente uma organização, todas as pessoas devem conhecer a visão, compreendê-la e aceitá-la (claro que isto vai-se obtendo paulatinamente no processo). Uma forma de resolver este problema é saltar por cima da cadeia de gestão e falar directamente com as “tropas”. Isto pode ser alcançado de várias formas: reuniões gerais, newsletters, email, sms, etc. Um aspecto chave é garantir que todos recebem a mesma mensagem e que esta não está a ser distorcida. Para os líderes de uma transformação o mais importante é comunicação, mais comunicação e, depois, comunicação.

Comunicar, comunicar, comunicar

Outra causa comum de fracasso nas transformações das TI é aquilo a que chamamos a resistência passiva. O que significa isto? Muitas a razão PORQUE uma transformação é necessária é mantida ao nível da direcção e não é partilhada com os outros níveis e com o pessoal. Ou, só são partilhadas algumas das razões para a mudança. Mesmo quando esta informação é partilhada, muitas vezes não é entendida pelo pessoal. Eles não têm o mesmo acesso a outras fontes de informação como a equipa de direcção e eles também não têm a mesma perspectiva.

A razão para a mudança deve ser colocada em termos tais que todas as pessoas possam relacionar-se com ela. Sem esta compreensão, as pessoas irão conformar-se com as “ordens” para mudar e na realidade, nunca irão aceitar de verdade a mudança. Ninguém se irá activamente opor à mudança, mas não iremos ter apoiantes activos ou agentes de mudança para assistir nas actividades.

Uma abordagem para evitar esta armadilha é envolver pessoas de todos os níveis em comunicações de dois sentidos. Ofereça ao pessoal a oportunidade de colocar as questões e perguntas acerca dos porquês da mudança, da sua necessidade, e permitir-lhes alcançar uma compreensão em sintonia com a equipa de liderança. Esta compreensão não acontece de um momento para o outro, irá levar tempo. Então necessita comunicar, comunicar e comunicar.

As Métricas ajudam a acontecer

Outro problema que a maioria dos esforços de transformação enfrenta é que ninguém está a seguir as melhorias. Sim, eu sei que todos os esforços têm um plano de projecto e uma escala de tempo e isto vai sendo reportado, mas até que ponto as mudanças estão a melhorar os resultados do negócio? Muitas vezes, o plano de projecto é utilizado para determinar em que medida o projecto progride e as pessoas não sabem na realidade se as melhorias estão a ter o desejado efeito.

O desenvolvimento de métricas é visto tão só como um subcomponente do projecto. De facto, deverá ter a mesma importância como o desenvolvimento dos Objectivos de Negócio. O desenho, recolha e acompanhamento destas métricas é muitas vezes realizado pela equipa de projecto. Se existem múltiplas equipas fazendo mudanças, usualmente cada equipa tem a sua abordagem para métricas de desenvolvimento o que resulta num conjunto de métricas descoordenadas. O que é que acontece quando o projecto termina e as equipas voltam às suas origens? Uma abordagem muito melhor é ver o desenvolvimento de métricas como um esforço separado mas apertadamente ligado às equipas de mudança.

Um grupo separado deverá reunir os requisitos em que se baseiam os objectivos de negócio e garantirá que estas mesmas métricas fornecem uma informação útil para todos os níveis de gestão. Depois de ser alcançado um acordo de que estas são as métricas “certas”, esta equipa deverá implementar as métricas e fornecer uma análise continuada e supervisão. Como estas métricas deverão comprovar a melhoria do negócio, devem continuar mesmo depois das equipas de projecto serem desmobilizadas. Se o que se passa não está escrito, então não aconteceu. A norma ISO 20.000 declara que se não é acompanhado e medido, então não irá acontecer.

A regra dos 80/20

O último tópico daquilo que liquida os esforços de transformação das TI é o tempo. Qualquer esforço sério de transformação tomará entre 12 a 24 meses para ficar concluído. Muitas das vezes, as melhorias de negócio não são tão óbvias senão quando o programa está quase terminado. Isto significa que já passou um ano desde que foi requerida a mudança e a altura em que foi implementada. Neste ano, ainda para mais, o ambiente já não é o mesmo e o impacto de quaisquer mudanças é inferior ao esperado. Muito provavelmente, as pessoas que esperavam a mudança implementaram medidas transitórias e temporárias para obter melhores resultados. Então por que leva tanto tempo a ver os resultados? Bem, quase todos os programas de transformação procuram quase a perfeição. Este é um programa grande e visível e eles querem que tudo corra bem para todos. Então o que podemos fazer para resolver isto?

Por natureza um Programa de Transformação é grande, complexo e longo. Mas este programa pode ser decomposto em pequenos subprojectos, que podem ter resultados concretos em 90 a 120 dias. Mais importante ainda, estes resultados NÃO tem de ser perfeitos. Utilizamos uma filosofia prática para obtermos 80% certo. Acima de tudo, uma melhoria de 80% em 90 dias é melhor que nenhuma melhoria em 1 ano. Os primeiros subprojectos devem apontar a melhorias já prontas a serem implementadas, coisas que são fáceis e rápidas de implementar. Desta forma, a sua equipa de mudança instila confiança nos seus clientes, na liderança de topo e, o que é mais importante, neles próprios. Este será um esforço longo e se nos sentirmos bem no início poderemos caminhar ate muito mais longe.

Em Suma

Para proceder a uma transformação da Gestão de Serviços de TI, é necessário o conhecimento e a vontade mas temos de estar atentos a:

• Possuir uma clara visão da mudança que é comunicada de forma contínua e consistente e todos.
• Garantir a compreensão e aceitação das razões para a mudança por todos.
• Criar e implementar métricas ligadas aos resultados de negócio desejados.
• Seja rápido e ágil com os resultados intermédios que estejam 80% certos.

Gerir o esforço de transformação

O esforço de transformação foi então financiado e a equipa segue a liderança após um primeiro empenho na transformação. Todos conhecem as áreas a mudar, mas agora o papel do líder da transformação tem de evoluir.

Conforme o esforço é desenvolvido a liderança altera-se para uma função de Protecção, visto que o esforço de transformação estará, na sua fase inicial, numa situação frágil e, mesmo nas melhores organizações, haverá um pequeno exército de pessoas a tentar de forma consciente ou subconsciente miná-lo.

As pessoas têm medo da mudança. Se damos corpo à mudança e obtivemos financiamento para ela e fizemos uma demonstração pública disso, as pessoas começam a receber uma mensagem de que a mudança está a chegar. Isto pode criar ansiedade e incerteza e levar a que alguns dos membros da sua equipa tomem decisões irracionais. Tem de proteger o esforço de transformação e dar-lhe tempo para ter sucesso.

Há duas coisas críticas que deve fazer para proteger o esforço:

• Respeite as Decisões da sua Equipa de Projecto: Uma forma de minar o esforço de transformação é colocar em questão as decisões da equipa do programa. Embora ninguém deva ter receio de feedback construtivo, devemos resistir à tentação de substituir as equipas do programa por razões de maior eficácia, por exemplo. Se alguém à sua volta levanta uma questão relacionada com o programa, dirija-o para a equipa do programa e a sua estrutura de direcção para solucionar a questão. Se puser em questão a autoridade da equipa do programa a mudança não irá surgir.

• Suporte o esforço da gestão do dia-a-dia: Muito mais do que ultrapassar as decisões, deve procurar utilizar todas as mudanças que surgem do programa e embebê-las nas suas práticas de gestão diárias. Será que o programa criou novas métricas? Então reveja-as como parte das suas reuniões de revisão operacional. Foram implementados novos critérios de mudança? Peça que as restantes mudanças feitas sigam os mesmos critérios.

O seu suporte continuado e visível ao esforço será crítico para o seu sucesso de longo prazo. Pode ser facilmente ficar cansado pelos esforços de gestão do dia-a-dia e ficar com a percepção que já fez tudo para suportar o esforço. Mas não. Exige-se que de forma consciente pense em que forma visível poderá dar ao esforço um maior peso de apoio todos os dias. Respeitar decisões, embeber os resultados no trabalho do dia-a-dia, aparecer nos eventos do programa, oferecer encorajamento pessoal aos membros da equipa – todas estas acções dar-lhes-ão suporte e protecção que eles necessitam para terem sucesso no esforço de mudança.

Posts anteriores:

• O Esforço de Transformação
• Mudar não é de borla

Mudar não é de borla

Uma das actividades tácticas mais importantes que deve ser realizada é financiar o esforço de transformação.

Claro que isto até parece óbvio, por que todos sabem que uma mudança custa recursos – humanos e financeiros -, mas o que necessitamos é muito mais do que dar ao programa o dinheiro que ele precisa. Financiar é um símbolo muito poderoso para aquilo que a Liderança das TI valoriza. Muitos programas de transformação tiveram uma morte dolorosa porque tornaram-se só esqueleto e nenhuma carne. Apesar de falarmos e  nos empolgarmo, quando chega a hora de andarmos para a frente, o financiamento não se materializa. Isto é como quando um papagaio deixa de ter vento e cai, o que envia à equipa é uma mensagem  de que a liderança não valoriza o esforço realizado tanto como dizia e que afinal não falava seriamente da mudança.

Temos de evitar esta sina pelo público e conhecido financiamento do esforço. Esta acção significa de facto duas coisas. Primeiro, que temos de ser realistas acerca do que irá ser necessário. Reconhecer que a maioria esmagadora da «despesa» vais ser o tempo dos vossos colaboradores internos. Mas com base nos objectivos de transformação, pode ser que necessite de alguma consultoria externa, o aumento de alguns recursos para libertar a equipa e, ainda algumas ferramentas.

Seja lá o que necessita, não seja tímido. Obtenha o financiamento. Se não quer fazer agora e falhar, então espere até que esteja pronto e seja garantido.

Lançar um esforço de transformação sem financiamento e pela declaração simbólico que isto representa é certamente uma receita para o fracasso.

Com o financiamento garantido, faça um farol dele.

Faça reuniões. Envie emails. Faça sms em broadcast. Envie, enfim, uma mensagem em alto som e clara de este esforço é uma das suas mais importantes e críticas prioridades. Assegure-se que toda a sua equipa sabe que financiou este esforço com a quantia adequada – e isso é muito importante. Não pode haver dúvidas e não podemos fracassar. Torne claro para todos que este esforço de mudança irá ser conseguido.

Contribuiu para reforçar a liderança da equipa e da transformação.

O Esforço de Transformação

A liderança é uma coisa que não existe em abundância na maioria das organizações de TI. Se está a ler isto, provavelmente, já faz parte dum grupo exclusivo de pessoas preocupadas com a liderança ou é mesmo um líder – porque só um líder procura constantemente novas formas de melhorar.

A liderança de um esforço de transformação exige todas as competências de liderança que tem e estas devem ser aplicadas com determinação para serem efectivas neste contexto. A razão para isso, em muitos casos, é porque a liderança é muito simplesmente acerca de visão e confiança. Estabelecemos a direcção e movemo-nos nesse sentido com confiança e a equipa segue-nos. Embora isto seja um ponto crítico do que é necessário realizar, um esforço de transformação numa organização é tanto acerca de construir líderes como acerca de liderança.

Para realizar um esforço de transformação com sucesso são necessárias várias coisas. Hoje falamos de como nos tornarmos um Campeão da Mudança.

A primeira coisa e também a mais importante para nos tornarmos num líder das transformação é sermos o corpo e a alma da mudança. Uma das maiores barreiras da mudança é a simples inércia.

A estrada da modernização das estruturas de TI está juncada dos esforços abandonados de esforços falhados de mudança. Não podemos culpar ninguém, mesmo na nossa equipa, por acreditarem em que a verdadeira mudança nunca ocorre.

Precisamos de mudar isto.

Seleccione algo pequeno, mas significativo, que exige que mude a forma como opera e mude-o – de forma pública. Pode ser, por exemplo, que quer ser chamado sempre que se declare um Incidente de Maior Dimensão – qualquer que seja o dia ou a hora. Talvez possa ser que agora irá pessoalmente aprovar qualquer Mudança importante ou que irá pessoalmente dirigir a Reunião de Revisão de Incidentes de Maior Dimensão e que irão concentrar-se nas falhas dos processos e não nos esforços heróicos. Qualquer que seja, deve:

• Afectá-lo pessoalmente e exigir que deve de forma óbvia e visível alterar o comportamento
• Exigir um investimento pessoal da sua parte – não pode ser simples e conveniente
• Ser significativo – não pode ser só para fazer figura.

Inicia-se aqui um processo de construção apoiada da confiança na mudança.

Mas ainda é necessário muito!

Nada substitui saber do que se está a falar!

As organizações que tiveram sucesso na implementação de processos ITIL são aquelas que conseguiram perceber que para cada problema complexo existe uma solução simples e atractiva que está errada, ou como no caso da ITIL – incompleta.

Textos anteriores sobre o assunto:

• A ITIL só por si não resolve!
• Deixe de Procurar uma receita

Tem tudo a ver com seguir ou liderar!

A liderança exige que o líder tenha uma compreensão «operativa» sobre a ITIL. Tal não significa uma «introdução à ITIL» de duas horas apertada entre outros assuntos importantes, Muitas vezes a gestão executiva das TI pede que a empresa comprometa recursos significativos em ferramentas, consultoria e formação para “fazer ITIL” sem ter sequer uma luz do que é que esta trata. Isto é sintomático da “concepção simplista” de que falamos. “Parece simples demais para ser verdade. Assim «faça ITIL» e depois faça outras coisas mais importantes como, por exemplo, perceber por que é que parece que todos andamos a apagar fogos e porque é que os meus colegas continuam a enviar-me brochuras acerca de companhias de outsourcing.”

Qualquer pensamento acerca de uma estrutura, metodologia ou standard deve ser empreendido com a compreensão completa dos objectivos e uma descrição sem ambiguidades do resultado desejado.

Vá comprar alguns livros; sim e leia-os também. Junte-se a um grupo local da internet. Faça a sua própria pesquisa, faça um curso e obtenha uma certificação. Perceba o que é a Gestão do Serviço e como é que ele também não é importante.

Compreenda o seu apetite pelo risco!

Isto não é acerca de «para a frente é que é o caminho». Isto é acerca de criar uma boa compreensão de quanto risco estão as TI e o negócio dispostos a aceitar. Em palavras simples, você está a gerir o risco; a compreender o que são os riscos, assegurar-se que os riscos são transparentes para os stakeholders e a tomar as decisões necessárias para aceitar, mitigar ou transferir o risco. Esta é a razão de a V3 da ITIL pôr um grande foco na governação.

Isto significa que todos os que têm uma palavra no resultado da implementação de qualquer estrutura, método ou standard compreendem quais sãos os riscos/recompensas, como podem enfrentá-los e como podem ser transferidos para outros, tais como fornecedores ou parceiros. A importância desta compreensão do apetite pelo risco fica mais clara de seguida.

Exige-se alguma integração!

Exige-se liderança para oferecer visão e direcção, muito mais do que uma compreensão «literária» do assunto e, entenda, que implementar uma mudança organizacional é um trabalho arriscado.

Não existe «um modelo para todas as situações» na Gestão dos Serviços de TI, apesar daquilo que os vendedores de software, consultores e formadores possam ter afirmado. A Gestão dos Serviços de TI é um problema complexo e a sua solução exige muitos componentes móveis. Embora a ITIL possa não ser a resposta, certamente será uma parte da resposta. Faltam-lhe alguns dos componentes como Governação das TI, gestão de recursos, gestão da qualidade e da segurança. Assim «fazer a ITIL» não é tanto em fazer a ITIL, mas a integração de um conjunto de estruturas, métodos e standards que quando combinados oferecem algumas das soluções para a Gestão dos Serviços de TI.

Sumário em jeito de conclusão

A gestão dos Serviços de TI é uma realização complexa. O ambiente em que a empresa de hoje compete é muito complexo e as organizações de TI dos nossos dias são requeridas a fornecerem serviços de TI que permitam que a empresa concorra com sucesso no mercado.

As organizações que tiveram sucesso na implementação de processos ITIL são aquelas que conseguiram perceber que para cada problema complexo existe uma solução simples e atractiva que está errada, ou como no caso da ITIL – incompleta. Eles compreenderam que não existe uma solução rápida e fácil. Eles sabem que a ITIL não pode ser “comprada” e que não podem simplesmente «fazer ITIL» para sua organização. Eles aprenderam que devem ser “eles a fazer “ de forma a internalizarem a mudança organizacional requerida para o sucesso com a ITIL.

E eles sabem, também, que quando isso acontece, não há um limite natural para o nível de sucesso que pode ser alcançado por uma organização de TI ou uma empresa.

Textos anteriores sobre o assunto:

• A ITIL só por si não resolve!
• Deixe de Procurar uma receita

Deixe de procurar uma «receita»

Os passos para «fazer ITIL», ou seja, resolver problemas complexos nas TI…

Se olhar para a quantidade de livros de ajuda, métodos, esquemas ou outros métodos, o seu primeiro passo será admitir a realidade e confirmar que está perante um problema. Pois, este problema é que continua a pensar que problemas complexos têm soluções simples, mas se isso fosse verdade já não existiam problemas para solucionar?

A inclusão de componentes da infra-estrutura de TI como um conjunto de serviços de TI que permitem directamente alcançar objectivos de negócio não é simples. É muito complexa e conforme o mundo e a tecnologia continuam a ficar mais complexos ainda se torna mais difícil obter mesmo um sucesso marginal na sua realização.
O primeiro passo verdadeiro é uma compreensão que os profissionais de TI, a todos os níveis, devem desenvolver um conhecimento aprofundado sobre a natureza dos problemas enfrentados na implementação de serviços de TI. Não há solução rápida, simples ou «ITIL in a Box».

Siga ou lidere, mas saia do caminho!

Esta é uma questão difícil porque aquelas poucas organizações que podem reclamar algum sucesso também podem afirmar que tinham uma boa liderança das TI bem como da empresa no seu conjunto.
A razão da grande importância da liderança é que qualquer implementação de processos da gestão do serviço, ou de outra framework de processos, metodologia ou adopção de standards exige uma mudança fundamental na forma como as pessoas executam as suas funções. Os bons líderes construirão uma visão para um «mundo melhor» e ajudarão os participantes a verem por eles essa visão.
Com efeito, qualquer esforço para a mudança da forma como as pessoas trabalham exige um esforço significativo na gestão dessa mudança. Os executivos das TI que «’ouvem» sobre a ITIL e querem por decreto «ir para a ITIL» não irão ter sucesso. “Fazer ITIL” requer que a equipa de gestão executiva das TI «viva e respire ITIL». Exige-se um compromisso da gestão que não pode ser só um envolvimento.

continua com Nada substitui saber do que se está a falar.

A ITIL só por si não resolve!

Nas Tecnologias da Informação em ambiente de empresa, em cada dia, há mais problemas para resolver do que os que podem ser solucionados. Para cada problema complexo, quando não se analisa a fundo, encontra-se sempre uma solução simples e atractiva que está errada. Para muitos, a solução simples está na ITIL.

Esta ilusão de simplicidade é idêntica à que o Rei tem acerca das suas roupas finíssimas. Para se ter sucesso com a ITIL temos de compreender porque é que o Rei não tem roupa…
Todos estamos de acordo que as práticas que encontramos na ITIL correspondem a objectivos com valor, mas então porque é tão difícil encontrar organizações que tiveram sucesso real na implementação de mais do que os processos básicos da ITIL?
Muitas organizações acabaram com dezenas de milhares de euros enterradas em ferramentas consultoria e formação – só para acabarem com ferramentas dispendiosas, geridas e suportadas por consultores bem oleados; com um lote de pessoas certificadas ITIL a pensar em por que é que o que fazem não tem nada a ver com aquilo que aprenderam na formação.
É claro, seria fabuloso que tivéssemos a colaboração total do negócio e que os clientes soubessem definir com clareza a qualidade e a quantidade dos serviços de TI que necessitam e que estes serviços possuíssem uma valor estabelecido e claro para a empresa. Bem e quem não quer “restaurar rapidamente serviços de TI que não funcionam” ou #descobrir e remover a causa primária dos problemas”. Já para não mencionar “perceber o conteúdo e o contexto da infra-estrutura”, “ avaliar com propriedade o impacto das mudanças” e “implementar as mudanças sem provocar dano” e, mais, toda aquela coisa de compreender e controlar os custos das TI.
Mas nós não fazemos, eles não conseguem e nós não podemos – pelo menos a fazer as coisas da forma como as estamos a fazer. Na verdade o Rei ITIL não está a usar nenhumas roupas. Vai nu!
Tem de haver uma forma qualquer de iniciar o caminho e começarmos a responder aos problemas dos serviços de TI, em conformidade com a ITIL, mas de acordo com uma metodologia consistente.
Continua com Deixe de Procurar uma Receita

A segurança é uma decisão de negócio

A quantidade de risco que um negócio pode assumir é determinada pela sua própria cultura, a sua sensibilidade de risco da sua reputação e a sua tolerância à perda.

O propósito de alinhar a segurança das TI com a do negócio vai muito mais longe do que garantir que todos têm a mesma pauta de música e estão afinados. A chave está na existência de uma boa política de aceitação do risco para que os objectivos se alinhem.

Definição de Aceitação do Risco

Quando uma organização toma uma decisão acerca do risco só pode fazer de 3 escolhas:

Aceitar o risco tal como foi avaliado – a organização pretende tolerar o impacto potencial de uma segurança comprometida.

Mitigar o risco – reduzir o nível de risco através de controlados melhorados até atingir um nível aceitável.

Terminar a actividade – isto implica que o risco não pode ser reduzido, até um nível aceitável, com efectividade de custo para a actividade de negócio que está a criar o risco.

A forma como estas decisões são tomadas e por quem são definidas na Política de Segurança de Informação da organização. Decisões de Ao Nível de risco podem ter de ser tomadas pela Comissão Executiva enquanto os riscos de baixo nível podem ser decididos pelo proprietário do negócio.

Em todos os casos, a decisão deve ser baseada numa avaliação formal do risco real. Sem surpresa, este processo é denominado Avaliação de Risco e é o trabalho da Segurança da Informação garantir que o risco é avaliado de forma regular.

A actividade de Avaliação de Risco

Risco = Impacto x Ameaça x Vulnerabilidade. Esta não é uma verdadeira fórmula matemática, mas é uma equação que declara que o risco é a combinação do impacto de uma perda e a capacidade de uma ameaça explorar uma vulnerabilidade.

Uma avaliação de risco abrange todos estes factores para determinar o nível de risco. Os controlos de uma organização são, também, analisados para determinar se estão adaptados à tarefa de gerir as vulnerabilidades. Há métodos quantitativos (ou seja $$) e qualitativos (por exemplo, alto, médio e baixo) para a avaliação do risco; ambos são desenhados para comunicar decisões sobre o risco.

A Ligação ao SLA

Qual é a quantidade suficiente de segurança? O negócio já tomou esta decisão na sua aceitação formal do risco. A um nível prático, O Service Level Agreement (SLA) pode referir-se ou às Política de Aceitação do Risco, ou defini-la com mais detalhe para um serviço particular em questão.

Muitas vezes o SLA documenta a frequência com que a avaliação de risco deve ser realizada e define o proprietário do negócio que está apto para tomar as decisões acerca do risco e até que nível. Pode ainda definir os níveis de risco para os quais as decisões devem ser delegadas para outras pessoas. Um SLA deve produzir investimentos de TI com custos justificáveis e o processo de aceitação de risco produz automaticamente investimentos de custos justificáveis em controlos de segurança.

Conclusão

A segurança da informação assumiu uma muito maior importância para as organizações nestes anos recentes devido à regulação, confiança nos sistemas e às preocupações dos clientes e empregados. Isto deveria reflectir-se em decisões sobre o risco pelos proprietários do negócio que directamente podem experimentar a perda potencial.

Mas, neste pequeno paìs da Europa, parece que nada pode acontecer e, portanto, gastar recursos e tempo na avaliação de risco é uma opção de segunda prioridade.

Compreender o Workflow ITIL

Muitas companhias começam a sua implementação ITIL com a função Service Desk e os processos de Gestão de Incidente e Problema. O seguinte exemplo mostra como estes grupos podem trabalhar em conjunto.

Call Center – o Serviço de Call Center redirecciona as chamadas para o apropriado Service Desk ou membro do Service Desk com base nos atributos da chamada. Por exemplo, um utilizador requer assistência na utilização de uma aplicação. Esta chamada é redireccionada pelo Call Center para o agente apropriado no Service Desk.

Service Desk – O agente do Service Desk toma a propriedade do Incidente. Regista o Incidente em preparação de realizar suporte directo ao utilizador, este membro do Service Desk de forma segura realiza as actividades estabelecidas no processo de Gestão de Incidente.

Gestão de Incidente – O agente, torna-se um operador de Incidente no âmbito do processo de Gestão de Incidentes, recolhe a informação e tenta verificar a triagem com o utilizador. Se o agente for incapaz de assistir o utilizador, pode escalar ou abrir um registo de Problema.

Escalar o Incidente

A Escalação é outro ponto de confusão em muitas organizações que planeiam para ITIL. Quando o primeiro nível de tratamento esgota todas as fontes de informação disponíveis e determina que é provável que não seja capaz de concluir dentro da linha de tempo ou é-lhe impossível assistir o utilizador, então o Incidente deve ser encaminhado para outra pessoa (2º nível) ou aberto um Problema.

Assumindo encaminhamento do Incidente para um 2º nível, o agente continua a desempenhar actividades na base da Gestão de Incidentes. A pessoa do 2º nível de Incidente pode residir fisicamente em qualquer sítio, seja num departamento de TI ou mesmo fora da organização, mas desde que trabalhe sobre o Incidente, estará a trabalhar na dependência e controlo da Gestão de Incidentes.

Não há nenhum requisito de que qualquer nível de suporte para além do agente do Service Desk (p. ex. 2º, 3º, etc.) faça parte de qualquer função ou departamento e qualquer linha de suporte pode realizar investigações talvez até com a utilização de procedimentos de teste, ferramentas de diagnóstico, etc.

Como exemplo, na dependência de um Incidente, o segundo nível poderá ser um técnico no grupo de redes ou um administrador que trabalha no departamento de comunicações. É o trabalho realizado, não a estrutura de reporting organizacional que interessa. Isto exige muitas vezes a existência de Acordos de Nível Operacional (OLA – Operational Level Agreements) entre as TI e vários processos, bem como grupos funcionais.

No nosso exemplo continua a ser a rotina do trabalho do dia-a-dia e considerado, contudo, um Incidente. Se o segundo nível determina que não é provável solucionar ou é incapaz de resolver a questão, pode então ser escalado. O número de níveis de suporte é indefinido, sendo único para cada infra-estrutura da companhia ou organização. Não é incomum existirem dois, três ou quatro níveis de Suporte a Incidentes cada um com crescente foco em conhecimento e experiência.

Gestão de Problemas

Em qualquer momento, se parece que a questão é tão complexa ou que exige o envolvimento de múltiplos departamentos tecnológicos ou silos, o Incidente pode exigir a criação de um registo de Problema. Algumas organizações escolhem levantar um Problema sempre que um Incidente não possa ser encontrado na Base de Conhecimento.

Quando trabalha com um Registo de Problema, a equipa passa a trabalhar sob o controlo do processo de Gestão de Problemas. Este exige a nomeação de um “Gestor de Problemas” ou um “Coordenador de Problemas” para liderar o trabalho e supervisionar as interacções entre departamentos.

È neste ponto que é formada uma “equipa de Problema” de técnicos de vários grupos técnicos. Os técnicos do Service Desk (que realizam o suporte de 1º nível no tratamento de Incidentes) tomam agora a responsabilidade de supervisão e monitorização da resolução do Problema, coordenando com o líder da equipa de problema e mantendo o utilizador ou cliente informado conforme for requerido.

Sumário

Precisamente são estas funções e as suas responsabilidades que criam o processo. Como pudemos ver nestes exemplos, a estruturação para os processos nem sempre exige a reorganização dos departamentos. Mas exige muitas vezes formação e organização de equipas dinâmicas para que saibam como e quando devem actuar (por exemplo, Utilização de Scripts para a Gestão de Incidentes) e podem, ainda exigir Acordos de Nível Organizacionais.