MaxShared BaseTreinamento Incidentes e SR - v2.2

Global Technology Services
Treinamento MAXIMO SHARED
Módulo 2: Incidents e Service Requests
Service Management Competency
© 2010 IBM Corporation

Módulo : Gerência de Incidentes e Service Requests
Agenda
 Processo de Gerência de Incidentes

 Start Center – Support Incident
 Estados de um Registro de Incident e Service Request
 Criar um Incident ou um Service Request
 Relacionar Incidentes a um Registro de Global Incident
 Revisar e designar um Registro de Incidente
 Resolver um registro de Incidente
2 Service Management Competency | © 2010 IBM Corporation

Processo de Gerência de Incidentes

Objetivos do Processo
 Os objetivos do processo Gerência de Incidentes são:
– Restaurar a operação normal dos serviços o mais rápido possível para
minimizar a interrupção dos negócios.
– Garantir que os incidentes sejam resolvidos dentro dos Níveis de Serviço
acordados.
– Reduzir o número de incidentes a um nível aceitável de risco, e a um custo
aceitável, direcionando incidentes para o processo de Gerência de
Problemas quando requerido, para execução de Análise da Causa Raiz dos
problemas e ajudar a prevenir a reincidência do problema.
– Minimizar o tempo de duração do incidente:
– Automatizar processos e tarefas no que for possível.
– Otimizar tempos e esforços despendidos na resolução de incidentes.
– Maximizar produtividade dos recursos.
– Monitorar, medir e avaliar o processo.

Visão Geral de Gerência de Incidentes
Vários processos,
especialmente incluindo
Atendimento de 1o. Nível e
Operations Monitoring
Management
Processo
Incidente requisitante
Solicitação de status
e informação sobre
Incidente
Identificar e registrar
Incidente
Incidente
Incidente
Crítico
Situation Management Classificar Incidente e

prover suporte inicial
Incidente
Incidente
Investigar e
diagnosticar Incidente Ter a propriedade,
monitorar, rastrear e Avaliar a performance
Incidente comunicar Incidentes do gerenciamento de
incidentes
Requisição
de Mudança Informação
sobre
Incidente Incidente
Gerenciamento de
Mudanças Resolver Incidente e
recuperar o Serviço Métricas e
relatórios de
Incidente Processo Gerenciamento
requisitante de Incidentes
Incidente
Crítico
Base de Incidente
Gerenciamento deIncidentes
Problemas Fechar Incidente

Definições importantes
 Incidente:
– Qualquer evento que não faz parte da operação normal de um serviço e
que causa, ou pode causar, uma interrupção do serviço ou uma redução
da sua qualidade.
 Requisição de Serviço (Service Request):
– Evento que representa a solicitação de um serviço ou consulta ao
Service Desk, não representando uma falha na infraestrutura de TI.
 Problema:
– Vários incidentes, que exibem sintomas comuns; ou incidente único, mas
significativo (crítico). Que indique a existência de um único erro, cuja
causa é desconhecida.

Quando se abre um incidente?
 A partir de uma falha identificada pelo Cliente. Após a identificação da

falha o Service Desk IBM ou o Service Desk do Cliente abre o registro
de incidente.
 A partir de uma necessidade identificada pela própria IBM, para

correção de alguma falha, interrupção ou anormalidade no serviço
(através de eventos da monitoração ou identificação da falha pelos
times de suporte).
 A partir de integração da ferramenta de registro de Incidentes do

Cliente e da IBM.
 A partir de registro da falha ou solicitação pelo próprio Cliente em

Portal Web para o registro de Service Requests

Recomendações importantes
 Registrar as ações realizadas no registro de incidentes possibilita

uma melhor comunicação com o Cliente, possibilita um melhor
entendimento das atividades realizadas pelos outros times
envolvidos no processo e permite uma melhor análise do incidente
para conduzir iniciativas de análise de causa raiz.
 Os registros de incidentes são auditados pelo time de Gerência de

Incidentes, para assegurar uma melhor qualidade no preenchimento
dos registros, avaliando os seguintes aspectos:
– Abertura: descrição, severidade correta, prioridade correta, direcionamento
correto, coleta de evidências.
– Investigação e Diagnóstico: problem determination, utilização correta de todas
actions/work logs, redirecionamento correto e severidade correta.
– Solução: o que realmente foi aplicado como solução de contorno ou permanente.
– Fechamento de Incidentes: validação da solução aplicada

Recomendações importantes
 O processo de Gerência de Incidentes possui vários controles e é importante que
todos os participantes do processo busquem a melhoria contínua desses
indicadores, como:
– Níveis de serviço contratuais para resolução e atendimento de incidentes
– Quantidade de incidentes fechados por mês
– Backlog de incidentes (incidentes não resolvidos) e Redirecionamento de incidentes (bouncing de
chamados)
– Tempo médio de resolução de incidentes
– Nível de qualidade de registros de incidentes
 Algumas boas práticas são importantes para melhorar os indicadores acima:

– Trabalhar em Gerência de Problemas, para identificar a causa raiz e solucionar os problemas em
definitivo
– Skill e quantidade de recursos adequados para resolver os incidentes abertos
– Validar as soluções aplicadas para evitar a reabertura de incidentes e a insatisfação dos usuários
– Se um incidente foi direcionado indevidamente para seu grupo, direcione para a grupo correto ao invés
de devolver o incidente para o grupo anterior. Trate os problemas de direcionamento depois de
direcionar o incidente adequadamente. Lembre-se que o usuário está sendo impactado pelo incidente.
– O uso de severidades incorretas prejudica o processo, significando mais esforço do que o necessário em
alguns casos e falta da atenção adequada em outros casos. Ao identificar a atribuição incorreta de
severidades trabalhe junto aos times que registram os incidentes para corrigir o problema na causa raiz.

Start Center – Support Incident

Start Center – Support Incident
Quick Insert
Portlet
Result Set
Portlets
Favorite
Applications
Portlet

Start Center – Support Incident – Result Set Portlets
 My Open Incidents: Incidentes que estão abertos e que estão designados

para o meu usuário
 All Open Incidents owned by Group: Todos Incidentes que estão abertos
e designados para o meu Grupo
 All Open Global Incidents: Todos os Global Incidents que estão abertos
 My Open Service Requests: Service Requests que estão abertos e que
estão designados para o meu usuário
 All Open Service Requests owned by Group: Todos Service Requests
que estão abertos e designados para o meu Grupo

Clicar na opção Incidents no

Como ir para o Módulo de Incidents menu Go To > Service Desk para
abrir o módulo de Incidents
Clicar na opção New Incident no

Quick Insert Portlet para abrir um
novo Incidente
Clicar na aplicação
Incidents no Favorite
Applications Portlet
Clicar em um Incidente para

abrir diretamente o Incidente
no módulo de Incidents
Como ir para o Módulo de Service Requests

Clicar na opção Service Requests no
Clicar na opção New Service menu Go To > Service Desk para abrir
Request no Quick Insert Portlet para o módulo de Service Requests
abrir um novo Service Request
Clicar na aplicação Service

Requests no Favorite
Applications Portlet
Clicar em um Service Request para

abrir diretamente o Service Request
no módulo de Service Requests
Estados de um Registro de Incident e Service Request

Estados de um Registro de Incident e Service Request

Preencher Closure Code e
utilizar botão de workflow
para mudança de status
NEW QUEUED INPROG RESOLVED CLOSED
SLA HOLD PENDING RESOLVCONF

Preencher
Owner Group
(fila)
Preencher REJECTED
Assigned To e
Owner Group
Incluir work log

REASON_REJECTING e
CANCELLED HISTEDIT
utilizar botão de workflow
para mudança de status
Criar um Incident ou um Service Request

Como criar um Incident

 Clicar no botão “New Incident” no módulo de Incidents
 Clicar no botão “New Incident” no Quick Insert portlet do Start Center
 Dentro da aba de Incidents (detalhe de um Incidente) vá para o menu “Select Action” e selecione a ação
“Duplicate Incident”. Vários campos (mas não todos) serão copiados do registro antigo para o novo.
Obs: Se freqüentemente você precisa duplicar Incidentes ou

Service Requests a melhor opção seria criar um Ticket
Template para facilitar essa atividade. Quando você aplica um
template, alguns campos são preenchidos automaticamente,
com menor necessidade de digitação de dados. Se você é um
analista de Service Desk entre em contato com o seu
Coordenador de Service Desk

Como criar um Incident

Dentro da aba de Incidents (detalhe de um Incidente) vá para o menu “Select Action” e selecione a ação “Create > Incident”. Quando você usa uma das opções da ação de “Create”, você copia informação para o novo registro, mas você também estabelece um
 relacionamento originator/followup entre os dois registros e o novo registro criado vai passar o seu status para o pai e os worklogs podem ser visualizados nos dois registros.

Como criar um Service Request

 Clicar no botão “New Service Request” no módulo de Service Requests
 Clicar no botão “New Service Request” no Quick Insert portlet do Start Center
 Dentro da aba de Service Requests vá para o menu “Select Action” e selecione a ação “Duplicate
Service Request”. Vários campos (mas não todos) serão copiados do registro antigo para o novo.
Obs: Se freqüentemente você precisa duplicar Incidentes ou

Service Requests a melhor opção seria criar um Ticket
Template para facilitar essa atividade. Quando você aplica um
template, alguns campos são preenchidos automaticamente,
com menor necessidade de digitação de dados. Se você é um
analista de Service Desk entre em contato com o seu
Coordenador de Service Desk

Como criar um Service Request

Dentro da aba de Incidents vá para o menu “Select Action” e selecione a ação “Create > Service Request”. Quando você usa uma das opções da ação de “Create”, você copia informação para o novo registro, mas você também estabelece um relacionamento
 originator/followup entre os dois registros e o novo registro criado vai passar o seu status para o pai e os worklogs podem ser visualizados nos dois registros.

Tela Principal – Incident e Service Request

Tela principal – Incident

Tela principal – Service Request

Campos de preenchimento obrigatório

Os campos marcados com * são de preenchimento obrigatório e devem ser preenchidos na abertura do Incident ou Service Request:
Owner Group: Grupo responsável pela resolução do Incident ou atendimento do Service request
Reported By: User ID do usuário que relatou o Incident ou solicitou o Service Request. Ao preencher o campo Reported By, o campo Affected Person é preenchido com o mesmo valor. Pode ser necessário alterar o campo Affected Person se este for diferente do campo Reported By.
 – Affected Person: User ID do usuário impactado pelo Incident ou atendido pelo Service request. Com o preenchimento desse campo o campo Site, Customer e outros campos são preenchidos automaticamente,
– Summary: Resumo do Incident ou do Service Request
– Classification: Preencher o classification relacionado ao Incident ou Service Request. Se você já souber o número do classification, coloque diretamente no campo e tecle Tab. Se você não souber, clique na seta “Detail Menu” para exibir a árvore de opções.
– Internal priority: Prioridade (Severidade) do Incident ou Service Request
– Service: Preencher o serviço relacionado ao Incident ou Service Request. Ao preencher o Service, o Service Group é preenchido automaticamente.
– Service Group: Preencher o grupo de serviço relacionado ao Incident ou Service Request.
– Site: Indica o Cliente impactado pelo Incident ou atendido pelo Service Request. O preenchimento correto desse campo é fundamental para o cálculo correto do SLA aplicado aos tickets
–
–

Informações gerais sobre o incidente

 Não é necessário preenchimento nesta fase, as informações abaixo serão utilizadas para entendimento do
registro.
 A – Número do incidente (campo “Incident”). Campo fixo e não há possibilidade do conteúdo ser alterado
 B – Dono do incidente (campo “Assigned To”)
 C – Grupo Solucionador responsável pelo incidente (campo “Owner Group”)
 D – Estado do incidente (campo “Status”). Não pode ser alterado diretamente, reflete as alterações realizadas
através do “workflow”
 E – Quem criou o incidente (campo “Created By”)
 F – Grupo de quem criou o incidente (campo “Created By Group”)
 G – Anexos relevantes ao incidente (campo “Attachments”)
B
C D
A
G
E F

User Information - Preencher campo “Reported By”
 O campo “Reported By” deve ser preenchido com o id do usuário que reportou o incidente.
 A – Se já souber o nome (user id) do usuário, escreva no campo “Reported By”

 B – Se não souber o nome do usuário, clique na seta ao lado do campo “Reported By”
B
A


(continuação)
 C – A janela de usuários será mostrada
 D – Se desejado, entre com valores para filtrar nos campos “Person”,
“Department” etc e tecle “ENTER”
 E – Clique no usuário desejado
E
C D


(continuação)
 F – Preenchido automaticamente, refere-se a nomenclatura na qual o usuário VIP quer
ser identificado Ex: Senhor,Presidente, Senhor Presidente.
 G,H,I – São preenchidos automaticamento após a seleção do campo (“Reported By”)
 J – Telefone Adicional (alternativo)
 Caso as informações sejam alteradas, a nova informação vale apenas para este
registro de incidente (o cadastro do usuário não é atualizado).
G H
F I

User Information - Preencher campo “Affected Person”
 O campo “Affected Person” deve ser preenchido com o id do usuário que está sendo
afetado pelo incidente.
 A – Se já souber o nome (user id) do usuário, escreva no campo “Affected Person”

 B – Se não souber o nome do usuário, clique na seta ao lado do campo “Affected
Person”
A B


(continuação)
 C – A janela de usuários será mostrada.
 D – Se desejado, entre com valores para filtrar nos campos “Person”,
“Department” etc e tecle “ENTER”.
 E – Clique no usuário desejado.
E
D
C


(continuação)
 F – Preenchido automaticamente, refere-se a nomenclatura na qual o usuário VIP quer ser
identificado Ex: Senhor,Presidente, Senhor Presidente.
 G,H,I – São preenchidos automaticamente após, seleção do campo (“Affected Person”)
 Caso as informações sejam alteradas, a nova informação vale apenas para este
registro de incidente (o cadastro do usuário não é atualizado).
G H
F I

Incident Details – Preencher campo “Summary”

O campo “Summary” deve ser preenchido com a descrição do incidente
 A – Escreva o título do incidente no campo “Summary”.
 IMPORTANTE: Pesquisas posteriores do incidente só podem ser feitas a partir da

informação que está no campo “Summary” – o texto dos “Details” não pode ser
pesquisado. Sendo assim, as informações essenciais sobre o incidente devem
ser colocadas no campo “Summary”.
 B – Clique no botão de caixa de texto ao lado do campo.
A B

Incident Details – Preencher campo “Summary”

(continuação)
 C – Quando a janela ao lado abrir:
 D – Preencha a descrição detalhada do incidente na área de texto
 E – Clique no botão “OK”
C

Incident Details –Preencher informação de item de

configuração
O item de configuração afetado pelo incidente deve ser inserido no campo “Asset”.
 A – É possível digitar o código do Asset ou então clicar na seta ao lado do campo

“Asset” para realizar uma pesquisa


configuração (continuação) B
 B – Quando o menu for mostrado, selecione “Select Value”

 C - Mude o valor do “Filter By” de “USERCUST” para “All”
 D – Clique no botão “Refresh”
D
C


configuração (continuação)
 E – Se necessário, utilize as opções de filtro para encontrar o item de configuração
desejado. Preencha os campos para filtrar (“Asset”, “Host Name” etc) e digite
“ENTER”
 F – Clique sobre o “asset” desejado

Incident Details – Preencher “Classification”
 A – Clique na seta ao lado do campo “Classification”

 B – Quando a janela de classificação for mostrada, selecione o valor apropriado
 C – Utilize o botão “+” e “-” para expandir e contrair as categorias
 D – Quando tiver escolhido a categoria clique no quadrado azul
C
A
D

Incident Details – Preencher “Classification” (continuação)
 E – Depois que o “Classification” for selecionado, a descrição (campo

“Description”) será mostrada automaticamente.
 Caso haja necessidade de alteração do Classification, clique novamente na

seta do campo “Classification” para uma nova seleção.

Incident Details – Preencher “Internal Priority” (SLA)
 A – Clique na lupa e selecione o valor para o campo (“Internal Priority”) com a

severidade correspondente ao incidente
 B, C –Os campos “Reported Priority” e “Urgency” não serão utilizados
B
A

Incident Details – Preencher “Service”
 A – Clique na seta ao lado do campo de “Service”

 B – Quando o menu for mostrado, escolha “Select Value”
 Automáticamente o Service Group será selecionado, após a seleção do
Service
A
B

Incident Details – Preencher “Service” (continuação)

C
 C – Quando a janela de valores for
mostrada
 D – Clique no valor desejado

Incident Details – Preencher “Service”
 A – O campo “Service” é preenchido de forma análoga ao campo “Service Group”. Depois

que o “Service Group” é selecionado, as opções de “Service” são automaticamente filtradas
de acordo com o “Service Group”
 IMPORTANTE: Caso saiba o nome do “Service”, este campo pode ser preenchido
diretamente. Neste caso a ferramenta preencherá o campo “Service Group”
automaticamente, de acordo com o “Service”.
 B – O campo “Vendor” não será utilizado
 C – O campo “Site” será preenchido automaticamente de acordo com o affected person
B
C
Incident Details – Campo “SLA Applied”
 A – O campo “SLA Applied” indica que o MAXIMO já aplicou SLA. Este campo é
marcado automaticamente pela ferramenta quando o registro de incidente é salvo
e não pode ser alterado manualmente.

Dates – Preencher Datas

 A – Campo “Target Resolution” refere-se a data e hora em que o incidente deve estar resolvido (Mudança
para status “RESOLVED”), conforme SLA applied
 B – Campo “Target Start” refere-se a data e hora prevista de início de atendimento do incidente (Mudança
de “QUEUED” para “INPROG”), será preenchido pela ferramenta de acordo com o SLA
 C – Campo referente a data e hora em que o incidente foi reportado, este campo é preenchido
automaticamente pela ferramenta
 D, E – Os campos (“Actual Contact”) e (“Target Contact”) não serão utilizados
 F - Campo – Preenchido automáticamente referente a data na qual o registro foi criado na ferramenta
F
D E
B
c

Dates – Preencher Datas – Para SLA

 A e B - Para os incidentes nos quais um SLA está aplicado, de acordo com
as informações preenchidas anteriormente (Service Group, Service,
Classification) os campos de Target Resolution e Target Start serão
preenchidos automaticamente

Dates – Preencher Datas (continuação)
 A , B – Os Campos (“Actual Start”) e (“Actual Finish”) são referentes, respectivamente, à data e hora em que
se iniciou atuação no incidente (definido campo “Assigned To”) e à data e hora em que o incidente foi
resolvido (status = Resolved), estes campos são preenchidos automaticamente pela ferramenta.
 C – Data e hora em que o incidente foi encerrado (status = Closed), este campo é preenchido
automaticamente pela ferramenta.
 D – Campo (“Affected Date”) não será utilizado
D B
C A

Relacionar Incidentes a um Registro de Global Incident

Global Issue – Definir um Incidente como global Issue
 Um “Global Issue” é um incidente que afeta (ou pode afetar) um grande número
de usuários.
 Se o incidente for considerado um “global issue”, marque a caixa
correspondente.
 A partir daí, outros incidentes poderão ser associados a este “global issue”, de
forma que quando o “global issue” for encerrado os outros também o serão.
 Diferenças entre o “global issue” e os “related records”
– Quando o “global issue” é fechado os incidentes que estão associados a ele como “global issue”
são encerrados. Isto não ocorre para os “related records”.
– Uma mudança pode ser associada (através dos “related records”) a um incidente (que pode estar
marcado ou não como “global issue”) mas uma mudança não pode estar associada a um “global
issue” através do campo “Related to Global Id” (este campo não existe para mudanças.
– Um incidente posse ser associado a qualquer outro incidente através dos “related records” –
Nenhuma identificação especial é necessária no incidente antes da associação. No caso do “global
issue”, o incidente “pai” tem que ser marcado como “global issue” antes que outros incidentes
possam ser associados a ele através do campo “Related to Global Id”.

Global Issue – Definir um Incidente como global Issue
 Se quiser marcar um incidente como um “global issue”.

 A – Clique na caixa do campo (“Global Issue”)
 IMPORTANTE: Se desejar associar um incidente a um global issue

existente, veja as instruções a seguir.

Global Issue – Associar Incidente com Global Issue
 Se quiser associar o incidente a um “global issue” que já existe:

 A – Clique na caixa do campo (“Global Issue”)
 B – Clique em “Select Value”
A
B


(continuação)
 C – Selecione o “Global Issue” adequado. Na lista só são mostrados “global
issues” que já estão identificados como tal na ferramenta. Se o incidente que
você deseja associar ainda não foi marcado como “global issue” você precisa
editá-lo e marcá-lo como “global issue” antes de fazer a associação aqui.


(continuação)
 Uma vez preenchida a informação do número do “global issue”, a classe é
preenchida automaticamente:
 A – Campo (preenchido automaticamente, não é necessário alterar).
 B – Possíveis valores (“Global Class”)

Revisar e designar um Registro de Incidente

Selecionar o Grupo dono do incidente
 A - Clique na lupa ao lado do campo “Owner Group” para selecionar o grupo

dono do incidente.

Selecionar o Grupo dono do incidente
 A - Clique sobre o código da fila para selecioná-lo.

Related Records
 Nesta aba podem ser visualizadas ou alteradas as relações entre

este registro de incidente e outros registros de incidentes,
problemas e mudanças.
 Estas relações podem ser estabelecidas
– Automaticamente
– Quando são utilizadas as opções de “Create Incident” a partir de um registro de
incidente, problema ou mudança existente o Maximo cria a relação, como nos
slides anteriores onde um incidente é criado através de um Incidente, problema
ou mudança
– Manualmente
– Utilizando a opção de “New Row” ou “Select Work Order” (para relacionar com
mudança) ou “Select Tickets” (para relacionar com um incidente ou problema),
como a seguir.

Related Records
 A – Clique na aba Related Records

 B – Clique no botão “New Row” da sessão de “Related Tickets”
 C – Clique na seta ao lado do campo (“Ticket”) para selecionar o Incidente ou
Problema
B
C

Related Records (alternativa)
 B – Clique no botão “Select Tickets”

 C – Após exibição da tela de seleção, escolha os tickets para serem relacionados
com o incidente
C
B

Salvar o registro de incidente

 A - Clique no botão (disquete) para salvar o registro de incidente.

Log
 Nesta aba encontram-se

– Work Log
– São os registros de atuação no incidente.
– Communications Log
– Não será utilizado
– Audit Log
– Registra alterações de determinados campos de maneira automática. Não
pode ser alterado.

Log – Work Log

A - Clique no botão “New Row” para inserir um registro de trabalho

Log – Work Log (continuação)

 A – Clique na lupa ao lado do campo (“Type”) para selecionar o tipo da atividade
realizada no incidente – Veja nas tabelas a seguir os “work logs” existentes
 B – Selecione a opção do campo (“Viewable”) caso deseje que o usuário veja o
comentário. Este Viewable só vale para acesso pelo portal. Acessos diretamente pela
ferramenta não são afetados por esta opção.
 C – Preencha os campos (“Summary”) e (“Details”), utilizando a opção texto longo para o
Sumário caso necessário. Cuidado com o conteúdo do texto, pois pode ser visto por
qualquer usuário que acessar o ticket
A
C

“Work Logs”
Maximo Work Log

Type (Value)
APPR_OBTAINED
ASSET_UPDATED

“Work Logs” (Continuação)
Maximo Work Log

Type (Value)
CHANGEPIR
65
CLIENTNOTE
Service Management Competency | © 2010 IBM Corporation
Maximo Work Log

Type (Value)
MAIL_CLIENT_INC
MAIL_CLIENT_OUT
Maximo Work Log

Type (Value)
RECALL

Maximo Work Lo
Type (Value)
SOL_SUPPLIER
Como fazer para parar o relógio (STOP SLA) em Incidents

e Service Requests
 O cálculo das paradas de relógio (STOP SLA) no Maximo Shared é realizado através de
relatórios, que consideram alguns Work Logs específicos para descontar o tempo em que o
registro ficou com o relógio parado.
 Os work logs considerados são os seguintes:
– DEP_CUSTOMER: Quando um Incident ou Service Request necessita de ação do cliente para a
sua solução
– DEP_CHANGE: Quando é necessário abertura, programação, aprovação e execução de change
para resolução do problema
– RESP_SUPPLIER: Quando um Incident ou Service Request necessita de ação de um
fornecedor/terceiro sob gestão do cliente para a sua solução
– ASSIGN_SUPPLIER: Quando um Incident ou Service Request necessita de ação de um
fornecedor/terceiro sob gestão do cliente para a sua solução
– CONTACT_ATTEMPT: Quando não foi possível contatar o solicitante por 3 dias consecutivos e
em horários diferentes
– SCHEDULED: Quando o horário de resolução/atendimento de um Incident ou Service Request
foi agendado com o usuário
 Quando é inserida uma ação diferente das anteriores no registro o tempo volta a contar
para cálculo do SLA no relatório

Como inserir um Work Log de parada de relógio (STOP

SLA) no Maximo Shared
 Dentro de um registro de Incident ou Service Request, selecionar a aba Log
 Dentro da aba Log, selecionar a aba Work Log e clicar no botão New Row


 Alterar o tipo (campo Type) do Work Log para um dos tipos anteriores, alterando o
campo ou clicando na lupa para pesquisar os tipos de Work Log disponíveis
 Todos os novos Work Logs criados vem com o campo Type = CLIENTNOTE como padrão. Esse tipo deve ser
alterado para considerar as paradas de relógio nos relatórios de cálculo de SLA.


 Selecionar o Work Log desejado na lista exibida
 Dica: Se na caixa de filtro você colocar as condições abaixo, somente

serão exibidos os Work Logs que realizam a parada de relógio:
• =DEP_CUSTOMER, =DEP_CHANGE, =RESP_SUPPLIER, =ASSIGN_SUPPLIER,
=CONTACT_ATTEMPT, =SCHEDULED


 Se for inserido um novo Work Log diferente de DEP_CUSTOMER, DEP_CHANGE, RESP_SUPPLIER, ASSIGN_SUPPLIER, CONTACT_ATTEMPT ou SCHEDULED, o
cálculo do relatório considera que o tempo de resolução do incidente voltou a contar

Mudança de Status de registros para SLA Hold ou Pending
 A mudança de status do registro para SLA Hold ou PENDING NÃO interfere no cálculo do SLA na ferramenta Maximo Shared. O cálculo é feito somente com
base nos horários em que os Work Logs foram gravados na ferramenta, para que seja feito o cálculo nos relatórios gerados para análise de SLA ON e NOK
 A mudança de status é importante para facilitar o controle pelos times sobre o status dos registros

Designar o Incidente a um usuário específico
 O campo “Assigned To” deve ser preenchido com o id do usuário que será o
solucionador do incidente.
 IMPORTANTE: Esta ação define o tempo de atendimento, que é a obrigação

contratual (SLA) existente para alguns Clientes.
 A – Se já souber o nome (user id) do usuário, escreva no campo “Assigned To”

 B – Se não souber o nome do usuário, clique na lupa ao lado do campo
“Assigned To”
B
A

User Information - Preencher campo “Assigned To”
 C – Clique no user id desejado. A

janela fechará automaticamente e
o valor será preenchido no campo
“Assigned To”.
 Após o preenchimento do campo
salve o registro do incidente. O
estado do problema será alterado
automaticamente para “INPROG”, C
setando automaticamente o campo
“Actual Start”, usado para verificar
se foi atingido o SLA de
atendimento.

Resolver um registro de Incidente

Solucionando o Incidente
 O solucionador deverá executar as ações necessárias para solucionar o incidente

 Todas as ações deverão ser registradas nos Work Logs, para que possam ser consultadas por outros
solucionadores, caso necessário, ou para serem consultados em incidentes futuros
 Ao resolver o incidente o Solucionador deverá alterar o status do incidente para Resolved
 Após 5 dias corridos, caso não haja nenhuma ação, o incidente será encerrado (status de CLOSED)
automaticamente.

Preencher Solução do Incidente

 Preencher aaba de Solution Details com as informações
de Symptom, Cause, Resolution Code e Cause Code
antes de alterar o status do incidente para Resolved

Alterar incidente para status Resolvido
 A – Clique no botão de “workflow”.

 B – Selecione a opção “Resolved or Closed”, não é necessário preencher o
campo “Memo”.
 C – Clique no botão “OK”

Alterar incidente para status Resolvido (continuação)
 A – Clique no botão “Resolved”. Não escolha CLOSED. Este status será alterado
automaticamente após 5 dias
 B – Clique no botão “OK”

Fechamento do incidente
 O fechamento do incidente é feito automaticamente após 5 dias

corridos da resolução do incidente.
 Baseia-se no feedback dado pelo originador do incidente e do
cliente (quando for o caso).
 Após encerrado (Status = CLOSED) um incidente não poderá ser
reaberto.

 A – Clique na aba “Incident”

Fechar Incidente  B – Clique no botão de “workflow”.
 C – Selecione a opção “Is Root
Cause Set”, não é necessário
preencher o campo “Memo”.
 D – Clique no botão “OK”
 E – Selecione a opção “Resolved”
E
 F – Clique no botao “OK”
A B
F
C

Módulo 1: Conceitos Gerais

MaxShared BaseTreinamento Incidentes e SR - v2.2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MaxShared BaseTreinamento Incidentes e SR - v2.2

Enviado por

Direitos autorais:

Formatos disponíveis

Global Technology Services

Treinamento MAXIMO SHARED

Módulo 2: Incidents e Service Requests

Service Management Competency

© 2010 IBM Corporation

 Processo de Gerência de Incidentes

2 Service Management Competency | © 2010 IBM Corporation

Processo de Gerência de Incidentes

3 Service Management Competency | © 2010 IBM Corporation

4 Service Management Competency | © 2010 IBM Corporation

Visão Geral de Gerência de Incidentes

Situation Management Classificar Incidente e

5 Service Management Competency | © 2010 IBM Corporation

6 Service Management Competency | © 2010 IBM Corporation

Quando se abre um incidente?

 A partir de uma falha identificada pelo Cliente. Após a identificação da

 A partir de uma necessidade identificada pela própria IBM, para

 A partir de integração da ferramenta de registro de Incidentes do

 A partir de registro da falha ou solicitação pelo próprio Cliente em

7 Service Management Competency | © 2010 IBM Corporation

 Registrar as ações realizadas no registro de incidentes possibilita

 Os registros de incidentes são auditados pelo time de Gerência de

8 Service Management Competency | © 2010 IBM Corporation

 Algumas boas práticas são importantes para melhorar os indicadores acima:

9 Service Management Competency | © 2010 IBM Corporation

Start Center – Support Incident

10 Service Management Competency | © 2010 IBM Corporation

Start Center – Support Incident

11 Service Management Competency | © 2010 IBM Corporation

Start Center – Support Incident – Result Set Portlets

 My Open Incidents: Incidentes que estão abertos e que estão designados

12 Service Management Competency | © 2010 IBM Corporation

Clicar na opção Incidents no

Clicar na opção New Incident no

Clicar em um Incidente para

Como ir para o Módulo de Service Requests

Clicar na aplicação Service

Clicar em um Service Request para

Estados de um Registro de Incident e Service Request

15 Service Management Competency | © 2010 IBM Corporation

Estados de um Registro de Incident e Service Request

NEW QUEUED INPROG RESOLVED CLOSED

SLA HOLD PENDING RESOLVCONF

Incluir work log

Criar um Incident ou um Service Request

17 Service Management Competency | © 2010 IBM Corporation

Como criar um Incident

 Clicar no botão “New Incident” no Quick Insert portlet do Start Center

Obs: Se freqüentemente você precisa duplicar Incidentes ou

18 Service Management Competency | © 2010 IBM Corporation

Como criar um Incident

19 Service Management Competency | © 2010 IBM Corporation

Como criar um Service Request

Obs: Se freqüentemente você precisa duplicar Incidentes ou

20 Service Management Competency | © 2010 IBM Corporation

Como criar um Service Request

21 Service Management Competency | © 2010 IBM Corporation

Tela Principal – Incident e Service Request

22 Service Management Competency | © 2010 IBM Corporation

Tela principal – Incident

23 Service Management Competency | © 2010 IBM Corporation

Tela principal – Service Request

24 Service Management Competency | © 2010 IBM Corporation