La experiencia nos dice que las pruebas deficientes del sistema antes de que un sistema ERP entre en funcionamiento inevitablemente conducen a la decepción y, en el peor de los casos, a un fracaso total. Es difícil obtener una cifra precisa de las tasas de fracaso porque las personas tienen diferentes ideas sobre lo que son el éxito y el fracaso. Algunos consideran que es un éxito si el sistema se pone en marcha, independientemente de lo bien que cumpla con los beneficios anticipados; e incluso el fracaso viene en diferentes sabores.
Algunos sistemas fracasan en absoluto al momento de ponerse en marcha, porque sin importar cuán tarde, la empresa se da cuenta de que el sistema elegido nunca va a ser capaz de hacer lo que se necesita, o de la manera en que se necesita. Otros se ponen en marcha, pero se desempeñan tan mal que se detienen y la empresa vuelve a las formas anteriores de trabajar; al menos temporalmente.
Y, sin embargo, otros se ponen en marcha y no producen ningún beneficio que valga la pena, pero volver al sistema antiguo no es posible, por la razón que sea, por lo que la empresa avanza cojeando con sistemas inadecuados que deben ser respaldados por sistemas de nivel extra departamental y soluciones alternativas engorrosas.
Los problemas que se encuentran con frecuencia después de la puesta en marcha incluyen:
Datos faltantes e inexactos
Antes de que un sistema ERP pueda entrar en funcionamiento, se debe cargar una enorme cantidad de datos. Siempre existe la tentación de limitar la carga de trabajo transfiriendo datos electrónicamente desde el sistema anterior, pero pocas empresas cuentan con sistemas y procedimientos para garantizar la integridad de sus datos, entonces lo que puede suceder es que el nuevo sistema comience la vida con los datos antiguos y defectuosos.
Ingresar datos manualmente alienta a las personas a eliminar datos incorrectos de antemano, pero lleva mucho tiempo y esfuerzo, e inevitablemente se cometen errores, por lo que los datos deben verificarse cuidadosamente, tanto antes como después de ingresarlos. Pero verificar los datos es aburrido e, irónicamente, cuanto más cerca está del 100% de precisión, más aburrido se vuelve porque se encuentran menos errores. Después de haber verificado 100 registros y encontrado que son precisos, es fácil para las personas creer que solo se necesitan controles aleatorios en los 10,000 restantes. Se convencen a sí mismos de que el 99% de precisión es, de todos modos, lo suficientemente bueno; y a veces tienen razón.
Pero a veces se equivocan, y eso conduce a todo, desde buenos clientes a los que se les suspende el crédito cuando no deberían hacerlo, y a los malos clientes a los que no se les suspende el crédito cuando deberían hacerlo; hasta materiales y artículos necesarios que no se ordenan cuando deberían y artículos innecesarios que se compran a precios elevados para satisfacer una demanda que en realidad no existe.
Detectar datos erróneos o faltantes es notoriamente difícil de hacer, pero hay características y estrategias de ERP que pueden ayudarlo con esto. Por ejemplo; si verifica los límites de crédito del cliente, ejecute un informe de clientes ordenado por límite de crédito y aparecerán las excepciones. Y, en las empresas de fabricación, ejecute informes de listas de materiales presupuestados y compare los valores con los costos reales estándar o últimos. ¡Pero haz estas cosas antes de entrar en funcionamiento y no después!
Personal inadecuadamente capacitado
Cuando las empresas intentan reducir costos o comprimir los plazos, reducir la capacitación que recomiendan los proveedores de ERP y los integradores de sistemas puede parecer una buena idea. Es fácil entender por qué: se conoce la cantidad de días que se recortan, al igual que la tasa diaria, por lo que es muy fácil calcular el ‘ahorro’. El problema es que a veces ahorrar dinero cuesta una fortuna y, cuando se hacen ‘ahorros’ recortando la formación, siempre hay un precio que pagar. ¿Cuál es el costo de que el personal capacitado de manera incompleta no pueda obtener información precisa del sistema, ordene materiales demasiado tarde para mantener la línea de producción en funcionamiento y los estantes llenos, y cobre a los clientes el precio incorrecto? Y, cuando las personas no pueden usar el sistema formal correctamente, usarán sistemas informales: ¿cuál es el costo de eso?
Por lo tanto, un nuevo sistema no debería ponerse en marcha hasta que las personas que lo usarán hayan demostrado que pueden usarlo de manera eficiente y efectiva.
Falta de funcionalidad e informes
Es común que la gente piense que el nuevo sistema será un «sistema antiguo plus» pero, incluso si el nuevo sistema es del proveedor anterior, es casi seguro que no lo es. Durante un período de tiempo, las ideas cambian y el equipo de desarrollo del autor del sistema también habrá cambiado. Y, si el nuevo sistema fuera solo «Old system plus», no habría un nuevo sistema de todos modos: solo la versión 47 del sistema anterior. Agregue a eso el hecho de que lo que la mayoría de la gente considera como «el sistema» generalmente incluye una serie de modificaciones e informes a medida, y con frecuencia la única similitud entre los sistemas antiguos y nuevos es, en el mejor de los casos, el nombre en la caja.
El problema se agrava cuando no hay un documento adecuado de ITT o especificación del sistema que describa exactamente lo que el sistema debe hacer. En el período previo a la selección del sistema, todo tipo de personas habrán declarado, tanto en reuniones formales como informales, lo que requieren del nuevo sistema y, si no se les ha dicho específicamente que no obtendrán lo que han pedido, asumirán que lo obtendrán. Pero las conversaciones casuales alrededor de la máquina de café no son solicitudes formales: y tampoco lo son las solicitudes verbales indocumentadas.
En el período previo a la puesta en marcha, nada existe a menos que se haya confirmado su existencia. Y eso significa que debe describirse explícitamente en el documento ITT / especificación y alguien debería haber comprobado que existe, que funciona y que funciona de manera aceptable.
Procesos poco prácticos
La cantidad de cambios que los departamentos individuales y las personas tienen que enfrentar cuando se implementa un nuevo sistema ERP varía según lo que estén moviendo. Hacia un extremo del espectro, un departamento de nómina que se está moviendo de un sistema computarizado a otro no verá mucha diferencia en sus procesos diarios, pero, en el otro extremo, es probable que una empresa de fabricación que pasa de sistemas manuales, como hojas de cálculo, a una solución totalmente integrada que incorpore todo, desde la planificación de requisitos de materiales (MRP) hasta la programación de capacidad finita (FCS) probablemente tenga que rediseñar completamente sus formas de trabajo.
El problema entonces es que estarán entrando, para ellos, en territorio inexplorado. Un fabricante de muebles estaba entusiasmado con la posibilidad de tener listas de materiales adecuadas (en lugar de solo listas de piezas) y el potencial que daba para recaudar costos de fabricación muy precisos para absolutamente todo lo que hacían; hasta las clavijas. Como parte de sus pruebas, ingresaron algunos pedidos de ventas, ejecutaron el MRP y levantaron y procesaron los pedidos de trabajo necesarios. Lo que no hicieron fue considerar cuántos artículos tenían que fabricar cada semana y, aunque configuraron el MRP para consolidar la demanda a nivel semanal, se sorprendieron un poco cuando, antes de entrar en funcionamiento y ejecutar MRP contra su cartera de pedidos completa, recomendó recaudar más de 4,000 pedidos de trabajo para la producción de la próxima semana.
Entonces, ¿cómo pueden las empresas superar estos problemas?
Claramente, hay mucho que puede salir mal cuando un nuevo sistema ERP se pone en marcha, pero ninguno de los problemas discutidos aquí debe ser una sorpresa. Son todas las cosas que pueden y deben anticiparse y las cosas que pueden y deben evitarse. La clave radica en las pruebas completas y realistas, y la clave para eso es tener un buen plan de pruebas. Es necesario que las empresas, al probar el sistema, se den cuenta de que «el sistema» no es solo software, sino también las personas y los procedimientos que el software debe respaldar. A un nivel muy básico; si la gente no sabe cómo usar el software correctamente, si la calidad de los datos en el sistema es pobre y, recordando al fabricante de muebles, si se imponen demandas poco realistas a las personas y los departamentos, entonces el sistema no funcionará.
___________________
En Sphere Consulting S.A.C., contamos con excelentes profesionales que pueden ayudarte a implementar un software ERP. Visita nuestra web para más información o contáctanos para programar una reunión.
Recuperado de: The importance of proper ERP testing (erpfocus.com)