Cómo DataOngoing mapea la arquitectura empresarial

De la fricción operativa a la lógica determinista en sprints de dos semanas

La lógica nunca fue el cuello de botella

La mayoría de las empresas medianas y grandes que operan NetSuite, Salesforce o un conjunto de múltiples SaaS creen que su software está roto o es demasiado lento.

Cuando una orden tarda 15 segundos en guardarse, cuando los operadores del almacén asignan lotes desde una hoja de cálculo fuera de línea, o cuando un CFO descubre que el margen bruto de los estados financieros mensuales está desviado seis puntos porque el costo de importación (landed cost) está en una cuenta transitoria, la dirección culpa a la plataforma.

Entonces entran las consultoras tradicionales. Proponen una "fase de diagnóstico y descubrimiento" de seis meses con un precio de entre $250,000 y $400,000. Envían un equipo de analistas junior a entrevistar a los jefes de área, arman una presentación de 120 páginas con diagramas de carriles de alto nivel y concluyen con la recomendación de gastar otros $500,000 en una reimplementación completa.

Rechazamos ese modelo. El software nunca fue el cuello de botella. El motor de base de datos nunca fue el cuello de botella. El cuello de botella fue el razonamiento.

Todo modo de falla empresarial en los más de 100 mapas de sistemas en producción que hemos trazado se remonta a una misma causa raíz: la fragmentación arquitectónica sin gobierno. La lógica de negocio se fue acumulando durante cinco años, script sobre script, flujo de trabajo sobre flujo de trabajo, webhook de middleware sobre webhook de middleware, hasta que las colas de bloqueo de la base de datos se saturaron y la verdad operativa se desconectó del libro mayor.

No escribimos presentaciones que acumulan polvo. Mapeamos la realidad física y económica del negocio, modelamos la lógica determinista de la base de datos y desplegamos software funcional y probado en sprints de producción de dos semanas. Así mapeamos la arquitectura.

1. Las tres capas de la realidad de un sistema empresarial

Para mapear una arquitectura que resista la escala de producción, un arquitecto debe separar la empresa en tres capas y trabajarlas en orden.

1. Capa 1. La realidad económica

   Camiones, tarimas, almacenamiento en frío, facturas de proveedores, contratos con clientes, horas de trabajo y velocidad del margen, todo en su forma física. Moléculas y efectivo.

2. Capa 2. El registro de verdad gobernado (NetSuite o el núcleo del ERP)

   El libro mayor conforme a ACID, el inventario por lote, los subregistros, los calendarios de ingresos, los permisos y el nexo fiscal. Lógica determinista y APIs.

3. Capa 3. La superficie inteligente

   Portales móviles de almacén, ingesta por OCR, sincronización con el CRM, Suitelets a la medida y cadenas de herramientas de trabajadores de IA gobernados. La parte que la gente ve.

La consultoría tradicional empieza en la Capa 3, con el aspecto de la pantalla, y construye una nueva interfaz sobre una lógica de base de datos corrupta.

DataOngoing empieza en la Capa 1. Trazamos el movimiento físico del inventario, las obligaciones contractuales del contrato con el cliente y el flujo de efectivo dólar por dólar. Solo cuando la física económica está modelada diseñamos la Capa 2, las reglas del libro mayor gobernado, e implementamos la Capa 3, la superficie.

2. Los cuatro antipatrones estructurales que eliminamos

Cuando ingerimos y auditamos la arquitectura de una empresa, las mismas cuatro enfermedades estructurales aparecen una y otra vez.

Antipatrón 1: la cadena de bloqueos en cascada de la interfaz (el guardado de 15 segundos)

• El síntoma. Los gerentes de almacén y los representantes de servicio al cliente esperan de 12 a 18 segundos cada vez que guardan una orden de venta o un despacho de artículos. Con volumen pico reciben errores de RCRD_HAS_BEEN_CHANGED por colisión.
• La falla estructural. Ocho scripts de eventos de usuario asociados al mismo tipo de registro por cuatro equipos de desarrollo durante seis años. Cada uno ejecuta sus propias llamadas record.load() y search.create() de forma síncrona en el hilo del usuario, agotando los puntos de gobernanza y reteniendo bloqueos de tabla.
• La solución. El enrutador de punto de entrada único. Todos los disparadores se consolidan en un solo despachador. La validación de solo lectura se ejecuta en un beforeSubmit de menos de un segundo; las asignaciones al libro mayor, las tareas pesadas y las notificaciones a terceros se envían a colas de pipelines Map/Reduce. El guardado baja a menos de 800 milisegundos.

Antipatrón 2: el margen bruto que miente (deterioro de la cuenta transitoria del costo de importación)

• El síntoma. El contralor revisa el cierre de mes y encuentra $250,000 en una cuenta transitoria de fletes y aduanas sin conciliar. Ventas celebró un margen bruto de 42% en papel; el margen real después del costo de importación (landed cost) era de 31%.
• La falla estructural. El flete marítimo, la aduana, el acarreo y el almacenamiento en frío se facturan semanas después de que el inventario fue recibido y vendido. El asiento contable de fin de mes separa el gasto del lote al que pertenecía.
• La solución. Asignación automatizada del costo de importación (landed cost): una provisión estimada registrada en la recepción, la factura real del proveedor conciliada contra el lote específico y el ajuste del COGS escrito en la línea de la transacción. El margen de una venta es real desde el día en que se registra.

Antipatrón 3: el subauxiliar en hojas de cálculo en la sombra (una planta de $50M operada en Excel)

• El síntoma. Una planta de manufactura o un distribuidor de alimentos lleva la programación de lotes de producción, las solicitudes de cambio de diseño o las liberaciones de lotes de QA en una hoja de cálculo en una unidad compartida porque "NetSuite no podía manejar los cálculos".
• La falla estructural. Los formularios estándar rígidos empujan a los equipos operativos fuera del sistema de registro, y cada recaptura introduce errores de digitación, registros huérfanos y pistas de auditoría rotas.
• La solución. Portales de operaciones nativos con Suitelet: interfaces diseñadas a la medida dentro de la propia infraestructura de NetSuite. Los operadores obtienen la velocidad de cálculo de una hoja de cálculo, y cada clic se escribe en un registro personalizado gobernado, con permisos por rol y un historial de auditoría completo.

Antipatrón 4: la red frágil de middleware

• El síntoma. HubSpot, Stripe, Shopify, un 3PL y NetSuite están conectados mediante un iPaaS de arrastrar y soltar. Cuando cambia el formato de una API o se agota el tiempo de un webhook, los pedidos se pierden sin aviso, los envíos quedan sin facturar y alguien concilia a mano.
• La falla estructural. El middleware trata las tablas del ERP como almacenes de clave-valor e ignora las sublistas de transacciones, los subregistros de ubicación de inventario y la revaluación de moneda.
• La solución. Integración directa con RESTlet y colas idempotentes. Los sistemas externos envían datos a endpoints seguros de NetSuite que validan los subregistros obligatorios, respetan los límites de concurrencia y registran hashes de las cargas para que nada se contabilice dos veces. La comparativa entre nativo y middleware detalla el lado de los costos.

3. El estándar de mapeo de procesos

Ya sea que documentemos un entorno existente o diseñemos una modernización desde cero, una transacción correctamente mapeada pasa por cinco estaciones. Quien está al inicio nunca espera por el trabajo del final.

Cinco estándares no son negociables en cada mapa:

1. Transiciones de estado deterministas. Una transacción no puede existir en un estado ambiguo. Cada flujo de trabajo tiene estados explícitos, con control por etapas: Pending Allocation, Allocated, Staged, Fulfilled, Billed.
2. Gobernanza de subregistros y ubicaciones. Una línea de artículo nunca es un valor escalar aislado. Cada línea de inventario se vincula a un subregistro de inventario, a un contenedor o lote específico, y a una subsidiaria y un nexo fiscal declarados.
3. Idempotencia y capacidad de repetición. Cada transacción automatizada almacena un id de referencia externo. Si una integración reintenta cinco veces, actualiza el registro existente y nunca crea un duplicado fantasma.
4. Separación asíncrona de responsabilidades. Nunca haga que una persona espere a una computadora por un cálculo que no cambia su siguiente acción.
5. Conciliación al dólar. Cada automatización que toca el inventario o los ingresos deja un rastro que un controller puede auditar, antes y después, en menos de tres minutos.

4. Del mapa a producción en dos semanas

No creemos en iniciativas de ERP de varios años que nunca muestran valor incremental. El mapeo se hace primero, en la lectura de diligencia de 48-72 horas; la construcción posterior es un sprint de catorce días a precio fijo, con una fuga identificada dentro del alcance.

Si el código no funciona en producción, el hito no se factura. La página Sprint de puntos base de dos semanas contiene los términos.

El siguiente paso

Si su empresa convive con demoras de varios minutos al guardar, fuga de costos de importación (landed cost) sin asignar o integraciones sostenidas con hojas de cálculo, no necesita otra presentación de $300,000. Necesita un arquitecto que entienda el impacto en el balance de cada línea de código.

Las cuatro retrospectivas que aplican este mapa se publican junto con este documento: trazabilidad de lotes perecederos con un cutover en vivo, facturación disparada desde el escaneo del transportista, una columna vertebral de ingresos con HubSpot, Stripe y NetSuite y trabajadores de IA gobernados dentro de NetSuite.

Comience con la lectura de diligencia de 48-72 horas.

Las cifras de este documento son casos compuestos modelados, salvo que una clase de fuente indique otra cosa. Texto fuente: versión en markdown • Servicio: Technology Due Diligence para Private Equity