Cómo llevar a cabo una transformación de entre 3 y 6 meses sin agotar a su equipo operativo
Una guía práctica sobre la gestión del cambio y la transformación digital dirigida a los proveedores de servicios B2B de la región DACH que llevan a cabo una implantación de sistemas informáticos sin interrumpir el funcionamiento habitual de la empresa
Índice
La mayoría de las guías de gestión del cambio para la transformación digital están pensadas para grandes empresas: equipos de RR. HH. dedicados al cambio, gestores del cambio certificados y presupuesto para programas de adopción estructurados. Una empresa mediana de servicios B2B funciona de otra manera. En una empresa de este tamaño, las pocas personas que comprenden el proceso operativo fundamental suelen ser las mismas que se encargan de mantenerlo en marcha cada día. Pedirles que diseñen el nuevo sistema y que, al mismo tiempo, asuman toda su carga de trabajo es la principal dificultad, y la mayoría de las guías nunca abordan este tema.
Esa es la tensión estructural que subyace a toda transformación operativa en el rango de facturación de entre 10 y 50 millones de euros. Para las pymes de este tamaño, el problema de la gestión del cambio no radica en la resistencia cultural ni en cuestiones de liderazgo. Se trata de un problema de planificación de la carga de trabajo. El equipo no puede detener la actividad para implantar el nuevo sistema, y el sistema no puede implantarse sin el equipo. (El motivo por el que los equipos internos a menudo no pueden desarrollar por sí solos un sistema operativo central es una cuestión aparte que tratamos en la guía «Desarrollo interno frente a agencia»). Las siguientes páginas describen cómo una implementación bien estructurada resuelve esta contradicción en la práctica.
Por qué los equipos de operaciones se agotan más rápido que otros departamentos durante la implantación de un sistema informático
Todas las funciones sufren interrupciones durante una transformación digital. Los equipos operativos se enfrentan a una combinación específica de exigencias que hace que el agotamiento sea más probable que en otros ámbitos, por dos razones estructurales.
En primer lugar: las empresas de este tamaño, con un enfoque operativo, rara vez disponen de margen de maniobra en sus procesos básicos. Trabajan de forma deliberadamente ágil, con poca redundancia de personal en las funciones que mantienen en marcha la actividad diaria, por lo que no hay reservas para asumir un proyecto de varios meses además del trabajo habitual. El contexto general agrava aún más la situación. La encuesta «Gartner Workforce Change Survey» reveló que, en 2022, un empleado medio experimentó unas diez transformaciones organizativas planificadas, frente a las dos de 2016, mientras que la disposición a aceptar los cambios se redujo en ese mismo periodo del 74 % al 43 %. Una transformación no se produce en un equipo descansado, sino en uno que ya está gestionando más cambios de los que ha tenido que afrontar en años. Harvard Business Review
En segundo lugar: los empleados operativos son precisamente las personas cuyos conocimientos son más necesarios durante la implementación. Quienes comprenden cómo funcionan realmente las excepciones de precios, qué acuerdos con los clientes anulan el proceso estándar y por qué determinados pedidos se tramitan manualmente en lugar de a través del sistema, son al mismo tiempo la aportación más valiosa para el nuevo diseño y el eslabón más insustituible que mantiene en marcha el proceso actual. Desempeñar ambos roles a la vez es el camino más rápido hacia el agotamiento y una causa frecuente de fracaso en la implementación en empresas de este tamaño.
Las tres decisiones que determinan si el equipo está agotado
Antes de programar el primer taller o escribir una sola línea de código, la dirección debe tomar tres decisiones de forma explícita. No se trata de decisiones relacionadas con los procesos, sino de compromisos estructurales que marcan todo lo que viene a continuación.
Decisión 1: Un responsable interno, no un comité. Toda transformación requiere un único responsable interno, identificado por su nombre, por parte del cliente: ni un comité directivo, ni un grupo de proyecto, ni el equipo operativo en su conjunto. Una persona que sea el principal punto de contacto para el socio encargado de la implementación, que participe en la reunión semanal de coordinación, que apruebe las decisiones de diseño y que sea responsable de la aceptación interna. La responsabilidad compartida convierte cada decisión en una tarea de coordinación y absorbe mucho más tiempo del equipo del necesario.
Decisión 2: El tiempo de esta persona debe protegerse formalmente. Nombrar a una persona responsable a nivel interno y, al mismo tiempo, dejar que siga asumiendo toda su carga operativa no es una solución. La dirección debe retirar tareas concretas de su ámbito de trabajo durante el periodo de implementación, y hacerlo de forma visible, para que el equipo perciba que la empresa está realizando un verdadero ajuste para el proyecto y no está aumentando silenciosamente la carga de trabajo de alguien.
Decisión 3: Las pruebas se realizan con pedidos reales, no con escenarios ficticios. El enfoque habitual consiste en crear casos de prueba hipotéticos y ejecutar el sistema con ellos. Esto genera resultados que inspiran confianza, pero que fallan ante la primera excepción real. Las pruebas deben utilizar tipos de pedidos reales del funcionamiento diario, incluidas las excepciones que se producen entre dos y tres veces al mes. Antes de comenzar las pruebas, la persona responsable interna define entre cinco y diez tipos de pedidos: casos estándar y las excepciones más frecuentes. Se trata de una tarea de dos horas que evita semanas de gestión de crisis tras la puesta en marcha.
Cómo organizar los 3 a 6 meses: qué hace el equipo operativo y cuándo
El patrón más perjudicial en una transformación digital es involucrar por completo al equipo operativo durante todo el periodo de implementación. Cuando llega la fecha de puesta en marcha, el equipo ya está agotado antes de que comience la parte más difícil. La alternativa es una participación por fases: intensa al principio, cuando se recopila la información; moderada durante la fase de desarrollo; y de nuevo intensa durante las pruebas.
| Fase | Período | Participación del equipo de trabajo |
|---|---|---|
| Auditoría estratégica y diseño de procesos | Semanas 1 a 4 | Solo aportaciones. El socio lleva la iniciativa. El equipo facilita el acceso y responde a las preguntas. No se asume ninguna responsabilidad por el resultado. |
| Fase de compilación | Semanas 5 a 14 | Un responsable interno. Reunión semanal de una hora. Sin comités. Sin reuniones con todo el equipo. |
| Pruebas paralelas con pedidos reales | Semanas 15 a 18 | De duración limitada. De 2 a 4 horas por semana por evaluador. Escenarios estructurados basados en tipos de encargos reales. |
| Puesta en marcha por fases | A partir de la semana 19 | Un proceso tras otro. Una transición difícil con un plan de contingencia. Sin funcionamiento paralelo permanente. |
| Estabilización tras la puesta en marcha | Semanas 20 a 28 | El equipo es el único responsable del sistema. Se puede contactar con los socios en caso de problemas. No habrá nuevas funciones durante al menos 6 semanas. |
El principio fundamental: la participación del equipo operativo debe ser máxima al principio, cuando sus conocimientos se incorporan al diseño, y de nuevo durante la fase de pruebas. Durante la propia fase de desarrollo, la participación debe ser mínima y de duración limitada. Las personas encargadas de mantener el funcionamiento del sistema no deberían tener, en esta fase, ninguna obligación relacionada con el proyecto que vaya más allá de la reunión semanal de coordinación de los responsables internos.
La trampa del trabajo simultáneo: la causa más frecuente del agotamiento
La decisión más habitual que convierte una implantación manejable en un proceso agotador es la siguiente: «Vamos a utilizar ambos sistemas en paralelo hasta que confiemos en el nuevo». Esto parece prudente. En la práctica de los sistemas ERP, es el modelo de transición que más recursos consume, y la carga que conlleva está bien documentada: el funcionamiento simultáneo de ambos sistemas implica una doble introducción de datos y el consiguiente agotamiento de los empleados. Xserpconsulting
En la práctica, esto significa que el equipo procesa cada pedido dos veces. El responsable de planificación con experiencia introduce un pedido en el sistema antiguo, porque confía en él, y luego lo vuelve a introducir en el nuevo, porque se le ha pedido que lo haga. Quienes se encargan de elaborar los presupuestos introducen primero los datos en la hoja de cálculo y, a continuación, los vuelven a introducir en el nuevo sistema. En el plazo de dos semanas, el funcionamiento en paralelo ha duplicado efectivamente la carga de trabajo de las personas que, de por sí, ya son las que más trabajo asumen.
Tomemos un caso típico. Un proveedor de servicios B2B gestiona en paralelo su antiguo proceso de elaboración de ofertas y un nuevo sistema de ofertas durante varias semanas tras la puesta en marcha, «hasta que todos se sientan seguros». La responsable de planificación con más experiencia, que ya de por sí es la persona con mayor carga de trabajo del equipo, ahora tiene que hacer el doble de trabajo. Bajo esta carga, el riesgo real no es un fallo del sistema, sino una baja, y los conocimientos que se pierden con esa persona son precisamente la base sobre la que se sustentaba el proyecto. No se trata de un escenario lejano: La experiencia con los sistemas ERP señala una y otra vez que la duplicación de datos, el agotamiento de los empleados y la pérdida de una persona clave en pleno proyecto son patrones típicos de fracaso en las operaciones paralelas prolongadas, por lo que los enfoques por fases acortan deliberadamente el periodo de tiempo durante el cual una sola persona se ve sobrecargada. XserpconsultingTechTarget
La alternativa es una transición radical con un plan de contingencia específico. El día de la puesta en marcha, el nuevo sistema estará operativo. Si no puede gestionar un tipo concreto de pedido, solo ese tipo de pedido volverá provisionalmente al proceso anterior; el problema se registra y se soluciona, y todo lo demás permanece en producción. Supongamos que, el primer día, el nuevo sistema aún no puede gestionar un único caso especial. Ese tipo concreto se tramita mediante el proceso antiguo durante uno o dos días, se soluciona el problema y el resto de las operaciones nunca vuelve al proceso anterior. En lugar de semanas de funcionamiento en paralelo con todos los pedidos, se dedica uno o dos días a gestionar la excepción de un único caso. Este enfoque supone una mayor carga durante las primeras 72 horas, pero es considerablemente menor en las semanas siguientes.
Cómo saber, antes de empezar, si tu equipo es capaz de llevar a cabo la transformación
Antes de fijar una fecha para el primer taller, comprueba tres indicadores. Estos te indicarán si el equipo es capaz de asumir esa carga adicional o si primero debes crear capacidad.
En primer lugar: ¿Existe una sustitución documentada para el puesto clave en el proceso, que suele ser el de planificación o gestión de ofertas? Si el proceso solo existe en la mente de una única persona, esta se ve doblemente limitada durante la ejecución, y el proyecto se ve comprometido desde el principio.
En segundo lugar: ¿Esta persona ya trabaja habitualmente más allá de su jornada laboral habitual? Un equipo sin margen de maniobra no puede asumir tareas adicionales de recopilación de conocimientos y pruebas sin que disminuya la calidad del funcionamiento diario.
En tercer lugar: ¿se resuelven hoy en día las excepciones, los precios especiales y los acuerdos con los clientes basándose en la intuición y la experiencia, en lugar de en una norma documentada? Es precisamente este conocimiento el que debe incorporar el nuevo sistema, y son precisamente estas personas a las que resulta más difícil liberar de sus tareas habituales.
Si los tres indican una sobrecarga, el primer paso no es iniciar el proyecto, sino aliviar la carga de trabajo de los responsables internos. En la práctica, esto significa designar a un sustituto que se haga cargo de las tareas rutinarias del responsable durante la duración del proyecto, como la planificación diaria o la aprobación de ofertas, no de forma permanente, sino durante el periodo de ejecución. Esta redistribución supone un coste de capacidad a corto plazo y, precisamente por eso, es una decisión que debe tomar la dirección y no el equipo. Solo entonces comienza la transformación.
Qué hacer ahora
Si tiene previsto llevar a cabo una transformación operativa sin interrumpir el funcionamiento habitual, lo primero que debe hacer es tomar tres decisiones: designar a un responsable interno concreto, asignarle un tiempo protegido formalmente y realizar pruebas con encargos reales en lugar de con escenarios ficticios. Organice la participación del equipo operativo de tal forma que sea máxima al principio y durante la fase de pruebas, y mínima durante la fase de implementación. Y evite la trampa del funcionamiento en paralelo: una transición radical con un plan de contingencia claro supone una mayor carga para el equipo durante las primeras 72 horas, pero una carga considerablemente menor en las semanas siguientes.
Si la inversión resulta rentable o no es una cuestión aparte, y debe abordarse antes de la implementación, no durante la misma. En la guía sobre el retorno de la inversión (ROI) del software a medida explicamos cómo elaborar un caso de inversión sólido a partir de sus propios datos operativos, antes de que un socio escriba una sola línea de código.
Si desea tener esta claridad antes de empezar: la auditoría estratégica appleute analiza su proceso operativo, identifica dónde se concentran los costes y proporciona una cifra de los costes en la situación actual, además de una delimitación del alcance y una estimación de la amortización. Se trata de un proyecto independiente a precio fijo que le proporcionará un documento que podrá presentar con total confianza a su director financiero o a la dirección de su empresa. Si las cifras no respaldan la inversión, también se lo diremos.
Concierte una consulta gratuita y sin compromiso con nuestro equipo.
Concierte una consulta gratuita y sin compromiso con nuestro equipo.
ES 
DE 
EN 
FR