Sus sistemas funcionan. Lo que se pierde está entre ellos.

Una integración que falla no avisa: deja un hueco que alguien llena a mano

Un pago que salió del canal y no llegó a contabilidad. Una póliza emitida que el CRM no conoce. Un socio que no puede cobrar desde su sistema y le manda un archivo por correo. Cada sistema dice que todo está bien, y la diferencia la absorbe su gente, con hojas de cálculo, al cierre. Cuando las conexiones crecen sin un mapa, el trabajo manual se vuelve parte de la operación.

Qué ofrecemos

• Cambiar un sistema con el menor impacto en los demás.

  Cuando reemplaza su ERP o su core, diseñamos la convivencia por etapas: sus canales y su operación siguen alimentando al sistema correcto, con la confirmación de cada envío. Se migra por tramos, no de golpe en un fin de semana.

• Cada envío con su respuesta y su motivo.

  Cada operación entre sistemas queda registrada con su respuesta, su hora y el motivo si falló. Las excepciones quedan a la vista de su equipo, en vez de aparecer en el cierre o en una queja.

• Su core conectado a lo que lo rodea.

  Cores de seguros —Acsel/X, SIVI, SABE, SIS/SISnet, Guidewire, Duck Creek u otro— y cores bancarios —Temenos, FLEXCUBE, Bantotal u otro— con su CRM, su ERP, sus canales y sus socios, por las interfaces que ya exponen: el conjunto de servicios SOAP de Guidewire, los servicios y tablas de SIVI, SABE o SIS/SISnet, o lo que su core ofrezca. Si su sistema corre en IBM i (AS/400), sus programas RPG se vuelven servicios que sus canales y sus socios pueden llamar, sin reescribirlos. Y si sus sistemas viven sobre Oracle —Siebel, E-Business Suite, Acsel/X, SIS/SISnet u otro—, nos conectamos por sus procedimientos almacenados o por tablas de intercambio, sin tocar su lógica ni sus pantallas, aunque sean aplicaciones de escritorio de hace veinte años. Cuando su política lo permite, sus consultas sobre las tablas del core se vuelven servicios REST de solo lectura, con permisos y registro de cada llamada. Y si su integración vive en la familia WebSphere de IBM —servidor de aplicaciones, MQ, ESB o Business Integration—, la conocemos desde dentro: llevamos más de veinte años trabajando con ella. Sus datos, donde estén: Oracle, DB2 (también en IBM i), Informix, SQL Server, PostgreSQL, MySQL, MariaDB, MongoDB u otra. Y sus documentos, en su gestor documental —Alfresco, SharePoint u otro—, ligados a la operación que los originó.

• Su ERP por sus interfaces estándar.

  SAP (S/4HANA, Business One), Oracle, Microsoft Dynamics 365, Odoo, CONTPAQi u otro: priorizamos las interfaces que el propio fabricante soporta —en SAP, por ejemplo, JCo, OData, IDoc o REST—, para no dejarle desarrollos a la medida que estorben al actualizarlo. Si alguna extensión es inevitable, se lo decimos en el diagnóstico.

• APIs para sus socios.

  Bancos, tiendas, brókers y distribuidores cotizan, emiten o cobran desde su propio sistema, con su identidad, sus permisos y su propio rastro, en REST o GraphQL según lo que necesite quien consume.

• Una puerta de entrada única para sus APIs.

  Identidad, permisos y registro de cada llamada en un solo punto, con la puerta de enlace que convenga —Apigee, Azure API Management, Amazon API Gateway, Kong, WSO2, APISIX u otra—, sin meter ahí reglas de negocio que después nadie pueda probar. Detrás pueden vivir sus servicios de siempre o funciones en la nube que solo cobran cuando se usan.

• Eventos entre sistemas, sin efectos duplicados.

  Cuando un sistema necesita enterarse de lo que pasó en otro, se avisa por colas o eventos —IBM MQ, Kafka, RabbitMQ, ActiveMQ u otro—. Un aviso puede llegar dos veces; el diseño hace que la operación impacte su negocio y su contabilidad una sola vez.

• Cobro, facturación y SAT en el mismo flujo.

  Pasarelas y bancos, conciliación de cada cobro, CFDI con su complemento de pago y cancelaciones, orquestados hacia su proveedor de timbrado.

• Sus datos personales, protegidos en el camino.

  Viajan cifrados entre sistemas, salen enmascarados en las bitácoras y solo se envía a cada sistema lo que necesita. Las reglas se definen con su equipo, contra sus políticas.

• Salir de su bus heredado sin apagarlo de golpe.

  Si sus integraciones viven en WebSphere ESB, IBM Integration Bus, MuleSoft, WSO2 o procesos de Pentaho que ya nadie quiere tocar, las conocemos porque las construimos durante años. Las mantenemos en pie mientras las pasamos, tramo por tramo, a una capa que su equipo pueda operar y cambiar.

Lo que su área de Cumplimiento recibe

Cada operación entre sistemas queda registrada con su respuesta, su hora y su motivo si falló; los accesos de socios y sistemas, por credencial y con bitácora; los datos personales, enmascarados en las bitácoras. Evidencia consultable para su auditor, sin buscarla en correos.

El diagnóstico, en dos niveles

1. Primera conversación, sin costo.

   El mapa de las conexiones entre sus sistemas y los tres puntos donde probablemente se pierde dinero, tiempo o rastro.

2. Diagnóstico a fondo, con alcance acordado.

   Qué descuadres están vivos, qué riesgo fiscal atender primero y una ruta por etapas.

Quién revisa su diagnóstico: Trabajamos con pocos clientes a la vez: quien revisa su diagnóstico sigue su proyecto hasta el final.