Assim como a Igreja Cristã usava gárgulas e santos para atrair os povos pagãos para seu domínio, a Pink Elephant atrai profissionais de TI para o ITIL com método similar.

Como assim?

No passado, os povos pagãos – politeístas que acreditavam em vários deuses – foram atraídos para o cristianismo através de uma estrategia muito esperta da Igreja.

Para trazê-los para dentro de seus domínios, a entidade criou figuras (como gárgulas e santos) que substituíam antigos deuses, costelações do zodíaco e animais (lembre-se da importância dos gatos no Antigo Egito).

Você já deve ter assistido filme de gregos, romanos etc. Cada sujeito escolhia o seu deus preferido, acendia velas para ele, realizava oferendas etc.

Assim, a Igreja criou santos que pudessem ocupar o lugar destas divindades pagãs nas preces dos povos idólatras.

Dessa maneira, o sujeito continuava fazendo o que sempre fez e gradualmente ia migrando para o monoteísmo, já dentro do alcance dos padres, bispos, jesuítas etc.

Veja essa lista http://www.estudosdabiblia.net/a17_5.htm

Não é curioso como uma religião monoteísta permitiu que brotasse culto a várias outras pseudo-quase-divindidades além do próprio Deus? Bem, agora você já conhece uma das origens..

Tem santo que protege os viajantes (São Cristóvão). Os policiais (São Miguel). Os atletas (São Sebastião). Tem santo que cuida de causas urgentes, Santo Expedito. São Francisco? Cuida da ecologia. Santo Antônio, arruma casamento.

Tem santa que é muito popular no momento:

Santa Edwiges, padroeira dos endividados.

Ah, os gárgulas?

Eram figuras que, entre outras explicações, simulavam os animais para quem também os povos pagãos acendiam suas velas, torciam por uma intervenção etc.

Pra colaborar no entendimento dessa ideia recordo uma circunstância que presenciei na sinagoga:

O rabino realizava a leitura do texto litúrgico. No fundo do salão, crianças corriam e brincavam. E claro, gritavam. Um pessoa entre os bancos virou para trás e pediu que a meninada fizesse silêncio. O rabino interveio e disse:

Deixe. Enquanto estiverem sob nossos olhos é melhor do que lá fora.

Capisce?

E o ITIL, Cohen? E a Pink?

A versão 3 do ITIL chegou para atualizar a biblioteca com novas e melhores práticas.

Mas também para dar um enfoque aos leitores e praticantes sobre o que é mais importante:

O serviço que é prestado ao usuário e cliente

Excerto do texto do Gary que você poderá fazer download mais adiante:

ITII V3 has a much stronger focus on business results and thinking in terms of services and not just processes. Because of this major shift from a process-centric view to a Service Lifecycle view, the refresh became more of a rewrite.

Muitas vezes, na organização do ambiente para prestar suporte ao negócio da empresa, os profissionais perdem a noção do todo e preocupam-se muito mais com backup, infra-estrutura etc. do que o objetivo fim de seu trabalho. Ou seja, se envolvem com os processos e esquecem os serviços prestados.

Peter Drucker já dizia:

É o consumidor quem determina o que é uma empresa. É somente a vontade do consumidor de pagar por um bem ou serviço que converte os recursos econômicos em riquezas e os objetos em bens. O queo consumidor comprar e considera como valor nunca é um proudot. É sempre uma utilidade, isto é, algo que o produto faz para ele.

(Aliás, este ano comemoraria-se o centenário de Drucker, caso estivesse vivo)

Significa o quê?

Não adianta bolar milhões de diagramas, processos e fluxos se o resultado final é algo que o cliente não deseja. Ou é o que se quer  “empurrar” a ele.

Então, mais do que nunca (uau!), é importante:

1. Pensar no serviço que o cliente deseja
2. Examinar internamente como faremos para chegar a tal resultado

Cohen, e o ITIL? A Pink?

Orra, puxa! Como você é ansioso, hein?!

Dia desses recebi um  pela lista do ITSMF enviado por um representante da Pink. O título do texto é:

“ITIL V3: Where to start & how to achieve quick wins” que, em português significa “ITIL V3 – onde começar e alcançar rápidas vitórias”.

Aliás, presumo que o texto seja de divulgação pública, pois foi distribuído numa lista igualmente pública. Se você desejar, clique aqui e baixe as 7 folhas de orientação.

O texto é muito bom.

E concordo plenamente com ele.

Mas..

Rá-rá, tal como a igreja, ele usa aquilo que NÃO SE QUER para conseguir atrair os iniciantes.

O que não se quer?

Na igreja, que existam múltiplos deuses. Para isso, foram criadas figuras como santos e gárgulas para seduzir os pagãos a ingressarem em nossas hostes. E depois, catequizar a turma.

O texto da Pink, por analogia, não é diferente.

Quer que o pessoal pare de pensar em processos e passe a pensar em serviços.

E usa qual método?

Implantar um gerenciamento de incidentes, um catálogo de serviços etc. (que são processos) para alcançar vitórias rápidas. E depois que o profissional estiver no clima do ITIL, então pode alargar seu conhecimento, seguir a catequese e ir adiante.

Antes que as pedras chovam: não sou contra catequese.

Nem da igreja, nem do ITIL.

As pessoas escolhem seus caminhos. São livres para isso.

E ambos os caminhos acima são positivos.

Mas de alguma maneira me recordei de um pensador do passado que levou muito ferro por uma frase que, de alguma maneira, descreve o que acabei de refletir:

Os meios justificam os fins.

Grande Nicolau. Maquiavel.

É minha opinião

Abraços,

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:

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:

]]> http://www.4hd.com.br/blog/2008/09/12/eficiencia-x-eficacia-peter-drucker/feed/ 12