Cuando el documento, el ERP y el CRM no dicen lo mismo

Estimated reading time: 8 minutos

En muchas empresas basta con seguir el recorrido de un dato para descubrir que conviven varias versiones de la misma información. Lo que aparece en un documento no coincide exactamente con lo que figura en el ERP y, al abrir el CRM, encontramos todavía otra cosa.

Pensemos en un proveedor que comunica un cambio de domicilio fiscal y envía la documentación correspondiente. En el ERP sigue apareciendo la dirección anterior, el CRM conserva otra versión y Compras tiene además una hoja de cálculo que lleva meses utilizando para determinadas gestiones. Quizá no haya un error grave detrás de todo esto. Puede ser simplemente que el CRM no se actualizara en su momento, que esa hoja se crease para un proyecto concreto o que cada departamento haya ido manteniendo la información que necesitaba.

Mientras estas diferencias las resuelve una persona, suelen pasar bastante desapercibidas. Se consulta un documento, se mira otra pantalla, alguien pregunta qué dato es el bueno y se continúa trabajando. Cuando queremos automatizar el proceso, esas decisiones que antes se resolvían casi sobre la marcha necesitan unas reglas bastante más claras.

Porque podemos conectar perfectamente un documento con el ERP y el CRM y seguir sin saber qué hacer cuando los tres contienen información diferente.

Integrar los sistemas no hace desaparecer las diferencias

Hace tiempo hablamos sobre cómo integrar un gestor documental con ERP y CRM para evitar duplicidades, reducir tareas manuales y conseguir que la documentación forme parte del propio flujo de trabajo.

Una integración permite que la información circule, pero en cuanto aparecen varias versiones del mismo dato hay que introducir algún criterio adicional.

La API puede llevar una dirección de una aplicación a otra en unos segundos. Si la dirección de origen estaba desactualizada, lo hará con la misma eficacia. Incluso puede terminar sobrescribiendo un dato correcto que ya estaba en el sistema de destino.

En la práctica es bastante habitual que las responsabilidades estén repartidas. Finanzas mantiene información en el ERP, Comercial trabaja principalmente en el CRM, Compras controla otros datos de los proveedores y la documentación que justifica determinados cambios puede encontrarse en un gestor documental.

IBM utiliza el término system of record para referirse al sistema que actúa como fuente autorizada dentro de un determinado ámbito. Un CRM puede desempeñar ese papel para cierta información de clientes mientras que el ERP lo hace para los datos económicos. No tiene por qué existir una única aplicación que mande sobre absolutamente todo.

Llevado al día a día, interesa bajar un nivel más y decidir de dónde debe salir cada dato que utiliza el proceso.

Cuando aparecen varias versiones, no siempre sirve escoger la más reciente

Con algunos datos resulta relativamente sencillo.

“Avda. de América, 25” y “Avenida de América 25” pueden acabar siendo la misma dirección después de normalizar el formato. También podemos encontrar identificadores escritos con o sin determinados caracteres, nombres con pequeñas variaciones o fechas expresadas de forma distinta.

Ese trabajo se puede automatizar con bastante seguridad si las reglas están bien definidas.

Ahora supongamos que el ERP muestra una dirección en Madrid y el documento recibido indica una nueva sede en Valencia. En ese caso ya queremos saber cuándo se emitió el documento, quién lo aportó y si forma parte del procedimiento previsto para modificar ese dato.

Y si lo que cambia es una cuenta bancaria, seguramente seremos todavía más cuidadosos.

Lo interesante es que todos estos casos pueden llegar al mismo proceso como una simple “diferencia entre campos”, aunque detrás haya situaciones muy distintas.

Por eso no suele bastar con establecer que prevalece siempre el dato más reciente, el del documento o el que ya estaba en el ERP. Habrá información que pueda actualizarse mediante reglas bastante sencillas y otra en la que necesitaremos comprobar el origen o pedir una validación antes de tocar nada.

SAP trabaja este tipo de consolidación mediante distintas fases en las que los datos procedentes de varias fuentes se estandarizan, se comparan, se identifican posibles duplicados y se calcula cuál debe ser el mejor registro según las reglas definidas. Algunos resultados pueden resolverse automáticamente y otros quedan pendientes de revisión cuando no alcanzan los criterios establecidos.

No hace falta implantar una arquitectura de Master Data Management para aplicar esa lógica a un proceso administrativo. Muchas veces basta con dejar bien definido qué diferencias sabemos resolver y cuáles queremos apartar.

Hay discrepancias que casi se corrigen solas

Una buena parte de las diferencias que aparecen entre sistemas son bastante poco emocionantes. Abreviaturas, mayúsculas, formatos de teléfono, espacios, nombres escritos de forma ligeramente diferente o datos que pueden contrastarse con una regla conocida.

Si todo eso acaba siempre en la mesa de alguien, estamos dedicando tiempo a decisiones que probablemente puedan resolverse antes.

Otras situaciones son menos claras. Dos empresas con nombres muy parecidos pueden ser la misma o no. Un proveedor puede haber cambiado de denominación social. Un dato nuevo puede llegar acompañado de documentación suficiente o puede aparecer simplemente escrito en un correo.

Es aquí donde empieza a tener sentido separar el trabajo automático de las excepciones.

El proceso puede continuar con los casos en los que existe suficiente certeza y dejar aparte aquellos en los que realmente hace falta que alguien compruebe qué ha ocurrido. Así evitamos uno de los problemas habituales de este tipo de automatizaciones, que consiste en exigir que absolutamente todo cuadre para poder avanzar.

Tampoco interesa hacer justo lo contrario y resolver cualquier contradicción con una regla excesivamente simple. Una discrepancia que se propaga automáticamente puede terminar reproduciéndose en varias aplicaciones y resultar bastante más costosa de corregir después.

En realidad, muchas de las decisiones que toma una persona cuando trabaja con estos procesos siguen esa misma lógica. Hay cosas que corrige sin pensarlo demasiado y otras ante las que se detiene porque sabe que tienen consecuencias.

Cuando automatizamos, ese criterio tiene que dejar de vivir únicamente en la experiencia de quien tramita el caso.

Si el mismo dato vuelve a fallar, conviene mirar un poco más atrás

Puede ocurrir que revisemos el proveedor, comprobemos su documentación y dejemos la información perfectamente actualizada en todos los sistemas. Dos semanas después aparece otra vez el domicilio antiguo.

A partir de ahí merece la pena averiguar por dónde ha vuelto a entrar.

Quizá existe una importación periódica que sigue utilizando una fuente antigua. Otra aplicación puede estar sobrescribiendo el cambio o un departamento continuar trabajando con un fichero que nadie incorporó al nuevo circuito.

Son situaciones que durante bastante tiempo pueden mantenerse gracias a pequeñas correcciones manuales. Una persona ve que algo no cuadra, modifica un campo y continúa. Si ese gesto se repite con frecuencia, termina siendo parte de la rutina y cuesta incluso reconocerlo como un problema del proceso.

Automatizar tiene la virtud incómoda de sacar a la luz muchas de esas decisiones.

Cuando ya no hay una persona delante de cada registro, necesitamos saber quién mantiene el dato, desde dónde puede actualizarse y qué debe ocurrir si dos fuentes intentan modificarlo de manera diferente.

También cambia bastante el diagnóstico. Si una discrepancia aparece una vez, quizá solo tengamos que resolver ese caso. Si aparece cincuenta veces al mes, seguramente tengamos un problema en el origen, en la sincronización o en la forma en la que se están repartiendo las responsabilidades entre sistemas.

Y después tendremos que poder saber qué ocurrió

En un proceso automatizado conviene poder volver atrás y entender por qué un dato terminó siendo el que vemos ahora.

No siempre hará falta conservar una historia interminable de cada campo, aunque para determinadas operaciones sí resulta útil saber qué valor había, qué nueva información llegó, de dónde procedía y qué regla permitió realizar la actualización.

Si el caso pasó por una revisión humana, también interesa dejar constancia.

Esto sirve cuando aparece una incidencia, pero también para ir afinando el propio proceso. A veces descubriremos que una discrepancia que enviábamos siempre a revisión termina resolviéndose de la misma manera y podemos incorporarla a las reglas automáticas. Otras seguirán apareciendo con demasiadas particularidades y será preferible mantenerlas fuera.

Buena parte del trabajo de automatización del back office acaba bajando a este nivel de detalle. El documento llega, sus datos se extraen, los sistemas están conectados y aun así queda por resolver qué hacemos cuando la realidad trae una versión que no coincide exactamente con la que esperábamos.

En muchas organizaciones esa decisión ya se está tomando hoy, solo que la toma alguien de manera manual después de consultar varias pantallas, revisar la documentación o preguntar a otro departamento.

Cuando queremos que el proceso avance con mucha menos intervención, esas pequeñas decisiones también tienen que formar parte de su diseño.

Si en tu organización estas comprobaciones siguen dependiendo de personas que contrastan documentos, revisan varias aplicaciones y corrigen datos manualmente, es un buen punto para estudiar cuánto de ese proceso puede automatizarse.

FAQ