Implantar un sistema es mucho más que instalar software

Recuerdo que, durante muchos años, una de las preguntas más frecuentes que escuchaba al hablar de un nuevo sistema empresarial era cuánto tiempo tomaría instalarlo.

Era una pregunta perfectamente comprensible. Después de todo, cuando una empresa adquiere una herramienta tecnológica, quiere saber cuándo podrá comenzar a utilizarla.

Sin embargo, con el paso del tiempo he llegado a considerar que hay una pregunta mucho más importante:

¿Cuánto tiempo tomará conseguir que la empresa trabaje mejor gracias a ese sistema?

La diferencia entre ambas preguntas puede parecer sutil, pero es enorme.

Instalar un programa, configurar sus parámetros, registrar usuarios y comenzar a capturar operaciones son actividades necesarias. Algunas pueden ser relativamente sencillas; otras, bastante complejas.

Pero ninguna de ellas, por sí sola, garantiza que la empresa vaya a obtener los beneficios que esperaba.

Porque una cosa es conseguir que un sistema funcione y otra muy distinta es conseguir que una organización funcione mejor con él.

La puesta en marcha no es la meta

En los proyectos tecnológicos solemos establecer fechas importantes.

La entrega del sistema. La capacitación de los usuarios. La migración de información. El inicio de operaciones.

Todas son necesarias para organizar el trabajo y evaluar su avance.

El problema aparece cuando confundimos alguna de esas fechas con la conclusión del proyecto.

Imaginemos que una empresa comienza a utilizar su nuevo sistema el lunes por la mañana.

Los usuarios pueden ingresar, las operaciones se registran correctamente y los documentos se generan sin inconvenientes.

Desde el punto de vista técnico, podríamos decir que la puesta en marcha fue exitosa.

Pero ¿qué sucede durante las siguientes semanas?

¿Los empleados están utilizando el sistema con seguridad? ¿Han dejado de llevar controles paralelos? ¿Los responsables de cada área cuentan con la información que necesitan? ¿Los procedimientos realmente se están siguiendo como fueron definidos?

Y, sobre todo, ¿están comenzando a observarse las mejoras que justificaron el proyecto?

Esas respuestas no siempre aparecen el primer día.

Algunas requieren semanas. Otras, meses.

La puesta en marcha es un acontecimiento importante, pero no debería confundirse con la obtención de resultados.

Las personas no son una actividad más del proyecto

Con frecuencia encuentro planes de implantación en los que la participación de los empleados aparece concentrada en una etapa llamada capacitación.

Se programan algunas sesiones, se explica cómo utilizar las pantallas y se espera que, a partir de ese momento, todos comiencen a trabajar de la nueva manera.

Pero aprender a utilizar un sistema y sentirse preparado para cambiar la forma de trabajar son dos cosas diferentes.

Un empleado puede comprender perfectamente cómo registrar una operación y, aun así, tener dudas sobre lo que se espera de él.

Quizá ahora deba capturar información que antes no registraba. Tal vez una actividad que realizaba de manera independiente pasará a depender de otra área. O puede ocurrir que ciertos controles hagan más visible su trabajo y eso le genere preocupación.

No todas esas inquietudes son resistencia al cambio.

Algunas son preguntas legítimas que merecen respuestas claras.

Otras revelan problemas que no se habían considerado durante el diseño del proyecto.

Y algunas pueden ayudarnos a descubrir que determinado procedimiento, aunque parezca correcto sobre el papel, no funciona tan bien en la práctica.

Por eso considero indispensable escuchar a quienes realizan las operaciones todos los días.

Las personas no deberían enterarse al final de cómo van a trabajar. Deberían participar en la construcción de esa nueva manera de hacerlo.

El conocimiento de la empresa no está solamente en sus directivos

Cuando comienzo a conocer una organización, naturalmente necesito conversar con sus propietarios y responsables.

Ellos conocen las prioridades del negocio, los problemas que les preocupan y los resultados que desean alcanzar.

Pero también he aprendido que una parte extraordinariamente valiosa del conocimiento de una empresa se encuentra entre quienes ejecutan sus operaciones cotidianas.

La persona que recibe mercancías sabe qué situaciones complican una recepción.

Quien prepara los pedidos conoce los errores que suelen presentarse antes de una entrega.

El responsable de cobranza puede explicar por qué ciertas facturas terminan convirtiéndose en problemas.

Y un vendedor probablemente sabe qué información necesita con urgencia cuando está frente a un cliente.

Escuchar estas experiencias no significa que todas las sugerencias deban convertirse automáticamente en modificaciones al sistema.

Significa reconocer que difícilmente podremos mejorar un proceso si no comprendemos cómo funciona realmente.

En ocasiones, lo que descubro en esas conversaciones es muy diferente de lo que inicialmente me habían explicado.

No necesariamente porque alguien haya proporcionado información equivocada, sino porque existe una diferencia entre la manera en que creemos que funciona una empresa y la manera en que sus operaciones suceden todos los días.

Esa diferencia merece toda nuestra atención.

La capacitación debe tener sentido para quien aprende

He visto que una capacitación puede ser técnicamente correcta y, sin embargo, resultar poco útil.

Esto ocurre cuando nos concentramos en explicar todas las funcionalidades de un sistema sin relacionarlas suficientemente con el trabajo de las personas.

Podemos dedicar horas a mostrar menús, botones y opciones. Pero si el usuario no comprende cómo esas herramientas le ayudarán a realizar sus actividades, probablemente olvidará buena parte de lo aprendido.

Prefiero que la capacitación parta de situaciones que las personas reconocen.

¿Cómo registramos un pedido que requiere una entrega parcial?

¿Qué hacemos cuando llega mercancía diferente de la solicitada?

¿Cómo identificamos una factura pendiente de cobro?

¿Qué ocurre cuando necesitamos corregir una operación?

Cuando trabajamos con ejemplos cercanos a la realidad de la empresa, el aprendizaje adquiere otro sentido.

El usuario deja de preguntarse para qué sirve determinada función y comienza a comprender cómo puede utilizarla para resolver situaciones que conoce.

Y hay algo más: no todas las personas aprenden al mismo ritmo ni necesitan el mismo tipo de acompañamiento.

Algunas se sienten cómodas explorando nuevas herramientas. Otras necesitan practicar varias veces antes de adquirir seguridad.

Eso no debería convertirse en motivo de impaciencia.

El propósito de capacitar no es demostrar cuánto sabe quien enseña, sino conseguir que quien aprende pueda trabajar con confianza.

El proveedor no puede desaparecer después de la instalación

Este es uno de los aspectos sobre los que tengo una convicción más firme.

Quien vende e implanta un sistema empresarial asume una responsabilidad que va más allá de entregar tecnología.

Por supuesto, la empresa también tiene compromisos. Debe proporcionar información, dedicar tiempo al proyecto, involucrar a sus responsables y tomar decisiones cuando sea necesario.

Pero no me parece razonable esperar que el cliente sepa conducir por sí mismo una transformación tecnológica y operativa.

Precisamente para eso ha contratado a un especialista.

El proveedor debe conocer el sistema, pero también necesita comprender la organización en la que va a utilizarse.

Debe anticipar dificultades, proponer alternativas, explicar las consecuencias de ciertas decisiones y acompañar a los usuarios cuando aparecen problemas.

Y, sobre todo, debe tener la capacidad de distinguir entre una dificultad técnica y una dificultad de adaptación.

No es lo mismo que una operación falle porque el sistema tiene un error, que descubrir que los usuarios siguen trabajando de una manera distinta a la acordada.

Ambas situaciones requieren atención, pero no se resuelven de la misma forma.

La primera probablemente necesite una corrección tecnológica.

La segunda puede requerir escuchar a las personas, revisar el procedimiento, aclarar responsabilidades o proporcionar acompañamiento adicional.

Un buen implantador no solamente sabe resolver problemas de software. También debe saber ayudar a las personas a resolver problemas de trabajo.

El cambio necesita liderazgo, no imposición

Cuando una empresa decide adoptar una nueva manera de trabajar, es natural que aparezcan dudas, desacuerdos e incluso cierta resistencia.

Algunas personas pueden sentir que perderán autonomía. Otras pueden preocuparse por cometer errores. También habrá quienes consideren que la forma anterior de trabajar era más sencilla.

Mi experiencia me ha enseñado que intentar resolver estas situaciones únicamente mediante instrucciones y exigencias rara vez produce los mejores resultados.

Por supuesto que la dirección debe respaldar el proyecto y establecer con claridad las decisiones que se han tomado.

Pero el respaldo de la autoridad no sustituye la necesidad de explicar, escuchar y convencer.

El proveedor tiene aquí una responsabilidad especialmente importante.

Debe ayudar a que las personas comprendan por qué se están realizando determinados cambios, qué se espera conseguir y de qué manera su participación contribuirá al resultado.

No se trata de organizar discursos motivacionales ni de pretender que todo cambio será recibido con entusiasmo.

Se trata de construir confianza a partir de explicaciones claras, decisiones congruentes y una disposición genuina para escuchar.

También de reconocer que, en ocasiones, las objeciones de los empleados tienen fundamento y nos están señalando algo que deberíamos corregir.

El cambio no se implanta, y mucho menos se impone. Se inspira.

Y esa inspiración necesita algo más que palabras: necesita que las personas descubran, en su propia experiencia, que la nueva manera de trabajar tiene sentido.

Los primeros días no cuentan toda la historia

La entrada en operación de un sistema suele ser un periodo de mucha actividad.

Aparecen dudas, se descubren situaciones que no habían sido previstas y algunas tareas pueden tomar más tiempo mientras los usuarios adquieren práctica.

Eso no significa necesariamente que el proyecto esté fallando.

Tampoco significa que debamos minimizar cualquier dificultad bajo el argumento de que todo cambio requiere adaptación.

Lo importante es observar lo que está sucediendo y actuar oportunamente.

¿Hay errores que se repiten?

¿Existen procedimientos que resultan innecesariamente complicados?

¿Algún área está teniendo más dificultades que las demás?

¿Se están utilizando correctamente las herramientas o han comenzado a surgir nuevamente controles paralelos?

Estas observaciones permiten realizar ajustes y, en ocasiones, descubrir oportunidades de mejora que no eran evidentes antes de comenzar a trabajar con el sistema.

Por eso considero que el acompañamiento posterior a la puesta en marcha debe formar parte de la implantación, no tratarse como una atención extraordinaria.

El proyecto necesita un periodo en el que podamos comprobar no solamente que el software funciona, sino que la organización está aprendiendo a trabajar mejor con él.

¿Cuándo podemos decir que una implantación fue exitosa?

No creo que exista una fecha universal para responder esta pregunta.

Cada empresa tiene su propia complejidad, sus necesidades y su ritmo de adaptación.

Pero sí creo que podemos establecer algunos criterios.

Una implantación comienza a demostrar su valor cuando las personas pueden realizar sus actividades con confianza, los procesos se ejecutan de manera consistente y la información se vuelve más útil para tomar decisiones.

Cuando disminuyen los errores que antes eran frecuentes.

Cuando se reducen las tareas innecesarias.

Cuando las áreas comienzan a coordinarse mejor.

Y, especialmente, cuando los resultados que la empresa esperaba conseguir empiezan a hacerse visibles.

No todos los beneficios aparecerán al mismo tiempo. Algunos serán inmediatos; otros requerirán más trabajo y seguimiento.

Pero esa es precisamente la razón por la que debemos definir desde el principio qué queremos lograr y mantener la atención en esos objetivos durante todo el proyecto.

Hay algo que me parece importante recordar: el verdadero protagonista de una implantación exitosa no es el sistema ni quien lo desarrolla. Son las personas que consiguen que la empresa trabaje mejor gracias a él.

El proveedor puede orientar, proponer, enseñar y acompañar.

La dirección puede respaldar, decidir y proporcionar los recursos necesarios.

Pero son los colaboradores quienes, día tras día, convierten las posibilidades de la tecnología en una nueva realidad para la empresa.

Y cuando eso sucede, el éxito deja de ser simplemente un proyecto tecnológico concluido.

Se convierte en una mejora real en la manera de trabajar.

Porque implantar un sistema no consiste solamente en conseguir que las personas aprendan a utilizar un programa.

Consiste en ayudar a que una organización aprenda a trabajar mejor.