9 factores clave para la Calidad en implantaciones de ERP (III)

16 Aug

7. Basarse en un buen producto

  • Si el objetivo de una buena implantación de un sistema de gestión radica en dar soporte adecuado a los procesos de negocio, la calidad de dicho sistema es un factor clave.
  • Un ERP puede considerarse de calidad si es robusto, si está basado en buenas prácticas (la operativa obedece a cómo habría que hacer las cosas) y si posee suficiente flexibilidad (permite dar respuesta a la casuística del día a día).
  • En cambio, un ERP de escasa calidad destaca por ser poco robusto (surgen problemas de rendimiento, hay problemas serios de estabilidad, los datos no son consistentes), si no está basado en buenas prácticas (por ejemplo, si la gestión contable no es suficientemente rigurosa) o si no posee unos mínimos de flexibilidad.
  • Sin buen producto, todo cae en adaptaciones, lo que supone una serie de problemas. En primer lugar, el problema más importante es el sobrecoste requerido para llevarlas a cabo. Sin embargo, también surgen problemas de mantenimiento: las personalizaciones suelen conllevar más esfuerzos de corrección y de ajustes, puesto que son más propensas a sufrir errores. Es decir, si el producto es incompleto, cualquier cambio requiere desarrollos adicionales, que pueden ser costosos en tiempo y en mantenimientos posteriores.
  • A veces, según el producto o el ámbito, ni siquiera es posible construir dichas adaptaciones. Y si se trata de necesidades realmente importantes para la empresa, y el proyecto ya está en curso o el sistema ya está puesto en marcha, tenemos un serio problema.

A reflexionar:

  • Desde la perspectiva de la empresa cliente:
    • ¿Cuáles son los verdaderos requerimientos que necesito tener cubiertos para una aplicación? ¿Qué requerimientos son anecdóticos (no son relevantes en sí) y cuáles son imprescindibles?
    • En base a la planificación estratégica de la organización, y según las posibles líneas de crecimiento que tengamos, ¿qué funcionalidades podrían ser convenientes? No sólo debemos pensar en escoger un sistema para dar respuesta a las necesidades del presente, sino también las necesidades futuras más probables. Por ejemplo, una organización recientemente seleccionó un sistema ERP frente a los de la competencia porque incluía gestión de lotes y un módulo de CRM, funcionalidades que hoy por hoy no necesitan pero que encajaban perfectamente en las futuras líneas de trabajo de la compañía. Se preparó para crecer.
    • Un ejercicio muy útil para asegurarse de que el producto encaja, y que recomiendo encarecidamente, es solicitar a los usuarios clave (los referentes de cada área) que confeccionen ellos mismos una lista con las funcionalidades que debería tener la aplicación: las cosas que ya pueden hacerse con el sistema actual, los problemas que actualmente tienen y que el sistema actual no resuelve, y las cosas que les gustaría también disponer. De esta forma, es posible solicitar demostraciones de producto concretas, realizadas de forma precisa para responder estas cuestiones y con los propios usuarios implicados. Involucrar a nuestro personal en la elección del producto facilita la propia gestión del cambio.
  • Desde la perspectiva de la empresa consultora:
    • En ocasiones las necesidades comerciales nos hacen caer en la tentación de precipitarnos, asegurando que el sistema responderá adecuadamente a las necesidades, sin antes asegurarnos de que así es. En este sentido, es preferible ser cautos: pocas cosas hay peores que percatarnos de que la herramienta que estamos implantando en una organización no es la solución que realmente necesitan, por la que pagan y que están esperando recibir.
    • ¿Estamos seguros de que el producto que implantamos obedece a las buenas prácticas del sector? Si es así, ¿potenciamos ese mensaje lo suficiente? Es importante recordar que las buenas prácticas existen porque son las formas de hacer las cosas más ampliamente aceptadas, con adecuados resultados que han sido empíricamente demostrados. Tal vez los usuarios no deseen cambiar su forma de hacer las cosas, pero un gerente cuando invierte en una nueva herramienta de gestión, desea que su empresa trabaje mejor.
    • Un ejercicio muy útil para asegurarnos de que el producto da la respuesta adecuada a las necesidades es, lógicamente, reflexionar acerca de dichas necesidades. Parece una trivialidad, pero lamentablemente no es algo frecuente. Nos acostumbramos a realizar presentaciones genéricas, que en realidad no le sirven a nadie. Recuerda: el objetivo es dar soporte para solucionar problemas de negocio; por lo tanto, pregunta qué problemas tiene la organización, y propón ejemplos concretos de cómo se resuelven.


8. Una adecuada migración de datos

  • Sin datos, no es posible operar.
  • Ya sea con una migración completa o parcial de datos previa al Arranque (lo habitual) o bien una migración asumida por la propia organización tras el Arranque, lo importante es que esté debidamente planificada. Pero no basta con planificación, también se requiere comunicación, distribución de tareas, seguimiento, control de calidad de la migración y, sobre todo, acordar entre ambas partes qué se hará realmente.
  • En mi experiencia personal, aunque tenemos unas pautas genéricas, siempre hemos tenido que adaptar el enfoque de migración según cada cliente. Esto dificulta la rentabilidad de los proyectos desde la perspectiva de quien implanta y la adecuada planificación de tareas, pero satisface en gran medida las necesidades de información de las organizaciones que reciben el nuevo sistema informático.

A reflexionar:

  • Desde la perspectiva de la empresa cliente:
    • ¿Tenemos bien identificados los datos a migrar, los que queremos pasar del sistema antiguo al nuevo sistema? Esta parte no es trivial, y bajo ningún concepto debe delegarse ciegamente en la empresa consultora. Pueden proponer y aconsejar qué datos deberían traspasarse, pero es fundamental que aseguremos que no se queda excluida ninguna información vital. Los datos son de nuestra propiedad, por lo que la responsabilidad sigue estando en nuestro campo.
    • Un error común es querer traspasar todo. Esto es particularmente reseñable en los proyectos donde existe una clara inconsistencia de datos en el sistema anterior. Algunos de mis clientes me transmitían que uno de los motivos del cambio es que no confiaban en absoluto en los datos de su sistema, y luego en la fase de migración querían traspasarlo todo. ¿Cuando nos mudamos de casa, también mudamos todo lo que había en el trastero y también traspasamos la basura?
    • A pesar de que la empresa consultora esté muy acostumbrada a realizar migraciones, no olvidemos de que la responsabilidad de los resultados del traspaso de información seguirá estando en nuestro campo. De nada sirve que lo blindemos con exigentes cláusulas a nivel de contrato. Al final de todo, si no disponemos de datos en el momento de puesta en marcha, operaremos mal y tendremos pérdidas de rentabilidad y de imagen. Es importante, por tanto, pedir migraciones previas de testeo (aunque sean parciales), involucrar a nuestro personal para que compruebe que dispone de todos los datos que necesita (por ejemplo, que el personal de cobros se asegure de que las nuevas fichas de clientes tienen la información requerida para su trabajo) y validar mínimamente que la migración es correcta.
  • Desde la perspectiva de la empresa consultora:
    • Involucrar a la organización cliente resulta clave para evitar confusiones y malas interpretaciones. Una migración realizada bajo nuestro criterio, que no ha sido validada y que el usuario ve por primera vez el mismísimo día de puesta en marcha (Arranque), está abocada al fracaso. Planifica, documenta y acuerda con el cliente qué datos se van a migrar, cuándo y cómo. Presenta ejemplos y solicita validaciones parciales.
    • Un elemento fundamental en la migración es la labor de extracción del sistema anterior. Según los conocimientos que tengamos y las capacidades propias del sistema origen y del sistema de destino, la labor de extracción puede ser muy sencilla o un quebradero de cabeza. Recomiendo no subestimar nunca este apartado: no es bueno asumir compromisos a este respecto sin antes haberlo analizado adecuadamente. Puede quedar como un elemento abierto en la oferta comercial, pendiente de revisión, o delegarse completamente a la organización cliente. En cualquier caso, es vital aclarar este punto de forma explícita y llegar a un acuerdo satisfactorio lo antes posible.
    • Otro elemento crítico es la limpieza de los datos. Normalmente, esto suele delegarse enteramente en la organización cliente, siendo ellos los responsables de preparar los datos a migrar de forma previa. Si es así, es fundamental aclarar este apartado, comentándolo de forma explícita y con el tiempo suficiente, puesto que se corre el riesgo de presunciones erróneas por ambas partes.


9. Una adecuada formación de usuarios

  • Básicamente, existen 4 pilares básicos para un sistema informático:
    • funcionalidades del producto (que satisfagan los procesos de negocio, que resulten ágiles)
    • datos (información que sirva de input a los procesos e información resultante de los mismos –output– para informes y nuevos procesos)
    • tecnología (estaciones de trabajo, servidores y dispositivos de red… una combinación adecuada de características hardware y software)
    • usuarios formados (personas que hagan un uso eficaz y eficiente de lo anterior para proporcionar resultados rentables a la organización)
  • Si falla una de esos cuatro elementos, difícilmente podrá operarse. Sin embargo, es frecuente que se menosprecie la relevancia de la formación del personal, ante otros factores aparentemente más complejos.
  • De hecho, resulta tristemente frecuente para mí ver ofertas comerciales de la competencia que incluyen el apartado de formación de usuarios como un elemento opcional en el presupuesto (si el gerente quiere, lo acepta; si no, no pasa nada). En mi opinión, resulta un ejemplo muy aclarador acerca del enfoque que posee dicha propuesta. Instalar un nuevo sistema de gestión que dé cabida a los procesos críticos de una empresa, sin explicar nada a los usuarios sobre su manejo, equivale a entregarle las llaves de un camión de reparto a un nuevo empleado sin carnet de conducir y pretender que espontáneamente realice bien su trabajo.
  • Que los usuarios no sepan cómo operar con el sistema puede tener el mismo efecto perjudicial que tener los ordenadores desconectados de la corriente eléctrica.
  • No olvidemos que, por encima de todo, lo más importante son las personas. Es el componente humano el que realmente determinará el éxito o el fracaso de una implantación.

A reflexionar:

  • Desde la perspectiva de la empresa cliente:
    • Siempre, siempre, siempre solicita formación. Nunca debe considerarse un elemento optativo si se desea asegurar el éxito.
    • Cuanto más próxima sea la formación a la puesta en marcha del sistema, mucho mejor. Además, es importante intentar que la formación se realice sobre un prototipo lo más parecido al sistema productivo, incluyendo un juego de datos realista. Evitemos entornos de formación genéricos y nada concretos. Cuanto más cercana sea la experiencia de la formación a la realidad del día a día, mejores resultados produce.
    • La formación requiere tiempo y dedicación. Es importante acordar una buena distribución de fechas y horarios, en función de nuestros procesos habituales. Por ejemplo, si el departamento de compras tiene los principales picos de carga de trabajo por la mañana, solicitemos que reciban formación por la tarde. Es importante enfatizar la relevancia de la formación: nuestro personal tiene que saber que debe dedicarle importancia a aprender lo mejor posible a usar el nuevo sistema.
  • Desde la perspectiva de la empresa consultora:
    • En mi experiencia he observado que frecuentemente existe una correspondencia inversa entre el nivel de implicación de cada usuario durante la formación y la cantidad de incidencias y dudas que produce dicho usuario tras el Arranque. Los usuarios más implicados durante la formación son aquellos que practican, que plantean preguntas, que cuestionan constructivamente y que se anticipan a los problemas que tendrán. Los usuarios que no prestan atención suelen ser los que después generarán la mayor cantidad de incidencias y consultas tras la puesta en marcha.
    • Si hemos conseguido involucrar adecuadamente a los usuarios clave durante las validaciones parciales de los prototipos, tendrán un conocimiento más avanzado que el resto de usuarios. Además, por el mismo hecho de ser usuarios clave, son los que más conocimiento tienen de su ámbito. Resulta por lo tanto muy conveniente apoyarse en ellos. Un usuario clave que participa en la formación colaborando, aportando sugerencias, aclarando casos concretos, apoyando a los compañeros,… es una manera excelente de facilitar la adopción de la nueva herramienta y mejorar la gestión del cambio, potenciar al propio usuario clave, disminuir las incidencias que habrán tras la puesta en marcha y, por supuesto, conseguir una formación más amena y distendida.
    • La formación de los usuarios es una oportunidad excelente de validar el prototipo y asegurar que realmente responde a las necesidades de la organización. No se trata de hacer una formación por encima para esquivar las preguntas, sino todo lo contrario. Cuanto más fomentemos la práctica rigurosa y extensiva, más probabilidades de éxito tendremos para la puesta en marcha. Pocos indicios hay que tranquilicen más para un Arranque que, tras haber probado los principales escenarios, se pregunte a los usuarios “¿se les ocurre algún caso más, por raro que sea, que no hayamos planteado todavía con el programa?” y tras unos momentos de reflexión, respondan “pues no… está todo contemplado“. Si es así, y si tenemos la migración de datos controlada, gran parte del éxito del Arranque ya está asegurado.

Leave a Reply

Your email address will not be published. Required fields are marked *