Eficiência x eficácia – Peter Drucker
by El Cohen
Criei uma categoria nova no meu blog denominada PETER DRUCKER.
Revendo meus livros sobre o mestre da administração moderna, encontrei várias anotações nas margens dos mesmos, sublinhados e comentários que considero interessantes ao nosso ambiente.
E assim, vou registrá-los aqui no blog, associando as idéias com o nosso cotidiano de Help Desk e Service Desk.
Bem, antes de mais nada, quem quiser conhecer mais Peter Drucker pode visitar o verbete correspondente na Wikipedia.
E de onde vem a polêmica para usarmos o conhecimento de Peter?
Da lista ITSM_BR do Yahoo, moderada pelo Gilberto Biasoto e que é um sucesso absoluto, com mais de 2.600 inscritos.
Evitarei citar nomes, mas vou inserir trechos do debate aqui no blog.
A questão apontada por um colega e que gerou a polêmica:
2) O ERP da empresa caiu, abrimos um chamado inicial para tratar do incidente, porém temos 200 ligações ao help desk sobre a indisponibilidade do sistema. Teríamos 201 incidentes ou 1 incidente e 200 chamados de informação?
Seguem as várias idéias e impressões apresentadas.
E quero comentar que é preciso respeitar as opiniões dos colegas, pois somos todos profissionais e cada um com um viés da realidade, em função da sua experiência, estudos, vida etc.:
1 incidente e 200 chamados de informação, correlacionados.
Nesse caso vc tem 201 incidentes e 1 problema. Se vc souber por que o ERP caiu, ele vira um erro conhecido, se não fica como problema, e talvez exista um workaround para isso. Exemplo, o ERP caiu porque o HD encheu, nesse caso vira um erro conhecido. De qualquer forma o registro de que esses 200 chamados estão ligados ao do ERP é fundamental.
2 – Este cenário já ocorreu várias vezes onde trabalho, neste caso o service desk é orientado a manter apenas um incident e sempre que aparecer outro é para atualizar com o primeiro, assim mantemos tudo centralizado num unico incident.
Convém não distanciarmos a teoria (modelo da realidade) da prática.
Talvez o bom-senso convide a não abrir 201 incidentes em função do inconveniente que traria em termos de esforço (talvez fosse mais adequado resolver logo o problema do ERP do que ficar abrindo duas centenas de incidentes).
No caso da indisponibilidade do sistema há 201 incidentes. O fato de um incidente ter causado 200 chamadas sem que os usuários tenham sido informados sobre a indisponibilidade do sistema é um problema que continuará a gerar vários incidentes registrados pelo held desk todos associados ao mesmo problema, neste exemplo a indisponibilidade do ERP.
Neste caso, observo a respostas dos demais participantes desta lista, abrir os 201 chamados para o incidente poderá sobrecarregar o service desk mas será o mais correto, porém fico a pensar que a razão de todos os chamados é a parada do ERP, e na prática há somente um incidente, os demais chamados podem ser relacionados ao primeiro, penso que os demais chamados apenas aumentam a urgência na solução, seja de contorno ou definitiva, vai depender de cada caso.
Uma das principais “funções sociais” das melhores práticas é a eliminação das ineficiências e desperdícios. Gerar 200 incidentes sabendo que existe um problema conhecido não é algo efetivo (eficiente e eficaz). No entanto se cada um dos incidentes gerados agregar valor através de solução de contorno para o problema do usuário (o problema do usuário não é o ERP. O real problema do usuário é o que ele queria fazer para o negócio usando o ERP) é importante registrar o incidente pois a base de conhecimento do SD será acrescida de informações sobre como oferecer ao usuários opções provisórias para endereçar as necessidades do negócio.
Se os 200 incidentes servirem apenas para documentar a indisponibilidade do ERP e informar o usuário que o sistema está inoperante e ele deve esperar então estamos falando apenas de tempo e dinheiro jogados fora.
Trata-se de um conjunto de Melhores Práticas e não de uma metodologia, cabe ao Negócio decidir o que agrega mais valor e, IMHO, discutir o que é “certo ou errado” é importantíssimo para não afastar a prática da teoria (conforme bem disse o fulano), mas vejo casos como este muito mais como uma questão de “mais ou menos adequado” do que a dicotomia anterior.
Obs.:
Gostei também do que disse o siclano, que trouxe neste comentário um pouco de “pensamento enxuto” para a TI. Acredito que tanto clientes quanto acionistas NÃO estejam dispostos a arcar com custos de tratar 200 incidentes. Embora seja verdade que a solução de contorno para cada um pode ser diferente, aliás acho que este seria o balizador para esta decisão.
O comentário do beltrano também é bastante pertinente, pois embora o assunto esteja bem mais maduro do que quando comecei a ler sobre isso em 2005, vez ou outra percebo esta confusão de incidentes que “evoluem” para problemas ou erros conhecidos.
Como percebem, as opiniões são divergentes.
O debate é excelente, pois permite identificar visões diferentes da que estamos acostumados (a nossa!!!). E isso mexe conosco. E nos ajuda a refletir e, pelo menos, tomar decisões baseados nalguma elocubração e não num estilo maria-vai-com-as-outras.
E o Peter?
Ele tem duas frases muito interessantes:
Eficiência é fazer certo as coisas.
Eficácia é fazer as coisas certas.
Eu acho que seria muito eficiente no case proposto, abrir 200 e sei-lá-quantos incidentes. Isso para ficar bem aderente aos conceitos do ITIL. E daí poderíamos gerar estatísticas de impacto, blá-blá-blá.
Mas, PQP, todo mundo sabe que o ERP parou.E o impacto que isso teve na empresa.
A gente não precisa de estatísticas para uma catástrofe dessas. 200 ou 300 incidentes, que diferença faria? São apenas números.
Precisamos é de eficácia nessa situação.
E evitar consumir os recursos do Help Desk / Service Desk feito robôs, registrando incidente-a-incidente, num processo automático e contábil.
Onde fica essência da coisa? A inteligência?
É preciso RESOLVER esse pepino de uma vez, pombas.
O que leva a um registro recente do blog sob o título Na ótica do ITIL, qual é o certo? onde o Pier Riboni se deparou com a mesma situação na lista de discussão ITIL-Service também do Yahoo (e cujo debate está na mensagem número 30…).
Lembrem-se:
A teoria é uma redução da realidade para que possamos estudá-la.
Mas ela nem sempre pode ser justaposta a toda e qualquer situação!
Outra coisa: essa é minha opinião e respeito todas as variantes e diversidade de idéias apresentadas. Mas claro, adoro uma polêmica, hahaha.
Abraços,
El Cohen
PS: De inhapa, dois livros sobre Drucker para conhecê-lo melhor:
Comentários
Cohen, td bem, minha opinião seria a seguinte:
Acredito que das 200 ligações dificilmente todas seriam atendidas, portanto já haveria aí um reflexo naquela hora na taxa de abandono.
Após isso parto do principio que se foi atendido uma ligação no SD, o esforço deve ser registrado!! afinal…se não todos os demais relatórios tornam-se inúteis e não confiáveis.
Outro ponto, para situações como essa, deve se iniciar um processo de MAJOR INCIDENT, Aonde todo o processo de escalonamento e alertas deve ser específico para proporcionar os recuros adequados a área de operação para resolver o incidente. algo parecido com o conceito de problema, aonde esse major incident deveria ser tratado e todos os demais deveriam então ser linkados a esse incidentes, sendo classificados e registrados corretamente, pois só assim , com essas entradas é que geraríamos saídas consistentes do processo de gestão de incidentes para a efetiva gestão de problemas entender o impacto, custo e as soluções que devem ser realizadas para eliminar o possível erro da infra estrutura. Acredito que ao burlar essa sistemática TI só tem a perder, pois maquiará o real impacto, não o subjetivo, mas sim o baseado em registros e fatos da queda do ERP.!!
Abraços e Parabéns pelo Livro!! assim que eu pagar as contas que to devendo!! comprarei um exemplar!!!
Abraços!!
Fernando,
A idéia é ótima e certamente fica muito confiável essa métrica, etc, etc, etc.
Porém… A minha principal função é capacitar e coordenar uma equipe para atender bem os clientes, ou para registrar bem os incidentes???
Acredito que, partindo do exemplo citado pelo Roberto, eu possa me dar ao luxo de desprezar uma exatidão na estatística, para atender “mais e melhor”, pois mesmo nos poucos segundos que leva-se no cadastramento do incidente, há tempo para um atendimento mais completo ou até mesmo para um novo atendimento…
Esses momentos, que chamo de HDD (Hora do Desespero), sempre complicam bastante o já corrido Service Desk, mas mesmo nestas horas, o atendimento acaba sendo realizado de forma rápida e eficiente…
Não é uma questão de “deixar de lado” ou “não dar atenção” às estatísticas, e sim de colocar na balança qual o impacto mais negativo.. Uma métrica perfeita e algumas reclamações, ou alguns números inexatos e reclamação zero??
Não penso duas vezes em sacrificar algum registro em detrimento à qualidade e agilidade do atendimento ao cliente. É ele que paga o nosso salário, e não a estatística!
Posso não ter números precisos no final do mês, mas acho que no fim das contas, esse é o prejuízo menor.
Abraço,
J.Gomes
P.S.: O Roberto me proibiu de vender o livro pra um sebo, então vais ter que comprar na livraria mesmo
Drucker eh simplesmente sensacional. Vale muito a pena reler – sugiro que comecem por uma serie lancada pela Folha, chamada EMPRESARIOS DE EXITO, escritas pelo Robert Heller, por sinal muito bem escrita e que consegue resumir bem as ideias e textos nao so do Drucker, mas de outras pessoas influentes tb. Vamos nos surpreender como coisas que o Drucker fala ha muito tempo, agora esta sendo praticadas. POr exemplo, sempre que tinha oportunidade, o Drucker perguntava: Qual o seu negocio ? A resposta era invariavel, independente do ramo de atuacao: TReinar e Desenvolver pessoas.
Olá, colegas.
Fernando,
Acho que você traz novas luzes sobre o assunto. Realmente, é capaz de engarrafar o atendimento na central de atendimento de maneira que nem seria possível registrar tudo, hehehe.
Em relação à sua idéia de registrar TUDO, em minha opinião a gerência de incidentes deve tentar reestabelecer o serviço o mais rápido possível.
Obviamente, não posso me esquecer que você – Fernando – opera geralmente como um TERCEIRO nas atividades de Help Desk. E nessa situação, é mais recomendável registrar TUDO para que se possa fazer auditorias em sua atividade (e mostrar o alto nível de excelência) mais tarde.
Gomes,
Nós temos visões bem parecidas, até por que atuamos na prestação de serviços a terceiros onde o que importa não é o registro e comprovação posterior, mas sim RESOLVER o pepino ASAP, hehe.
Abraços a todos e obrigado por compartilharem suas idéias.
El Cohen
PS: Fernando, outubro tem Help Desk Day em Curitiba o seu exemplar está garantido, gratuitamente, em troca da sua palestra
Caro Cohen,
Muitas vezes me deparo com problemas desses no dia-a-dia do SD. Creio que a melhor opção é registrar um incidente que deve ser endereçado à equipe responsável o quanto antes. Essa equipe deve munir o SD de informações e prazos para que os outros 200 chamados sejam relacionados ao primeiro, mas somente de orientação. Registrá-los é importante para medir o impacto no negócio, ainda mais quando a indisponibilidade não é programada.
Uma maneira que adotamos e ajuda muito a reduzir os chamados e deixar os usuários cientes do que está acontecendo é um anunciador antes que o analista atenda o telefone. Muitos usuários escutam a mensagem e já se dão por satisfeitos evitando tempo somente de orientação dos analistas. Podemos medir o impacto depois pelo número de abandonos após a mensagem do anunciador.
Seu livro é muito bom, está clareando algumas visões importantes para o dia a dia do SD !
Obrigado !
PS: acho que o blog fica muito interessante quando surgem tópicoos dessa natureza onde podemos trocar ideias e experiências diferentes
Abraços !
Igor,
Tem tem algo aí que me parece incongruente.
OK para o fato que você sugere registrar tudo. Mas como pode colocar um anunciador? Ele não vai fazer com que muitos incidentes NÃO SEJAM registrados?
Gracias pelos elogios ao livro. Confesso que fico lisonjeado sempre que alguém comenta sobre ele (a favor ou contra, haha).
Sobre os temas para o blog: putz, é difícil trazer assuntos polêmicos para cá. Tento ficar o máximo “antenado” com as várias comunidades (listas de discussão, orkut, blog’s) e daí recupero algo pra cá.
Abração,
El Cohen
Prezado Cohen,
Sobre o anunciador, a idéia é a seguinte: o usuário liga no SD porque o ERP está indisponível, mas ele não sabe … então a intenção dele em nos ligar é saber o que está acontecendo…
Se a mensagem do anunciador suprir essa necessidade de informação o usuário vai ouvir, e desligar o telefone, ou seja ele nem vai falar com o analista que não vai precisar ser repetitivo na orientação e não vai precisar registrar.
Durante o período que o anunciador esteve no ar, eu posso ver quantos usuários ouviram a mensagem e desligaram, ou seja, o quanto o anunciador ajudou a esclarecer as dúvidas do usuário.
Quem não se der por satisfeito com a mensagem, ficará na linha e consequentemente será atendido e terá uma ocorrência registrada…
Se eu tenho controle de quantos usuários ouviram a mensagem e desligaram, esse é um indicador relevante para eu mostrar para o cliente o impacto da indisponibilidade e quanto o uso do anunciador foi importante para ajudar a esclarer a dúvida dos usuários.
Que tal algumas indicações de listas de discussões boas para o nosso mundinho “service deskiano” ? rs …
Obrigado !
Oi, Igor.
Obrigado pelo debate, acho que está bem interessante.
Bem, na verdade o usuário “não liga para saber o que está acontecendo“, certo?
Ele provavelmente liga para reclamar de um serviço que não está funcionando direito. Não é por curiosidade, suponho, que ele contata o Service Desk, só pra saber que “confusão é essa com o pessoal do outro setor“.
Porém, você disse que consegue anotar o número de usuários que ouviram a mensagem e desligaram. Eu não tenho muita experiência com tais anunciantes automáticos, mas…
Todas as pessoas que ouvem a mensagem estão realmente atravessando aquele problema?
Caso contrário, sua contabilidade fica prejudicada. E seus argumentos lá em riba (“Registrá-los é importante para medir o impacto no negócio“) vão por água abaixo, pois a contabilização estará, no mínimo, misturando atendimentos.
Veja, não estou afrontando suas idéias. Eu as respeito. Estou é confrontando com meus pensamentos. Ambos (e mais todo mundo que nos lê) sairemos mais calejados no assunto com esse debate sério e responsável.
Em relação às listas: eu só acompanho duas nacionais oriundas do Yahoo: ITSMF e o GE ITIL-RS. Tentei algumas no orkut, mas o povo está mais interessado em material para certificação e dicas sobre arrumar hardware, hehehe..
Abração!
El Cohen
Um certo tempo atrás nós desligamos nossa Central Leucotron e passamos a utilizar um servidor com Asterisk…
Com isso, qualquer chamada pôde ser passada por um anunciador, dependendo da origem, interna/externa, nível 1 ou 2, de acordo com o nosso banco de dados.
A operação para mudança do anunciador é mais simples ainda… É só um upload via FTP do arquivo de áudio em wav ou mp3 em uma pasta específica.
Isso não nos resolve tanto pois lidamos diretamente com o cliente final… Mas pra quem tem isso num setor de TI que atende determinados serviços de uma ou mais empresas, seria fantástico!!
Com isso, o asterisk cria um relatório em html de quantas pessoas ouviram cada mensagem, e inclusive pode gravar todas as conversas
Há como configurar no Asterisk as opções depois da mensagem inicial, então colocando algo como “Caso deseje contato com um de nossos atendentes, disque 1″…
Todos que não discarem e abortarem a ligação depois da mensagem inicial certamente estão com o problema, então o relatório chega mais próximo possível dos 100% de exatidão.
Quanto à parte das listas infelizmente não conheço nada que aborde diretamente o assunto (GE ITIL-RS, que por sinal anda bem parada, aborda mais o Itil e não o Service Desk como um todo…).
Grande abraço,
J.Gomes
Vou dar o ponto de vista do local onde trabalho.
Lá quando ocorre de algum sistema cair, o ERP por exemplo, temos o chamado CAOS, que é um problema desconhecido, assim, quando recebemos ligação que algum sistema está fora do ar, o registramos como incidente e indicamos para a equipe responsável, essa equipe, ao receber vários incidentes, verifica que está realmente com problemas e solicita a abertura de um CAOS, após isso, todas as ligações recebidas sobre o mesmo problema são registrados como “informar indisponibilidade”, não gerando mais incidentes, porém não deixando de registrar, já que, pelo menos lá, todas as ligações atendidas devem ser registradas no sistema.
Espero ter contribuído com algo, já frequento este site e blog a bastante tempo, mas só agora vim a comentar.
Salve, Marcos!
Ajeitei o texto que comentaste.
Que bom que comentaste. Quando mais gente escrevendo, mais temos uma visão ampla dos procedimentos que o mercado realiza frente essa situação.
Agora, sacanagem chamar de CAOS, hein?
É um acrônimo de alguma expressão?
El Cohen
Salve Professor Cohen !
Só hoje tive tempo de entrar no blog….
Sim, o usuário não via nos ligar para saber o que está acontecendo e sim porque alguma coisa parou de funcionar e ele precisa entender o porque …
Então, respondendo…
“Todas as pessoas que ouvem a mensagem estão realmente atravessando aquele problema? ”
Não … todos escutam a mensagem, se o conteúdo for o suficiente para esclarecer o que está acontecendo, a pessoa desliga, então entendemos que, se não houvesse a mensagem, ela ficaria na linha somente para ser orientada sobre o que está acontecendo coisa que o anunciador fez…. certo?
Aí podemos considerar que o anunciador facilitou o trabalho e ajudou no controle de fila na hora da indisponibilidade, e quem desligou é porque só estava ligando por causa da indisponibilidade …
Se o usuário estiver com um problema que a mensagem não pôde resolver, então ele fica na fila até ser atendido pelo analista.
Sendo assim consideramos que, se o usuário desligou assim que ouviu a mensagem é pq uma simples orientação de que o “ERP está fora e a previsão de retorno é X” resolveu o motivo que gerou a ligação….
Não sei se fui muito claro … rs
Espero que sim …
Abraços !
Igor