O salto do software em breve se tornará uma doença muito comum nas empresas. Trocar um software por outro por causa de cada pequena coisa, pular de tecnologia em tecnologia, experimentar um negócio ao vivo está se tornando a norma. Ao mesmo tempo, começa uma verdadeira guerra civil no escritório: forma-se um movimento de resistência à implementação, os guerrilheiros realizam um trabalho subversivo contra o novo sistema, os espiões promovem um admirável mundo novo com novo software, gestão a partir do carro blindado de o portal corporativo está transmitindo sobre paz, trabalho e KPIs. Uma revolução geralmente termina em fracasso total de um lado.
Sabemos quase tudo sobre implementação, então vamos tentar descobrir como transformar uma revolução em uma evolução e tornar a implementação o mais útil e simples possível. Bem, ou pelo menos diremos no que você pode se envolver no processo.
Visualização ideal da aceitação do novo software pelos funcionários. Fonte - Yandex.Images
Consultores estrangeiros começariam este artigo assim: “Se você oferecer aos seus funcionários um software de qualidade que possa melhorar seu trabalho, ter um impacto qualitativo no desempenho, a adoção de um novo programa ou sistema acontecerá naturalmente”. Mas estamos na Rússia, então a questão dos funcionários suspeitos e beligerantes é muito relevante. Uma transição natural não funcionará, mesmo com software mínimo, como um mensageiro corporativo ou um softphone.
De onde vêm as pernas do problema?
Hoje, toda empresa tem todo um zoológico de software instalado (tomamos o caso geral, porque nas empresas de TI a quantidade de software é o dobro ou o triplo e os problemas de adaptação se sobrepõem parcialmente e são muito específicos): sistemas de gerenciamento de projetos, CRM/ERP, clientes de e-mail, mensagens instantâneas, portal corporativo, etc. E isso sem contar o fato de que existem empresas em que até a transição de navegador para navegador é feita por toda a equipe sem exceção (e também há equipes que são totalmente baseadas no Internet Explorer Edge). Em geral, existem diversas situações para as quais o nosso artigo pode ser útil:
- Existe um processo de automatização primária de algum conjunto de tarefas: está a ser implementado o primeiro CRM/ERP, está a ser aberto um portal corporativo, está a ser instalado um sistema de suporte técnico, etc.;
- um software é substituído por outro por algum motivo: obsolescência, novos requisitos, escalonamento, mudança de atividade, etc.;
- módulos do sistema existente estão sendo construídos para fins de desenvolvimento e crescimento (por exemplo, uma empresa abriu a produção e decidiu mudar de em com funcionalidade máxima);
- Uma grande atualização de interface e software funcional está ocorrendo.
É claro que os dois primeiros casos são muito mais agudos e típicos em suas manifestações, preste atenção especial a eles.
Portanto, antes de começar a trabalhar com a equipe (que já suspeita que haverá mudanças em breve), tente entender quais são os reais motivos da mudança de software e se você concorda que as mudanças são tão necessárias.
- O programa antigo é difícil de trabalhar: é caro, inconveniente, não funcional, não atende mais às suas necessidades, não é adequado à sua escala, etc. Esta é uma necessidade objetiva.
- O fornecedor parou de oferecer suporte ao sistema ou o suporte e as modificações se transformaram em uma série interminável de aprovações e perda de dinheiro. Se seus custos aumentaram significativamente e no futuro prometem aumentar ainda mais, não há o que esperar, é preciso cortar. Sim, um novo sistema também custará dinheiro, mas no final a otimização custará menos do que esse suporte.
- Mudar de software é o capricho de uma pessoa ou grupo de funcionários. Por exemplo, o CTO quer um retrocesso e está fazendo lobby para a introdução de um sistema novo e mais caro – isso acontece em grandes empresas. Outro exemplo: um gerente de projeto defende a mudança do Asana para o Basecamp, depois do Basecamp para o Jira e do Jira complexo para o Wrike. Muitas vezes, o único motivo para tais migrações é exibir o seu trabalho intenso e manter a sua posição. Nesses casos, é necessário determinar o grau de necessidade, motivos e justificativa e, via de regra, por uma decisão obstinada de recusar as alterações.
Estamos falando dos motivos da transição de um software para outro, e não da automação primária - apenas porque a automação é necessária a priori. Se sua empresa faz algo manual e rotineiramente, mas pode ser automatizado, você está simplesmente desperdiçando tempo, dinheiro e, muito provavelmente, dados valiosos da empresa. Automatize isso!
Como você pode atravessar: o grande salto ou o tigre agachado?
Na prática mundial, existem três estratégias principais para mudar para um novo software e se adaptar a ele - e elas nos parecem muito adequadas, por isso não vamos reinventar a roda.
Grande explosão
A adoção pelo método “Big Bang” é a transição mais difícil possível, quando você define uma data exata e faz uma migração brusca, desabilitando 100% o software antigo.
Prós
+ Todos trabalham em um sistema, não há necessidade de sincronizar dados, os funcionários não precisam monitorar duas interfaces ao mesmo tempo.
+ Simplicidade para o administrador – uma migração, uma tarefa, um suporte de sistema.
+ Todas as mudanças possíveis ocorrem em um determinado momento e são perceptíveis quase imediatamente - não há necessidade de isolar o que e em que proporção afetou a produtividade, a velocidade de desenvolvimento, as vendas, etc.
Contras
— Funciona com sucesso apenas com softwares simples: chats, portal corporativo, mensageiros instantâneos. Até o e-mail já pode falhar, sem falar nos sistemas de gerenciamento de projetos, CRM/ERP e outros sistemas sérios.
— Uma migração explosiva de um grande sistema para outro causará inevitavelmente o caos.
O mais importante para este tipo de transição para um novo ambiente de trabalho é a formação.
Corrida paralela
A adaptação paralela ao software é um método de transição mais suave e universal, no qual é definido um período de tempo durante o qual ambos os sistemas funcionarão simultaneamente.
Prós
+ Os usuários têm tempo suficiente para se acostumar com o novo software enquanto trabalham rapidamente no antigo, encontram paralelos e entendem a nova lógica de interação com a interface.
+ Em caso de problemas repentinos, os funcionários continuam trabalhando no sistema antigo.
+ O treinamento do usuário é menos rigoroso e geralmente mais barato.
+ Praticamente não há reação negativa dos funcionários - afinal, eles não foram privados de suas ferramentas ou maneira habitual de fazer as coisas (caso a automação ocorra pela primeira vez).
Contras
— Problemas de administração: suporte para ambos os sistemas, sincronização de dados, gestão de segurança em duas aplicações ao mesmo tempo.
— O processo de transição se estende indefinidamente - os funcionários percebem que ainda lhes resta quase uma eternidade e podem estender um pouco mais o uso da interface familiar.
- Confusão do usuário - As duas interfaces são confusas e causam erros operacionais e de dados.
- Dinheiro. Você paga pelos dois sistemas.
Adoção faseada
A adaptação passo a passo é a opção mais fácil para mudar para um novo software. A transição é realizada de forma funcional, dentro de prazos determinados e por departamento (por exemplo, a partir de 1º de junho adicionamos novos clientes apenas ao novo sistema CRM, a partir de 20 de junho realizamos transações no novo sistema, até 1º de agosto transferimos calendários e casos, e até 30 de setembro concluiremos a migração é uma descrição muito aproximada, mas geralmente clara).
Prós
+ Transição organizada, carga distribuída entre administradores e especialistas internos.
+ Aprendizagem mais cuidadosa e aprofundada.
+ Não há resistência à mudança, porque ela ocorre da forma mais suave possível.
Contras - aproximadamente o mesmo que para uma transição paralela.
Então agora, apenas uma transição gradual?
Uma pergunta lógica, você concordará. Por que ter complicações extras quando você pode definir um cronograma e agir de acordo com um plano claro? Na verdade, nem tudo é tão simples.
- Complexidade de software: se estamos falando de software complexo (por exemplo, ), então a adaptação de fase é mais adequada. Se o software for simples (messenger, portal corporativo), então um modelo adequado é quando você anuncia a data e desabilita o software antigo no dia marcado (se tiver sorte, os funcionários terão tempo para extrair todas as informações de que precisam , e se você não contar com sorte, precisará fornecer importação automatizada dados necessários do sistema antigo para o novo, se for tecnicamente possível).
- O grau de risco para a empresa: quanto mais arriscada for a implementação, mais lenta deverá ser. Por outro lado, o atraso também é um risco: por exemplo, você está mudando de um sistema CRM para outro e, durante o período de transição, é obrigado a pagar por ambos, aumentando assim os custos e o custo de implementação do novo sistema, que significa que o período de retorno é estendido.
- Número de funcionários: o Big Bang definitivamente não é adequado se você precisar dimensionar e configurar muitos perfis de usuário. Embora haja casos em que a implementação ultrarrápida é um benefício para uma grande empresa. Esta opção pode ser adequada para sistemas usados por muitos funcionários, mas pode não ter requisitos porque a personalização não é pretendida. Mas, novamente, isso é um grande sucesso para os usuários finais e um enorme trabalho passo a passo para o mesmo serviço de TI (por exemplo, sistema de faturamento ou acesso).
- Características de implementação do software selecionado (revisão, etc.). Às vezes, a implementação é inicialmente etapa por etapa – com coleta de requisitos, refinamento, treinamento, etc. Por exemplo, é sempre implementado de forma progressiva, e se alguém promete “implementação e configuração em 3 dias ou até 3 horas” - lembre-se deste artigo e ignore esses serviços: instalação ≠ implementação.
Novamente, mesmo conhecendo os parâmetros listados, não se pode seguir definitivamente um caminho ou outro. Avalie seu ambiente corporativo - isso ajudará você a entender o equilíbrio de poder e a determinar qual modelo (ou combinação de alguns de seus elementos) é certo para você.
Agentes de influência: revolução ou evolução
A primeira coisa que você deve prestar atenção são os funcionários que serão afetados pela implementação do novo software. Na verdade, o problema que estamos a considerar agora é um factor puramente humano, pelo que a análise do impacto nos colaboradores não pode ser evitada. Já mencionamos alguns deles acima.
- Os líderes da empresa determinam como o novo software será geralmente aceito. E aqui não é lugar para discursos promocionais e discursos inflamados – é importante mostrar exatamente a necessidade de mudança, passar a ideia de que isso é apenas escolher uma ferramenta mais bacana e conveniente, o mesmo que substituir um laptop antigo. O maior erro da gestão nessa situação é lavar as mãos e se retirar: se a gestão não precisa da automação da empresa, por que ela deveria interessar aos colaboradores? Esteja no processo.
- Os chefes de departamento (gerentes de projeto) são um elo intermediário que deve participar de todos os processos, gerenciar a insatisfação, mostrar vontade e superar todas as objeções dos colegas e realizar treinamentos aprofundados e de alta qualidade.
- Serviço de TI (ou administradores de sistema) - à primeira vista, estes são os primeiros, os mais adaptáveis e adaptáveis, mas... não. Muitas vezes, especialmente nas pequenas e médias empresas, os administradores de sistemas se opõem a qualquer mudança (fortalecimento) da infraestrutura de TI, e isso não se deve a nenhuma justificativa técnica, mas sim à preguiça e relutância em trabalhar. Quem entre nós não procurou maneiras de evitar o trabalho? Mas que isso não prejudique toda a empresa.
- Os usuários finais, via de regra, desejam trabalhar bem e convenientemente, por um lado, e, como qualquer pessoa viva, têm medo de mudanças. O principal argumento para eles é honesto e simples: por que estamos introduzindo/mudando, quais são os limites do controle, como o trabalho será avaliado, o que vai mudar e quais são os riscos (aliás, todos deveriam avaliar os riscos - mesmo sendo vendedores , mas não nos comprometemos a dizer que tudo corre sempre bem: há riscos em qualquer processo dentro de um negócio).
- As “autoridades” dentro da empresa são partidários que podem influenciar outros funcionários. Não se trata necessariamente de uma pessoa com alto cargo ou vasta experiência - no caso de trabalhar com software, a “autoridade” pode ser um sabe-tudo avançado que, por exemplo, releu Habr e começará a intimidar todos sobre como tudo vai ficar ruim. Ele pode até não ter como objetivo arruinar o processo de implementação ou transição – apenas exibicionismo e espírito de resistência – e os funcionários acreditarão nele. Você precisa trabalhar com esses funcionários: explicar, questionar e, em casos especialmente difíceis, sugerir as consequências.
Existe uma receita universal para verificar se os usuários estão realmente com medo de alguma coisa ou se têm paranóia de grupo liderada por um líder experiente. Pergunte-lhes sobre os motivos da insatisfação, sobre as preocupações - se esta não for uma experiência ou opinião pessoal, os argumentos começarão a surgir após 3-4 perguntas esclarecedoras.
Dois factores importantes para superar com sucesso o “movimento de resistência”.
- Fornecer treinamento: fornecedor e interno. Certifique-se de que os funcionários realmente entendem tudo, dominam e, independente do nível de formação, estão prontos para começar a trabalhar. Um atributo obrigatório do treinamento são as instruções impressas e eletrônicas (regulamentos) e a documentação mais completa do sistema (fornecedores que se prezam liberam junto com o software e fornecem gratuitamente).
- Procure apoiadores e escolha influenciadores. Especialistas internos e pioneiros são o seu sistema de apoio, tanto educando quanto dissipando dúvidas. Via de regra, os próprios funcionários ficam satisfeitos em ajudar seus colegas e apresentar-lhes novos softwares. Sua tarefa é aliviá-los temporariamente do trabalho ou dar-lhes um bônus decente pela nova carga de trabalho.
O que deve prestar atenção?
- Quão avançados estão os funcionários afetados pelas mudanças? (Relativamente falando, se amanhã eles inventarem um novo programa de contabilidade, Deus me livre de enfiar o nariz no departamento de contabilidade com mulheres com mais de 50 anos e sugerir uma transição de 1C, você não sairá vivo).
- Quanto os fluxos de trabalho serão afetados? Uma coisa é mudar o mensageiro numa empresa de 100 pessoas, outra coisa é implementar um novo sistema de CRM, que se baseia em processos-chave da empresa (e não se trata apenas de vendas, por exemplo, nas edições seniores afeta a produção, o armazém, o marketing e os gestores de topo que, juntamente com a equipa, construirão processos de negócio automatizados).
- Foi fornecido treinamento e em que nível?
A única transição lógica no sistema de pensamento corporativo
O que salvará a transição/implementação de novo software?
Antes de dizermos quais pontos-chave o ajudarão a migrar confortavelmente para um novo software, deixe-nos chamar sua atenção para um ponto. Há algo que definitivamente não deveria ser feito - não há necessidade de pressionar os funcionários e “motivá-los”, privando-os de bônus, sanções administrativas e disciplinares. Isso não melhorará o processo, mas piorará a atitude dos funcionários: se pressionarem, haverá controle; Se te forçarem, significa que não respeitam o nosso interesse; Se a imporem à força, significa que não confiam em nós e no nosso trabalho. Por isso, fazemos tudo de forma disciplinada, clara, competente, mas sem pressões ou forçamentos desnecessários.
Você deve ter um plano de ação detalhado
Todo o resto pode não existir, mas deve haver um plano. Além disso, o plano é ajustável, atualizado, claro e inevitável, ao mesmo tempo acessível para discussão e transparente para todos os colaboradores interessados. É impossível comunicar de forma diretiva que das 8h às 10h há uma façanha e às 16h há guerra com a Inglaterra; é importante ver todo o plano em perspectiva.
O plano deve necessariamente refletir as necessidades dos funcionários que serão usuários finais – desta forma cada funcionário saberá exatamente qual recurso desejado e em que horário poderá utilizá-lo. Ao mesmo tempo, o plano de transição ou implementação não é uma espécie de monólito imutável; é necessário deixar a possibilidade de finalizar o plano e alterar os seus atributos (mas não na forma de um fluxo interminável de edições e novos “desejos” e não na forma de mudança constante de prazos).
O que deveria estar no plano?
- Os principais marcos (etapas) da transição - o que precisa ser feito.
- Pontos de transição detalhados para cada etapa – como deve ser feito.
- Pontos-chave e relatórios sobre eles (conciliação de horas) - como será medido o que foi feito e quem deverá estar no ponto de controle.
- Pessoas responsáveis são pessoas a quem você pode recorrer e fazer perguntas.
- Os prazos são o início e o fim de cada etapa e de todo o processo como um todo.
- Processos afetados – quais mudanças ocorrerão nos processos de negócios, o que precisa ser alterado junto com a implementação/transição.
- A avaliação final é um conjunto de indicadores, métricas ou mesmo avaliações subjetivas que ajudarão a avaliar a implementação/transição ocorrida.
- O início da operação é a data exata em que toda a empresa aderirá ao processo automatizado atualizado e trabalhará no novo sistema.
Deparamo-nos com apresentações de implementadores em que a linha vermelha é o conselho: implementar à força, ignorar a reação, não falar com os funcionários. Somos contra esta abordagem e aqui está o porquê.
Olhe para a foto abaixo:
Um mouse novo, um teclado novo, um apartamento, um carro e até um trabalho são acontecimentos agradáveis e alegres, alguns deles até conquistas. E o usuário vai ao Yandex para saber como se acostumar e se adaptar. Como entrar em um apartamento novo e entender que ele é seu, abrir a torneira pela primeira vez, tomar chá, ir para a cama pela primeira vez. Como chegar ao volante e fazer amizade com um carro novo, seu, mas até agora tão estranho. O novo software no local de trabalho não é diferente das situações descritas: o trabalho do funcionário nunca mais será o mesmo. Portanto, implemente, adapte e cresça com novos softwares eficazes. E esta é uma situação sobre a qual podemos dizer: apresse-se devagar.
Fonte: habr.com