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.

Processos e Performance

A estrutura organizacional tem um papel significativo no sucesso ou fracasso da adopção da ITIL. Uma correcta estrutura organizacional é crítica para o seu sucesso … mas provavelmente não deverá reorganizar para a alcançar.
Embora muitos líderes percebam que a estrutura organizacional afecta a capacidade das TI de obter a performance exigida, já muitas vezes ficam confundidos quando as alterações efectuadas para esse efeito não devolvem os resultados esperados.
Em 2006, a Gartner previu que 45% dos realinhamentos organizacionais das TI iriam falhar devido à confusão entre processo e performance. Esta confusão acerca da estrutura, por sua vez, gera resistência dentro das organizações. No mesmo ano de 2006, um estudo realizado sobre as barreiras para a adopção da ITIL encontrou 72% das resposta a apontar para a resistência organizacional.
A tentativa de mapear os processos ITIL de forma funcional, ou seja um grupo de Incidentes, um grupo de Problemas, e por aí fora, rapidamente verifica-se problemático. Os processos descrevem o trabalho realizado por pessoas, não as estruturas organizacionais.

Processo vs. Performance

A estrutura organizacional tradicional das TI faz pouca distinção entre processo (descrição das actividades) e performance (execução das actividades.
A estrutura tradicional das TI é baseada num silo, com a especialização técnica concentrada em unidades organizacionais auto-contidas. Esta estrutura em silo é uma herança das operações de TI iniciais, que coleccionavam a tecnologia os seus tecnólogos em unidades geríveis.
Por exemplo, o departamento de telefones operava os sistemas de telefones, forneciam suporte aos utilizadores e realizavam a manutenção dos sistemas. O departamento do mainframe faz o mesmo, bem como o departamento de redes, etc. Cada silo tem as suas próprias versões de processos similares e não há nunca muita coordenação entre estes silos.
Não há nada de errado com a existência de silos e eles existem na maioria das organizações e profissões. A utilização de silos é usada para coleccionar especialistas em unidades geríveis.
Contudo, enquanto o âmbito das TI expandiu-se muito para além de sistemas isolados e desligados, a gestão em silo não acompanhou o progresso. Os serviços de TI dos nossos dias são sistemas complexos de comunicação e colaboração atravessando múltiplos silos. Esta expansão dos serviços de TI é a causa do dilema com que nos defrontamos para uma operação orientada aos processos.
Para visualizar uma organização efectiva a utilizar operação dirigida ao processo com equipas dinâmicas compostas por recursos provenientes de localizações variadas, considere a forma como opera tipicamente um quartel de bombeiros:

1. Os seus membros realizam os seus empregos regulares até que ouvem o alarme de incêndio; nessa altura reúnem-se no quartel.
   
2. Cada bombeiro conhece a sua função – um toma o comando, outro dá o arranque do carro e outros recolhem e carregam as ferramentas.
   
3. Todos conhecem o seu trabalho e não há confusão acerca de quem é que faz o quê, quando, como ou porquê.
   
4. A trabalhar em conjunto apagam o fogo.
   
5. Quando o fogo está extinto, regressam ao quartel para limpar o equipamento e completar a documentação.
   
6. Então regressam aos seus empregos e esperam por nova chamada.

Embora seja inevitável alguma mudança organizacional para suportar as TI modernas, a verdadeira mudança não está onde se sentam os técnicos de TI ou a quem eles reportam. A mudança real é em como eles se organizam dinamicamente e colaboram para alcançar um objectivo – tal como a analogia dos bombeiros voluntários.
Ver mais em How to Organize ITIL

Ciclo da Vida de uma EQUIPA

Na passada semana falámos da criação e funcionamento de uma equipa e apresentámos um ciclo de vida para a equipa. Um ciclo de desenvolvimento e funcionamento. Hoje vamos desenvolvê-lo.
Muitos irão identificar-se com processos em que estão ou estiveram envolvidos, o que é importante. É uma abordagem de discussão. O ciclo compõe-se de:

• Formação
  
• Discussão
  
• Normalização
  
• Realização
  
• Desmobilização

Reunião

Todas as equipas recentemente criadas passam por uma fase inicial de «tomada de conhecimento». Durante esta fase, a equipa e os seus membros evitam questões sérias e sentimentos e focam-se nos itens de rotina, como apresentações da equipa, quem faz o quê, quando são as reuniões, etc. A equipa depende muito do seu líder para orientação e direcção e este sente que está sempre a responder a perguntas acerca dos propósitos, objectivos e relações externas da equipa.

• Esta é uma fase confortável, mas ao evitarem-se os conflitos e ameaças não se faz, de facto, muito. Uma equipa que se mantém nesta fase demasiado tempo pode nunca conseguir a daí sair para enfrentar a actividade para a qual foi criada.

Discussão

Conforme a equipa vai saindo da face inicial de Reunião, começa a enfrentar as questões importantes e os primeiros confrontos começam a acontecer. Durante esta fase, os membros da equipa podem alterar de posição conforme tentam estabelecer-se em relação com os outros membros da equipa e com o líder. Pode mesmo vir a desafiar o líder. Facções e cliques podem formar-se e podem acontecer lutas pelo poder.

• Alguns membros podem comentar que é bom começar a entrar nas questões reais, enquanto outros irão querer permanecer no conforto e segurança da fase de Reunião. Mesmo quando os conflitos visíveis foram suprimidos, eles continuam lá, só que estão abaixo da superfície.

Nesta fase o líder apoia os membros individuais e foca a equipa nos seus objectivos. Tenta construir a transparência em volta do propósito da equipa para garantir que os membros compreendem as questões e problemas e que a equipa evita as distracções das questões emocionais e de relação.
Uma equipa que se mantém demasiado tempo na fase de Discussão irá gastar tempo precioso a solucionar conflitos entre os seus membros, mas falhará em enfrentar as actividades de que está encarregada.

Normalização

Quando a equipa progride para a fase de Normalização na realidade afirma o estabelecimento e aceitação das regras de funcionamento do grupo e o âmbito das suas actividades e responsabilidades.
Tendo ultrapassado as discussões, agora todos os membros do grupo compreendem e aceitam-se uns aos outros e apreciam as competências, experiência, funções e responsabilidades de cada um. As pessoas ouvem-se, apreciam-se e apoiam-se uns aos outros e estão Até preparados para alterar alguns preconceitos. A equipa acorda com facilidade nas grandes decisões e com conforto delega as decisões menores a indivíduos ou pequenas equipas dentro do grupo.
A equipa trabalha como um grupo em todos os aspectos e mantém um respeito geral relativamente ao líder que desempenha uma função de facilitação e apoio. O compromisso e a unidade são fortes e a equipa consegue envolver-se em actividades sociais e de diversão. Contudo, o líder deve continuar atento pois a equipa ainda é frágil. Os seus membros trabalharam muito para alcançar este nível e podem até resistir a qualquer pressão para mudar – especialmente de fora – por receio de que a força do grupo se quebre ou recue para a fase de Discussão.
O desenvolvimento a partir desta fase e o movimento para a fase de Realização, permitirá posicionar a equipa como uma entidade verdadeiramente performante.

Realização

Nem todos os grupos alcançam a fase de Realização, na qual o grupo mostra interdependência bem como flexibilidade. Todos conhecem os outros suficientemente bem para serem capazes de trabalhar em conjunto e confiar o suficiente para permitir actividade independente. Este alto grau de conforto significa que o grupo pode dirigir todas as suas energias em direcção às actividades em mãos. O grupo, consciente da estratégia, sabe claramente porque é que está a fazer o projecto. A equipa partilha uma visão e pode manter-se em pé sem necessidade de interferência ou participação do líder.
Irão continuar a ocorrer desavenças, mas a equipa soluciona-as positivamente, fazendo as alterações necessárias aos processos e estrutura. Ao mesmo tempo que trabalha para atingir o seu objectivo, a equipa também se envolve nas questões de relações, estilo e processos. Os seus membros são todos da mesma forma orientados às actividades e às pessoas.
O líder de uma equipa de Realização delega e acompanha, ao mesmo tempo que algumas vezes assiste os membros da equipa em questões de desenvolvimento pessoal e interpessoal.

Desmobilização

Finalmente, independentemente do nível alcançado pela equipa terá de enfrentar os desafios da Desmobilização, quer das actividades como dos restantes membros da equipa. Isto é mesmo verdade quando se tratam de grupos de projecto quando a equipa é descomposta no final. Os indivíduos atravessam um momento de perda.
Muitas equipas sublinham esta fase com uma cerimónia formal de fecho. Os indivíduos sentem-se orgulhosos das suas realizações e do grupo e felizes de terem participado em tal grupo. A fase de Desmobilização ajuda ao reconhecimento daquilo que foi realizado e de forma consciente partirem.

Manter a Dinâmica de Construção

Uma equipa envolve muita gente numa organização e a responsabilidade para construir uma equipa efectiva e produtiva estende-se bem para além do papel do líder nominal da equipa. De facto, assenta sim e solidamente nos pés de cada membro.
LQ