O salto do software converterase en breve nunha enfermidade moi común das empresas. Cambiar un software por outro por cada pequena cousa, pasar da tecnoloxía á tecnoloxía, experimentar cun negocio en directo estase a converter na norma. Ao mesmo tempo, comeza unha verdadeira guerra civil na oficina: fórmase un movemento de resistencia á implementación, os partidarios están a realizar un traballo subversivo contra o novo sistema, os espías están a promover un mundo novo e valente con software novo, a xestión desde o coche blindado de o portal corporativo está a transmitir sobre paz, traballo e KPI. Unha revolución adoita terminar nun fracaso total nun lado.
Sabemos case todo sobre a implementación, así que imos tentar descubrir como converter unha revolución nunha evolución e facer que a implementación sexa o máis útil e indolora posible. Ben, ou polo menos dirémosche en que podes meterse no proceso.
Visualización ideal da aceptación dos empregados do novo software Fonte: Yandex.Images
Os consultores estranxeiros comezarían este artigo algo así: "Se ofreces aos teus empregados software de calidade que pode mellorar o seu traballo, ter un impacto cualitativo no rendemento, a adopción dun novo programa ou sistema ocorrerá de forma natural". Pero estamos en Rusia, polo que o tema dos empregados sospeitosos e belixerantes é moi relevante. Unha transición natural non funcionará, mesmo cun software mínimo, como un mensaxeiro corporativo ou un softphone.
De onde veñen as patas do problema?
Hoxe en día, cada empresa ten todo un zoo de software instalado (tomamos o caso xeral, porque nas empresas informáticas a cantidade de software é o dobre ou o triplo, e os problemas de adaptación se solapan parcialmente e son moi específicos): sistemas de xestión de proxectos, CRM/ERP, clientes de correo electrónico, mensaxería instantánea, portal corporativo, etc. E isto sen contar que hai empresas nas que incluso a transición de navegador a navegador é realizada por todo o equipo sen excepción (e tamén hai equipos que están completamente baseados en Internet Explorer Edge). En xeral, hai varias situacións para as que o noso artigo pode ser útil:
- Existe un proceso de automatización primaria dalgún grupo de tarefas: estase a implantar o primeiro CRM/ERP, ábrese un portal corporativo, estase instalando un sistema de soporte técnico, etc.;
- un software substitúese por outro por algún motivo: obsolescencia, novos requisitos, escalado, cambio de actividade, etc.;
- están a construírse módulos do sistema existente con fins de desenvolvemento e crecemento (por exemplo, unha empresa abriu a produción e decidiu cambiar de en coa máxima funcionalidade);
- Estase a levar a cabo unha importante actualización de interface e software funcional.
Por suposto, os dous primeiros casos son moito máis agudos e típicos nas súas manifestacións, preste especial atención a eles.
Entón, antes de comezar a traballar co equipo (que xa sospeitaron que haberá cambios en breve), intente comprender cales son os motivos reais para cambiar o software e se acepta que os cambios son tan necesarios.
- O programa antigo é difícil de traballar: é caro, incómodo, non funciona, xa non responde aos teus requisitos, non é axeitado para a túa escala, etc. Esta é unha necesidade obxectiva.
- O vendedor deixou de apoiar o sistema, ou o soporte e as modificacións convertéronse nunha interminable serie de aprobacións e drenaxe de diñeiro. Se os teus custos aumentaron significativamente e no futuro prometen aumentar aínda máis, non hai nada que esperar, debes cortar. Si, un novo sistema tamén custará cartos, pero ao final a optimización custará menos que ese soporte.
- O cambio de software é o capricho dunha persoa ou dun grupo de empregados. Por exemplo, o CTO quere un retroceso e está presionando para que se introduza un sistema novo e máis caro, isto ocorre nas grandes empresas. Outro exemplo: un xestor de proxecto defende cambiar Asana por Basecamp, logo Basecamp por Jira e Jira complexo por Wrike. Moitas veces, o único motivo para tales migracións é mostrar o seu traballo ocupado e manter a súa posición. Nestes casos, é necesario determinar o grao de necesidade, motivos e xustificación e, por regra xeral, por unha decisión decidida de rexeitar os cambios.
Estamos a falar das razóns para a transición dun software a outro, e non da automatización primaria, só porque a automatización é a priori necesaria. Se a túa empresa fai algo manual e rutineiramente pero pode automatizarse, simplemente estás perdendo tempo, diñeiro e, moi probablemente, datos valiosos da empresa. Automatizalo!
Como podes cruzar: o gran salto ou o tigre agachado?
Na práctica mundial, hai tres estratexias principais para cambiar a un novo software e adaptarse a el, e parécennos moi adecuadas, así que non reinventemos a roda.
Big Bang
A adopción mediante o método "Big Bang" é a transición máis difícil posible, cando estableces unha data exacta e realizas unha migración brusca, desactivando o software antigo ao 100%.
Pros
+ Todos traballan nun só sistema, non é necesario sincronizar datos, os empregados non precisan supervisar dúas interfaces á vez.
+ Sinxeleza para o administrador: unha migración, unha tarefa, un soporte do sistema.
+ Todos os cambios posibles ocorren nun momento no tempo e son perceptibles case de inmediato: non hai que illar que e en que proporción afectou a produtividade, a velocidade de desenvolvemento, as vendas, etc.
Contra
— Funciona con éxito só con software sinxelo: chats, portal corporativo, mensaxería instantánea. Mesmo o correo electrónico xa pode fallar, sen esquecer os sistemas de xestión de proxectos, CRM/ERP e outros sistemas serios.
— Unha migración explosiva dun gran sistema a outro provocará inevitablemente o caos.
O máis importante para este tipo de transición a un novo ambiente de traballo é a formación.
Carreira paralela
A adaptación paralela ao software é un método de transición máis suave e universal, no que se establece un período de tempo durante o cal ambos os sistemas funcionarán simultáneamente.
Pros
+ Os usuarios teñen tempo suficiente para acostumarse ao novo software mentres traballan rapidamente no antigo, atopar paralelos e comprender a nova lóxica de interacción coa interface.
+ En caso de problemas repentinos, os empregados seguen traballando no sistema antigo.
+ A formación dos usuarios é menos rigorosa e xeralmente máis barata.
+ Non hai practicamente ningunha reacción negativa dos empregados; despois de todo, non foron privados das súas ferramentas ou forma de facer as cousas habituais (se a automatización ocorre por primeira vez).
Contra
— Problemas de administración: soporte para ambos sistemas, sincronización de datos, xestión da seguridade en dúas aplicacións á vez.
— O proceso de transición esténdese infinitamente: os empregados dan conta de que lles queda case unha eternidade e poden ampliar un pouco máis o uso da interface familiar.
- Confusión do usuario: as dúas interfaces son confusas e causan erros operativos e de datos.
- Diñeiro. Vostede paga polos dous sistemas.
Adopción por fases
A adaptación paso a paso é a opción máis suave para cambiar a un novo software. A transición realízase funcionalmente, dentro de períodos de tempo especificados e por departamento (por exemplo, a partir do 1 de xuño engadimos novos clientes só ao novo sistema CRM, a partir do 20 de xuño realizamos transaccións no novo sistema, ata o 1 de agosto transferimos calendarios). e casos, e para o 30 de setembro completamos a migración é unha descrición moi aproximada, pero en xeral clara).
Pros
+ Transición organizada, carga distribuída entre administradores e expertos internos.
+ Aprendizaxe máis reflexiva e profunda.
+ Non hai resistencia ao cambio, porque ocorre o máis suavemente posible.
Contra - aproximadamente o mesmo que para unha transición paralela.
Entón, agora, só unha transición gradual?
Unha pregunta lóxica, estarás de acordo. Por que tes problemas extra cando podes facer un horario e actuar segundo un plan claro? De feito, non todo é tan sinxelo.
- Complexidade do software: se falamos de software complexo (por exemplo, ), entón a adaptación de fase é máis adecuada. Se o software é sinxelo (mensaxería, portal corporativo), entón un modelo axeitado é cando anuncias a data e desactivas o software antigo o día sinalado (se tes sorte, os empregados terán tempo para sacar toda a información que necesitan). , e se non contas con sorte, entón tes que proporcionar os datos necesarios para a importación automatizada do sistema antigo ao novo, se é técnicamente posible).
- O grao de risco para a empresa: canto máis arriscada sexa a implantación, máis lenta debería ser. Por outra banda, o atraso tamén é un risco: por exemplo, estás cambiando dun sistema CRM a outro e durante o período de transición tes que pagar por ambos, aumentando así os custos e custos de implantación do novo sistema, que significa que se amplía o período de amortización.
- Número de empregados: Big Bang definitivamente non é axeitado se precisa escalar e configurar moitos perfís de usuario. Aínda que hai casos nos que a implementación ultrarrápida é un beneficio para unha gran empresa. Esta opción pode ser axeitada para sistemas que usan moitos empregados, pero pode non ter requisitos porque non se pretende personalizar. Pero de novo, este é un gran éxito para os usuarios finais e un gran traballo paso a paso para o mesmo servizo de TI (por exemplo, facturación ou sistema de acceso).
- Características da implementación do software seleccionado (revisión, etc.). Ás veces, a implementación é inicialmente paso a paso, con recollida de requisitos, perfeccionamento, formación, etc. Por exemplo, sempre se implementa de forma progresiva e se alguén che promete "implementación e configuración en 3 días ou mesmo en 3 horas" - lembre este artigo e evite tales servizos: instalación ≠ implementación.
De novo, aínda coñecendo os parámetros enumerados, non se pode tomar definitivamente un camiño ou outro. Avalía o teu entorno corporativo: isto axudarache a comprender o equilibrio de poder e a determinar que modelo (ou combinación dalgúns dos seus elementos) é o adecuado para ti.
Axentes de influencia: revolución ou evolución
O primeiro ao que debes prestar atención é aos empregados que se verán afectados pola implantación do novo software. En realidade, o problema que estamos considerando agora é un factor puramente humano, polo que non se pode evitar analizar o impacto nos empregados. Xa mencionamos algúns deles anteriormente.
- Os líderes da empresa determinan como se aceptará xeralmente o novo software. E este non é o lugar para discursos promocionais e discursos fogosos: é importante mostrar exactamente a necesidade de cambio, transmitir a idea de que só se trata de escoller unha ferramenta máis fría e cómoda, o mesmo que substituír un portátil antigo. O maior erro da dirección en tal situación é lavarse as mans e retirarse: se a dirección non precisa da automatización da empresa, por que debería interesarlle aos empregados? Estar no proceso.
- Os xefes de departamento (xestores de proxectos) son un elo intermedio que debe participar en todos os procesos, xestionar a insatisfacción, mostrar vontade e traballar con todas as obxeccións dos compañeiros e realizar unha formación de alta calidade e en profundidade.
- Servizo de TI (ou administradores de sistemas): a primeira vista, estes son os seus primeiros paxaros, os máis adaptables e adaptables, pero... non. Moitas veces, sobre todo nas pequenas e medianas empresas, os administradores de sistemas opóñense a calquera modificación (reforzo) da infraestrutura informática, e isto non se debe a ningunha xustificación técnica, senón á preguiza e á reticencia a traballar. Quen de nós non buscou formas de evitar traballar? Pero que isto non vaia en detrimento de toda a empresa.
- Os usuarios finais, por regra xeral, queren traballar ben e convenientemente por unha banda e, como calquera persoa viva, teñen medo ao cambio. O argumento principal para eles é honesto e sinxelo: por que estamos introducindo/cambiando, cales son os límites de control, como se avaliará o traballo, que cambiará e cales son os riscos (por certo, todos deberían avaliar os riscos - aínda que somos vendedores , pero non nos comprometemos a dicir que todo vai sempre ben: hai riscos en calquera proceso dentro dunha empresa).
- As "autoridades" dentro da empresa son partidarios que poden influír noutros empregados. Esta non é necesariamente unha persoa cun alto cargo ou unha ampla experiencia; no caso de traballar con software, a "autoridade" pode ser un experto que, por exemplo, volveu ler Habr e comezará a intimidar. todos sobre o mal que se vai facer todo. É posible que nin sequera teña o obxectivo de arruinar o proceso de implementación ou transición -só presumir e espírito de resistencia- e os empregados crerán nel. Debes traballar con estes empregados: explicar, cuestionar e, en casos especialmente difíciles, indicar as consecuencias.
Existe unha receita universal para comprobar se os usuarios teñen realmente medo a algo ou se teñen paranoia grupal dirixida por un líder intelixente. Pregúntalles sobre os motivos da insatisfacción, sobre as preocupacións; se esta non é unha experiencia ou opinión persoal, os argumentos comezarán a aparecer despois de 3-4 preguntas aclaratorias.
Dous factores importantes para superar con éxito o "movemento de resistencia".
- Impartir formación: provedor e interna. Asegúrate de que os empregados entendan todo, o dominan e, independentemente do seu nivel de formación, estean preparados para comezar a traballar. Un atributo obrigatorio da formación son as instrucións impresas e electrónicas (normativas) e a documentación máis completa do sistema (os provedores que se precexan publícana xunto co software e entrégano de balde).
- Busca seguidores e escolle influencers. Os expertos internos e os primeiros adoptantes son o teu sistema de apoio, tanto educando como disipando dúbidas. Como regra xeral, os propios empregados teñen o pracer de axudar aos seus compañeiros e presentarlles o novo software. A súa tarefa é liberalos temporalmente do seu traballo ou darlles unha bonificación decente pola súa nova carga de traballo.
En que debes prestar atención?
- Que avanzados están os empregados afectados polos cambios? (Relativamente falando, se mañá inventan un novo programa de contabilidade, Deus non che meta o nariz no departamento de contabilidade con mulleres de máis de 50 anos e propoñan unha transición de 1C, non sairás con vida).
- Canto se verán afectados os fluxos de traballo? Unha cousa é cambiar o messenger nunha empresa de 100 persoas, outra é implantar un novo sistema CRM, que se basee en procesos clave na empresa (e isto non só son vendas, por exemplo, nas edicións sénior afecta a produción, almacén, marketing e xestores superiores que, xunto co equipo, construirán procesos de negocio automatizados).
- Impartiuse formación e a que nivel?
A única transición lóxica no sistema de pensamento corporativo
Que aforrará a transición/implementación do novo software?
Antes de dicirche cales son os puntos clave que che axudarán a pasar cómodamente a un novo software, chamemos a túa atención sobre un punto. Hai algo que definitivamente non se debe facer: non hai que presionar aos empregados e "motivalos" privándoos de bonificacións, sancións administrativas e disciplinarias. Isto non mellorará o proceso, pero a actitude dos empregados empeorará: se presionan, entón haberá control; Se te obrigan, significa que non respectan o noso interese; Se o impoñen por forza, significa que non confían en nós e no noso traballo. Por iso, facemos todo de forma disciplinada, clara, competente, pero sen presións nin forzas innecesarias.
Debe ter un plan de acción detallado
Todo o demais pode non existir, pero debe haber un plan. Ademais, o plan é axustable, actualizado, claro e inevitable, á vez accesible para a discusión e transparente para todos os empregados interesados. É imposible comunicar de forma directiva que de 8:10 a 16:00 hai unha fazaña, e ás XNUMX:XNUMX hai guerra con Inglaterra; é importante ver todo o plan en perspectiva.
O plan debe reflectir necesariamente os requisitos dos empregados que serán usuarios finais; deste xeito, cada empregado saberá exactamente que función desexa e en que momento poderá utilizala. Ao mesmo tempo, o plan de transición ou implementación non é unha especie de monólito inmutable; é necesario deixar a posibilidade de finalizar o plan e cambiar os seus atributos (pero non en forma de fluxo interminable de edicións e novos "queres"). e non en forma de constante cambio de prazos).
Que debería estar no plan?
- Os principais fitos de transición (etapas) - o que hai que facer.
- Puntos de transición detallados para cada etapa: como se debe facer.
- Puntos clave e informes sobre eles (conciliación de horas): como se medirá o feito e quen debe estar no punto de control.
- As persoas responsables son persoas ás que podes acudir e facer preguntas.
- Os prazos son o inicio e o final de cada etapa e de todo o proceso no seu conxunto.
- Procesos afectados: que cambios ocorrerán nos procesos de negocio, que hai que cambiar xunto coa implementación/transición.
- A avaliación final é un conxunto de indicadores, métricas ou mesmo valoracións subxectivas que axudarán a avaliar a implantación/transición que se produciu.
- O inicio da operación é a data exacta na que toda a empresa se incorporará ao proceso automatizado actualizado e traballará no novo sistema.
Atopámonos con presentacións de implementadores nas que a liña vermella é o consello: aplicar á forza, ignorar a reacción, non falar cos empregados. Estamos en contra deste enfoque, e velaí por que.
Mira a imaxe de abaixo:
Un novo rato, un novo teclado, un apartamento, un coche e ata un traballo son eventos agradables e alegres, algúns deles incluso son logros. E o usuario acode a Yandex para descubrir como acostumarse e adaptarse. Como entrar nun apartamento novo e entender que é teu, abrir a billa por primeira vez, beber té, deitarse por primeira vez. Como poñerse ao volante e facer amizade cun coche novo, o teu, pero ata agora tan alleo. O novo software no lugar de traballo non é diferente das situacións descritas: o traballo do empregado nunca será o mesmo. Polo tanto, implementa, adapta, crece cun novo software eficaz. E esta é unha situación sobre a que podemos dicir: apurade lentamente.
Fonte: www.habr.com