Gestor e sua equipe devem medir os riscos quando chegar a hora de decidir pela compra de um produto ou desenvolvimento in-house

O mercado nacional oferece uma profusão de softwares para gerenciamento das atividades de suporte técnico. Isso sem contabilizar  produtos estrangeiros; outros que são adaptados, vindos de Call Center e ambientes similares; até o alçapão final que é a boa e velha planilha eletrônica.

Sempre comento nos cursos de gestão de suporte: a decisão que o gestor (auxiliado por sua equipe) precisa tomar  nunca é baseada na melhor relação custo-benefício ou em vantagens x desvantagens etc.

A decisão sempre recai sobre…

Quais são os riscos?

• Quais os riscos de nada usarmos?
• Ou de usarmos uma solução open source, como o Ocomon ou GLPI?
• Um bem simples e baratinho no mercado?
• Um entry e middle level como Fireman?
• Algo mais completo (e complexo) como o Qualitor, Relativa ou Automidia?
• Um mais poderoso como a suíte do Trauma Zero?
• Ou “às ganhas” mesmo, com custos bem superiores, como aqueles que pagam para ter o selo da Pink Elephant?

• Ou desenvolvermos em casa e fazer algo bem adaptado à nossa realidade, mas que nos comerá recursos?

Essa não é uma dúvida nova

E não se trata de orçamento curto, quero deixar claro (ao menos, neste artigo).

A maioria das empresas em crescimento (extrapolando agora o assunto suporte técnico) se depara com algo parecido: comprar um concorrente que já tem o que desejamos ou desenvolver em casa essa tecnologia?

Os exemplos de empresas que compram outras existem aos milhares, inclusive na nossa área, onde a fome da CA parece que passou, mas a da Totvs segue crescendo enormemente…

Joan Magretta, no livro que recomendei em artigo anterior (O que é gerenciar e administrar):

Quando você mesmo faz alguma coisa, utilizando seus próprios recursos e empregados, você tem mais controle. Isso resolve um dos problemas fundamentais da organização: como coordenar os recursos e as pessoas dos quais você depende para realizar seu trabalho.

Mais adiante ela complementa:

Mas enquanto você resolve o problema da coordenação, afasta-se de um problema de igual importância para a organização, o problema da motivação. Para que uma organização tenha bom desempenho, cada participante deve estar motivado a dar o melhor de si. (…) Com a propriedade, você perde o poderoso incentivo da sua posição no mercado: o limite nervoso que mantém tensos os fornecedores (e autônomos) bem a seu alcance.

Resumindo: você detém o controle se faz em casa. E adapta o produto exatamente como deseja.

Por outro lado, se contrata um produto feito fora de casa sabe que fornecedores externos são pressionados pela concorrência. E por você. E precisam ter asas para atender bem. E isso é perdido quando se desenvolve o produto em casa.

É claro, se você é uma empresa como a Constat que presta serviços de infraestrutura e ainda por cima pode desenvolver (e comercializar) seu produto, o Qualitor, vale a pena.

Contudo, apesar do produto ser completo, não é raro ficar-se entre a cruz e a espada, pois…

O software não roda em Oracle, o que explica – de certa maneira – a exposição do segundo parágrafo da Joan: o mercado pressiona para que o produto rode em múltiplas plataformas de bancos de dados.

(Ae Donald, Juliano e time Qualitor: perdoem por usá-los como exemplo, mas quem tem “bala na agulha” como vocês, não se micha por pouca coisa).

O fato é que se você cresce bastante, pode desenvolver em casa, pois tem economia de escala para distribuir as despesas por vários outros setores e projetos.

O ressurgimento da GM com Sloan foi mais ou menos assim.

Enquanto Ford trabalhava com linha de produção e não sacou que uma hora o pessoal ia cansar do Modelo T, Sloan manteve várias fábricas diferentes (compartilhando certas facilidades e departamentos entre elas) e produzindo veículos diferentes, atendendo a um novo mercado emergente.

Conclusão

Se você é grande, talvez valha a pena desenvolver em casa e fazer um rateio das despesas.

Se você é uma empresa pequena ou média, esqueça.

Cuide do objetivo fim do seu negócio. Irá consumir recursos internos além de nunca alcançar o nível de tecnologia de um fornecedor. Trate de selecionar um produto de mercado, pressionando o fabricante para entregar (quase) tudo aquilo que você deseja.

Quanto a questões de orçamento, fica meu testemunho que existem preços para todos os bolsos.

Mas lembre-se que um gestor sempre lida com o RISCO.

Como por exemplo, “- O que acontece se eu comprar algo muito barato?”

Abraços,

El Cohen

Um debate no mundo cyber entre cachorros-grandes (expressão gauchesca), questiona o benefício da certificação ITIL para softwares. Tem o presidente da Pink Elephant e mais fornecedores na peleia.

O auê começou no artigo do Michael Lohr, gestor do time de vendas da Tripwire. O texto foi publicado no Information Security Systems com o título ITIL Certified Products are No Magic Bullet (“Produtos certificados não são bala mágica” ou, digamos, “certeira”).

Dos argumentos

Os argumentos da fera estão relacionados com a crescente onda de certificação de ferramentas relacionada com os preceitos do ITIL.

Certificação de compatibilidade com ITIL para softwares já era feita pela Pink Elephant. Agora a OGC está liberando para outros parceiros. Tudo a um custo mínimo de US$ 12.000.

Michael diz que contratar um software certificado em ITIL NÃO AJUDA EM NADA na implementação do ITIL na empresa. Por que não existe garantia alguma para assegurar que as melhores práticas serão realmente implementadas.

Como exemplo, cita o fato de ter se mudado de Atlanta para Boston. Neste novo endereço enfrenta muita neve, por isso comprou pneus especiais para esse tipo de clima como precaução. Só que dirigindo o carro na neve, ainda assim teve problemas.

Ao conversar com o fornecedor, o mesmo disse: NÃO ADIANTA APENAS OS PNEUS, é preciso SABER DIRIGIR NA NEVE.

Finalmente, apresenta seu medo: que as empresas comprem produtos certificados achando que o projeto será um sucesso, quando há muito para fazer, para uma implementação de ITIL adequada.

Resposta do presidente da Pink Elephant

Respondendo a ele, o presidente da Pink Elephant, David Ratcliffe, em seu artigo More on “ITIL Certification of S/W Products” diz:

“Concordo plenamente com Michael quando ele diz que não bastam pneus para a neve, é preciso habilidade para isso.”

“Concordo plenamente com Michael quando ele diz que de nada adianta comprar um software certificado em ITIL se a empresa não realizar o árduo trabalho de projetar os processos.”

“MAS não concordo quando diz que comprar um produto certificado em nada ajuda.”

E usando a mesma analogia, pergunta quem pode garantir que o pneu realmente é para neve, com o objetivo de ajudar ao usuário? Apenas uma etiqueta colada e escrita “Pneu para neve” ou a certificação por uma entidade independente que avalia um conjunto de critérios e os documenta?

Encerra comentando que a Pink oferece uma lista de produtos que são certificados. E o resto é com você.

Do Reth, da Service Now

OK, quando você pensa que a coisa ficou assim, vem o Reth da Service Now e dá seus pitacos também no texto An expensive compliment from a friend.

Ele diz que certificação em ITIL virou um check-box nas RFP’s (Request For Proposal ou Pedidos de Propostas) na maioria das contratações de software para TI.

Mas cita que isso é apenas um pedaço da solução.

Como exemplo, comenta que os produtos de software precisam ser, entre outras coisas, flexíveis.

Menciona o exemplo da BMC que anunciou o Remedy como o primeiro software certificado em ITIL. Mas que os clientes sofriam para migrar de uma versão para outra, inclusive abandonando o produto, tamanha a frustração nesse processo de atualização.

Não dá pra esquecer que parte desse argumento é por que o produto do Reth é comercializado em modalidade Saas, o que evita o trabalho de instalar etc.

Do Cohen

É, certificações viraram uma febre. Uma moda, mas isso você já sabe, se me acompanha há algum tempo.

Segunda-feira recebi um edital de licitação de software.

Pedia, em apenas um parágrafo, com uma descrição quase lacônica, que o produto fosse compatível com sete disciplinas do ITIL V2. Mas, a seguir, exigia que a “ordem de serviço” pudesse ser entrada assim, assado etc.

Caramba, há uma desconexão entre o que é pedido e a cultura duma empresa que ainda denomina incidente ou requisição como ordem de serviço.

Ainda não foram aculturados para ITIL.

E é claro que corrobora plenamente os argumentos do Michael lá em cima, quando diz que o pessoal contrata software achando que vai resolver as dores do mundo (ou pelo menos, da TI).

Eu desdenho as certificações. Talvez por não ter uma sequer, hahahaha.

Todo gestor precisa apresentar resultados. E muitas vezes isso vem da batalha diária em equilibrar custos, investimentos, motivação etc.

E, quem sabe, usando smartphones produzidos na China, sem certificação, nem garantia de proteção ao meio-ambiente, nem proteção aos direitos humanos… mas que funcionam!

Se eu pudesse, teria uma BMW. Mas tenho um Astra. E funciona bem.

Compreendo que as certificações e proteções são resultado de um processo civilizatório. Inmetro, Pink Elephant, Procon, leis regulando Call Centers e outros vão surgindo para defender direitos, mas…

Na hora do “bem bom”, a gente vê o presidente do partido dos trabalhadores andando de Land-Rover.

(Oh, hummm, onde veio parar meu artigo!!)

Ninguém está errado nesse debate.

Existem várias verdades num copo cheio até a metade. Ou vazio até a metade, haha.

• Realmente o software não garante implementação bem-sucedida do ITIL (e infelizmente muita gente só pensa na tecnologia, esquecendo totalmente os outros dois pilares, pessoas e processos)
• Alguém pode certificar que o produto é compatível com ITIL. E se tiver respeito no mercado e o cliente achar que isso (a certificação) é algo que lhe ajuda na seleção de ferramentas, beleza. Mande ver.
• Obviamente, existem trocentas outras variáveis a analisar na contratação do software. Compativel com ITIL (ou certificado, nível mais acima?) é um dos check-boxs. Preço, suporte, simpatia, localização, flexibilidade, SGBD, interface e outros aspectos também tem seus pesos.
• Dê uma olhada nesse artigo Licenciar software para Help Desk

Sudae, men and girls!!!

Baita abraço a todos,

El Cohen

PS: Semana que vem não tem artigo pois estarei em Sampa, para o Help Desk Day e o Curso de Gestão de Suporte para Empresas de Tecnologia. Aliás, por que você não vai estar lá?!

Ao longo destes dez anos de vida do Fireman tenho visitado clientes interessados em uma solução de software para Help Desk.

Em geral, relegados durante anos pela diretoria e gerência de TI, um dia chega a oportunidade (e o amém) para licenciarem uma solução deste tipo.

Planos são feitos. Avaliações de mercado. Características desejadas reunidas. Pesquisa em produtos estrangeiros e nacionais. Os eventos devem acontecer de maneira mais ou menos rápidos, pois qualquer mudança na economia pode postergar a compra para seis meses ou até dois anos para frente. E, cá entre nós, administrar um departamento de Help Desk sem um software é dureza (nem vou entrar no mérito dos produtos caseiros que vicejam em 80% do mercado nacional, estimativa produzida por mim).

Pois então, um dia o conjunto de características é definido. Está tudo na pastinha com o título: PROJETO DO SOFTWARE DE HELP DESK.

E dentro?

Um desenho do Superman.

Sim, em geral é com isso que me deparo.

Tenho dez anos de Fireman. Dezoito de SIAL Software e Help Desk / Service Desk. Antes disso, já trabalhara anos em infra-estrutura, atendimento, etc na Edisa, Banco Iochpe, Procempa, CA, etc. Tudo em TI. E essa bagatela de anos (dizem que o diabo sabe das coisas mais por ser velho do que diabo) me ajuda a concluir isso.

E confirmo: o “croquit” do produto se assemelha ao Superman.

Ou seja: um produto idealizado.

Sabem o que acontece quando idealizamos algo? Em qualquer coisa na vida? Uma namorada, um relacionamento, um carro, um celular, um novo emprego de trabalho? Um jogador de futebol? Uma praia? Sabem?

Acabamos nos frustrando. Por que a imagem idealizada, perfeita, nunca se alinha com a realidade.

Tem dias que a namorada rança. O celular não tem sinal em determinada localidade. O carro faz um barulhinho que irrita. O jogador muda de time para o maior rival. A praia tem algas e a água fica marrom.

E também isso acontece com o software de Help Desk. Ou ele não tem todas as features que desejamos (integração com AD, totalmente aderente às disciplinas do ITIL, chover de baixo pra cima, conectar batedeira via mensagem SMS, ter a máquina-de-refeição dos Jetsons, etc).

Bom, depois de toda a luta para conseguir na diretoria a autorização orçar o software, a situação parece perdida quando a “salvação” (o software) não é tão perfeita quanto queríamos. Há um sentimento de fracasso. Nenhum produto atende aos requisitos “mínimos”.

Essa é a vida.

O que acho existir por trás de todo este envolvimento? Essa idealização, etc?

Um desejo, ainda que inconsciente, que a ferramenta de software venha resolver todos os problemas do Help Desk / Service Desk!

E nestas horas me vem à mente um white paper da HP, cuja introdução era:

A FOOL WITH A TOOL IS STILL A FOOL!

There are a lot of clients (both of HP and other vendors) that have implemented tools in hopes of solving business problems, only to discover that the root cause of the problem ends up being process related.

O texto acima, apesar de possuir um título provocante, demonstra existir uma tendência a concentrar na tecnologia a solução de dificuldades que acontecem em outras esferas. No caso acima, dos processos.

Gostaria de passar uma mensagem para todos que um dia irão avaliar ferramentas de software. E, de quebra, também para suas experiências de vida:

Reduzam suas expectativas.

Não se trata de ser pessimista. Ou jogar por terra expectativas. Nem de ser pouco ambicioso.

Alerto apenas que perfeição, exceto a Monique Evans, não existe.

Sejam realistas, compreendam que seu funcionário tem aspectos positivos e negativos. Seu carro o leva aonde quer, apesar de ter um barulhinho chato. Sua namorada (assim como você) tem seus dias de alto astral e outros de TPM.

Vá adiante, gere menos expectativas (que possam lhe gerar frustrações) e seja mais feliz.

Abraços

El Cohen

Vou contar um fato verídico que aconteceu comigo ontem e, em seguida, uma analogia com nosso ambiente de Help Desk e Service Desk.

Andei na chuva com o carro da minha filha. Depois, deixei-o na garagem (do hotel onde deixamos nossos carros) por uns quinze dias, já que ela foi fazer uma mochila-trip por Bolívia e Peru.

Quando ela voltou e tentou fazer o carro andar, ele não ia adiante. Baixando o freio-de-mão, continuava emperrado. Chamei o pessoal da oficina que recém fizera uma vistoria completa. Deixei-os trabalhando e quando fui pegar meu carro, vi que estavam dirigindo o carro até a oficina. Fiquei feliz. Disseram que a lona enferrujou e criou um clima adesivo (se é verdade, são outros trocentos). Mas, ao ver nossas vagas no estacionamento, percebi que o cone que utilizo quando o carro está ausente, havia sumido.

Opa!

A 200 kms/h (exagero!) fui até a oficina e perguntei se não haviam pego o cone “por engano“. Alguém disse: “- É mesmo, este não é nosso. Vamos devolver hoje mesmo.”

Aí entra o tema de nosso post. Eu poderia ter esbravejado, xingado, etc. Não renderia muita coisa. Por outro lado, sendo sutil, mostrei que estava atento aos movimentos deles, assim como obtive o cone de volta.

E o Help Desk?

A suite Fireman possui um módulo específico chamado FireDog que, além de coleta de inventário, gerenciamento de licenças de software, também faz alerta de mudanças súbitas.

Suponha que você receba a mensagem de email abaixo apresentada. Ela avisa sobre mudanças na configuração da estação.

O que normalmente faríamos?

Ligar para o usuário em questão e esbravejar, ou sermos irônicos, etc. “- Quem deixou instalar tal software nesta máquina?” ou “- Onde foi parar este pente de memória, pombas?”

Existe uma atitude mais esperta que seria, na minha opinião, a seguinte:

“- Olá, prezado usuário. Estou lhe telefonando por que nosso software de gerenciamento de ativos informa que a sua máquina sofreu algumas modificações, como <citar quais>. Poderia verificar isso para mim e me retornar daqui a alguns minutos?”

Desta maneira:

• não se coloca o usuário contra a parede;
• gera um tempinho para que ele encontre uma desculpa plausível (ainda que não aceitável de nossa parte; mas isso são outros quinhentos);
• demonstra também que o Help Desk está “ligado” com o que acontece no parque de máquinas da empresa;
• e ainda reguarda você de uma situação: acusar o usuário e ter sido um terceiro a intervir na estação.

Em geral, esse método de investigação gera mais dividendos do que prejuízos. Todo mundo sai bem, além da imagem do Help Desk / Service Desk mostrar-se reforçada.

Abraços,

El Cohen

Como desenvolvedor de software para Help Desk e Service Desk (yes, Fireman is our product), nós buscamos atender a demanda do mercado.

Isso não significa que a gente endossa tudo o que o mercado quer. Significa que desenvolvemos um produto para os outros usarem, respeitando as necessidades e desejos dos outros colegas profissionais.

Aqui eu poderia discorrer várias e várias histórias, mas a visita que fiz hoje vale a pena citar e está um pouco associado com aquele item anterior, Quebrando paradigmas.

Questão:

Vale a pena disponibilizar consulta da base de conhecimento, via WEB, para o usuário?

Bom, no tópico acima referenciado tivemos um registro de uma empresa que não acha adequada liberar a abertura de incidentes via WEB, por motivos próprios.

Hoje enfrentei outra situação de aprendizado.

Em alguns contratos, o prestador de serviços do Help Desk pode receber por incidente. Por uso.

Assim, apesar de ser politicamente inadequado freiar o uso da WEB para que o usuário consulte a base de conhecimento, é bom fazer isso. E orientar ao cliente que telefone em caso de dúvidas. Ligue e não acesse via WEB. Por que neste caso estará gerando um novo incidente que vai garantir uma grana de contrato ao final do mês.

Yeah, a gente não pode ser muito purista ao avaliar as coisas somente sob o aspecto T�?CNICO. �? preciso saber também como as contas do final do mês serão pagas, hehehe.

Ao implementar ou reestruturar seu novo Help Desk é bom pensar não somente no aspecto técnico, mas no impacto que mudanças culturais irão gerar. Inclusive no caixa de sua empresa, caso ela seja prestadora de serviços.

Think about.

Abraços

El Cohen

A tecnologia em uso no Help Desk / Service Desk precisa auxiliar o departamento.

Parece banal e até patética a frase acima. Mas no dia-a-dia do atendimento, algumas interrogações podem surgir. Em especial quando a tecnologia que você utiliza tem um reconhecimento mercadológico tão grande que você nem fantasia questioná-la.

Dia desses acompanhei uma lista de discussão onde um analista consultava colegas sobre como classificar uma reinicialização de senha (este assunto é campo fértil em nossa área).

Em um enfoque profissional, é preciso qualificar o incidente, classificá-lo e anotar todas as demais informações inerentes. Ora, muitas vezes essa burocracia de documentação toma mais tempo do técnico do que a reinicialização de senha propriamente dita.

Contudo, e aqui aparece o viés da administração, estes apontamentos precisam ser realizados. Isso por que tais dados geram um mapa do que acontece dentro do departamento. Assim, ações de melhoria, aperfeiçoamento e eficiência podem ser desenvolvidas.

Refletindo um pouco mais, como trabalhar sobre um plano de segurança se não existe idéia de quantos incidentes, chamados, etc são abertos por mês? Como saber se vale a pena o esforço nesta área? Os problemas são sazonais? São específicos para um grupo de usuários?

Não dá pra trabalhar e melhorar sem massa crítica de informações para avaliação.

Por outro lado…

Tomar cinco minutos do técnico para registrar algo que resolveu em apenas 30 segundos é rigor demais.

Pois é nesta fresta que a tecnologia precisa ajudar.

O incidente precisa ser registrado.

E o analista não pode tornar-se um vítima da burocracia.

É a tecnologia que deve ajudá-lo a aumentar sua eficiência.

Abaixo apresento uma tela do Fireman. No seu lado direito o analista é contemplado com vários quick-codes (código de preenchimento rápido) para este tipo de situação.

Isso significa que ao clicar no item correspondente (“Reinicializar senha”, por exemplo), todos os campos a esquerda da tela e outros serão automaticamente preenchidos. Rápido. Simples. E tudo fica documentado.

A principal utilidade é evitar que o analista despreze a ação do registro, ou faça-o inadequadamente.

Nestes quick-codes é possível, adicionamente, inserir scripts, questões, etc. Mas isso é papo pra discutir com o fornecedor

Abraços,

El Cohen

Esse é o título de um artigo apresentado pela Anna Salleh no site News in Science (original em inglês: Computers to fix themselves).

O artigo comenta a projeção futurística (mas nem tão longe assim, pois já estão sendo realizados testes), em que o sistema de atendimento de Help Desk e Service Desk será automatizado por computador.

Ou seja: não estamos falando do computador ter auto-diagnóstico, etc, mas da central de atendimento receber chamados de usuários e atendê-los.

De maneira automática.

Sem intervenção humana.

Baseado em a) mecanismos de inteligência artificial, b) em padrões de mais de 30.000 atendimentos e soluções e engines similares ao do Google, o sistema permitiria ser “razoavelmente preciso” (curiosa essa expressão: ou é preciso ou não é; seria como dizer “mais ou menos certo“).

Eu não duvido que o futuro caminhe por esse trilho.

Contudo, uma frase me chamou a atenção:

Os usuários irão tolerar alguma imprecisão do sistema ou respostas incompletas. Por exemplo, se o sistema der ao usuário a página certa para download de um software mas informar os procedimentos errados, os usuários ainda assim acharão o sistema automatizado útil.

Hahahaha…

Aqui eu acho que a academia se distancia da realidade.

Seria muito legal este professor sentar em uma PA (ponto de atendimento) e ver se isso realmente é aceitável. Ou é uma projeção do que ele gostaria que os usuários se conformassem (receber a página certa para download, mas os passos incorretos).

PONTO 1

Eu nunca encontrei um usuário que aceitasse informações erradas. Ora, ele liga para um local que deve lhe dar suporte e as orientações… e o faz perder ainda mais tempo?

PONTO 2

O diretor dessa empresa ou corporação vai concordar com este desperdício de tempo do usuário, esta imprecisão? Com certeza, alguém precisando enviar uma proposta vai dizer “- F.D.P. desse sistema automatizado que me faz perder tempo, me passando dados errados…”

PONTO 3

O foco desta idéia parece muito mais substituir a área de atendimento do que fazer com que a TI seja aderente ao negócio. Ora, a “economia” acontece no Help Desk, quando os processos e infra-estrutura da empresa é que deveriam ser melhorados para diminuir incidentes no Help Desk (melhor cabeamento, computadores mais novos, melhor treinamento de usuários, etc)

PONTO 4

Quem vai lidar com o lado emocional do usuário? Com certeza não será a máquina…

Algum supervisor vai ter que interagir nas questões de prioridade, urgência, “- Isso daqui me informa errado“, “- Essa coisa tem que funcionar agora!!!“, etc.

De fato, eu acho que as coisas podem caminhar neste sentido: automatização.

Com este posicionamento esclareço que, como uma pessoa alicerçada na tecnologia, não renego meu “berço profissional“, hehe. Não sou descrente no avanço e na modernidade. Afinal, escrevo de um notebook do tamanho de um caderno, via internet banda larga e num blog mundial.

Mas é conveniente preocupar-se com os enfoques acima. Não serei eu que apontará os mesmos para os pesquisadores da Austrália, onde este projeto está em desenvolvimento. Aliás, no final do artigo, o próprio professor confessa ainda algumas “não-adequações do sistema”.

Contudo, escrevo para você!

É bom saber para onde as coisas estão indo e ter consciência do que acontece.

Não se assuste, caso esteja preocupado com seu emprego!

Em minha humilde opinião, eu não acho que a tecnologia per si suprirá nossas vagas. Ao contrário, acho que cada vez abrirá mais dentro da seara da própria tecnologia.

Abraços

El Cohen

Eu não gosto de clichês. Mas é impossível negar que a sabedoria popular conseguiu retratar em poucas palavras uma situação ímpar. Por isso esta expressão se universalizou.

Minha filha vai estudar Moda em São Paulo. Então achamos interessante que aprenda Corel Draw: para ajudar na confecção do projeto-piloto, essas coisas todas que envolvem desde a criação até a confecção da roupa. E neste sábado acinzentado de 11 de novembro, garoa fina com modos paulistanos, vamos ao SENAC Informática completar a inscrição dela.

E…

Ao entrarmos, um templo de modernidade. Mural lotado de eventos na área de tecnologia, inclusive o SENACTECH: presença de palestrantes da IBM, Google e outros. Catracas eletrônicas para ingresso nas salas de aula, etc. Te mete, hein?

Minha filha dirige-se ao atendimento e completa um formulário com uma quantidade exagerada de informações requisitadas. Entre outras, título de eleitor e religião.

Pode parar!

Na universade, ela preencheu um formulário on-line e no momento da matrícula, gastou apenas dois minutos. E por que eu peço uma nota fiscal, o SENAC exige coisas inusitadas, como o CARIMBO DO CNPJ no formulário de inscrição, etc. Além, é claro, de preencher o o campo CNPJ manualmente. A impressão: realizar a matrícula no curso é mais difícil que telefonar para surdo.

Ela – minha filha – tenta amenizar. Explica que várias pessoas que comparecem a esta instituição conhecem pouco e possuem pouca experiência com internet. São pessoas humildes em busca de uma formação para se colocarem no mercado. Fiquei satisfeito com a idéia.

Quando solicito nota fiscal ou recibo, sabem o que acontece? A atendente pega um talão de notas, em pleno SENAC Informática, e dissipa dez longos e penosos minutos preenchendo-o à mão. Mas katzo, não tem INFORMÁTICA no nome da instituição?

Quando percebo que ela separa a caneta para escrever, um sentimento de frustração se abanca de mim. Aquele mesmo de consultório médico, onde esperamos 60 minutos para ser atendidos, apesar de chegar no horário.

E, entre indignado e aborrecido com o fato, quando voltamos para casa, rememoro inúmeros departamentos de Help Desk e Service Desk que visitei nos últimos nove anos.

Quase todos usando uma ferramenta caseira para registro de incidentes.

Ora, como é que nossa comunidade quer se profissionalizar, exigir mais direitos, compartilhar conteúdo e experiências (vai uma prolepse? Isso será tema de outro post), crescer, etc se permanece numa zona de conforto com algo obsoleto?

Software de registro de incidentes caseiro detém um valor simbólico e emblemático da nossa comunidade de profissionais de Help Desk do Brasil. Demonstra um certo nível de despreocupação ou conformismo com progredir, lutar e avançar, entre outras coisas.

Como pode uma área de TI desenvolver nas horas vagas uma ferramenta que já é oferecida por fabricantes nacionais (nem escrevo sobre os estrangeiros que poriam à baila argumentos como “dólar flutua“, “distribuidor muda de produto e ficamos empenhados“)?

Softwares que falam português nativo, integrados com e-mail, Apache, IIS, disponíveis em vários bancos de dados, pesquisa textual, coleta de inventário com mil-e-uma funções, etc, etc? Um mar de tecnologia e economia de tempos e recursos para os departamentos de TI.

De certo modo, tentamos (SIAL Software) despertar alguma preocupação com profissionalismo ao realizarmos os eventos (já na 14a edição) www.helpdeskday.com.br. Não citamos Fireman durante o dia inteiro. A idéia é lançar uma semente de inquietação nos participantes. Não se trata de apresentar o software, mas de estimular idéias (por isso é um seminário e não treinamento) com as quais o analista se PREOCUPE. �? claro que buscando o melhor, lá adiante, ele também pensará no software.

Por isso a visita ao SENAC gerou esta associação livre (salve a psicanálise!) que revelou este (p)ressentimento em mim.

Aliás, abençoado o ITIL que, ainda que carregue (ou seja carregado por) uma indústria voraz, vem conseguindo chacoalhar os pensamentos “naftalianos” e empurrar a classe um passo a frente na sua profissionalização e modernização.

Mas sobre nossa comunidade, um novo post aguarda meu desabafo.

Abraços

El Cohen

Self-Service.

Auto-ajuda.

Você vai encontrar em quase todo fornecedor de software ou soluções para Help Desk e Service Desk, um módulo que oferece a tradicional auto-ajuda para o usuário.

Isso significa que ele pode obter informações e até a solução de uma dificuldade pesquisando em um mecanismo preparado para isso.

Ele pode ser uma FAQ na internet/intranet, uma base de conhecimento, manuais, etc. O modo não importa muito nessa argumentação que farei.

O que importa é que o usuário tem a sua disposição recursos para resolver suas questões sem interagir com o departamento de suporte técnico. E, com isso, a equipe de atendimento pode se dedicar a outras tarefas ou até mesmo a incidentes mais complexos.

Voilà, que maravilha!

Maravilha?!

Sei não… Eu também achava isso, até que Mestre (mestre mesmo, em Finanças e Administração e com MBA em TI) Ricardo Mansur me apresentou, por e-mail, novas idéias sobre o assunto.

Em primeiro lugar, examinem o gráfico abaixo:

Aliás, ler o texto original do Mansur é ainda melhor:

O custo-hora do Help Desk de TI é quase sete vezes menor do que o custo do usuário se auto-ajudando.

Na realidade, a pesquisa apenas vem comprovar o chamado “Paradoxo da produtividade” de TI.

Na década de 80 economistas norte-americanos, como o prêmio Nobel Robert Solow, verificaram que, apesar de gastarem cada vez mais com computadores, as empresas e a economia como um todo não obtinha ganhos significativos de produtividade.

Tal constatação ficou conhecida como “Paradoxo de Solow” ou “Paradoxo da Produtividade“!

Uma pesquisa da “The Economist” sobre o comportamento da produtividade no período 1987-1997 e intensidade relativa de tecnologia mostrou:

Setor – Bancos
Produtividade: -4,0%
IRTI: + 2,8

Setor – Mineração
Produtividade: +4,0%
IRTI: +0,6

Uma das causas-raiz deste paradoxo é a crença do Service Desk nas ferramentas de auto-ajuda, onde foram considerados APENAS os custos de TI.

Quando analisamos a empresa como um todo, vemos que o custo improdutivo do usuário de TI é muito caro, e se o processo de informatização não levar em conta este custo, o resultado final é que o investimento realizado em TI reduz os lucros ao invés do seu objetivo de alavancar o crescimento da empresa.

As áreas de tecnologia necessitam rever as suas estratégas levando em conta o custo global da empresa e desta forma conseguir um alinhamento das estratégias de TI com os objetivos e metas da organização.

Mansur me parece tocar num ponto muito interessante: o Help Desk / Service Desk tentando agilizar as coisas (e se aliviar de um carga, geralmente sob o argumento de “um analista atende n usuários via Self-Service e não 1 x 1 como ao telefone“) acarreta um custo mais alto para a organização!

Não há mais o que dizer depois dessa argumentação do mestre, IMHO.

Ave, Mansur! Salve, Mansur!

É claro, está aberto ao debate

El Cohen