Regis, Posso estar enganado, mas AGREGAR VALOR não tem muito a ver com análise CUSTO/BENEFÍCIO, certo?
Por que a primeira é uma visão externa. E a segunda, interna. Explique melhor pra que eu acompanhe... Abração EL Co 2010/3/25 Regis Machado <[email protected]> > > > Sim... > > De acordo com a metodologia estabelecida (depois de "x" tempo, depois de > "y" tentativas infrutíferas de contactar o usuário etc.), cancela com > comunicação ao próprio usuário e ao superior dele. O que não dá é pra > modelar toda a metodologia em função de um caso de pior cenário que vai > acontecer uma vez por ano, ou menos, pois o custo superará o benefício. > > Mas é claro que tudo depende da realidade da empresa, como sempre. Se esse > caso ocorre com frequência, e tem um impacto potencial significativo para o > negócio, a metodologia utilizada será outra (esperar mais tempo, realizar > mais tentativas de contato, ou talvez até mesmo implicando no > não-cancelamento permanente do ticket). A linha mestra de raciocínio será > sempre o valor agregado ao negócio da instituição. Se agrega mais valor > cancelar, cancela. Se não, não cancela. > > Pra variar, a resposta é depende, né? Deve sempre ser analisada a realidade > de cada empresa, nesse e em todos os demais casos. O que baliza cada decisão > de fazer ou deixar de fazer algo, ou de fazer do modo "a" ou do "b", é o > valor que a adoção de cada alternativa retorna para aquele negócio > específico. Na maioria das coisas geralmente esse valor é equivalente de um > negócio ao outro (as tais boas/melhores práticas, por exemplo). Mas em > muitos casos não. Por isso não dá pra ficar se balizando cegamente na > maneira como as coisas são feitas em outros lugares. Há muitas variáveis em > jogo (o ramo do negócio é o mesmo, o porte da empresa é equivalente, quem > implementou lá *sabia o que estava fazendo* etc.). > > Resumindo, o norte é sempre esse. Agregar valor ao negócio. Mas nem sempre > a escolha de qual alternativa específica é a mais adequada nesse sentido é > tão óbvia, pois muitas vezes a quantificação dos custos/benefícios totais de > cada uma das escolhas não pode ser feita muito claramente. Bom, mas se não > fosse assim, não teríamos razão de existir, não é mesmo? > > Abs, > > Regis. > > ------------------------------ > To: [email protected] > From: [email protected] > Date: Wed, 24 Mar 2010 14:33:02 -0300 > Subject: Re: [itsm_br] Tickets Pendentes > > > Pô, Daniel... > > Cancelar? > > Imagine a situação que já descrevi. > > Você é uma software-house. Seu cliente abre um ticket por que algo não > funciona. > Você diz: seu SGBD é antigo, migre para um mais moderno. > > Ele leva seis a dez meses para fazer isso. > > Você cancelaria o ticket? > > E se o funcionário do cliente vai embora da empresa, justamente o que abriu > o ticket? > > Ninguém mais lembra disso, ou que foi aberto etc... > > Abrazon > > EL CO > > > > > 2010/3/24 Daniel Andrade <[email protected]> > > > > João, > > Este é o tipo de situação que requer compromisso dos dois lados. Entendo > sua preocupação com o cliente ter que abrir outro ticket, tendo em vista que > ele paga por ticket aberto. > Mas justamente está ai o gancho para conseguir maior comprometimento dele > no fechamento do ticket. O fato de estar pagando pelo serviço deve reverter > em maior atenção e acompanhamento por parte do cliente. > Não é muito diferente da contratação de tantos outros serviços onde temos > que ser pontuais, e se não somos, perdemos o direito de reclamar depois. Se > você adquire um lugar num vôo ou teatro e chega tarde, você perdeu seu > direito, mesmo estando pagando. > > Se o cliente tem um prazo justo e acordado entre as partes, e não cumpre, > cancele o ticket. > > O fato de vocâ cancelar influencia também na conscientização dos clientes > sobre o uso do serviço, e tende a auxiliar a mudança de comportamento com o > tempo. > > Atenciosamente > > Daniel Andrade, ITIL Expert > www.vitisconsultoria.com.br > > > > Em 24 de março de 2010 11:01, Victor Cesar <[email protected]>escreveu: > > > > Prezado João, > > > Na minha empresa também enfrentamos esse problema, mas aqui eu tenho um > timeout de 72horas, até esse prazo ficamos cobrando o cliente, caso seja > pendencia do cliente, finalizamos o ticket e colocamos a observação: Foi > orientado o cliente sobre bla bla bla... enviamos email para diretoria > (cliente) e responsavel pelo processo interno e solicitamos ao cliente qnd > concluido a pendencia, abrir um novo ticket, temos um campo para referenciar > o ticket origem ( problema, essa informação o cliente tem q informar - com > isso algumas coisas ficam "perdidas" - cabe o gerente fazer rollback da > memoria) > > Tem funcionando muito bem, o aceite por partes do cliente foi otimo. > > > esperto ter ajudado. > > Victor Cesar. > Solution IT > > > > Em 23 de março de 2010 16:16, MansurR <[email protected]> escreveu: > > > > > Prezados (as), > > Prezado João, > > Antes de ir em qualquer direção eu creio que deves avaliar os motivos do > garlo junto ao cliente e ver o que pode ser feito. Os que não querem como > ticket pendentes tem uma dose de razão pois foi feito o que deveria ser > feito até o momento do gargalo. > > Eu recomendaria olhar os garlahos e avaliar a criação de SLAs do cliente > para vcs. SLA do cliente rompido poderia significar ticket encerrado por > exemplo. > > No entanto neste primeiro pense e comunique muito com o cliente. > > > Cordialmente > Ricardo Mansur > http://itgovrm.blogspot.com > http://twitter.com/itgovrm > > ----- Original Message ----- > *From:* João Eduardo Brando <[email protected]> > *To:* [email protected] > *Sent:* Tuesday, March 23, 2010 7:38 AM > *Subject:* [itsm_br] Tickets Pendentes > > > Bom dia Srs e Sras, > > Esta é a minha primeira participação no grupo em forma de dúvidas, pois > venho acompanhando as mensagens há cerca de 3 meses. > > Bom, estou com uma dúvida com relação à melhor prática para administrar > tickets pendentes. Em nossa empresa, passamos por situações onde o usuário > abre um ticket de solicitação de reparo e, em um determinado ponto do > desenvolvimento da solução, passamos a contar com uma pendência por parte do > cliente, podendo ser desde aquisição de material, contratação de terceiro ou > mesmo liberação de acesso à área. Após a liberação desta pendência, damos > continuidade ao processo, resolvemos o incidente e finalizamos o ticket. > > O problema é que essas pendências geralmente levam dias para serem > sanadas e aí enfretamos o SLA. Desta forma, até então, estávamos > direcionando este tipo de ticket para uma categoria chamada de "Pending > Customer" onde o relógio pára de contar enquanto o ticket estiver nessa > situação. Lembrando que esta categoria foi previamente acordada com o > cliente. > > A questão é que atualmente tem acontecido uma discussão muito grande em > nossa empresa com relação a redução do Backlog, o que é totalmente aceitável > na medida em que devemos garantir o máximo de qualidade e agilidade nos > atendimentos. Todavia, há uma visão interna de que os tickets em "Pending > Customer" devem ser fechados após determinado período (a ser definido), pois > o mesmo já teve a atenção de nossa parte, depende do cliente e não pode > ficar "sujando" nosso poço de tickets. Eu sou totalmente contra esta opnião, > pois fechar um ticket sem resolvê-lo em definitivo gera controles paralelos > e, ainda, seria injusto solicitar ao cliente para abrir um segundo ticket > quando resolver sua pendência, pois o mesmo para por cada abertura. > > Gostaria de saber a opnião de vocês, se nas suas empresas também > existem os tickets "Pending Customer", se isso é natural e aceitável ou se é > um "workaround" administrativo indevido. > > Grato, > -- > João Brando > ITIL v2 Foundation Since 10/2009 > (32) 8885-7941 > > > Em 22 de março de 2010 08:41, Roberto Cohen > <[email protected]>escreveu: > > > > Também dá margem a outros pensamentos... > > Que escassez de literatura nacional que teu chefe é obrigado > a comprar um livro que mantém um site sobre gauchismo, hein? > > :-) > > Valeu, André! > > EL CO > > > > > 2010/3/20 André Pinto <[email protected]> > > > > Gostei da idéia, El Co. > Não é o foco, mas gostaria de dizer q fiquei feliz ao ver o seu livro de HD > na mesa do meu gestor. Tu é bão mesmo, uai! :P > > > On 19/03/2010, *Roberto Cohen* <[email protected]> wrote: > > > > ** Retribuição / Reconhecimento ** > > OK, esqueçam o dinheiro por que pode ser constrangedor para ele (o Gilberto > me mata agora!!). > > Que tal cada um enviar um POSTAL DE VERDADE da sua cidade para o Gilberto? > > Pô, isso não é muito. > Vamos encher a mesa do compadre de postais dos mais variados pontos do > país. > > É preciso reconhecer o esforço que ele faz de SETE - sim, você leu - SETE > anos > mantendo a lista. Quanta gente não leu nome de software, ideias, bla bla > bla que > foram compartilhados através desse canal mantido por ele? > > Se toparem, eu libero o endereço profissional dele. > > EL Cohen > > > > > > > > > -- > Atenciosamente, > > André Pinto > (31)8456-8118 > > --------------------------------------------------------- > Esta mensagem e seus anexos podem conter informações confidenciais ou > privilegiadas. Se você não é o destinatário dos mesmos você não está > autorizado a utilizar o material para qualquer fim. Solicitamos que você > apague a mensagem e avise imediatamente ao remetente. O conteúdo desta > mensagem e seus anexos não representam necessariamente a opinião e a > intenção da empresa, não implicando em qualquer obrigação ou > responsabilidade por parte da mesma. > > > > > > > > > -- > Atenciosamente > -------------------------------- > Victor César > Solution IT - MBA - ITIL > Cel: (0XX85) 8885-6042 > Skype: victor.cesar > > > > > > > -- > Daniel Andrade, PMP > > > > > > ------------------------------ > Transforme-se em personagens engraçados. Conheça o novo site de I Love > Messenger.<http://ilm.windowslive.com.br/?ocid=ILM:ILM:Hotmail:Tagline:1x1:Tagline> > > >
