APIs y sistemas de gestión a medida

Tu operación ya tiene reglas. El software debería seguirlas.

Diseñamos APIs y sistemas de gestión para empresas cuya forma de trabajar no entra en un producto enlatado: un contrato de datos escrito antes que el código, integración con los sistemas que ya usás y la historia anterior migrada con su contexto.

Ninguno de estos tres problemas se arregla comprando otra licencia.

La planilla ya no da.

Funcionó hasta que fueron cuatro personas cargando la misma. Ahora hay tres versiones del archivo, alguien pisó una fila sin querer y nadie se acuerda de cuál era la buena.

Dos sistemas que no se hablan.

El mismo dato se carga dos veces: una en facturación y otra en el sistema de la operación. Cuando difieren, gana el que revisó último.

El enlatado manda.

Funciona, pero impone su forma de trabajar. Cada excepción de tu negocio termina en una planilla aparte, y eso devuelve todo al problema uno.

Cuatro trabajos distintos. Casi nunca hacen falta los cuatro.

API propia con contrato claro

Cada dato tiene nombre, tipo y una respuesta definida para cuando algo falla. Ese contrato se escribe antes que el código: es lo que permite conectar un sistema nuevo el año que viene sin volver a tocar el primero.

Integración entre sistemas existentes

Facturación, depósito, la planilla del vendedor. En vez de reemplazarlos, se los conecta para que el dato se cargue una vez y viaje.

Migración de datos sin perder historia

Los años anteriores entran con su contexto: quién, cuándo y contra qué documento. Un sistema nuevo que arranca vacío obliga a dejar el viejo prendido para consultar, y entonces no reemplazó nada.

Operación medible

Registro de lo que pasa, métricas de uso, alertas y respaldo. Es la diferencia entre «el sistema anda lento» y saber qué consulta se volvió lenta, desde cuándo y para quiénes.

Primero se entiende la operación. Después se escribe el código.

  1. 01

    Relevamos la operación real.

    No el organigrama: lo que pasa un martes. Quién carga qué, en qué momento, y qué planilla aparece cuando el sistema no alcanza.

  2. 02

    Definimos el contrato de datos.

    Qué entidades existen, qué campos son obligatorios y qué pasa cuando llega un dato incompleto. Escrito y acordado antes de la primera pantalla.

  3. 03

    Construimos e integramos por etapas.

    Un módulo entra en uso mientras el resto sigue como está. Si una etapa no funciona, se corrige con la operación andando y no en una migración de una sola noche.

  4. 04

    Medimos y evolucionamos.

    Con el sistema en uso aparecen los casos que nadie mencionó en la reunión. Se ajusta con esa información, no con la suposición inicial.

Evidencia, no promesa

Control Romeva se diseñó exclusivamente para la operación de Transporte Romeva. Conecta cotizaciones, hojas de ruta, remitos, facturas, cobranzas, compras, inventario, flota, personal y control financiero: cotizar y cobrar ocurren dentro del mismo sistema, cada rol accede a lo que necesita y cada movimiento conserva su contexto. Es lo que podemos publicar —el alcance, no las pantallas— y alcanza para ver de qué tamaño puede ser un sistema a medida cuando la operación entera entra en él.

Ver el caso Control Romeva

Preguntas frecuentes

¿Qué es una API y para qué la querría?

Es la puerta por la que dos programas se pasan datos sin que una persona los copie a mano. Si tu facturación tiene la lista de clientes y tu sistema de reparto tiene otra, la API es lo que hace que sean la misma lista en vez de dos que se van separando. No siempre hace falta: si un solo sistema cubre todo el circuito, una API agrega una pieza más para mantener.

¿Reemplaza mi sistema actual o se integra?

Depende de dónde esté el problema. Si el sistema hace bien su trabajo y sólo está aislado, se integra: sale más barato y no obliga a reentrenar a nadie. Se reemplaza cuando la herramienta impone un circuito que la operación no puede seguir, y eso se decide después del relevamiento, no antes.

¿Qué pasa con mis datos históricos?

Se migran con su contexto: quién, cuándo y contra qué documento. Es la parte más lenta del proyecto y la que más sorpresas trae, porque los datos viejos casi nunca están tan ordenados como se recuerda. Un sistema nuevo que arranca vacío obliga a dejar el viejo prendido para consultar, y eso no es una migración: es un sistema más.

¿De qué depende el costo?

De tres cosas que se pueden contar: cuántos circuitos entran (cotizar, facturar, cobrar, comprar, controlar stock), con cuántos sistemas hay que hablar, y en qué estado están los datos que se migran. El relevamiento existe justamente para ponerle número a esas tres antes de comprometer un presupuesto.

¿Quién lo mantiene?

El mantenimiento se acuerda al inicio. Sobre una cosa no hay nada que negociar: el código y los datos son tuyos desde el primer día. Un sistema a medida que no podés llevarte a otro proveedor no es a medida: es un alquiler con otro nombre. Podés acordar un acompañamiento mensual continuo o resolver por cambios puntuales; en los dos casos, mantener significa que el sistema siga andando cuando algo alrededor cambia —una versión, un proveedor, una regla impositiva— y que haya alguien a quien avisarle cuando no responde.

¿Cómo sé que funciona bien en el día a día?

Porque el sistema avisa antes que un usuario. Cada operación queda registrada, se miden los tiempos de respuesta y hay alertas cuando algo deja de responder. Sin eso, el primero en enterarse de que el sistema está caído es el que estaba por facturar. Qué se mide y qué dispara una alerta se define con vos: una alerta que suena por cualquier cosa termina ignorada, y ahí ya no protege nada.

¿Cuántas veces se carga el mismo dato en tu empresa?

Contanos cómo trabajan hoy y qué se rompe. Empezamos por relevar la operación; recién con eso sobre la mesa se puede decir si hace falta un sistema propio, una integración entre los que ya tenés, o corregir dos pasos del circuito actual. Las tres respuestas son posibles y cuestan muy distinto.

Pedir un relevamiento