Electronic entry of PMRs / Registo eletrónico de PMRs
This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português
English version:
The PMR opening...
I'm going to use an IBM announcement as an excuse to talk a bit about technical support. The announcement in question is that IBM is trying to get their customers to use a web based tool for opening PMRs (or Service Requests) for severity 2, 3 and 4 (higher means lower business impact, 1 being most critical, eventually a system down). The status of this change may vary with your geography, so if you still have any doubts after reading the information provided in the announcement and the links it includes, don't hesitate to contact IBM to clarify.
The change is that currently you can open the service requests by phone. In the future that will be reserved for severity 1 issues. I haven't received any feedback on the announcement, but I can imagine there will be different reactions to this:
- Wow... So they want to save even more costs?
- What?!... I always use the web based tool
- What?!... So it means I must always have access to the web to open a problem?
- Why the difference between severity 1 and the others?
- Yes... You can be sure every company is trying to save costs. IBM is not an exception, and I'd be worried if it was. The question here is that the "cost" of having a couple of persons without specific product training, that just answer the phone and ask a set of pre-defined questions to the customer and enter the answers in some internal tool is probably very low. On the other hand, the "cost" (meaning bad impression) that derives from the bad interaction between these persons and a customer with a problem in his hands can be significant. Believe me. I've opened PMRs this way, and it's not a good experience. The person only purpose is to collect a minimum set of information (like product name, problem description, customer information, severity etc.) that will allow the opening of the service request and sending to a proper queue. It's a non-value added work. And if you have a serious problem, and on the other end of the line is someone asking you to spell "Informix" you won't like it. Furthermore, this can create some basic errors that may lead to bad queuing of the PMRs
- You always use the web based tool? Great... so do I. End of story :)
- Yes... it means you should always have an Internet connection. But that's mostly pervasive today... But if you don't have one, the phone channel will probably be accepted. But let's be honest... When was the last time that we did not have an Internet connection while working on IT?
- The difference would be that if you have a severity one PMR (possibly a system down) you need immediate feedback. Personally and let me stress "personally" I'd create the PMR using the electronic web based tool and then I'd call IBM to make sure it will reach an engineer as soon as possible
I've been using the SR tool for some years and my experience tells me it's available, easy, quick and safe. The reasons why I feel this way are:
- Never caught it off-line
- It asks the essential, not a lot of useless information
- Since I have to authenticate it already knows the customer details
- It's flexible in the sense that I can upload files with relevant information
- It allows me to save the PMR in "draft" and come back later to complete and send it to IBM
- It always puts the PMR in the correct queue which guarantees fast feedback from a product specialist
Tech support in analysis
I'm sure we're able to find reports of bad technical assistance from IBM. And I suppose that it would be nearly impossible to be successful in 100% of the cases... But instead of basing my analysis on external reports from people I don't know, I prefer to base it on my own experience. And believe me, I open a lot of PMRs... I work mostly with Informix, but I've been involved in PMRs with other IBM products, and although the experience is not uniform, I'd say the end results are pretty good independently of the technology. The main difference I've found between different products would be that sometimes there is a bigger difference between different levels of support.
And in the case of Informix I must admit I may be privileged. We have a local resource doing L1 (first customer interaction) who is very good and experienced, and many times I discuss the issues previously with him. Assuming we're facing something new, he has to move the PMR to higher levels and then it's mostly business as usual, although I do have access to internal knowledge bases which may allow me to gather more useful information. But typically at this level I'm acting as a regular customer, interacting with people located around EMEA (Europe, Middle East and Africa).
As I mentioned before, I do open a lot of PMRs... In the last year or so I was involved in around 25. Most of them Informix. Before you start screaming that Informix must have a lot of issues let me explain a couple of points:
- Arguably, software is not cheap. And if a customer pays for support, if he has a reasonable doubt or if he hits what may look like a problem, I see no reason why not to open a PMR
- Many times a customer ask me a question and I may have an answer for them. But if they show me that a manual gives the incorrect information, a PMR should be raised to fix the manual even if the doubt is clarified
- If a customer has an issue, and that issue is caused by the OS or some external service (like DNS), if we have the feeling that Informix could be handling it better, I see no reason not to open a PMR and eventually ask for a FEA (Feature request).
- If a customer has an issue, but is able to workaround it, I see no reason not to open a PMR, even if the issue isn't urgent anymore due to the existence of a workaround
- A PMR is a natural way to interact with R&D (through technical support) so that some future improvements can be made. Specially for me, as an IBM employee, but also from a customer point of view, improving the product is in the best interests of all the customers and community members
Two good examples
I don´t' want to fill the article with technical details, but I'd like to leave here two success stories with the technical support and R&D.
- The nasty query
Some time ago a customer identified that, what looked like a very simple query would be running for several days. We investigate the query plan, but meanwhile the query was re-written and it run in half an hour. But the new query was nothing like intuitive and we decided to check with tech support if the original behavior was acceptable. Meanwhile I asked an Oracle DBA from that customer to create the tables, load the data and test the query. The result was roughly the same... The query would be running for weeks (accordingly to the estimation of their product). This query would deserve an article by itself... But guess what: IBM R&D looked at the query, understood the problem, asked me to try it on a non released version that included some features that could help, and finally considered that it was a bug. 11.70.FC6 should have the fix!
When I spoke again with the Oracle DBA and told him what we did, and asked him if he would consider enter a problem in Oracle he just laughed....
So, without any drama, for a problem that was already solved, R&D decided to accept a bug and improve the product. That's good, and I'd say that's expectable, but it's not what you get from other vendors. - The useless message
More recently a customer was seeing some messages in online log that mean something wrong was happening in the communication between the clients and the server. I don't want to go into big details, but basically the message was useless because it does not contain information that allows the customer to track down the issue. Again, a PMR was opened. Note that this was not causing measurable impact on their environment. I had an extensive chat with the technical support engineer and explained that the message as it was just causes anxiety on the customers since we're telling them that something is wrong, but not where or whom. In around a week R&D developed what we call a code fix (changes in the code that solve a problem) and after that customer is able to ask for a special build (patch like 11.50.xC7X? )
Again, a simple change, that will bring help to customers on future versions (11.50.xC10 and 11.70.xC7).
I bet that most vendors would just say "works as design"... or "we could consider a future change... insert a request in the features request database...". But here the answer was: "You're right! It's fixed. Do you need a patch?"
- You need to have a clear understanding of the problem. A reproduction always helps, and a good evidence collection may be crucial
- You must be willing to defend your point of view with valid arguments.
- You'll have much better chances if the changes are simple to implement and if they don't change old behavior
- You should be able to express yourself clearly and be assertive
Versão Portuguesa:
Abertura de PMRs...
Vou utilizar um anúncio da IBM como pretexto para falar um pouco sobre o suporte técnico.
No anúncio em questão a IBM anuncia que os seus clientes devem usar uma ferramenta web para abrirem os PMRs (ou pedidos de serviço) de gravidade 2, 3 e 4 (mais alta significa menor impacto no negócio, sendo 1 a mais critica - eventualmente um sistema em baixo).
O estado desta mudança pode variar com a sua geografia, por isso se lhe restarem dúvidas depois de ler a informação do anúncio e os links nele contidos, não hesite em contactar a IBM para mais esclarecimentos.
A mudança em relação ao método atual é que de momento os pedidos de serviço podem ser feitos por telefone. No futuro isso será reservado aos casos de gravidade 1. Não recebi qualquer feedback relativo ao anúncio, mas posso imaginar que irão existir várias reações a isto:
- Wow... Então ainda querem reduzir mais custos?
- Hmmm?!... Eu uso sempre a ferramenta web...
- Hmmm?!... Então isso significa que terei de ter acesso Internet para abrir um problema?
- Qual a razão da diferença entre gravidade 1 e as restantes?
- Sim... Pode apostar que todas as empresas estão a tentar reduzir
custos. A IBM não é uma exceção e eu estaria preocupado se fosse. A
questão é que o "custo" de ter algumas pessoas sem formação específica
em produtos, que apenas atendem telefones e fazem um conjunto
pré-definido de perguntas, introduzindo as respostas numa ferramenta
interna é provavelmente muito baixo.
Por outro lado, o "custo" (entenda-se a má impressão causada) que deriva de uma má interação entre essas pessoas e um cliente com um problema em mãos pode ser significativo. Acredite em mim. Eu já abri PMRs por esta via e a experiência não é boa. O único propósito da pessoa é recolher um conjunto mínimo de informação (como o nome do produto, descrição do problema, informação de cliente, gravidade etc.) que irá permitir abrir o caso e colocá-lo na "fila" adequada. É um trabalho sem valor acrescentado. E se estiver com um problema em mãos e do outro lado da linha estiver alguém que lhe pede para soletrar "Informix" qual será a sua reacção? Para mais, isto facilmente pode criar alguns erros que podem levar a uma má classificação ou encaminhamento do pedido. - Sempre usa a ferramenta web? Perfeito... eu também. Fim de assunto!:)
- Sim... significa que deverá ter sempre um acesso à Internet. Mas isso é quase omnipresente hoje em dia... No entanto, se tal não tiver disponível, o canal telefónico deverá ser aceite. Mas sejamos honestos... Quando foi a última vez que não tinha uma ligação à Internet enquanto estava a trabalhar em TI?
- A diferença será que se tiver um problema de gravidade 1 (possivelmente um sistema em baixo) necessita de resposta imediata. Pessoalmente, e deixe-me sublinhar "pessoalmente", eu abriria o PMR pela via eletrónica e depois ligaria para a IBM para garantir que o pedido chegaria a um técnico tão rápido quanto possível
Tenho usado a ferramenta de abertura de pedidos de serviço já há uns anos e, a minha experiência diz-me que é altamente disponível, fácil rápida e segura. As razões para sentir isto são:
- Nunca a encontrei indisponível
- Pergunta o essencial e não um conjunto de informação inútil
- Dado que nos temos de autentica, já sabe todos os detalhes do cliente
- É flexível no sentido que posso enviar ficheiros com informação relevante
- Permite-me gravar os PMRs como "rascunho" e voltar mais tarde para completar a informação e fazer o envio para a IBM
- Coloca sempre os pedidos na fila correta, o que garante uma resposta rápida por parte de um especialista do produto
Suporte técnico em análise
Tenho a certeza que é possível encontrar relatos de má assistência técnica por parte da IBM. Julgo que seria impossível assegurar 100% de sucesso... Mas ao invés de basear uma análise nos relatos externos de pessoas que não conheço, prefiro basear-me na minha própria experiência. E garanto que eu abro bastantes PMRs... Trabalho essencialmente com Informix, mas já estive envolvido em PMRs com outros produtos da IBM, e apesar de a experiência não ser absolutamente uniforme, diria que o resultado final foi sempre bastante bom, independentemente da tecnologias. Talvez a principal diferença entre produtos tenha sido a diferença entre diferentes níveis de suporte. E no caso do Informix posso admitir que sou privilegiado. Temos um recurso local que trata do nível 1 (L1 ou a primeira interação com o cliente). E esse recurso é muito bom e experiente. Muitas vezes acabo por discutir os assuntos com ele mesmo antes da abertura dos casos. Mas admitindo que estamos a enfrentar algo novo, ele terá de mover o PMR para os níveis de suporte acima e então sou mais um "cliente", isto apesar de ter acesso a algumas ferramentas internas que me permitem pesquisar alguma informação que pode ser importante. Mas no essencial assumo o papel do cliente e estou a lidar com alguém localizado na EMEA (Europe, Middle East adn Africa).
Como referi antes, eu abro realmente bastantes PMRs... No último ano estive envolvido em cerca de 25. Na sua maioria relacionados com Informix. Antes que alguém comece a gritar que o Informix deve ter muitos problemas, deixe-me esclarecer e deixar bem claro alguns pontos:
- É discutível, mas o software não será barato. E se um cliente paga pelo suporte, se tiver uma dúvida razoável ou se encontrar o que lhe parecer um problema, não vejo razão para não abrir um PMR
- Muitas vezes sou questionado por clientes e até posso conseguir esclarecer as dúvidas. Mas se me mostrar que o manual fornece informação errada, deve ser aberto um PMR para a sua correção, ainda que a dúvida tenha ficado esclarecida
- Se um cliente tem um problema, ainda que esse problema seja causado pelo sistema operativo ou outro serviço externo ao Informix (como o DNS), se pensamos que o Informix poderia lidar melhor com isso, não vejo razão para não abrir um PMR e eventualmente pedir uma melhoria (FEA ou Feature Request)
- Quando um cliente encontra um problema, mas consegue contorná-lo, não vejo porque não abrir um PMR, ainda que dada a existência de uma alternativa não o torne urgente
- Um PMR é uma forma natural de interagir com as equipas de desenvolvimento (através do suporte técnico), no sentido de tentar obter melhorias para o futuro. Isto é especialmente verdade para mim, sendo da IBM, mas julgo que também do ponto de vista de qualquer cliente, dado que melhorar o produto é do interesse de qualquer cliente e dos membros da comunidade
Dois bons exemplos
Não quero encher o artigo com detalhes técnicos, mas gostaria de deixar aqui duas histórias de sucesso de interação com o suporte e equipa de desenvolvimento.
- A query perversa
Há algum tempo atrás um cliente identificou aquilo que parecia uma query muito simples, mas que no entanto iria ficar a correr por vários dias
Investigámos o plano de execução, mas entretanto a query foi re-escrita e correu em meia-hora. Mas a nova query era tudo menos intuitiva e decidimos verificar com o suporte técnico se o comportamento inicial estava correto e se não haveria nada a fazer.
Neste intervalo de tempo pedi a um DBA de Oracle do mesmo cliente que criasse as duas tabelas envolvidas, carregasse os dados e analisasse o resultado e plano de execução. O resultado era sensivelmente o mesmo... A query de acordo com a estimativa fornecida pela base de dados iria estar a correr durante semanas (note-se que a estimativa em si ia variando). Esta query merecia um artigo por si só.... Mas o que se passou com o suporte da IBM? Olharam para a query, compreenderam o problema, pediram-me que tentasse a execução numa versão ainda não disponível, dado que havia novas funcionalidades que poderiam fazer diferença (não adiantou) e finalmente considerara que era um bug. A versão 11.70.FC6 deverá conter a correção.
Quando voltei a falar com o DBA Oracle e lhe contei a história da IBM, perguntei-lhe se considerava abrir um problema na Oracle... Apenas se riu...
Ou seja, sem grandes dramas, para um problema que na realidade já não existia, o desenvolvimento decidiu aceitar um bug e melhorar o produto. É bom e diria que é o desejável, mas não é o que se obtém com outros fornecedores. - A mensagem inútil
Mais recentemente um cliente estava a encontrar algumas mensagens no online.log que indicavam que algo de errado estava a ocorrer na comunicação entre o servidor de base de dados e algum cliente. Não querendo entrar em grandes detalhes, entendemos que a mensagem era inútil dado que não continha detalhes que permitissem ao cliente investigar e depois rsolver a questão. Novamente foi aberto um PMR. Note-se que isto não estava a provocar nenhum impacto sensível no ambiente do cliente. Não havia queixas de erros ou problemas de performance.
Tive uma extensa conversa com o técnico de suporte e expliquei que tal como estava, a mensagem apenas causava desconforto no cliente (pois fica a saber que algo de errado estava a ocorrer), mas que não permitia uma investigação sobre o assunto por falta de detalhes. Em cerca de uma semana o desenvolvimento desenvolveu o que chamamos um code fix (alteração no código) e depois disso o cliente pode pedir um special build (patch como 11.50.xC7X?)
Mais uma vez foi uma alteração simples, que irá trazer benefícios e ajudar os clientes com versões futuras (11.50.xC10 e 11.70.xC7)
Julgo que a maioria dos fornecedores concluiria algo como "trabalha como planeado... Insira um pedido de melhoria na nossa base de dados....". Mas aqui a resposta foi: "Tem razão. Está corrigido. Quer um patch?"
- Tem de ter um entendimento claro do problema. Uma reprodução do mesmo ajuda sempre e uma boa recolha de evidências pode ser crucial
- Tem de estar disposto a defender o seu ponto de vista.usando claro argumentos válidos
- Terá maiss possibilidades de sucesso se as alterações necessárias não forem demasiado complexas se não modificarem comportamentos antigos por omissão
- Deve saber exprimir-se claramente ser assertivo
No comments:
Post a Comment