Tu equipo de operaciones identificó la brecha. El software existente no la cerrará. ¿Construir o comprar? Ese marco omite el único camino que cierra la brecha este trimestre.

TL;DR

Lo que el comprador realmente pregunta

La pregunta de “construir vs comprar” surge después de que el responsable de operaciones ha identificado una brecha concreta, y ese replanteamiento es incorrecto. Ambos caminos se miden en trimestres; la brecha consume margen cada turno. El marco de decisión que necesitas tiene tres caminos con criterios concretos para cada uno.

La brecha se identificó antes de que llegara la pregunta de construir vs comprar

La brecha es real. Un contratista de climatización no puede actualizar automáticamente las órdenes de trabajo a partir de los mensajes de texto de los técnicos. Un operador de 3PL no puede conciliar el estado de piezas en camión en tiempo real. Un propietario de flota no puede vincular el tiempo de inactividad con los datos de telemática. El operador pidió software a IT, e IT consultó con compras. Compras preguntó: ¿construir o comprar?

Por qué la disyuntiva binaria es el marco equivocado

Ambos caminos se extienden durante trimestres. La brecha consume margen cada semana. Un marco de decisión con tres caminos y criterios claros para cada uno supera a una tabla de pros y contras de dos opciones. La disyuntiva binaria omite el único camino diseñado para la brecha entre lo que el proveedor SaaS entregará en 24 meses y lo que el desarrollo interno no puede financiar este año.

Lo que realmente entrega comprar en 2026

Para flujos de trabajo estructurados y repetibles, el SaaS maduro se despliega más rápido de lo que cualquier equipo interno puede construir. Los equipos de servicio de campo en un FSM, las flotas de vehículos en un FMS de grado telemático y las plantas con ERP+EAM se benefician de ello. Para el trabajo fuera del sistema que impulsa el FTFR, el MTTR y el margen, la respuesta del proveedor siempre es la misma: “está en la hoja de ruta”, de 18 a 24 meses vista, no este trimestre.

Dónde el SaaS gana de forma clara

Lo que tu FSM no cierra es el 60% de la realidad operativa que permanece fuera del sistema. Planificación, despacho, órdenes de trabajo móviles, registro de activos, planificación de rutas y facturación: el SaaS maduro los entrega más rápido y más barato de lo que los equipos internos pueden construirlos, y el FSM funciona. El FMS funciona. El stack ERP+EAM funciona para lo que fue diseñado.

Dónde se agota la hoja de ruta del proveedor

Para la señal fuera del sistema que mueve el FTFR, el MTTR, el OEE y el margen contractual, la respuesta del proveedor es siempre la misma: está en la hoja de ruta, de 18 a 24 meses vista. El precio por puesto implica pagar por un techo que el responsable de operaciones alcanzó hace tiempo. La investigación State of Service de Salesforce, basada en más de 5.500 profesionales del servicio, reveló que los trabajadores móviles pierden más de siete horas semanales en tareas administrativas que el sistema debería haber absorbido. Cómo la telemática de flota alcanzó su techo es la misma historia en todos los sectores. Los costes de cambio se acumulan cuanto más se prolonga la brecha en la hoja de ruta.

Lo que realmente cuesta construir en 2026

Equipo mínimo: 1 PM de plantilla, 2 o 3 ingenieros senior, 1 diseñador y soporte de DevOps. Eso supone un TCO total de $1,5M a $5M para la v1 de un solo flujo de trabajo. De nueve a dieciocho meses hasta el lanzamiento. Uno de cada seis proyectos de IT estudiados tuvo una desviación de costes del 200% de media y una desviación de calendario de casi el 70%. El responsable de operaciones que espera al desarrollo interno compite por capacidad contra funcionalidades que generan ingresos.

El recuento honesto de personal y el calendario para un solo flujo de trabajo

Un flujo de trabajo no trivial (integración de despacho, conciliación de piezas, mantenimiento predictivo) requiere un PM para definir el alcance, dos o tres ingenieros senior, un diseñador de UX y soporte de DevOps para el pipeline. Eso equivale a un coste total de $1,5M a $5M y de nueve a dieciocho meses para la v1 en una empresa tecnológica de tamaño medio, en línea con la investigación de McKinsey que muestra que los grandes proyectos de IT entregan un 56% menos de valor del previsto.

El coste oculto que la mayoría de los patrocinadores internos no reconocen

El coste real no es el presupuesto. Es la brecha funcionando fuera del sistema durante dieciocho meses. Cada mes que el flujo de trabajo vive en WhatsApp es un mes de tiempo de inactividad evitable, objetivos de FTFR incumplidos y trabajo manual. El responsable de operaciones compite por la capacidad de desarrollo interno contra funcionalidades de ingresos trimestrales. La investigación de McKinsey sobre más de 5.400 proyectos de IT, realizada con la University of Oxford, reveló que los grandes proyectos de IT superan el presupuesto en un 45% y el calendario en un 7% de media, mientras entregan un 56% menos de valor del previsto.

Cuándo comprar sigue ganando

Flujos de trabajo genéricos: todo lo que el FSM/FMS/ERP/EAM ya entrega con madurez. Planificación, despacho, órdenes de trabajo móviles, planificación de rutas, facturación y registro de activos: cómpralo. Los flujos de trabajo de back-office y recursos humanos sin variación de campo son casi siempre más rápidos y baratos como SaaS. Si el requisito es “solo necesitamos lo que tienen todos los demás”, el tercer camino no es para este alcance.

Cuándo construir sigue ganando

Un sistema de registro desde cero que requiere un modelo de datos personalizado desde el primer día exige una construcción interna real. Estos proyectos necesitan capacidad de desarrollo completa y plazos de varios años. Los datos regulados o soberanos que no pueden salir de tu cortafuegos deben permanecer internamente. Lo mismo aplica a los flujos de trabajo que SON tu ventaja competitiva. Los programas de transformación digital plurianuales en los que se reconstruye todo el stack tecnológico son adecuados para desarrollos internos. No son adecuados para una brecha de flujo de trabajo único que debe cerrarse este trimestre.

El tercer camino: software a medida, hecho para ti

Un proveedor escribe software funcional para la brecha específica que el stack existente no cierra, y se integra con el FSM/FMS/ERP/EAM/CMMS. Se entrega en semanas. El cliente paga solo cuando aparece el beneficio operativo. Esto llena la brecha entre lo que el proveedor SaaS entregará en 24 meses y lo que el equipo interno no puede financiar este trimestre.

Qué es y qué no es

No es SaaS estándar ni una aplicación interna personalizada. Un proveedor construye software funcional para la brecha específica que el stack existente no cierra. Capturar datos fuera del sistema desde WhatsApp y radio es la clave. Esta es precisamente la capa que representa aproximadamente el 60% de la realidad operativa en los sectores impulsados por el campo. Ejemplo: un contratista de climatización multirregional cuyo FSM gestiona la planificación y el despacho, pero no puede capturar los mensajes de texto de los técnicos fuera de horario ni actualizar automáticamente la orden de trabajo. La capa de software a medida construye ese flujo de trabajo sobre el FSM existente, integrándose mediante captura de datos agéntica y alcanzando la capa que el FSM no cubre.

La unidad de trabajo: un flujo de trabajo, semanas en lugar de trimestres

El alcance es una brecha de flujo de trabajo. El plazo es semanas, no trimestres. Flujos de trabajo operativos activados por AI sobre el FSM existente, sin reemplazarlo. Se integra con SAP, Maximo y Navis sin sustitución de sistemas mediante REST y webhooks. La unidad de trabajo está acotada, el plazo está comprimido y el riesgo recae sobre el proveedor.

Opsima es la fábrica de software nativa en IA para operaciones industriales. Construye el software de CMMS, TMS, TOS, EAM, ERP, monitoreo de equipos y procesamiento de documentos sobre el que funciona su operación, adaptado a cómo trabaja realmente su operación.

Dos modos de servicio: (1) adaptar sobre su stack existente (SAP, Maximo, MainPac, Navis, Priority, JDE, AS400) sin reemplazar ningún sistema, o (2) construir el reemplazo desde cero cuando el sistema legacy se ha quedado pequeño. Entrega en semanas. Usted paga solo cuando ve el valor.

PNCT (Port Newark Container Terminal) es el caso de referencia: tras reemplazar un backlog de integración IT de 12 meses con una capa de software a medida, pasaron de aproximadamente 1.000 a aproximadamente 14.000 cambios de estado de equipos estructurados al mes, lograron +5% de disponibilidad de flota y redujeron las averías aproximadamente un 15%. Software funcionando en semanas, bajo la gobernanza de IT, sobre la infraestructura que ya tenían.

Cómo compras enmarca el tercer camino

SOW acotado, hito de software funcional y puerta de confirmación de valor. Encaja de forma natural con el lenguaje de compras sin el compromiso de capex de 9 a 18 meses de una construcción ni el bloqueo de opex por puesto de una compra. La propiedad intelectual, la residencia de datos y la arquitectura de integración se responden desde el principio: el software funciona sobre los sistemas existentes y se integra mediante REST/webhooks con el ERP/CMMS/FSM, sin sustitución de sistemas.

El modelo de precios: ni por puesto ni capex

No es opex por puesto ni capex plurianual. SOW acotado, hito de software funcional (semanas) y puerta de confirmación de valor (el beneficio operativo se mide antes del pago). El modelo comercial coincide con el modelo de gobernanza: todo en staging primero, revisión y aprobación de IT y, después, despliegue en producción. El cliente paga solo cuando aparece el beneficio operativo.

Lo que IT necesita responder antes de aprobar

Entorno de staging: el software se construye en un entorno de staging gobernado. Nada toca producción hasta que IT lo aprueba. Evaluación de riesgos automatizada: cada flujo de trabajo se analiza para detectar problemas de acceso a datos, vulnerabilidades de seguridad y cumplimiento de gobernanza antes de la revisión de IT. Registro de auditoría: control de versiones completo, capacidad de reversión y registros de cambios. La visibilidad operativa en tiempo real expone los datos integrados en el panel unificado, e IT mantiene el control.

Cómo funciona en operaciones de campo: un ejemplo paso a paso

El TMS de un operador 3PL regional gestiona la planificación de rutas y la asignación de cargas, pero no puede conciliar el estado de piezas en camión, y los conductores reportan por WhatsApp. Las discrepancias se detectan con un día de retraso y se reconcilian manualmente contra los registros del WMS del almacén. Esta brecha en el flujo de trabajo puede costar decenas de miles de dólares al mes en trabajo de conciliación y excepciones por entregas tardías.

Semana 0: sesión de trabajo inicial

El 3PL aporta: documentación del sistema TMS, integración con el WMS, ejemplos de mensajes de WhatsApp de conductores que generan discrepancias, y la definición de “piezas conciliadas.” El proveedor aporta: un agente de descubrimiento que entrevista al equipo por Teams, genera requisitos, produce mockups y construye un caso de negocio. La semana 0 es una sesión de trabajo, no una demo.

Semanas 2-4: software funcionando en entorno de staging

La captura automática de actualizaciones de estado desde WhatsApp y radio y la sincronización del estado conciliado de vuelta al TMS y a un panel de operaciones en vivo convierten el estado de piezas en camión en datos estructurados. El panel muestra las discrepancias en tiempo real. El 3PL comienza a ver el impacto operativo.

Semanas 4-6: confirmación de valor y despliegue a producción

El tiempo de detección de discrepancias cae de días a minutos. El operador 3PL confirma el impacto operativo. IT revisa el entorno de staging, aprueba la integración, valida la evaluación de riesgos y el software pasa a producción. El cliente paga solo después de confirmar el impacto. Los paneles automatizados de MTBF y MTTR miden la mejora en los KPI y activan la condición de pago.

Seis preguntas para decidir qué camino corresponde

Pregunta 1: ¿Está la brecha en el roadmap publicado del proveedor en menos de seis meses? Compre y espere. Pregunta 2: ¿Es el flujo de trabajo su ventaja competitiva o requiere datos soberanos que no pueden salir de su perímetro? Desarrolle internamente. Pregunta 3: ¿Funciona completamente detrás del firewall sin llamadas externas? Desarrolle. Pregunta 4: ¿Es la brecha principalmente una señal fuera del sistema (WhatsApp, radio, foto, voz, papel) que el FSM/FMS/ERP/EAM no puede ingerir? Tercer camino. Pregunta 5: ¿Está la capacidad interna de desarrollo a seis meses o más para este flujo de trabajo? Tercer camino. Pregunta 6: ¿Está a punto de firmar un contrato SaaS de seis cifras por una funcionalidad que necesita este trimestre? Tercer camino. Lleve esta lista de verificación a su próxima reunión de IT.

Conclusión: lleve la brecha a una sesión de trabajo

La disyuntiva entre desarrollar o comprar era la pregunta correcta para otra era. En 2026, omite el único camino construido para la brecha entre lo que el proveedor SaaS entregará en dos años y lo que el desarrollo interno no puede financiar este año. El núcleo de datos operativos impulsa software a medida que opera sobre los sistemas existentes. Si su operación abarca puertos, minería, logística y manufactura y su brecha de despacho vive fuera del sistema, traiga el flujo de trabajo específico que su proveedor de FSM/FMS/ERP/EAM le dijo que estaba en el roadmap. Vea cómo es entregar en semanas. Los benchmarks de MTTR y disponibilidad de flota muestran cuánto está en juego. Traiga su brecha de flujo de trabajo a una sesión de trabajo y descubra cómo es el tercer camino.

Deja de perder eventos operativos en hojas de cálculo.

Alrededor del 60% de tus datos ops viven fuera del sistema. Opsima los captura en software personalizado, en semanas.

Ver cómo funciona →