10 cosas que un usuario no debería hacer...

...sin evaluar antes los riesgos

Nerea Narro

10 cosas que un usuario no debería hacer...

...sin evaluar antes los riesgos

A veces, gestos sencillos son los que pueden crear los mayores problemas. ¿Quién no ha cerrado un documento sin guardar y darse cuenta después de que ha perdido todo el trabajo? 

Hoy hemos decidido hablar de aquellas pequeñas cosas que pueden tocar los usuarios de un ERP sin darse cuenta, o sin saber las consecuencias de los peligros que acarrean. Vamos a hablar de cosas que pueden hacer que el software deje de funcionar como debería, así que atentos.

1.- Borrar datos de configuración

Borrar datos maestros, cuentas financieras, usuarios, clientes etc sin saber lo que son, y creyendo que no sirven para nada, puede ocasionar que se acaben borrando datos necesarios para el correcto funcionamiento de algún módulo, por lo que en la medida de lo posible se recomienda no borrarlo sino inactivarlo para que no se vea.

Si realmente requieres borrarlo de forma definitiva... pregunta antes a tu técnico qué consecuencias tiene el hacerlo

2.- Instalar o desinstalar módulos

No se debe instalar o desinstalar módulos directamente en el entorno de producción. Esta acción puede tener consecuencias y efectos laterales no deseados. En toda instalación, se requiere tener una base de datos o incluso un entorno completo de pruebas en el que analizar los impactos de este tipo de acciones.

En la instalación de módulos, verificar que hacen lo que uno quiere y que no alteran o entorpecen la operativa diaria. Hay que evitar dejarse llevar por el “por si acaso”, instalar módulos “por si lo necesito más adelante” o pedir cosas por que “igual me viene bien”. Esto puede hacer que los procesos se compliquen innecesariamente y el software deje de ser útil y eficiente.

En la desistalación de módulos, comprobar que los datos eliminados no eran realmente necesarios y que el módulo eliminado simplifica la operativa y el trabajo diario.

 Ante cualquier duda, preguntar. 

3.- Validar desarrollos y pedir que te los pongan sin haberlos probado

Para asegurar que en producción todo va correctamente, es imprescindible probar todos los desarrollos en un entorno de prueba, antes de instalarlos en el de producción. Esto evita problemas, en el caso de que se tenga que volver a modificar el módulo desarrollado o  se encuentre alguna incompatibilidad que pueda alterar los datos existentes previos a su instalación.

Se recomienda poner especial interés y esfuerzo en probar casos de uso de todo tipo, no solo los habituales.

4.- Tocar directamente la base de datos

Aún siendo técnico informático, no se recomienda cambiar directamente datos en la base de datos, aunque entendemos que quien lo hace, conoce los riesgos y no ha encontrado otra forma de hacerlo. Una modificación directa en la base de datos, puede hacer que el sistema entero deje de funcionar, además de que puede romper la integridad referencial entre tablas y puede hacer sumamente complicado la detección del problema que causa este mal funcionamiento.

Algunos ejemplos que podriamos mencionar, serían la rotura de los flujos de trabajo cuando se modifican estados directamente en base de datos, pérdida de relaciones entre datos de tablas o errores inesperados por pantalla.

5.- Realizar una carga de datos directamente en producción

Habitualmente, suele ser imprescindible la realización de una carga de datos previa al arranque en el uso de la aplicación pero la forma es que se realice dicha carga condicionará la configuración inicial y por tanto el comportamiento del sistema en cuanto a su funcionamiento. Es por ello, que se recomienda realizar varias cargas de datos en entornos de pruebas para validar que son correctas, antes de su carga definitiva en el entorno productivo. 

Por otro lado, recomendamos que las cargas de datos, sean realizadas por un técnico especialista en ello y que salvo situaciones muy controladas y puntuales, no se realicen una vez se ha iniciado el uso real de la aplicación ya que podría afectar a los datos reales existentes e incluso dejar el entorno inoperativo.  

6.- Eliminar usuarios

A veces nos encontramos con usuarios que solo tienen un email como único dato en la ficha y podemos creer que han sido creados por error o que no tienen ninguna función importante. Sin embargo, existen datos que han podido ser creados como maestros por módulos que los necesitan. Por ello, recomendamos NUNCA borrar un usuario creado por el sistema y en su lugar, dejarlo inactivo.

7.- Realizar cambios en los permisos

Realizar cambios en los permisos si no sabes exactamente a qué va a afectar, puede acarrear todo tipo de problemas, desde dejar a uno o varios usuarios sin poder realizar una tarea vital en sus funciones, a darles demasiados privilegios permitiéndoles modificar o borrar datos que no deberían tocar. Si se requiere modificar los grupos de permisos y privilegios que el sistema trae configurados de base recomendamos un buen asesoramiento técnico para su correcta configuración. En principio, estos grupos básicos suelen ser suficientes para cualquier empresa con el habitual reparto de funciones por departamentos.

8.- Sobreescribir un dato maestro

Hay campos en el sistema (los definidos por una lupa o flecha/carpeta) que nos llevan a navegar directamente a una tabla relacionada. Por ejemplo, el cliente en la cabecera de pedido.

Cuando el dato no ha sido establecido, se muestra la lupa para buscarlo pero si el campo ha sido establecido se muestra la flecha/carpeta que al pulsar nos hace navegar a la tabla relacionada. Este funcionamiento que puede parecer trivial y en algunos casos lo es, para algunos usuarios es complejo y lleva a cometer errores no deseados ya que si se navega a la tabla relacionada, se modifica el dato y se graba... lo que se ha hecho, no es cambiar un valor por otro, sino sobreescribir el valor existente, es decir, cambiarle el nombre.

Para evitar esto, es necesario asegurarse de seleccionar un valor de la tabla relacionada o crearlo nuevo si no existe, pero no sobreescribir o modificar el nombre de uno existente.

9.- Ocultar la verdad

A pesar de las recomendaciones y advertencias, es posible que alguien cometa un error. Todo el mundo lo hace. Por tanto, cuando el técnico os pregunte qué hicisteis, el decir “yo no he tocado nada” no es la mejor respuesta. Es muchísimo mejor indicar exactamente qué pasó y explicar con el mayor detalle que se recuerde los pasos que se han dado y cual es la posible acción que ha podido ser la causante del problema. Esto facilita enormemente la labor de aquellos cuyo trabajo es arreglar el problema.

10.- No formar a los usuarios

La mejor manera de evitar problemas es la formación. Lo hemos repetido en varias ocasiones y volveremos a repetirlo cada vez que podamos. Para conocer las consecuencias de una acción, lo mejor es tenerlas identificadas de antemano. 

Por ello, una buena formación asegura el poder evitar muchos de los problemas mencionados anteriormente. Esto hace que el equipo humano pueda sacar el máximo provecho del sistema minimizando el riesgo de conlleva la incorrecta gestión de los datos y los procesos de la empresa.