As origens filosóficas do ITIL estão na história da Inglaterra

Todo mundo segue uma filosofia. Mesmo sem saber.

A gente percebe isso nas pequenas coisas, como semana passada. Jantando em uma pizzaria, meu genro descreveu uma cena engraçada ocorrida com ele e minha filha em Nova Iorque.

Pegaram um táxi do hotel ao aeroporto. A corrida custou algo em torno de US$ 63,00. Meu genro deu 70 e o taxista, irônico, perguntou se a gorjeta ia ser apenas de sete dólares (parece que o hábito por lá é 18%). Minha filha não teve dúvidas,  recolheu os 70 e entregou 65.

Explicou ela sua ação com essa declaração: “- Olho grande é pra criar remela“.

OK, se vocês entenderam a introdução,  vamos adiante que atrás vem gente.  Senão, um segundo exemplo:

Melhor assim ou assado?

Existem gestores que acreditam, baseados em sua experiência e conhecimento, que o importante é analisar os números. “- Eles não mentem” é uma expressão corriqueira.

Através deles, é possível identificar se o centro de suporte está atendendo às demandas, se algum funcionário tem desempenho abaixo da média, se uma tendência pode ser determinada antes que cause desespero etc.

Gestores de outra corrente preferem vivenciar o centro de suporte. Ir até ele e sentir o que acontece ajuda a “sacar as coisas”. Mas é preciso “ir a campo”.

Chefia com os pés no chão de fábrica e não sentadinho atrás de uma mesa no décimo oitavo andar. Conversar com as pessoas que fazem acontecer na linha de frente, farejar problemas, ouvir a rádio peão, olhar com seus próprios olhos. Perceberam? Todos os verbos baseados nos sentidos.

Há muito que a  filosofia peleia entre duas vertentes de pensamento: “racionalismo” e “empirismo”. E se vocês me perguntarem qual dos comportamentos gerenciais acima é o correto, vou recomendar a leitura de muita filosofia, pois esse debate se prolonga desde os tempos de Platão e Aristóteles.

Racionalismo

De cada lado de tais correntes existem monstros da filosofia que se digladiaram explicando suas ideias e conceitos. Mas pra que você entenda melhor, vai um resumo do que é cada um.

RACIONALISMO – conjunto de teorias filosóficas fundamentadas na suposição de que para alcançarmos a verdade, é preciso levar essa investigação pelo pensamento puro, desprezando os dados imediatos fornecidos pelos sentidos.

O lance é simples de compreender e o argumento bem sagaz. Se vejo um galho enfiado metade na água e metade fora, a impressão que posso ter é que ele é torto (a parte que fica dentro d’água cria uma ilusão visual). É possível citar um buzilhão de situações em que os sentidos nos enganam e agora, com internet, uau, nossos sentidos e imaginação podem nos prejudicar ainda mais. Ou seja, nossas faculdades baseadas em sensações (tato, visão, audição, paladar e olfato) são mais fontes de erro do que de conhecimento.

Já dizia Descartes, o pai do racionalismo moderno: “Nunca posso estar certo de que as coisas são de fato tal como me parecem, por mais atentamente que olhe para elas, e por mais desesperado e alerta que seja meu estado de espírito.“.

Aliás, vocês sabem que esse filósofo era fera em matemática. Daí vem a expressão, por exemplo, o sistema de coordenadas cartesiano. E quer coisa mais abstrata e menos palpável que matemática?!

Querem ver um exemplo simples sobre como seus sentidos o enganam? Abaixo as linhas parecem não serem paralelas, right? Errado.

Empirismo

Well done!

Agora já aceitamos, Cohen, que não podemos nos guiar apenas pelos nossos sentidos.

Que com que estão convencidos. E ilustrei com um exemplo banal, baseado na visão. Audição, tato e os outros sentidos  podem gerar ainda mais confusões de interpretação, como acharmos que alguém está com raiva por que berra conosco, quando isso pode ser apenas um hábito do sujeito (ou ele é surdo e acha que os outros também são etc.).

EMPIRISMO – Doutrina segundo a qual o conhecimento provém unicamente da experiência, limitando-se ao que pode ser captado pelo mundo externo pelos sentidos ou do mundo subjetivo, pela introspecção.

 E sabem onde começou a reação contra o racionalismo de Descartes? Exatamente nas ilhas inglesas! Uma lista enorme de pensadores redarguiu contra o sujeito que declarou “- Penso, logo existo” (ah, o filme Matrix também explorou essa pendenga).

O inglês Locke

Locke (não o personagem de Lost, mas o filósofo) disse que “… Nossas noções acerca do que realmente existe – portanto nosso entendimento da realidade, do mundo – deve sempre derivar em última análise do que foi experimentado por meio dos sentidos.”

E veio com mais “- Se todos chegaram ao mundo com uma mente que é uma folha de papel em branco, uma tábula rasa, então, nesse aspecto, ninguém é superior a ninguém por nascimento: tudo para o indivíduo depende de como for educado“.

Vocês conseguem sentir o cheirinho do ITIL nascendo há 200 anos atrás?

Ainda ele: “- Nós generalizamos a partir da experiência – um processo conhecido como indução, não dedução-, mas às vezes nossas generalizações são errôneas, e precisamos permitir isso.”

E no embalo dele veio David Hume – escocês – que disse: “- Ao observarmos um padrão constante, inferimos que ele vai continuar no futuro, assumindo tacitamente quea natureza continuará a se comportar de maneira uniforme.“.

George Berkeley – irlândes – alegou “- Todo conhecimento deve vir da experiência e tudo a que temos acesso são as nossas percepções. “.

ITIL

E não foi por acaso que tal biblioteca surgiu dentro da comunidade inglesa de TI.

Com a cultura britânica sedimentada sobre o empirismo, era natural que tais experiências (na área de TI), fossem recolhidas, avaliadas e publicadas.

E o que é a ITIL? Uma biblioteca que fornece uma estrutura de boas práticas para gerenciamento dos serviços de TI. Boas práticas essas baseadas na coleta de experimentações realizadas com o passar dos anos.

Perceba: não é à toa que “boas práticas”, “melhores práticas” ou como sejam chamadas foram a expressão escolhida. O verbete “Prática” tem sua origem etimológica em “ciência prática, não especulativa“.

Tóiiiiii em Descartes justamente na parte especulativa. Esse filósofo dizia que as sensações e presunções baseadas nos sentidos podem nos enganar. A ITIL vai pelo caminho contrário, dizendo que somente aquilo que deu certo é que podemos levar como referência (salvo uma ou outra saída de emergência que a biblioteca deixa dizendo “some organizations may chose to utilize an automatic closure period on specific, or even all, incidents (e.g. incident will be automatically closed after two working days…“).

Dois dias úteis para encerrar automaticamente um incidente? Bom, vocês viram… Baseado na prática e experiência. A turma do racionalismo já ia bater martelo sobre essa inspiração da biblioteca para seus seguidores.

E existe um argumento muito interessante que outro empirista cético, Hume, usou e que faço questão de referenciar:

Por mais que eu observe que os cisnes são brancos, não posso afirmar que todos o são. Por que um dia podem aparecer alguns que não sejam, como de fato aconteceu. A inferência desse raciocínio? Ah, vamos, vocês terão que elocubrar por conta própria.

Uma frase final de Locke

Caramba, tanta coisa se aprende lendo filosofia e transplantando para nosso segmento de suporte técnico. Uma última frase de Locke:

Não siga irrefletidamente as autoridades, sejam elas intelectuais, políticas ou religiosas. Tampouco as tradições ou convenções sociais. Pense por si mesmo. Examine os fatos e tente basear sua opinião e seu comportamento nas coisas como de fato são.

Smack

EL Cohen

Dicas do ITIL para quem licenciou alguma ferramenta de Service Desk

Há um natural frenesi em fazer algo funcionar o mais rápido possível quando fazemos um investimento financeiro sobre um bem ou produto.

Se compro um carro, quero sair desfilando com ele pelas ruas e curtindo suas novidades. Se adquiro uma máquina fotográfica, vou lotá-la de fotografias na primeira semana, mas…

Tanto para um software de Service Desk quanto para os produtos acima, um período de experimentação livre de responsabilidades pode ser muito útil.

Se eu gastar um tempinho fuçando nas opções da câmera, é provável que em alguns dias minhas fotos sejam melhores do que se não tivesse experimentado – sem responsabilidades – a mesma.

No software é a mesma coisa.

E geralmente um aspecto que causa problemas para as equipes é realizar uma má definição de categorização de incidentes e depois ter que conviver com isso pelo resto de suas vidas (na empresa).

Vá devagar.

Não se “rale” por precipitação.

Dica do ITIL 3 para categorização de incidentes

A dica é do ITIL v3 para ajudar na categorização dos incidentes (tradução minha livre):

1. Realize uma reunião de brainstorming com os grupos de suporte, incluindo os supervisores.
2. Use tal sessão para decidir as “melhores sugestões” para as categorias de classificação e inclua uma que seja “OUTROS” – sabe como é, melhor deixar uma vala comum do que ver o técnico categorizando errado por que não encontrou algo adequado. Configure as ferramentas envolvidas para trabalharem durante um período de experiência com essas classificações.
3. Use tais categorias durante um pequeno período de experimentação, mas o suficiente para ter centenas de incidentes caindo nas categorias definidas.
4. Realize uma análise dos incidentes registrados durante o período experimental. O número de incidentes registrados em cada categoria de nível superior irá confirmar se as categorias valem a pena – e uma análise mais detalhada da categoria “OUTROS” identificará categorias adicionais que serão necessárias (salvo se os técnicos forem preguiçosos na classificação).

Sei que quando uma grana é colocada num projeto, os patrocinadores desejam um resultado visível. E que até mesmo os executores queiram “mostrar serviço” botando “pra quebrar” logo nas primeiras semanas, afinal eles foram decisivos na escolha do produto.

Novamente: vá devagar.

Apressar as coisas faz com que você se comprometa demais (inclusive com os erros), batendo pé para mostrar que não estava errado (mesmo sabendo que está, apenas para não dar o braço a torcer). Pequenos erros podem e devem ser aceitos no início, até para que se possa acertar em definitivo.

É como na Fórmula 1: existem os treinos preliminares (inclusive os livres) para acerto do carro, ajustes mecânicos, da suspensão etc.

Fica a dica.

Smack

EL CO

Classificar é importante para gerenciar com correção

O blog ITIL Service Management traz um artigo bem prático sobre o tema:

What is Password Reset: Service Request, Incident or Change?

Eu não sou muito aderente ao ITIL.

Explico: em “aderente” quero dizer grudado. Eu examino com certa distância, penso no que me é útil (sim, bem egocêntrico, mas centrado) e absorvo.

Faço isso por que as “melhores práticas” são muito úteis, mas é preciso examinar o meu contexto e como adaptá-las a ele.

É um incidente?

O autor do blog indicado afirma que reinicializar senha não é um incidente. Muita gente acha que sim em função dos softwares que utilizam. Eles tratam dessa maneira tal tarefa. E por conseguinte (ou preguiça), o time de suporte também.

Seguindo os conceitos do ITIL, a definição de incidente implica em um tempo de inatividade do serviço ou a probabilidade dele estar inativo. Bem, o serviço está disponível; o usuário é que não o utiliza por sua própria culpa.

A analogia feita é com um martelo, pois quando você só tem esse instrumento, todo problema vira prego. Ou seja, se o software lida dessa maneira com tal processo, seu centro de suporte será arrastado para isso também. Fora questões de herança cultural, como a expressão “sempre tratamos dessa maneira“. O que implica em dizer que nunca fizeram uma análise adequada de estatísticas, requisições etc. Se é que precisam, hehe.

É uma requisição?

Yeah!

Tá lá na lista de definições do livro Service Operation do ITIL 3, no verbete “Service Request”:

(Service Operation) A request from a User for information or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service requests are usually handled by a Service Desk, and do not require an RFC to be submitted. See also Request Fulfilment.

E de inhapa, já possui uma mudança pré-aprovada para que o primeiro nível providencie tal serviço sem incomodar o gestor de mudanças, o comitê de autorização e toda a tribo envolvida.

E o queco?

Ponha seu cérebro a pensar (Cohen estimulante no início de 2012, hehehe).

Se tudo (incidentes e requisições) vai pro mesmo saco, fica difícil a um gestor realizar sua atividade de administração.

Salvo se ele NÃO QUISER FAZER ISSO, permanecendo na sua zona de conforto, alegando muitas tarefas, falta de tempo e toda a ladainha que a hierarquia superior é obrigada a ouvir (e o próprio gestor) quando os prazos expiram.

A questão é que… no final das contas o centro de suporte não apresenta resultados progressivos e a posição do gerente torna-se incômoda.

Sim.

Eu sei que o gerente não faz por mal. Que ele deseja desempenhar o melhor possível. Mas ele não pode ficar sobrecarregado. Ele precisa gerenciar os processos e a sua equipe, deixando de assumir todas as tarefas e, muito mais do que isso, distribuindo-as.

Uma metáfora de um gerente querendo carregar o mundo nas costas:

Assim…

Convite

Convido você a participar do curso de fevereiro, em São Paulo, sobre Gestão de Suporte Técnico. Serão três dias que passarão voando, com apenas 9 participantes e promessa de uma experiência única.

Não perca, pois o tio Cohen proporcionará aos colegas apenas 5 cursos em todo 2012. Tenho outros projetos em andamento, mas não posso me furtar a compartilhar meu conhecimento.

Visite www.4hd.com.br/calendario

See you, brother. And sister.

EL Cohen

O ITIL sugere uma penca de papéis (roles) e alguns podem ser executados pela mesma pessoa, mas tem hora que…

Uma dica do Alexsandro Brum (gerente de projetos na EUAX) me levou até o artigo ITIL role conflicts and synergies de Abhinav Kaiser.

Qual o mote do artigo? Pequenas organizações tendem a fazer com que uma pessoa acumule vários papéis (para executar as premissas do ITIL). Porém, tem horas que isso pode ser uma MÁ IDEIA.

Obviamente quando a gente trabalha numa grande organização, esse problema não existe. “Cada macaco no seu galho” como diz o ditado e tudo vai relativamente bem. Mas nos pequenos centros de suporte (ou de TI), humm…

No artigo, Kaiser explica que são visíveis três situações:

1. Aquela onde o sujeito acumula dois papéis e isso pode causar conflito.
2. Outra em que esse acúmulo pode gerar sinergia.
3. E a terceira situação é indiferente o sujeito assumir dois papéis ao mesmo tempo.

Onde rola conflito

Quando o sujeito assume a Gestão de Incidentes. E também a de Problemas.

Por que surge conflito aqui? Por que um gestor de incidentes pretende fazer o usuário voltar a trabalhar o mais rápido possível. E o gerente de problemas não se preocupa muito com isso; ele não quer saber de paliativos e sim saber o que causa o problema e acabar de uma vez.

Obviamente, ambos estão certos na medida em que tentam alcançar seus objetivos. Mas se é a mesma pessoa…

Um exemplo:

Durante um show de rock, o artista com algum tipo de dor pode tomar um schnaps e aguentar até o final do espetáculo. Mas seu médico, gestor de problemas, quer investigar isso e evitar que se repita. Ora, o médico quer protelar a entrada do artista no show até concluir o diagnóstico (e o público uivando há 1/2 hora pelo atraso). O produtor, nosso gestor de incidentes, sugere que ele tome um trago de canha, um energizante, um analgésico, qualquer coisa e vá lá pro palco de uma vez.

Oh, yeah, desentendimento clássico.

Existem outros exemplos de conflitos no artigo. E é melhor você ler o texto do que apanhar meus “interpretaços”, porém…

Porém

No caso acima, podemos encontrar centros de suporte que nem conseguem dividir a equipe para assumirem tais papéis. Pense num departamento com quatro pessoas.

Elas acabam misturando as responsabilidades e em certos atendimentos o técnico quer matar o problema de vez (e deixa o usuário irritado, esperando pelo fim da sessão de controle remoto, for example) e outras horas em que o técnico faz uma gambiarra pra “resolver” o assunto temporariamente, cujo problema vai estourar mais tarde novamente.

Meu convite é:  pense no que deseja implantar do ITIL. Por que certas premissas são impossíveis de implementar. E outras, bem úteis.

Mas pelo amor de deus, faça uma reflexão a respeito e não saia adotando medidas só por que está na bíblia do ITIL.

Think about, my brother.

EL CO

Ler o artigo de Gilberto Pavoni Junior é imperdível

Sexta-feira é o meu dia de ler as revistas acumuladas da semana.

Sim, ainda sou daqueles que leem revistas impressas. Fazer o quê, o ônus de minha Geração X. Mas para não me taxarem de old man, quero destacar que também leio pra caramba on-line (“- Ah bom, Cohen, aí sim…“).

E na revista CRN de outubro de 2011 tem um artigo imperdível para você, gestor de suporte. E, por sorte, com versão no website da revista:

MDM ganha força com o mundo mobile

Apesar desse texto envolver muito mais o pessoal de suporte interno, você, do suporte externo, nunca sabe onde estará trabalhando amanhã. Por isso…

Seguem dois excertos abaixo para atiçar sua leitura.

Da zona

“Nessa nova febre, a proliferação de dispositivos dentro das empresas vem acompanhada de múltiplos sistemas operacionais e um desconhecimento sobre qual será a próxima novidade.

Somente nos últimos meses, esse nicho viu o surgimento de um novo smartphone e sistema operacional da Apple; um novo aparelho da Amazon; incertezas sobre os planos da HP; anúncios de diversos aparelhos para Android; e a expectativa de preços baixos nos tablets brasileiros.”

Dos perigos

“Se é comum perder um notebook no táxi, perder um smartphone durante uma palestra com dezenas de concorrentes ao lado é mais fácil ainda. Imagine quantos contatos de clientes, tabelas de preços e planos estratégicos poderiam ser facilmente lidos e copiados se isto ocorresse.”

Vai lá, meu: MDM (Mobile Device Management) é “da hora”.

Abrazon

EL CO

Defina frases que podem (ou não) ser expressas para melhorar o atendimento

Ah é…

Trabalho de gerente vai longe, incluindo preocupar-se com pequenos detalhes.

Coloque  a galera dentro de uma sala e explique por que algumas frases podem ser ditas e outras não. Lembre-se que suas criaturas imberbes (jovens, iniciantes, sem barba) do atendimento muitas vezes estão cheias de energia para ajudar, mas… A comunicação formal não faz parte de suas especialidades.

O uso frequente de algumas frases pode unir os técnicos em torno de uma identidade e ajuda a construir um estilo todo próprio de seu centro de suporte.

Incentive o uso de frases como “Por favor”, “Agora mesmo” (se for o caso), “Certamente” e assim por diante. E lembre-se das que não devem ser ditas: “Pode deixar, mano”, “Então tá”, “Isso daí” etc.

O pessoal da área de segurança criou há tempos uma blacklist para mensagens de SPAM, aproveite o embalo (e o exemplo). Elenque você e seu grupo as expressões que não devem ser transmitidas. Além de deixarem cair o nível, permitem interpretações dúbias e outras confusões.

O caminho das pedras

• Estude as expressões que melhor funcionam com seus usuários
• Identifique as expressões nocivas que devem ser evitadas
• Codifique tudo num pequeno manual (online ou impresso) ou dicionário

Chegando lá

Creia-me: isso não é ridículo.

Visito muitos centros de suporte para ministrar treinamento e existe uma liberdade (para não dizer libertinagem) exagerada nesse aspecto. A tal ponto de cada técnico realizar uma saudação de atendimento diferente do outro.

Salvo se você tiver o anel mágico e dizer “Shazan” ou usar o pó também mágico de Emília (do Sítio do Picapau Amarelo), as coisas não acontecem num vupt de magia.

É preciso acompanhar, fiscalizar, liderar etc. mesmo uma pequena iniciativa assim. Para que tenha sucesso.

See you, bro.

EL CO

PS: Perdão pelos exemplos antigos de magia… Sou das antigas. Quem estiver mais atualizado, mande ver.

PS 2 14/11/2011 – Lembrei de outra coisa. Os técnicos, ao tentarem tranquilizar o usuário, podem usar diminuitivos como “- Vamos resolver seu probleminha“. Só que para o outro lado é um problemão e usar os diminuitivos podem deixar o usuário mais p. da vida.

Livro de Geoffrey Moore explica como conquistar cada perfil de usuários

Não entendeu, né? Não faz mal, vou explicar mesmo. Porém, o contexto…

Contexto

Dia 02 de novembro, dia dos mortos, feriado. Resolvi me puxar nos exercícios de ginástica por que tinha tempo de sobra. Dupliquei as séries.

Saí feliz, tomei banho e fui para a empresa. Yeah, para a empresa, pois feriados são aqueles poucos dias em que há ninguém e o ambiente fica mais tranquilo e propício pensar.

Porém, Ao sair do carro… Crééck. Na coluna.

Fui à emergência de traumatologia e descobri que tive uma contratura muscular. Essas coisas que acontecem com velhos quando querem fazer coisas de jovens, hahaha. Então desde quarta-feira  “mofei” na sala de casa, ingerindo remédios e usando bolsa de água quente (essa é a marca da idade) nas costas.

Crossing the Chasm

De tal maneira que avancei bastante nas leituras. E uma delas foi Crossing the Chasm, marketing and selling disruptive products to mainstream customers.

Pra ajudar, explico que o título significa “Cruzando o abismo“. O autor explica que marketing para produtos de alta tecnologia, como software e dispositivos de hardware, envolvem conceitos diferentes do marketing de produtos tradicionais.

Quando escrevo diferentes, não significa que se desprezem os conhecimentos básicos. Mas que eles precisam ser complementados com ideias inerentes aos produtos de tecnologia.

Ideia principal

O conceito principal é que as pessoas são diferentes na “adesão” a novidades. E que por isso, as mensagens devem ser diferentes para cada grupo, de formas a tornar o marketing mais eficiente.

Veja o gráfico abaixo (copiei da internet dessa página):

Eu me concentrarei nos dois primeiros grupos mais à esquerda  por que estou recém na página 37. Essa lerdeza na leitura se deve a um defeito de fabricação: leio cinco a seis livros de maneira simultânea e dedico 20 a 25 páginas de cada “sentada” para ler.

Innovators – os mais à esquerda

Excertos por mim:

• … são os entusiastas por tecnologia que primeiro acreditam no potencial do novo produto. Marketing high-tech deve, portanto, começar com eles.
• Eles perdoam uma documentação medonha, um desempenho terrivelmente lento, omissões ridículas em funcionalidades e métodos bizarros para invocar algumas funções necessárias – tudo em nome do avanço da tecnologia.
• Em negócios, eles são o portão de entrada para qualquer nova tecnologia.
• Eles querem a verdade e sem truque algum. Segundo, sempre que possível e quando enfrentarem algum problema técnico, querem acesso à pessoa mais competente tecnicamente para responder suas questões. Terceiro, eles querem ser os primeiros a receber as novidades.

Visionaries – próximo grupo à esquerda

Vamos lá:

• Visionários são o tipo raro de pessoa que conseguem ter o insight de perceber como uma tecnologia emergente atende a uma oportunidade estratégica; possuem o temperamento para traduzir o insight em um projeto de alta visibilidade e alto risco, e o ainda detém carisma para conduzir o resto da organização a comprar o projeto.
• Como um conjunto, os visionários tendem a ser aqueles executivos mais novos, altamente motivados e movidos por um “sonho”. Compreenda o  sonho e você compreenderá como fazer marketing para eles.
• Visionários não estão em busca de aperfeiçoamentos; estão de olho em avanços substanciais.
• Como um grupo comprador, é fácil vender para os visionários, mas muito difícil de agradá-los. Tudo por que eles compram um sonho.

Cohen, e meu suporte com isso?

Katzo!

Você não acompanha as discussões no grupo “ITIL na Prática” do Linkedin?

Estão todos a debater como vender a ideia do ITIL dentro da organização. Muita gente dando ideia, o que funcionou em sua empresa etc. e tal. Comentário daqui, comentário dali. Force suas sinapses, bro.  É fundamental que você acompanhe. E participe, claro.

E as paletas?

As costas? Obrigado pelo interesse.

Ah, nada que o carinho das filhas e da esposa não recoloque tudo novamente no lugar. Mas estou proibido por elas de fazer ginástica na academia do prédio.

Estou obrigado a ir ao clube fazer musculação sob supervisão de um profissional (ou UMA profissional, hehehe).

Abrazon

EL Co
PS: E o abismo? Pô, compra o livro, hehehe.

Se o técnico de atendimento tem habilidades interpessoais, mas não tem competência, o resultado é ZERO!

Todo mundo sabe que a galera de informática tem certas dificuldades de relacionamento com as outras pessoas. O tesão pela lógica, pelo desafio computacional etc. é tão grande que sobra pouco espaço para desenvolver outras competências.

Daí que muita gente bate na tecla que eles, os técnicos de atendimento, precisam desenvolver mais suas “soft skills”,  expressão divulgada pelo HDI e que corresponde às competências interpessoais como: saber ouvir, ser gentil, empático etc.

Yeah, é por aí mesmo o caminho. Como ajudar usuários a resolverem seus problemas de tecnologia se o sujeito que as atende é um nerd: pouco vocabulário, um tanto lacônico e irritadiço com gente que conhece pouco de informática?

Porém…

Porém, isso não é tudo.

Por que um técnico de atendimento que é cordial, tem boas maneiras e excelente educação, mas não tem competência ou capacidade para resolver o problema do cliente, é um desastre.

Pequena história para ilustrar (conto ela nos meus cursos):

Minha esposa fez uma reserva em pousada na serra gaúcha para o dia dos namorados. E dentro do pacote turístico, um jantar romântico no sábado. A pessoa que nos recebeu no check-in foi a própria filha do dono da pousada. Uau, que coisa legal! Muito amável, explicou-nos tim-tim por tim-tim o funcionamento de tudo.

Mas no sábado à noite…

Quando descemos para o restaurante, percebemos a superlotação. Um garçom improvisado (alguém que no cotidiano deve colher uvas na região), perguntou nosso nome, procurou em papeizinhos escritos sobre as mesas e não encontrou. Lá pelas tantas me irritei, juntei uma mesa e comecei a enfeitá-la, removendo os adereços de outra mesa.

Nisso chegou a moça, filha do dono. Pediu mil desculpas, foi delicada, explicou que não esperava tanta demanda, blá blá blá, mas… Não resolveu o problema e fomos jantar noutro lugar.

Então? Não adianta o técnico ser “queridinho” se não resolve o problema!!!

E o pior: essa é uma situação comum na maioria dos centros de suporte.

Como o gestor não consegue treinar o novo técnico (se tirar alguém do atendimento para ensiná-lo, perde dois, em vez de um), ele vai para o atendimento cru de conhecimentos. E nu. E quando rola o problema, o cliente saca que ele não manja nada do aplicativo e pede por outro técnico. Que acaba ficando soterrado por mais e mais chamados.

E então?

Então que um curso de soft skill não será a “salvação da lavoura” se você, gestor, não pensar no todo. Como o problema que acima apresentei. É como matar cupim de um móvel e deixar noutro. Logo, logo, tudo estará destruído.

Abrazon

EL CO

Stephen Mann, consultor da Forrester Research, reconhecida empresa mundial de pesquisas, dá seus pitacos sobre o assunto

Hahaha, estou me sentindo uma hiena a me alimentar de comida alheia. Hoje acordei disposto a recuperar a semana passada que nada bloguei. Então estou a me amparar de artigos de terceiros para anunciá-los ou até debater. Mas isso é bom, ora pois. Afinal debatemos conhecimento. Melhor do que ficar mudo

O artigo original do Stephen é Where is all the incident classification best practice?

O título do artigo dele foi para chamar atenção que, apesar do ITIL estar sendo implementado aos montes pelo mundo (uma simples pesquisa no Google pela expressão ITIL mostra um resultado de 21 milhões de links), se pesquisar pelas expressões “incident classification best practice” ou “incident categorization best practice” é exibida uma mixaria de links.

No seu preâmbulo, Stephen arrisca dizer que a pouca quantidade informada pode ser por que não podemos ser prescritivos. Que algo de um tamanho pode não funcionar para outros, como sapatos.

Outro poderia argumentar que criar uma hierarquia de classificação de incidentes poderia ser muito bom para empresas de consultoria cobrarem por mais dias de serviço ajudando o cliente.

E depois de discorrer por vários motivos, Stephen apresenta uma penca de ideias que seriam os seus princípios para organizar uma boa classificação de incidentes.

Recomendações de Stephen

1. A hierarquia de classificação de incidentes deve ser direcionada ao negócio e não à TI.
2. A captura do incidente deve ser fácil, mas não em detrimento das atividades de análise tais como análise de tendências, gerenciamento de problemas ou melhoria contínua.
3. A categorização deve facilitar o workflow dentro do departamento e encurtar o tempo de vida do incidente, evitando ir para lá e para cá.
4. Tentar classificar fatos e não sintomas.
5. Muitos níveis de classificação impedem a velocidade de captura e encorajam erros de categorização, particularmente a tradicional vala comum outros. Três níveis de classificação (talvez um quarto) sejam suficientes para cobrir a maioria das eventualidades.
6. Refletir sobre por que você deseja mais do que 10 níveis de classificação de nível 1 (prioridade, criticidade, canal,  grupo etc.). Será que 10 já não são demais?
7. É preciso ter o mínimo possível de classificações em “Outros”.
8. Não permita a adição de novas categorias “on-the-fly” (durante o atendimento).
9. Códigos de solução podem ser úteis, em particular para identificar a precisão da captura do incidente e o fluxo de solução.
10. Finalmente, tente ir além dos interesses políticos e opiniões individuais para alcançar alguma coisa que os serviços realmente necessitam.

Sudae, brothers and sisters.

Abrazon

EL CO

“A ferramenta não funciona direito…” Kkkk…

Encontrei um artigo de David Mainville no site CIO Update datado de 14 de julho de 2011.

Chama-se (em inglês, claro), The 5 Key Reasons Why IT Initiatives Fail.

Segundo ele, elas são comuns ao ser humano e não específicas somente a TI, mas segue a sua lista, obviamente permeada por comentários Cohenianos. Para ler o original, siga o hyperlink acima.

Falta de planejamento – Ninguém consegue construir uma casa sem uma planta. A dúvida do David é por que muitas áreas de TI iniciam projetos sem uma devida organização. Segundo ele, o plano deve endereçar aspectos como conscientização, mudança organizacional, desenvolvimento do processo, seleção de ferramentas, treinamento dos funcionários etc.

Expectativas não realistas – As áreas de TI pensam que conseguirão implementar 12 processos (do ITIL?!) em 12 meses. Katzo, há um tempo enorme desperdiçado em reuniões, feriados, pânicos de última hora, festas etc. que nunca é contabilizado. Definir entradas, saídas, responsabilidades, papéis, atividades, tarefas, métricas etc. etc. etc. é algo que leva tempo para planejar, maturar etc.

Ceticismo – “- Quantas vezes já tentamos isso antes?” Quantas vezes tentaram implementar a base de conhecimento, o catálogo de serviços etc. e não deu certo? “Por que funcionará agora?” Falta de suporte na maioria dos níveis da organização sabotam as iniciativas. Faça o barco navegar, my brother.

Exigências medíocres – “Já que a ferramenta é baseada em ITIL e nós usamos ITIL também, então não precisamos mudar coisa alguma.” Segundo David, nas empresas pequenas até vai, mas nas maiores isso é inviável e está bem longe da realidade. Falta de requisitos básicos acarretam uma implementação ruim de uma ferramenta de ITSM.

Não fazer o trabalho pesado – Projetar um processo é uma coisa, garantir que as pessoas o adotaram é outra. Um gerenciamento de incidentes, por exemplo. Para ele ser efetivo o povo precisa entrar corretamente com os dados, classificar os incidentes, escalar o que for necessário etc. As métricas precisam existir e ações corretivas são necessárias quando for o caso.

See you, brothers and sisters.

Abrazon

EL Cohen

Top Guns questionam frameworks ou… eu que ando meio atrapalhado das ideias?!

Fernando Baldin

No mês passado assisti a uma palestra de Fernando Baldin no HDI 2011. Intitulada “Esqueça os frameworks“. Fernando é ninguém menos que diretor da Premier TI, maior empresa privada de informática do Paraná.

E autor do livro “Revolução Invisível“.

Nino Albano

Hoje li um novo artigo do Nino Albano em seu blog: “O Ego, o framework e o que a empresa precisa. Incômoda dissonância“, onde ele primeiro explica que é preciso definir as metas.

E somente então se preocupar em como alcançá-las, adotando um framework (se for o caso); mas primeiro as METAS!

Opa, opa…

Ué…

Um é ITIL Expert (o primeiro). O segundo, ex-HDI Boss.

Are the things changing? Ou… Are people changing?

Não creio! Acredito que as pessoas estão arriscando mais. Saindo da penumbra.

É claro que os dois  possuem interesses pessoais/profissionais no assunto (Fernando quer emplacar a nomenclatura MEFOS e o Nino a IST). IMHO, ambos os projetos já nascem bem-sucedidos em função da “mão que acalanta“. Freud e uma cambada de estudiosos de psicologia dizem que a criança educada com amor e carinho em casa, possui tremendas chances de sucesso.

Porém, retomo o foco para o assunto framework.

Top Guns estão dizendo que o time de TI não pode mais ter uma desesperada necessidade de dominar os frameworks.

Que é o  que o Mansur sempre disse. Foco no negócio, depois vê o que é preciso ajeitar a casa. (Kkkk, eu sou muito ordinário, valho-me de citar o Mansur para amparar minhas ideias. Mas quem manda ele pensar parecido comigo? Ou eu com ele?!)

Quanto tempo levará para que a ideia se propague pela comunidade de TI? Que o framework não é a salvação da lavoura (e, consequentemente, os cursos, os certificados, as ferramentas, as consultorias etc.)? Que todo gestor deve começar olhando para a parede e pensando aonde quer chegar? E depois ver se vai de ônibus, moto, carro, a pé, de carroça etc.

Sugestão: procure no Google Tradutor o significado em português da expressão em latim QUO VADIS (tá, clica aqui).

Depois, visite o link abaixo, hehehe, e compreenda melhor:

www.livrogestaohelpdesk.com.br/capitulo-1.pdf

Ou vem no curso de agosto de “Gestão de suporte técnico” que explico ao vivo, hehe.

Abrazon

EL CO

PS: Amanhã palestro no evento da poderosa Inteligência Negócios, distribuidor nacional do Qlik View. Quem estiver por lá, pago o café!

Oié, brothers. Mais um Drops foi colocado em nossa área de vídeos do facebook, agora sobre catálogo de serviços.

O bom seria curtir nossa página lá (quê? ainda não tem conta no facebook?), pois assim ficaria sabendo de imediato. Visite:

www.facebook.com/Boteco4HD

Abraços

EL CO

Information Week de hoje apresenta o desafio dos gestores de TI frente às novidades tecnológicas

A revista de hoje tem essa sugestiva capa:

E os assuntos giram em torno de questões de segurança, como lidar com as pressões e voilà, o que mais nos interessa:

Oferecer ou não suporte aos cacarecos que surgem a todo momento?

O que você acha? Como você procede?

Quem é do suporte não pode fechar os olhos ao fato de que os executivos (e usuários em geral) trazem cada vez mais, para o ambiente de trabalho, as últimas modas em produtos eletrônicos e de sofware (twitter, facebook, foursquare, linkedin etc).

Na verdade, vida profissional e pessoal estão se misturando, bem como sugere Bauman no seu Modernidade líquida. E é natural que o sujeito compre um iPhone para uso pessoal e resolva acessar suas mensagens profissionais também através dele, ora pois. E 48% das empresas pesquisadas pela revista estão permitindo conectar tais devices nas suas VPNs.

Onde surgem as desgraças

Elas começam pelos e-mails. Agora existem diferentes equipamentos com respectivos sistemas operacionais. E óbvio, a necessidade de prestar suporte a todos eles. Não é algo banal. A revista explica situações em que versões antigas do Android não conectavam com o Exchange ActiveSync e era preciso usar um software intermediário para facilitar a comunicação.

E quando um executivo deseja que o tablet faça coisas que o seu notebook fazia? E que você não pode deixá-los ir até a loja on-line da Apple e instalar direto o Microsoft Office.

Na revista há uma publicidade disfarçada do Citrix XenApp que nem vou comentar.

Onde eu quero chegar

É que não se trata apenas de iPhone, iPads e produtos baseados em Android. É muito mais, são softwares e outras ferramentas.E isso torna complicado elencar uma lista de serviços que você oferece, pois a todo dia novos produtos emergem no mercado. E são abraçados pelos early-adopters da sua empresa.

Se você proibe o uso e respectivo suporte, corre a chance de emperrar o negócio. Se libera, bom, nem preciso comentar.

1) Visite a revista em www.informationweek.com

2) Selecione a guia PREMIUM CONTENT

3) Faça download da revista

4) O MAIOR IMPORTANTE: medite a respeito.

See you, brother and sister.

EL CO

Pergunta comum de gestores de suporte: como fazer reuniões com a equipe se o dia é tão agitado e a presença de todos imprescindível?

Estou aqui no Starbucks da Alameda Santos e vi um time que consegue fazer isso. Em real-time, segue uma foto da turma debatendo questões muito importantes (e nada de chopp, veja bem):

Olha aí…

Esse deve ser o time da noite, hahaha. São 10:35 dessa 3a-feira.

OK, OK, você vai pensar? O que estou estou fazendo aqui a essa hora?

Exatamente procurando soluções para o seu problema, bro! Sacrifico minha atividade pelo bem da comunidade. Vale um chopps, isso sim.

Errr…

Abraçps

EL CO

Uma fábula para o gestor compreender no que dá contratar profissionais baseando-se nas suas certificações

É uma brincadeira. Mas é nelas que falamos as verdades.

Muitos gestores usam as certificações para separar o joio do trigo. É mesmo? Esquecem o aspecto comportamento, tão importante em ambiente sob pressão.

Abraços

EL Cohen