Los empleados no quieren software nuevo: ¿deberían seguir el ejemplo o ceñirse a su línea?

El salto del software pronto se convertirá en una enfermedad muy común entre las empresas. Cambiar un software por otro por cada pequeña cosa, saltar de tecnología en tecnología, experimentar con un negocio vivo se está convirtiendo en la norma. Al mismo tiempo, comienza una verdadera guerra civil en la oficina: se forma un movimiento de resistencia a la implementación, los partisanos realizan un trabajo subversivo contra el nuevo sistema, los espías promueven un mundo feliz con nuevo software, la gestión desde el vehículo blindado de el portal corporativo transmite sobre paz, trabajo, KPI. Una revolución suele terminar con el fracaso total de un lado.

Sabemos casi todo sobre la implementación, así que intentemos descubrir cómo convertir una revolución en una evolución y hacer que la implementación sea lo más útil e indolora posible. Bueno, o al menos te diremos en qué te puedes meter en el proceso.

Visualización ideal de la aceptación por parte de los empleados del nuevo software Fuente - Yandex.Images

Los consultores extranjeros comenzarían este artículo así: "Si ofrece a sus empleados un software de calidad que puede mejorar su trabajo y tener un impacto cualitativo en el desempeño, la adopción de un nuevo programa o sistema se producirá de forma natural". Pero estamos en Rusia, por lo que la cuestión de los empleados sospechosos y beligerantes es muy relevante. Una transición natural no funcionará, ni siquiera con un software mínimo, como un mensajero corporativo o un softphone.

¿De dónde vienen las patas del problema?

Hoy en día, cada empresa tiene instalado todo un zoo de software (tomamos el caso general, porque en las empresas TI la cantidad de software es el doble o el triple, y los problemas de adaptación se superponen parcialmente y son muy específicos): sistemas de gestión de proyectos, CRM/ERP, clientes de correo electrónico, mensajería instantánea, portal corporativo, etc. Y esto sin contar que hay empresas en las que incluso el paso de un navegador a otro lo realiza todo el equipo sin excepción (y también hay equipos que se basan íntegramente en Internet Explorer Edge). En general, existen varias situaciones para las que nuestro artículo puede resultar útil:

• Hay un proceso de automatización primaria de algún grupo de tareas: se está implementando el primer CRM/ERP, se está abriendo un portal corporativo, se está instalando un sistema de soporte técnico, etc.;
• un software es sustituido por otro por algún motivo: obsolescencia, nuevos requisitos, escalamiento, cambio de actividad, etc.;
• Los módulos del sistema existente se están construyendo con fines de desarrollo y crecimiento (por ejemplo, una empresa abrió la producción y decidió cambiar de RegionSoft CRM Profesional en RegionSoft CRM Enterprise Plus con máxima funcionalidad);
• Se está llevando a cabo una importante actualización de interfaz y software funcional.

Por supuesto, los dos primeros casos son mucho más agudos y típicos en sus manifestaciones, prestándoles especial atención.

Entonces, antes de comenzar a trabajar con el equipo (que ya sospecha que habrá cambios pronto), intente comprender cuáles son las verdaderas razones para cambiar el software y si está de acuerdo en que los cambios son tan necesarios.

• Es difícil trabajar con el programa antiguo: es caro, inconveniente, no funcional, ya no cumple con sus requisitos, no es adecuado para su báscula, etc. Ésta es una necesidad objetiva.
• El proveedor dejó de brindar soporte al sistema, o el soporte y las modificaciones se convirtieron en una serie interminable de aprobaciones y pérdidas de dinero. Si sus costos han aumentado significativamente y en el futuro prometen aumentar aún más, no hay nada que esperar, debe recortar. Sí, un nuevo sistema también costará dinero, pero al final la optimización costará menos que dicho soporte.
• Cambiar de software es el capricho de una persona o grupo de empleados. Por ejemplo, la CTO quiere una reversión y está presionando para que se introduzca un sistema nuevo y más caro; esto sucede en las grandes empresas. Otro ejemplo: un director de proyecto aboga por cambiar Asana por Basecamp, luego Basecamp por Jira y el complejo Jira por Wrike. A menudo, el único motivo de estas migraciones es mostrar su ajetreado trabajo y conservar su puesto. En tales casos, es necesario determinar el grado de necesidad, los motivos y la justificación y, por regla general, rechazar los cambios con una decisión decidida.

Estamos hablando de las razones de la transición de un software a otro, y no de la automatización primaria, solo porque la automatización es a priori necesaria. Si su empresa hace algo de forma manual y rutinaria pero podría automatizarse, simplemente está perdiendo tiempo, dinero y, muy probablemente, datos valiosos de la empresa. ¡Automatízalo!

¿Cómo se puede cruzar: el gran salto o el tigre agazapado?

En la práctica mundial, existen tres estrategias principales para cambiar a un nuevo software y adaptarse a él, y nos parecen muy adecuadas, así que no reinventemos la rueda.

Big Bang

La adopción mediante el método “Big Bang” es la transición más difícil posible, cuando se fija una fecha exacta y se realiza una migración brusca, desactivando el software antiguo al 100%.

Pros

+ Todos trabajan en un sistema, no es necesario sincronizar datos, los empleados no necesitan monitorear dos interfaces a la vez.
+ Simplicidad para el administrador: una migración, una tarea, un soporte del sistema.
+ Todos los cambios posibles ocurren en un momento dado y se notan casi de inmediato; no es necesario aislar qué y en qué proporción afectó la productividad, la velocidad de desarrollo, las ventas, etc.

Contras

— Funciona con éxito sólo con software sencillo: chats, portal corporativo, mensajería instantánea. Incluso el correo electrónico ya puede fallar, por no hablar de los sistemas de gestión de proyectos, CRM/ERP y otros sistemas serios.
— Una migración “explosiva” de un sistema grande a otro inevitablemente causará caos.

Lo más importante para este tipo de transición a un nuevo entorno laboral es la formación.

Carrera paralela

La adaptación paralela al software es un método de transición más suave y universal, en el que se establece un período de tiempo durante el cual ambos sistemas funcionarán simultáneamente.

Pros

+ Los usuarios tienen tiempo suficiente para acostumbrarse al nuevo software mientras trabajan rápidamente en el antiguo, encuentran paralelos y comprenden la nueva lógica de interacción con la interfaz.
+ En caso de problemas repentinos, los empleados continúan trabajando en el sistema antiguo.
+ La formación de los usuarios es menos rigurosa y generalmente más económica.
+ Prácticamente no hay reacciones negativas por parte de los empleados; después de todo, no se les privó de sus herramientas ni de su forma de hacer las cosas habituales (si se produce la automatización por primera vez).

Contras

— Problemas de administración: soporte para ambos sistemas, sincronización de datos, gestión de seguridad en dos aplicaciones a la vez.
— El proceso de transición se prolonga infinitamente: los empleados se dan cuenta de que les queda casi una eternidad y pueden ampliar un poco más el uso de la interfaz familiar.
- Confusión del usuario: las dos interfaces son confusas y provocan errores operativos y de datos.
- Dinero. Pagas por ambos sistemas.

Adopción por fases

La adaptación paso a paso es la opción más sencilla para cambiar a un nuevo software. La transición se realiza funcionalmente, dentro de períodos de tiempo específicos y por departamento (por ejemplo, desde el 1 de junio agregamos nuevos clientes solo al nuevo sistema CRM, desde el 20 de junio realizamos transacciones en el nuevo sistema, hasta el 1 de agosto transferimos calendarios y casos, y para el 30 de septiembre completaremos la migración (una descripción muy aproximada, pero en general clara).

Pros

+ Transición organizada, carga distribuida entre administradores y expertos internos.
+ Aprendizaje más reflexivo y profundo.
+ No hay resistencia al cambio, porque se produce de la forma más suave posible.

Contras - aproximadamente lo mismo que para una transición paralela.

Entonces, ¿solo una transición gradual?

Una pregunta lógica, estarás de acuerdo. ¿Por qué tener más problemas cuando puedes establecer un cronograma y actuar de acuerdo con un plan claro? De hecho, no todo es tan sencillo.

• Complejidad del software: si hablamos de software complejo (por ejemplo, sistema CRM), entonces la adaptación de fase es más adecuada. Si el software es simple (messenger, portal corporativo), entonces un modelo adecuado es anunciar la fecha y desactivar el software antiguo el día señalado (si tiene suerte, los empleados tendrán tiempo de obtener toda la información que necesitan). , y si no cuenta con la suerte, entonces debe proporcionar la importación automática de los datos necesarios del sistema antiguo al nuevo, si es técnicamente posible).
• El grado de riesgo para la empresa: cuanto más riesgosa sea la implementación, más lenta debería ser. Por otro lado, el retraso también es un riesgo: por ejemplo, estás cambiando de un sistema CRM a otro y durante el período de transición te ves obligado a pagar por ambos, lo que aumenta los costos y el costo de implementar el nuevo sistema, que significa que el período de recuperación se extiende.
• Número de empleados: Big Bang definitivamente no es adecuado si necesita escalar y configurar muchos perfiles de usuario. Aunque hay casos en los que la implementación ultrarrápida supone un beneficio para una gran empresa. Esta opción puede ser adecuada para sistemas que utilizan muchos empleados, pero que pueden no tener requisitos porque no está prevista la personalización. Pero nuevamente, esto es una gran explosión para los usuarios finales y un enorme trabajo paso a paso para el mismo servicio de TI (por ejemplo, sistema de facturación o acceso).
• Características de la implementación del software seleccionado (revisión, etc.). A veces, la implementación se realiza inicialmente etapa por etapa: con recopilación de requisitos, refinamiento, capacitación, etc. Por ejemplo, sistema CRM siempre se implementa de forma progresiva, y si alguien le promete "implementación y configuración en 3 días o incluso 3 horas", recuerde este artículo y evite dichos servicios: instalación ≠ implementación.

Nuevamente, incluso conociendo los parámetros enumerados, no se puede tomar definitivamente un camino u otro. Evalúe su entorno corporativo: esto le ayudará a comprender el equilibrio de poder y a determinar qué modelo (o combinación de algunos de sus elementos) es el adecuado para usted.

Agentes de influencia: revolución o evolución

Lo primero a lo que debes prestar atención son los empleados que se verán afectados por la implementación del nuevo software. En realidad, el problema que estamos considerando ahora es un factor puramente humano, por lo que no se puede evitar analizar el impacto en los empleados. Ya hemos mencionado algunos de ellos anteriormente.

• Los líderes de la empresa determinan cómo será generalmente aceptado el nuevo software. Y este no es el lugar para discursos promocionales y discursos ardientes: es importante mostrar exactamente la necesidad de cambio, transmitir la idea de que se trata simplemente de elegir una herramienta más fresca y conveniente, lo mismo que reemplazar una computadora portátil vieja. El mayor error de la dirección en una situación así es lavarse las manos y retirarse: si la dirección no necesita la automatización de la empresa, ¿por qué debería interesarle a los empleados? Estar en el proceso.
• Los jefes de departamento (directores de proyectos) son un eslabón intermedio que debe participar en todos los procesos, gestionar la insatisfacción, mostrar voluntad y superar cada objeción de los compañeros y realizar una formación profunda y de alta calidad.
• Servicio de TI (o administradores de sistemas): a primera vista, estos son los primeros, los más adaptables y adaptables, pero... no. A menudo, especialmente en las pequeñas y medianas empresas, los administradores de sistemas se oponen a cualquier cambio (reforzamiento) de la infraestructura de TI, y esto no se debe a ninguna justificación técnica, sino a la pereza y la desgana para trabajar. ¿Quién de nosotros no ha buscado formas de evitar trabajar? Pero que esto no vaya en detrimento de toda la empresa.
• Los usuarios finales, por un lado, suelen querer trabajar bien y cómodamente y, como cualquier persona viva, tienen miedo al cambio. El argumento principal para ellos es honesto y simple: por qué estamos introduciendo/cambiando, cuáles son los límites de control, cómo se evaluará el trabajo, qué cambiará y cuáles son los riesgos (por cierto, todos deberían evaluar los riesgos). aunque seamos vendedores Sistemas CRM, pero no pretendemos decir que todo va siempre sobre ruedas: hay riesgos en cualquier proceso dentro de un negocio).
• Las “autoridades” dentro de la empresa son partidistas que pueden influir en otros empleados. No se trata necesariamente de una persona con un puesto alto o una amplia experiencia; en el caso de trabajar con software, la "autoridad" puede ser un sabelotodo avanzado que, por ejemplo, ha releído a Habr y comenzará a intimidar. a todos sobre lo mal que se pondrá todo. Puede que ni siquiera tenga el objetivo de arruinar el proceso de implementación o transición, sino simplemente el alarde y el espíritu de resistencia, y los empleados le creerán. Es necesario trabajar con estos empleados: explicar, preguntar y, en casos especialmente difíciles, insinuar las consecuencias.

Existe una receta universal para comprobar si los usuarios realmente tienen miedo de algo o si tienen paranoia grupal dirigida por un líder inteligente. Pregúnteles sobre los motivos de la insatisfacción, sobre las preocupaciones; si no se trata de una experiencia u opinión personal, las discusiones comenzarán a llegar después de 3 o 4 preguntas aclaratorias.

Dos factores importantes para superar con éxito el “movimiento de resistencia”.

1. Proporcionar capacitación: proveedor e interna. Asegúrate de que los empleados realmente entiendan todo, lo dominen y, independientemente de su nivel de formación, estén preparados para empezar a trabajar. Un atributo obligatorio de la formación son las instrucciones impresas y electrónicas (reglamentos) y la documentación más completa sobre el sistema (los proveedores que se precian la publican junto con el software y la proporcionan de forma gratuita).
2. Busque seguidores y elija personas influyentes. Los expertos internos y los primeros usuarios son su sistema de apoyo, tanto para educar como para disipar dudas. Por regla general, los propios empleados están encantados de ayudar a sus compañeros y presentarles el nuevo software. Tu tarea es relevarlos temporalmente de su trabajo o darles una bonificación decente por su nueva carga de trabajo.

Lo que debería prestar atención?

1. ¿Qué tan avanzados están los empleados afectados por los cambios? (Relativamente hablando, si mañana inventan un nuevo programa de contabilidad, Dios no permita que metas la nariz en el departamento de contabilidad con mujeres mayores de 50 años y sugiera una transición de 1C, no saldrás con vida).
2. ¿Cuánto se verán afectados los flujos de trabajo? Una cosa es cambiar el messenger en una empresa de 100 personas, otra cosa es implementar un nuevo sistema CRM, que se base en procesos clave de la empresa (y esto no es solo ventas, por ejemplo, implementación de RegionSoft CRM en ediciones senior afecta a producción, almacén, marketing y altos directivos que, junto con el equipo, construirán procesos de negocio automatizados).
3. ¿Se proporcionó capacitación y a qué nivel?

La única transición lógica en el sistema de pensamiento corporativo.

¿Qué salvará la transición/implementación de nuevo software?

Antes de decirle qué puntos clave le ayudarán a pasar cómodamente al nuevo software, permítanos llamar su atención sobre un punto. Hay algo que definitivamente no se debe hacer: no es necesario presionar a los empleados y "motivarlos" privándolos de bonificaciones y sanciones administrativas y disciplinarias. Esto no mejorará el proceso, pero sí empeorará la actitud de los empleados: si presionan, habrá control; Si te obligan es que no respetan nuestros intereses; Si lo imponen por la fuerza, significa que no confían en nosotros ni en nuestro trabajo. Por eso, hacemos todo de manera disciplinada, clara y competente, pero sin presiones ni forzamientos innecesarios.

Debes tener un plan de acción detallado.

Puede que todo lo demás no exista, pero debe haber un plan. Además, el plan es adaptable, actualizado, claro e inevitable, al mismo tiempo accesible para el debate y transparente para todos los empleados interesados. Es imposible comunicar directamente que de 8 a 10 hay una hazaña y a las 16:00 hay guerra con Inglaterra; es importante ver todo el plan en perspectiva.

El plan debe reflejar necesariamente los requisitos de los empleados que serán usuarios finales; de esta forma, cada empleado sabrá exactamente qué función desea y en qué momento podrá utilizarla. Al mismo tiempo, el plan de transición o implementación no es una especie de monolito inmutable; es necesario dejar la posibilidad de finalizar el plan y cambiar sus atributos (pero no en forma de un flujo interminable de ediciones y nuevos "deseos" y no en forma de un cambio constante en los plazos).  

¿Qué debería estar en el plan?

1. Los principales hitos (etapas) de la transición: lo que hay que hacer.
2. Puntos de transición detallados para cada etapa: cómo se debe hacer.
3. Puntos clave e informes sobre ellos (conciliación de horas): cómo se medirá lo que se ha hecho y quién debe estar en el punto de control.
4. Las personas responsables son personas a las que puedes acudir y hacerles preguntas.
5. Los plazos son el inicio y el final de cada etapa y de todo el proceso en su conjunto.
6. Procesos afectados: qué cambios se producirán en los procesos de negocio, qué debe cambiarse junto con la implementación/transición.
7. La evaluación final es un conjunto de indicadores, métricas o incluso valoraciones subjetivas que ayudarán a evaluar la implementación/transición que se ha producido.
8. El inicio de operación es la fecha exacta en la que toda la empresa se unirá al proceso automatizado actualizado y trabajará en el nuevo sistema.

Nos hemos topado con presentaciones de implementadores en las que la línea roja es el consejo: implementar por la fuerza, ignorar la reacción, no hablar con los empleados. Estamos en contra de este enfoque y he aquí por qué.

Mira la foto de abajo:

Un ratón nuevo, un teclado nuevo, un apartamento, un coche e incluso un trabajo son acontecimientos agradables y alegres, algunos de ellos incluso logros. Y el usuario acude a Yandex para saber cómo acostumbrarse y adaptarse. Cómo entrar en un nuevo apartamento y entender que es tuyo, abrir el grifo por primera vez, tomar té, acostarte por primera vez. Cómo ponerse al volante y hacerse amigo de un coche nuevo, suyo, pero hasta ahora tan ajeno. El nuevo software en el lugar de trabajo no es diferente de las situaciones descritas: el trabajo del empleado nunca volverá a ser el mismo. Por lo tanto, implemente, adapte y crezca con nuevo software eficaz. Y esta es una situación sobre la que podemos decir: apúrate poco a poco.

Fuente: habr.com