O plano de acção para a implementação do SI consistiu na introdução faseada do processo proposto. Ao mesmo tempo que este foi introduzido foram sendo adaptadas as actividades ao novo processo, integração com outros processos e sistemas relevantes ao âmbito da organização (ver Figura 18) e ainda os papéis e ferramenta propostos. Foram também resolvidos os gaps detectados e a alteração de documentos e processos inadequados, promovendo desde cedo a melhoria do serviço.
Template para Relatórios Determinar / Acordar / Documentar SLAs e OLAs Recolher dados operacionais Gerar relatórios do serviço Gerar informação através do cálculo das métricas definidas Desenhar template para relatórios Comunicar resultados aos stakeholders Analisar desempenho / níveis de serviço Optimizar serviço e respectivos processos OLAs SLAs Relatórios do Serviço
Gestão de Níveis de Serviço
32 Pedro Dias
Figura 18 – Relações com outros processos e sistemas (baseado no ITIL v3) [20]
Relativamente à adaptação dos papéis e responsabilidades propostas à organização foi determinado o seguinte:
Função de Service Owner atribuída à actual função de Delivery Manager.
Função Service Manager, Service Level Manager e CSI Manager atribuídas ao actual Service Manager.
Função de Cliente atribuída, evidentemente, ao próprio cliente.
Todas estas funções foram desde cedo envolvidas nas devidas actividades, tal como definido na matriz RACI, acompanhando todo o progresso da implementação.
Vista a actual necessidade de melhoria na organização, a implementação do processo passou exactamente por ter início na actividade 5 (Analisar os dados), correspondendo à análise descrita na secção anterior. Foi analisada toda a informação disponibilizada, o que permitiu a análise do desempenho do serviço, tal como a identificação dos gaps, impactos, causas e oportunidades de melhoria. Concluída a análise passou-se para a actividade 6 (Apresentar e usar a informação), onde se realizou o planeamento das acções para a melhoria do serviço, produzido o template do SIP e consequente preenchimento (Tabela 2), mais tarde comunicado aos
stakeholders.
Com base no trabalho realizado na detecção de necessidades de melhoria, passou-se para a actividade 7 (Implementar acções correctivas) e fez-se uma reavaliação do serviço. Foram definidas prioridades para cada acção (ver Tabela 2) de acordo com a criticidade das mesmas e iniciaram-se as acções para optimização do serviço. Optou-se em primeiro lugar por alterar o próprio processo de Gestão de Níveis de Serviço,
Service Knowledge Management System (SKMS)
Configuration Management System (CMS) Service Portfolio Service Catalogue Processo de melhoria contínua para a Gestão de Níveis de Serviço Catalogue Management Incident Management Problem Management Change Management Availability Management Incident Records Known Error Database (KEDB) SLASLASLA SLASLAOLA
Problem Records Availability Management Information System (AMIS) Change Records SLASLAUC
âmbito desta investigação, também considerado como melhoria do serviço. As restantes acções têm vindo a ser implementadas sequencialmente de acordo com as prioridades. Quanto às melhorias associadas à comunicação ao cliente e às revisões de contratos associados ainda não se concretizaram, ficando a cargo da responsabilidade do Service Manager.
Passando à actividade seguinte, início “teórico” do processo, a actividade 1 (Definir o que deve ser medido) não foi alvo de melhoria, pois não surgiu a necessidade de voltar a esta actividade, embora tal como as restantes, tenha passado a fazer parte do processo da organização. Um dos processos que poderá provocar o início desta actividade é a mudança de um serviço (interligação com o processo gestão da mudança).
Já na actividade 2 (Definir o que pode ser medido), uma das primeiras necessidades foi a criação de um template para todas as métricas (Tabela 3) para que estas fossem documentadas com rigor, juntamente com todos os atributos que lhes dizem respeito, evitando a dispersão de informação a elas associado. Esta actividade tem interligação com o processo de gestão do catálogo de serviços, para a actualização do respectivo catálogo (para mais detalhes consultar ITIL v3).
Embora não tenham sido acordados novos SLAs, houve necessidade de redefinir algumas fórmulas que poderiam não ser completamente fiéis à prestação do serviço (Tabela 3), melhorando a qualidade da informação fornecida. De igual modo, baseado na análise anteriormente feita, surgiu necessidade de alteração de alguns OLAs para que estes estivessem alinhados com os SLAs. Quanto aos UCs, estes não foram acordados pois a equipa em questão não tem dependência de fornecedores.
Dada a relevância da medição do serviço, foram ainda criados novos KPIs, alinhados com o negócio. Estes indicadores são importantes pois conduzem o colaborador a trabalhar no sentido da obtenção de um bom desempenho na prestação do serviço, o que consequentemente leva a organização a atingir os seus objectivos de alto nível (Figura 19).
Estes objectivos podem ser traduzidos pelos seguintes factores críticos de sucesso: Melhoria da qualidade do serviço (melhoria nos níveis de serviço)
Redução de custos
Melhoria da satisfação do cliente
Figura 19 – Suporte para os objectivos de alto nível
Métricas de Actividade Key Performance Indicators (KPIs) Objectivos de Alto Nível
Gestão de Níveis de Serviço
34 Pedro Dias
Tabela 2 – Service Improvement Plan (SIP)
Descrição da Melhoria Benefício Prioridade Responsável Data de Início Data de Fim Estado
(Alta/Média/Baixa) (DD-MM-AAAA) (DD-MM-AAAA) (Aberto / Fechado / Cancelado)
Desenhar e implementar novo processo para a gestão de níveis de serviço. Melhorar prestação do serviço com a melhoria da qualidade e desempenho
do mesmo. Alta Pedro Dias 18-04-2011 17-06-2011 Fechado
Redefinir algoritmos para cálculo dos SLAs. Não contabilizar o tempo fora das “business hours” no cálculo dos tempos de resposta e resolução dos issues (excepto P1s)
Evitar possíveis quebras dos SLAs que não reflectem a realidade da
prestação do serviço. Alta Pedro Dias 26-04-2011 15-04-2011 Fechado
Alteração do documento “Unique EPD”: Alterar o deadline do RMS das 4h no mínimo
para as 3h pois o SLA está definido como 3h. Garantir que os OLAs estão alinhados com os SLAs. Alta Carlos Águeda 04-05-2011 30-06-2011 Fechado
Alteração do documento “Unique EPD”: Definir deadline para o RDW (10h ) Garantir que os OLAs estão alinhados com os SLAs. Alta Carlos Águeda 04-05-2011 30-06-2011 Fechado
Desenhar e implementar novos KPIs para o serviço. Alinhar os objectivos pessoais com os objectivos do negócio. Alta Pedro Dias 16-05-2011 Aberto
Implementar ferramenta de suporte ao serviço. Automatizar actividades do processo. Alta Pedro Dias 25-05-2011 Aberto
Definir com o cliente métricas complementares às existentes. Evitar utilizar unicamente percentagens nas métricas.
Evitar que uma única falha numa população pequena comprometa todo o
SLA. Média
Definir claramente se o prestador de serviço trabalha nos feriados do seu país e/ou se
trabalha nos feriados do país do cliente. Garantir alinhamento entre prestador de serviço e cliente. Média Criar mecanismo para não contabilizar, no cálculo das métricas, o tempo gasto por 3ª
partes.
Evitar possíveis quebras dos SLAs que não reflectem a realidade da
prestação do serviço. Média
Acrescentar glossário à proposta/contrato. Evitar ambiguidades. Baixa
Criação de medidas preventivas associadas às métricas. Geração de avisos prévios sobre potenciais quebras do serviço. Média Acrescentar YTD às métricas e respectivo reporte. Fornecer visão global da prestação de serviço no ano em questão. Baixa Criar forma de calcular e apresentar automaticamente o esforço dedicado à resolução
de um dado issue.
Fornecer ao cliente uma visão clara do tempo e pessoas afectos a
determinado issue. Baixa
Redefinir o que é P1, P2, P3 e P4 e se necessário acordar preços diferentes. Actualmente os preços de P1, P2 e P3 são iguais originando a abertura de quase
exclusivamente P1 e P4.
Evitar que o cliente abra issues P1 que deveriam ser considerados P2 ou P3. Média
Distinguir claramente incidentes , problemas e change requests.
Obter percepção da quantidade de issues de cada tipo. Os problemas são considerados P4, mas nem todos os P4 são problemas. Os Change requests
não são registados.
Baixa Devido à diferença do fuso horário entre Portugal e Itália, as “business hours” em
Portugal deverão ser das 8am às 5pm (correspondente às 9am - 6pm de Itália definidas no contracto) ou alterar contrato.
Respeitar o contracto e evitar quebra de SLAs. Média
A apresentação ao cliente dos tempos relacionados com os issues devem estar
convertidos para a hora do cliente, ou identificado o fuso horário associado. Evitar que os dados sejam mal compreendidos. Baixa
Criar registo automático do deadline para a resolução de um dado issue. Informar o prestador do serviço dos limites para a resolução de um dado
issue. Baixa
Alterar o tempo definido nos SLAs para business hours, pois é imperceptível se 1dia
equivale a 24horas de trabalho ou às 9horas definidas (9 – 18 CET time) Evitar ambiguidades no cálculo dos SLAs. Média O SLA de resolução de P1s deve ser calculado tendo como base o numero de issues não
resolvidos por ano. Que ano? Ano do contrato? Ano do calendário? Ou os últimos 365 dias até ao reporte dos dados?
Tabela 3 – Template para métricas: SLAs
Metric Name Type Process (ITIL) Category Goal Business hours /
days
Aggregation
Period Algorithm Target (Green) Target (Red)
P1 (Critical) 24/7 MTD
if (severity = Critical ){ countif ((response time) <=15min)) * 100% / count(P1 Calls submited in the period) }
P2 (Urgent) MTD
if (severity = Urgent ){ countif ((response
time)<=30min)) * 100% / count(P2 Calls submited in the period) }
P3 (Medium) MTD
if (severity = Medium){ countif ((response time)<=1hour)) * 100% / count(P3 Calls submited in the period) }
P4 (Low) MTD if (severity = Low) { countif ((response time)<=9hour)) * 100% / count(P4 Calls submited in the period) } P1 (Critical)
Seebeyond YTD
if (severity = Critical and application = Seebeyond){ countif ((resolution time)>4hours)}
P1 (Critical)
Others YTD
if (severity = Critical and application <> Seebeyond){ countif ((resolution time)>4hours)}
P2 (Urgent) MTD
if (severity = Urgent){ countif ((resolution
time)<=8hours) * 100% / count(P2 Calls closed in the period) }
P3 (Medium) MTD
if( severity = Medium) { countif ((resolution time)<=40hours)) * 100% / count(P3 Calls closed in the period) }
RMS MTD if(RMS) { countif (RMS_END time <=3a.m) * 100% /
count(days in the period) }
DWI MTD if(DWI) { countif (DWI_END time <=5a.m) * 100% /
count(days in the period) }
RDW MTD if(RDW) { countif (RDW_END time <=10a.m) * 100% /
count(days in the period) }
… …
…
% of Issues Resolved (Closed) in
Time SLA Incident Management 9am to 6pm (CET time) / Monday to Friday
% of Compliance with Deadlines SLA Availability
Management -
% of Issues Responded
(Acknowledge) in Time SLA
Incident Management 9am to 6pm (CET time) / Monday to Friday
# of Issues NOT Resolved (Closed) in Time SLA
Incident
Gestão de Níveis de Serviço
36 Pedro Dias
Tendo em conta que as métricas pretendem suportar uma área de suporte e manutenção, fez sentido defini-las em função dos processos chave da equipa, gestão de incidentes e de disponibilidade. Documentados no mesmo template, foram criados os seguintes KPIs, e respectivos atributos, tendo como referência as boas práticas, que também podem ser encontradas no ITIL:
Average Time in Issues Response (Tempo médio de resposta) Average Time in Issues Resolution (Tempo médio de resolução)
% of issues solved rightly the first time (% de issues resolvidos à primeira) % of issues reopened (% de issues reabertos)
Average Antiquity of Open Issues (Antiguidade média de incidentes e problemas abertos)
Average Time of Batch Conclusion (Tempo médio a que o batch é concluído) Os KPIs são quantitativos e pretendem classificar o serviço em termos de desempenho. Ainda não se encontram completamente implementados dada a necessidade de um período de testes destinado a verificar se estes são realmente específicos, mensuráveis, alcançáveis, relevantes e possíveis de ser calculadas em tempo útil (S.M.A.R.T).
Outra das componentes do SI presentes na implementação foi a ferramenta tecnológica. Esta tem como fundamental função o apoio das tarefas das actividades 3
e 4. A ferramenta em questão, escolha da organização, é o Digital Fuel (DF) [9], um
Software as a Service (SaaS) para a gestão financeira de tecnologias de informação. A sua arquitectura é Web-based, com dados agregados e armazenados na “cloud” (paradigma Cloud-Computing) não sendo necessários nem requisitos mínimos de hardware para utilizar o serviço, nem actualizações, que ficam a cargo do prestador deste serviço. Consiste num conjunto de módulos que automatizam as actividades chave da gestão de negócios de TI, permitindo a melhoria contínua da qualidade do serviço, aumento da satisfação do cliente e redução dos custos de entrega do serviço (Figura 20).
No âmbito desta implementação foi utilizado o módulo relativo à Gestão de Níveis de Serviço, designado por ServiceFlow SLM [10], que está alinhado com as características referidas na proposta e ainda possibilita a integração com o catálogo de serviços e a gestão financeira de serviços, disponíveis por outras duas aplicações da mesma ferramenta, o ServiceFlow Catalog e o ServiceFlow Finance.
Figura 20 – Benefícios do Digital Fuel [8]
Iniciando a actividade 3 (Recolher os dados), foi dado grande foco à criação de procedimentos para a recolha de dados, assim como à própria recolha. De referir que esta actividade está interligada com o processo de gestão de incidentes onde é utilizada uma ferramenta para registo de todos os dados associados ao tratamento dos incidentes.
Os procedimentos seguiram as acções representadas pela Figura 14. Foram definidos os dados necessários para o cálculo das métricas, a frequência, a ferramenta já conhecida e a forma como serão exportados mensalmente os dados. Numa primeira fase a ferramenta acede a um repositório para importar um ficheiro .csv com os dados brutos anteriormente exportados da base de dados e futuramente terá mesmo ligação directa com a base de dados da ferramenta de registo de incidentes. A exportação de dados é actualmente feita a partir de uma query via instrução PL/SQL, também ela alterada no âmbito da investigação devido à alteração do algoritmo para o cálculo dos SLAs, proposto no SIP.
O envio dos relatórios para análise da satisfação do cliente (Client Satisfaction Analysis – CSAT) é feito anualmente, pelo que se pretende aumentar a sua periodicidade, dada a sua importância para a melhoria do serviço. Os respectivos templates deverão ser construídos de acordo com as necessidades de um dado momento.
Desempenho do Serviço Automatisar relatórios Reduzir custos na prestação do serviço Construir confiança e aumento da satisfação dos clientes Gerir proactivame nte a entrega do serviço Melhorar a qualidade do serviço
Gestão de Níveis de Serviço
38 Pedro Dias
Recolhidos os dados passou-se para a actividade 4 (Processar os dados). Nela foram tratados todos os procedimentos para cálculo das métricas a partir da ferramenta proposta. Estando já definida nos templates toda a informação necessária ao cálculo, passou-se para a configuração da ferramenta com os procedimentos necessários ao cálculo e reporte do desempenho do serviço. A ferramenta está neste momento em fase de testes.
Figura 21 – Desde os requisitos até ao reporte (ITIL v3) [23]
Finalizadas todas as actividades, desde os requisitos até ao reporte mensal do serviço (Figura 21), o processo está implementado e adaptado à organização, devendo continuar constantemente a percorrer as actividades e respectivas sub-actividades do processo, promovendo a melhoria contínua do serviço.