De acordo com o The Standish Group nos EUA e na Europa para 2015:
- 31,1% de todos os projetos de TI estão parados e não concluídos;
- 52,7% de todos os projetos de TI foram concluídos com um prazo final, um aumento significativo no orçamento planejado originalmente ou uma mudança radical nas metas planejadas originalmente;
- apenas 16,2% de todos os projetos de TI atenderam às expectativas.
Total:
83,8% (na verdade, 8 em 10) falhas versus 16,2% de sucesso.
Nos últimos 10 anos, esses números não mudaram - ao implementar sistemas de TI, uma empresa enfrenta problemas típicos que podem ser agrupados da seguinte forma:
- Dificuldades e problemas organizacionais.
- Erros no planejamento e administração do projeto de implementação (orçamento, prazos e outros erros associados à abordagem do projeto).
- Problemas relacionados à infraestrutura e ferramentas de trabalho (incluindo práticas e sistemas que devem ajudar na implementação).
E o que leva a falhas na implementação do Service Desk e outros sistemas na Rússia?
Estamos desenvolvendo um
sistema de Help Desk para automatizar todos os processos de serviço pós-venda em empresas de serviços . Depois de conversar com mais de 5.000 representantes de uma ampla variedade de setores de serviços (médias e pequenas empresas), decidimos compartilhar as razões das implementações malsucedidas do Service Desk na Rússia / CEI e os métodos para superar a maioria das dificuldades! De fato, os problemas acabaram sendo "universais" para a implementação de quaisquer sistemas e projetos de TI.
Temos certeza de que isso permitirá que você se prepare e evite pelo menos alguns deles.
Implementação do Service Desk. Realidades russas
A comunicação com mais de 5.000 empresas de serviços que operam no segmento b2b na Rússia e nos países da CEI não fornece estatísticas precisas sobre os projetos, mas nos permite identificar grupos semelhantes de problemas (não sem especificidades locais). A seguir, consideramos cada item com mais detalhes, concentrando-se nos "representantes" mais populares de falhas. Note-se que a classificação dos problemas utilizados é condicional e selecionada apenas para conveniência da apresentação. Os grupos selecionados se cruzam. Por exemplo, o medo de mudar está indissociavelmente ligado a questões organizacionais etc.
Bala de prata
“O próprio sistema de Service Desk resolverá todos os problemas”
Muitos realmente acreditam que um sistema de automação resolverá todos os problemas. Nos processos atuais da maioria das empresas de serviços, o caos reina e parece que a implementação do
Service Desk ou CRM permitirá que você obtenha controle total sobre a situação em relação às vendas ou ao suporte ao cliente.
Este é um grande erro. Existe um ditado bem conhecido:
"Se a sua empresa está caótica, o resultado da introdução de um sistema de automação será um caos automatizado" .
Nenhuma ferramenta pode resolver problemas internos urgentes. O efeito da introdução do Service Desk em empresas com baixa maturidade terá, sem dúvida, um efeito sério (por exemplo, eliminará a perda de aplicativos,
reduzirá o atraso do SLA etc.). Mas a conclusão bem-sucedida do projeto com resultados compreensíveis e mensuráveis, que podem ser desenvolvidos mais adiante, dificilmente é possível no caso geral sem alterar o componente organizacional.
"Puxe" nossos requisitos
Esse problema é característico de um negócio maior e mais burocrático.
Como regra, os processos nessas empresas vêm se desenvolvendo há muito tempo; algum tipo de esquema de gerenciamento está tomando forma. No topo deste sistema, há automação de "retalhos" - Service Desk em algumas áreas específicas, diferentes CRMs em diferentes departamentos, etc. Mas a empresa deseja obter um único sistema centralizado e automatizado, vinculando todos os processos entre si. O erro é que, ao mesmo tempo, ele não deseja se adaptar aos sistemas e melhores práticas existentes, de acordo com o qual eles são desenvolvidos, tentando "puxar" o produto selecionado de acordo com seus requisitos. E fazer isso é extremamente difícil.
Para alcançar o resultado, juntamente com o projeto de implementação, você terá que mudar as abordagens para trabalhar, realizar mudanças organizacionais e até se livrar de algumas pessoas ou, inversamente, introduzir novas funções no estado. E tudo isso deve ser feito razoavelmente, entendendo quais indicadores precisam ser alcançados.
Implemente o Service Desk. Medo da mudança
"Nossos clientes não estão tão acostumados a isso."
As empresas de serviços realmente consideram algo como isto:
"Não vai funcionar porque nossos clientes não estão acostumados."
Eles nem estão prontos para tentar alterar o esquema de trabalho existente, por exemplo, propondo novos, mais simples e convenientes mecanismos de teste para vários de seus clientes. Desde o início, eles têm a confiança de que os clientes rejeitarão tudo de novo. Isso significa que não faz sentido iniciar um projeto ou, inversamente, um projeto lançado não termina.
"Reorganização necessária"
Esse problema está amplamente associado à introdução de sistemas de central de atendimento devido à complexidade comparativa dos processos de suporte. A recusa de projetos está associada ao medo de reorganização. Mas, muitas vezes, essas mudanças beneficiam os negócios. Eles podem se basear nas “melhores práticas e bibliotecas” nas quais são agregados -
ITIL, ou na abordagem para organizar o gerenciamento de serviços ITSM , mas as pequenas e médias empresas, é claro, se recusam a usar essas “melhores” práticas.
Um ótimo exemplo é uma empresa de serviços, onde o serviço não é mais realizado por 2-3, mas por 10 ou mais pessoas. Nessa escala, em primeiro lugar, já existe um grande fluxo de aplicativos e, em segundo lugar, há uma clara classificação das pessoas em termos de competências e pagamento. A reorganização do serviço de suporte envolve a alocação da primeira, segunda e terceira linhas, uma mudança na interação com os contratados e muito mais.
Sem levar em conta a reorganização, as empresas têm medo de lançar projetos para a introdução de sistemas de service desk ou estão introduzindo-os, mas não obtêm o resultado desejado (automatizar o caos).
"Os custos em tempo real aumentarão"
As empresas adiam a implementação de ferramentas quando percebem que os custos em tempo real dos funcionários ao trabalhar com o novo sistema de central de serviços estão crescendo. E isso é verdade!
No começo, você realmente precisa gastar mais tempo. Por exemplo, você precisará registrar 100% dos aplicativos, marcar as ações executadas durante o processamento, amortizar custos de mão-de-obra etc. Mas os pontos de ineficiência não podem ser identificados sem fixar atividades e rastrear métricas neles. Portanto, antes de iniciar o projeto, basta responder à sua pergunta "O que queremos como resultado da implementação do service desk?"
Familiaridade: "Os colegas ficarão infelizes"
Nos negócios russos, as relações de "familiaridade" são muito comuns. E quanto mais "casa" é uma empresa, mais complexa é. Isso é especialmente pronunciado em empresas da periferia - no negócio de 10 a 20 pessoas que trabalham juntas há muito tempo.
O clientelismo levanta questões morais difíceis quando são necessárias mudanças ou demissões daqueles que trabalham mal. Freqüentemente, nessas situações, o projeto é suspenso e a nova ferramenta não é usada, porque na empresa há descontentamento ou uma pergunta sem resposta: "Como assim?"
Em tal situação, você terá que priorizar. Se o clientelismo é mais importante, não faz sentido pensar no desempenho dos negócios e nas atividades em que sua empresa está envolvida em chamar os negócios em princípio. E ainda mais, introduza ferramentas que revelam gargalos. Mas se você precisar de resultados, precisará ser duro. A implementação do Service Desk permitirá apenas tomar decisões objetivas e informadas em questões de suporte de serviço e atendimento ao cliente pós-venda.
Erros organizacionais e dificuldades na implementação do Service Desk
Resistência interna
Os funcionários das empresas não gostam de mudanças no modo de vida existente. Por exemplo, o atendente sentou-se e, em uma revista, em uma caneta, à moda antiga, anotou todos os apelos dos moradores da casa sobre a inoperabilidade do elevador e bebeu calmamente chá. E aqui ele é forçado a consertar algo em um sistema incompreensível. Naturalmente, ele resiste.
O problema também está relacionado à idade. Quanto mais velha a equipe, mais difícil é a adoção de novos formatos de trabalho em mudança.
Não há interesse real na gerência / tomadores de decisão (tomadores de decisão)
Em grande medida, isso é verdade para empresas de médio e pequeno porte. Os líderes dessas empresas são forçados a ser "multi-trabalhadores". Eles vendem, fornecem suporte ao cliente e resolvem problemas burocráticos. E quando eles não têm interesse real no projeto, ele não termina com nada de bom.
Qualquer projeto precisa de um "driver". Ele pode "vir" da alta gerência - a melhor opção. Caso contrário, o gerente intermediário ou a pessoa responsável pela unidade de processo dentro da empresa terá que "vendê-la" dentro e ser responsável pelo resultado.
Falta ou problemas com a abordagem de design
Nenhuma equipe dedicada e gerente de projeto
Quando as empresas não alocam pessoas responsáveis pelo resultado da introdução do sistema de central de atendimento, nada acontece.
Se o projeto for pequeno e houver poucas pessoas na empresa, não será necessária uma equipe dedicada. Mas deve haver um gerente de projeto com autoridade. Ele é obrigado a liderar o projeto até o ponto final, sendo responsável por orçamentos e pessoas, tendo a oportunidade de aplicar influências organizacionais ou esquemas motivacionais.
A propósito, é necessário não apenas destacar pessoas com poderes e responsabilidades claras, mas pelo menos parcialmente remover delas atividades simultaneamente em outras áreas.
Não há tempo disponível para as pessoas afetadas.
Freqüentemente, a empresa possui uma equipe de projeto dedicada e até mesmo seu líder, mas não há tempo para aqueles que serão afetados pela implementação do sistema de service desk. Por exemplo, engenheiros, executando aplicativos ou programadores (se os incluirmos no processo de suporte na forma de uma terceira linha). Quando o tempo não é alocado e, o mais importante, as pessoas não têm motivação e entendimento por que isso é necessário, o projeto repousa sobre resistência interna e “sabotagem”.
Não há requisitos reais e casos de uso (escopo do projeto)
Tais problemas são freqüentemente encontrados no Ocidente: no início, não há requisitos claros para o sistema de central de serviços ou para os resultados do projeto. Isso leva, inter alia, a um processo interminável de tomada de decisão. Esses clientes desejam automatizar absolutamente tudo - para reforçar o sistema a seus requisitos (mais sobre isso acima), ou os requisitos para o sistema estão mudando constantemente.
Por fim, os projetos abandonam sem iniciar: eles testam 20 sistemas várias vezes e percebem que nenhum é adequado. Pior ainda, se o projeto foi lançado, alguns prazos e orçamentos foram determinados e, em seguida, os requisitos se espalharam, o que leva a uma interrupção significativa do prazo e a custos internos seriamente "inflacionados". Em um certo estágio, fica mais fácil abandoná-lo.
Sem "impacto" (Check - Act)
Muitas empresas, tendo obtido resultados primários (às vezes muito bons, especialmente se nada havia sido automatizado antes), param de melhorar o sistema e os processos para os quais se destina a ser automatizado. Eles deixam de controlar os indicadores e, mais importante, de acompanhar os resultados desse controle.
Qualquer projeto se assemelha a uma "espiral". Existe o chamado ciclo de Deming - Planejar -> Fazer -> Verificar -> Agir. Se falamos sobre o Service Desk, uma das tarefas típicas de implementar esse sistema é reduzir o atraso no SLA. Mas após o início do trabalho, muitas empresas, em princípio, não usam relatórios. E alguns dos que ainda o usam não planejam mudanças subsequentes em seus processos, o que lhes permite alcançar indicadores de alguma forma melhores. Sem isso, a satisfação final não pode ser obtida no projeto.
O conto de "qualidade / rápido / grátis"
Até agora, muitas empresas, especialmente pequenas, acreditam que você pode encontrar um sistema ou pessoas que podem fazer tudo de forma rápida, eficiente e praticamente gratuita. Na presença dessa esperança, o projeto termina em nada - acaba por muito tempo, não muito caro e de baixa qualidade.
O desejo do cliente de desenvolver seu próprio sistema do Service Desk também está relacionado a essa categoria de problemas (por que não precisamos fazer isso, escrevemos em detalhes em nosso artigo). Se a empresa tiver a oportunidade de alocar 2 a 3 programadores, por exemplo, por seis meses - um ano, seus negócios serão muito ruins - os negócios não estarão focados no que devem fazer. Nas áreas que não são essenciais para os negócios, é melhor atrair pessoas ou usar sistemas "de fora", em vez de reinventar sua bicicleta.
Implementação do Service Desk. Como evitar erros?
Aqui estão algumas recomendações universais que permitirão economizar tempo na fase de lançamento de um projeto e implementação de um sistema do Service Desk:
- A empresa deve ter um "driver" para o projeto de implementação do sistema . Ao mesmo tempo , ele deve ter autoridade para tomar decisões , inclusive impopulares, e todos os participantes do projeto e aqueles que serão afetados pelo sistema após o lançamento devem estar cientes desses poderes.
- É necessário definir metas e registrar requisitos (para o sistema, projeto, resultados). Antes de começar a procurar um sistema de central de atendimento, você precisa definir metas, porque, na ausência delas, esse épico pode não terminar em nada.
- O orçamento / tempo / equipe deve ser destacado . Todos esses recursos obviamente dependem dos requisitos. Não deve haver ilusões: o desejo de restringir o sistema a requisitos individuais levará a altos custos (um processo de pedido é sempre mais caro). O escopo do projeto também determina o tempo que precisa ser alocado pelos motoristas e participantes do projeto, bem como por todas as pessoas que serão afetadas pelo uso do sistema.
- Não é preciso ter medo das mudanças e do "novo" . As alterações podem ser testadas em partes de clientes ou usuários, por exemplo, em vários clientes. Sim, levará mais tempo para reorganizar a estrutura, principalmente após identificar focos de ineficiência. É difícil e às vezes doloroso, especialmente considerando o compadrismo. Mas isso é necessário se focarmos na eficácia da organização e dos negócios em si.
- Supere persistentemente a resistência - o direito de "vender" . Os sistemas de central de atendimento são projetados não apenas para controlar o trabalho, mas também para criar relacionamentos transparentes com os clientes. Os funcionários, mesmo os mais velhos, entendem esse e outros argumentos razoáveis.
- Concentre-se no seu negócio principal . Quando as empresas decidirem inventar sua própria bicicleta em meio ano ou ano, desenvolva CRM, Helpdesk etc. - quase sempre termina em fracasso. Mas o principal é um indicador de quão ineficaz é sua empresa atualmente.
- Pare de acreditar em contos de fadas sobre "grátis, barato e de alta qualidade" . O próprio não "voa". O principal problema da introdução de todos os sistemas é justamente as dificuldades e mudanças organizacionais que deverão ser realizadas, caso contrário o sistema trará resultados, mas não será exatamente o que poderia ser obtido.
Nota publicada com base no material do
blog Okdesk