Dos proveedores pueden presupuestar la conexión del mismo CRM, sistema de pedidos y programa de contabilidad y estar hablando de trabajos muy distintos. Uno quizá envíe los pedidos nuevos. El otro puede incluir la correspondencia entre clientes, devolver el estado contable, gestionar cambios posteriores e incorporar registros antiguos.
Para comparar los presupuestos, describa qué debe ocurrir con un pedido concreto y quién comprueba el resultado. El número de aplicaciones indica dónde se trabaja. Las reglas entre ellas determinan qué hay que construir.
Siga un pedido a través de la conexión
Imagine una empresa mayorista ficticia. Ventas guarda los contactos de clientes en el CRM, el personal acepta pedidos en un sistema de pedidos y finanzas utiliza un programa de contabilidad independiente. La empresa quiere que un pedido aceptado genere un borrador de documento para que finanzas lo revise.
Tomemos el pedido ORD-204. Su cliente tiene el identificador C-81 en el CRM y la cuenta A-347 en contabilidad. Alguien debe establecer que ambos identificadores corresponden al mismo cliente. Comparar solo el nombre de la empresa deja la decisión pendiente si el nombre cambia o hay dos registros parecidos.
Después, decida qué sistema es responsable de cada dato. El CRM podría aportar el nombre del contacto; contabilidad, los datos de facturación aprobados; y el sistema de pedidos, las cantidades aceptadas y los precios acordados. Son reglas propuestas para este ejemplo. Cada empresa debe acordar las suyas.
También hay que definir qué significa «aceptado». Que ventas acepte un pedido no implica que finanzas haya aprobado el documento resultante. La documentación de Microsoft sobre Dynamics 365 Sales ilustra esta diferencia mediante etapas separadas para presupuestos, pedidos y facturas. Es el flujo de un producto concreto. La conexión debe seguir las reglas del software y del negocio que usted utiliza.
Los mismos tres sistemas, distintos alcances
Estos son tres posibles alcances para la empresa ficticia. Cada uno añade trabajo de definición, implementación y comprobación, siempre que los productos utilizados permitan las acciones necesarias.
Solo pedidos nuevos
Cuando el personal acepte un pedido nuevo, envíe los campos acordados y los identificadores de cliente existentes a contabilidad para crear un borrador. Finanzas lo revisa allí. Las correcciones posteriores siguen siendo manuales y se asignan a un equipo concreto.
Cambios acordados y respuesta
Defina también qué cambios posteriores del pedido pueden transferirse, qué ocurre después de que finanzas revise el documento y qué estado contable vuelve al sistema de pedidos. Asigne a una persona los cambios que queden sin resolver.
Con registros existentes
Añada un periodo seleccionado de pedidos antiguos y los registros de clientes relacionados. Relacione sus identificadores, resuelva los problemas de datos acordados y compruebe el conjunto importado antes de iniciar las transferencias continuas.
El alcance menor puede ser suficiente. El trabajo manual debe figurar en la propuesta para que quien compra pueda decidir si le sirve. Los alcances mayores necesitan describir expresamente sus rutas y decisiones adicionales.
Prepare un mapa de conexiones que se pueda presupuestar
Empiece por la ruta del sistema de pedidos a contabilidad y anote qué la inicia: «Un pedido pasa a aceptado en el sistema de pedidos». Registre el identificador del pedido y la correspondencia entre identificadores de cliente. Enumere los campos que se transfieren y, cuando corresponda, cómo se interpretan cantidades, descuentos, moneda y estado. Acuerde cualquier tratamiento contable con las personas responsables.
Indique la acción en destino: crear un borrador, actualizar un borrador que aún pueda modificarse o remitir el caso a finanzas. Señale quién puede aprobarlo. Fije el plazo esperado y cuándo debe investigarse una transferencia pendiente. «Periódicamente» da al proveedor menos información que un plazo acordado según las necesidades del negocio.
Describa por separado cada ruta de vuelta. Que contabilidad devuelva el identificador de un documento es una acción; que devuelva el estado de un pago es otra. Ninguna implica que todos los datos del cliente o todos los documentos puedan editarse en ambos sistemas.
La guía de Microsoft sobre la traducción entre sistemas explica por qué las diferencias de significado entre datos exigen un tratamiento deliberado, y señala que habrá que considerar el mantenimiento y la supervisión. Describe un patrón de arquitectura, no un requisito para todas las conexiones. A efectos del presupuesto, lo importante es identificar ese trabajo de traducción en vez de suponer que dos campos con nombres parecidos significan lo mismo.
Una descripción útil de la ruta ORD-204 podría decir: crear un borrador para este pedido aceptado con la correspondencia de cliente acordada; devolver el identificador contable; mostrar los casos pendientes a la persona coordinadora de finanzas. La propuesta también debe definir cómo se tratan las notificaciones repetidas y los resultados inciertos. Es un requisito que hay que acordar y verificar, no una promesa de que cada entrega ocurra exactamente una vez.
Acuerde cómo comprobará el resultado el personal
Defina qué cuenta como completado en cada ruta. Un mensaje enviado no demuestra por sí solo que exista el borrador previsto con el cliente y los totales correctos. Acuerde cómo comparar los registros de origen y destino, detectar resultados ausentes o discrepantes y encontrar los identificadores necesarios para investigarlos.
Designe a la primera persona o equipo que recibirá cada incidencia, la información que podrá consultar y quién podrá corregir el registro de origen o autorizar otro intento. Incluya casos como un cliente desconocido, un campo rechazado o una corrección que llega después de la revisión. Decida cuáles resolverá el personal manualmente.
Así, el mapa de conexiones se convierte en una guía de trabajo: evento que inicia la ruta, datos de referencia, identificadores, dirección, significado de los campos, acción en destino, plazos, comprobación final y responsable de las incidencias. Añada quién facilitará cuentas de prueba y confirmará que el resultado es aceptable.
Delimite los datos históricos
«Incluir pedidos antiguos» plantea más preguntas de las que resuelve. Elija los tipos de registro y el periodo, decida qué registros de clientes relacionados hacen falta y asigne la tarea de relacionarlos y depurarlos. Indique qué se comprobará después de la importación.
Separe ese trabajo puntual de las transferencias continuas. Acuerde dónde termina el conjunto histórico y empieza el procesamiento actual, y cómo se tendrán en cuenta los cambios durante la transición. De lo contrario, dos proveedores pueden prever distinta preparación y comprobación aunque ambos escriban «importación de datos» en su propuesta.
Compare los supuestos y el trabajo posterior
Pida a cada proveedor que presupueste el mismo mapa de conexiones. Solicite que indique qué ha confirmado sobre las versiones de los productos, las operaciones permitidas, los permisos, los límites de las interfaces y las condiciones de los conectores, y qué queda por comprobar. Que exista una API o aparezca el logotipo de un conector no demuestra que su cuenta pueda ejecutar la acción necesaria.
Cuando falte acceso o una regla siga sin decidirse, pregunte cómo se resolverá esa incertidumbre y qué efecto tiene en la propuesta. La guía del Gobierno británico sobre contratación ágil explica cómo la información incompleta influye en las decisiones comerciales de la contratación pública. Para esta comparación, la lección útil es dejar claros los supuestos antes de considerar equivalentes dos compromisos.
Separe la configuración y las pruebas iniciales de las suscripciones periódicas al software o a los conectores. Después, identifique el trabajo de operación y mantenimiento acordado: cuidar las credenciales, revisar las transferencias pendientes, adaptar las correspondencias entre datos y gestionar cambios de compatibilidad. Pregunte qué incluye la propuesta, quién se ocupa y cómo se acuerdan los cambios posteriores. La línea de una suscripción no aclara esas responsabilidades.
Termine la comparación siguiendo ORD-204 en cada propuesta. ¿Puede ver qué llega, cuándo llega, qué ocurre si el proceso no se completa y quién se hace cargo? Cada diferencia es una decisión sobre el alcance que conviene resolver antes de comparar los importes.
Si quiere hablar con LINK-V sobre una conexión definida, nuestro servicio de integración de API es un punto de partida adecuado. Traiga las rutas y las preguntas pendientes. El alcance y la atención posterior se acuerdan para cada proyecto.
Preguntas sobre presupuestos de integración
¿Un conector existente define todo el alcance de la integración?
Puede cubrir parte de la transferencia. Compruebe la versión del producto, los permisos y las operaciones disponibles, y acuerde para sus rutas el significado de los campos, las aprobaciones, los cambios posteriores y la gestión de incidencias.
¿Por qué influyen los datos históricos en el presupuesto?
Los registros antiguos pueden requerir relacionar identificadores, depurar datos, incluir registros vinculados y verificar el resultado. Defina tipos de registro y periodo, quién los prepara y dónde la importación da paso a las transferencias continuas.
¿Quién debe mantener la conexión tras la puesta en marcha?
Indique en la propuesta quién cuidará las credenciales, revisará las transferencias pendientes, cambiará las correspondencias entre datos y atenderá los problemas de compatibilidad. Separe ese trabajo acordado de las suscripciones y establezca cómo se gestionan el soporte y los cambios posteriores.
