Normalmente se evalúa a los productos ERPs por los grandes títulos. Dentro de los módulos básicos del ERP existen detalles finos que hacen que una aplicación sea mucho mejor o mucho peor al momento de utilizarla, que permita escalar a gran cantidad de puestos o no, que sea útil para empresas localizadas en distintos países, etc. En este artículo se trata sobre la estructura de datos para disminuir la carga de los mismos.
En los viejos sistemas de gestión el ABM de clientes era muy popular (ABM= Altas, Bajas Modificaciones). Al ingresar a la “pantalla” de ABM se cargaban los datos que incluían información tal como domicilio, teléfono, contactos, etc. Algo parecido sucedía con el ABM de proveedores en el que se cargaba información similar.
¿Y cuando la misma persona jurídica era cliente y proveedor de la empresa? ¿Qué pasaba?
En este caso los datos debían ser cargados dos veces, y consecuentemente actualizados dos veces en si se producían variaciones. El mundo va cambiando y hoy las relaciones cruzadas son comunes. Resulta que una misma persona puede ser cliente, proveedor, empleado, y familiar a su vez de otro empleado.
Algunos ERPs rediseñaron su estructura de datos para conceptualizar lo siguiente: Existen personas físicas o jurídicas que cumplen roles, esto es el rol de cliente, o de proveedor, o de socio, o de lo que fuera, pero su información personal no varía fundamentalmente en función de papel que cumpla. Es así que cuando se ingresan por ejemplo los domicilios, la web, o los teléfonos de un cliente, el mismo ingreso de datos sirve también para su eventual rol de proveedor disminuyendo las tareas de mantenimiento, y fundamentalmente, aumentando la coherencia de la información del sistema. Así, por ejemplo, se hace viable el mantener cuentas corrientes donde se intercambian bienes o servicios con proveedores que a su vez son clientes. Y con una estructura de datos así, también se resuelven problemáticas que suelen ser extrañas para los ERPs como ser el manejo de los socios de un club, los alumnos de un colegio o los afiliados a una obra social, que reconocen vínculos familiares, por nombrar algunos ejemplos.
¿Usted tiene hijos o sucursales?
Por ejemplo un ERP que debe facturar en un colegio debe reconocer el vínculo de padre, hijo, hermano. En este caso el alumno no es el cliente del colegio, sino su padre, y normalmente se deben agrupar las cuotas de los hermanos en una misma transacción.
Lo más curioso que llegamos a ver fue definir a todos los miembros de una familia como un conjunto de clientes con sucursales. Este tipo de soluciones es posible, pero antinatural y generadora a posteriori de múltiples problemas, que usualmente se sufren luego durante años.
