¿Puede la IA descubrir cómo funciona una empresa? Sí. Pero descubrir no es lo mismo que la verdad operativa.

 

Está surgiendo una narrativa poderosa en torno a la IA empresarial:

 

Conectar la IA a la empresa, permitirle observar datos y actividad de usuarios en todos los sistemas, reconstruir cómo funciona la organización, optimizar esos procesos y, con el tiempo, automatizarlos mediante agentes de IA.

 

De hecho, hay mucho de verdad en esto.

 

Tecnologías como la minería de procesos, la minería de tareas, la minería de procesos centrada en objetos, las ontologías empresariales y la IA agéntica están llevando la Gestión de Procesos de Negocio tradicional (BPM) y la Automatización Robótica de Procesos (RPA) a un nivel completamente distinto.

 

Sin embargo, existe una distinción arquitectónica importante que la narrativa de la IA puede perder fácilmente:

 

Observar un proceso de negocio no es lo mismo que poseer la transacción comercial que lo generó.

 

Y reconstruir una empresa a partir de sus huellas digitales es fundamentalmente distinto de operar la empresa mediante un sistema transaccional específico del dominio.

 

1. ¿Cómo “observa” realmente la IA una empresa?

 

Primero, la IA no entiende mágicamente lo que ocurre dentro de una empresa.

 

En cambio, necesita evidencia.

 

En la práctica, una de las fuentes más importantes de esa evidencia es el registro de eventos generado por los sistemas operativos.

 

Cada vez que un usuario crea una factura, aprueba una orden de compra, registra una recepción de mercancías, completa una orden de trabajo o cierra un ticket de servicio, el sistema subyacente puede generar un evento.

 

Un evento convencional de minería de procesos normalmente requiere al menos:

 

ID de caso + Actividad + Marca de tiempo

 

Por ejemplo:

 

PO-1057 → Requisición de compra creada → 09:02 PO-1057 → Requisición aprobada → 11:43 PO-1057 → Orden de compra emitida → 15:21 PO-1057 → Material recibido → tres semanas después PO-1057 → Factura aprobada → cuatro semanas después

 

Recolecte millones de estos eventos y, entonces, los algoritmos podrán reconstruir el proceso real que siguió la organización.

 

Eso es la minería de procesos.

 

En lugar de preguntar a los empleados cómo funciona el proceso de compras, el sistema lo reconstruye a partir de evidencias. En otras palabras, muestra cómo miles de transacciones de compras se movieron realmente a través de la empresa.

 

Luego puede identificar:

 

• variantes de proceso;
• cuellos de botella;
• bucles y retrabajos;
• secuencias inusuales;
• retrasos en aprobaciones;
• desviaciones de cumplimiento;
• actividades duplicadas;
• y oportunidades potenciales de automatización.

 

Esto ya es considerablemente más científico que los talleres tradicionales de BPM. Al fin y al cabo, se basa en evidencia transaccional observada y no solo en entrevistas y diagramas de procesos preparados manualmente.

 

2. ¿Pero qué ocurre fuera del ERP?

 

Aquí es donde la minería de tareas amplía el panorama.

 

Después de todo, no todas las actividades empresariales generan un evento limpio en el ERP.

 

Por ejemplo, un empleado puede:

 

abrir un correo electrónico → descargar un archivo de Excel → copiar una cantidad → abrir SAP → buscar una PO → cambiar a otra aplicación → copiar un valor → volver a Excel → enviar un correo de aprobación.

 

La tecnología de minería de tareas, a su vez, puede capturar elementos de esta actividad de escritorio.

 

Según la tecnología y la configuración, esto puede incluir interacciones con aplicaciones, eventos del navegador, clics, acciones de teclado, elementos de interfaz de usuario y capturas de pantalla.

 

Los algoritmos de aprendizaje automático pueden agrupar luego miles de estas observaciones e identificar secuencias recurrentes.

 

En lugar de descubrir simplemente:

 

Orden de compra creada → Orden de compra aprobada

 

la plataforma puede descubrir, por tanto, la actividad humana que rodea esas transacciones.

 

En resumen, de ahí proviene la idea popular de que la IA “observa cómo funciona la empresa”.

 

Aun así, no es magia.

 

Más bien, es esencialmente:

 

Eventos digitales + telemetría de interacción del usuario + contexto + análisis estadístico/aprendizaje automático → reconstrucción de procesos

 

3. Del Process Mining al Process Mining Centrado en Objetos

 

Sin embargo, el process mining tradicional tiene una limitación importante.

 

En la práctica, las empresas reales no operan en torno a un único “caso” aislado.

 

Por ejemplo, una orden de compra puede relacionarse simultáneamente con:

 

• varias líneas de orden de compra;
• múltiples materiales;
• uno o más proveedores;
• facturas;
• entregas;
• proyectos;
• órdenes de producción;
• contratos;
• empleados;
• activos.

 

El Object-Centric Process Mining (OCPM) moderno intenta preservar estas relaciones.

 

En lugar de reconstruir solo una secuencia lineal alrededor de un Case ID, modela las interacciones entre múltiples objetos de negocio.

 

Como resultado, el modelo se acerca más a:

 

Proveedor ↔ OC ↔ Material ↔ Factura ↔ Entrega ↔ Proyecto

 

Esto supone un avance significativo porque la realidad empresarial es relacional y no simplemente secuencial.

 

4. Luego Viene la Capa Semántica o de Ontología

 

A continuación, plataformas como Palantir dan otro paso.

 

Pueden transformar datos de ERP, CRM, MES, SCM, bases de datos, documentos y sistemas externos en objetos empresariales.

 

Como resultado, una fila de base de datos se convierte en algo significativo:

 

• Proveedor
• Orden de compra
• Empleado
• Máquina
• Proyecto
• Factura

 

Luego, la plataforma establece relaciones entre esos objetos.

 

Por ejemplo:

 

• Proveedor → suministra → Material
• Material → requerido por → Proyecto
• Orden de compra → emitida a → Proveedor
• Factura → hace referencia a → Orden de compra
• Máquina → asignada a → Proyecto

 

De este modo, la plataforma crea una representación legible por máquina de la empresa.

 

Después, la siguiente capa añade:

 

• Datos + Lógica + Acciones + Seguridad

 

En consecuencia, un agente de IA ya no se limita a recuperar una fila de base de datos.

 

En su lugar, puede razonar sobre un objeto empresarial, comprender sus relaciones, invocar lógica aprobada y potencialmente ejecutar una acción autorizada.

 

Esto es enormemente poderoso.

 

Pero observe algo importante:

 

¿De dónde surgieron la mayoría de esos objetos y transacciones empresariales?

 

Con frecuencia, de ERP, CRM, SCM, MES, RR. HH., gestión de proyectos y otros sistemas operativos.

 

En otras palabras, la capa de inteligencia está creando una representación más rica de la realidad operativa.

 

Sin embargo, eso no elimina necesariamente los sistemas que generan esa realidad.

 

5. ¿Cómo se Verifican los Datos?

 

Esta es quizá la parte más importante del debate.

 

Al fin y al cabo, las plataformas empresariales no pueden simplemente ingerir todo y asumir que eso representa la verdad.

 

Por ello, las canalizaciones de ingeniería de datos utilizan mecanismos como:

 

• Validación de esquema — ¿los datos entrantes tienen la estructura esperada?
• Validación de tipo — ¿la cantidad es numérica, la fecha es realmente una fecha y la moneda está representada correctamente?
• Comprobaciones de completitud — ¿faltan campos obligatorios?
• Comprobaciones de unicidad — ¿aparecen objetos duplicados?
• Comprobaciones referenciales — ¿este proveedor, OC, empleado o proyecto existe realmente?
• Reglas de transformación — ¿cómo debe normalizar la canalización los diferentes formatos del sistema origen?
• Linaje de datos — ¿de dónde se originó este valor y qué transformaciones lo produjeron?
• Comprobaciones de salud — ¿han dejado de llegar datos, han cambiado inesperadamente o han incumplido las expectativas definidas?

 

A nivel de proceso, los equipos también utilizan otra técnica importante:

 

Comprobación de conformidad

 

Aquí, la plataforma compara el proceso descubierto con un modelo de proceso esperado o aprobado.

 

Por ejemplo:

 

Esperado

 

• Solicitud → Aprobación → OC → Recepción → Factura → Pago

 

Observado

 

Solicitud → OC → Recepción → Factura → Aprobación → Pago

 

Como resultado, la tecnología puede detectar que la ejecución real se desvió del proceso esperado.

 

Claramente, eso es extremadamente útil.

 

Sin embargo, pone de relieve una cuestión filosófica importante.

 

¿De dónde salió la definición del proceso “correcto”?

 

En última instancia, alguien debe definir la regla de negocio.

 

• La IA puede descubrir lo que ocurrió.
• A continuación, puede calcular qué secuencia ocurre con mayor frecuencia.
• Puede identificar correlaciones entre determinados comportamientos y mejores resultados.
• Finalmente, puede recomendar un proceso rediseñado.

 

Pero la frecuencia no establece la corrección.

 

Si 5.000 empleados ejecutan repetidamente la misma solución alternativa, la IA puede descubrir con éxito el proceso dominante.

 

En ese caso, ha descubierto el comportamiento organizativo.

 

Sin embargo, no necesariamente ha descubierto la política organizativa.

 

6. Esta Es la Diferencia Crítica Entre la Observación y la Generación de Transacciones

 

Por ejemplo, consideremos compras.

 

Una plataforma de process mining puede observar:

 

Solicitud de material → Aprobación → RFQ → Evaluación → OC → Entrega → Factura

 

Pero una plataforma operativa debe crear y controlar realmente:

 

• ID de material
• Cantidad solicitada
• Cantidad aprobada
• Disponibilidad presupuestaria
• Proveedor
• Moneda
• Precio unitario
• Impuesto
• Términos contractuales
• Autoridad de aprobación
• Coste comprometido
• Movimiento de inventario
• Asiento contable

 

El sistema no puede simplemente inferir esos valores estadísticamente cada vez que ocurre la transacción.

 

En cambio, deben ajustarse a reglas predefinidas, permisos, datos maestros, presupuestos y estructuras contables.

 

Por esta razón, los sistemas empresariales son intencionalmente deterministas.

 

Para una transacción controlada:

 

Entrada validada + reglas de negocio aprobadas = transacción predecible

 

En otras palabras, la previsibilidad no es un atraso tecnológico.

 

Es el mecanismo de control.

 

7. Por lo Tanto, la IA Crea una Nueva Capa, No Necesariamente una Capa Sustitutiva

 

En términos simples, la arquitectura empresarial emergente se parece aproximadamente a esto:

 

Sistemas de registro ERP | CRM | SCM | MES | RR. HH. | Sistemas de proyecto

 

↓

 

Transacciones operativas y registros de eventos

↓

 

Integración / malla de datos

 

↓

 

Process & Task Mining

 

↓

 

Capa semántica / de ontología

 

↓

 

Razonamiento y predicción de IA

 

↓

 

Agentes de IA y orquestación

 

↓

 

Acción controlada

 

↓

 

Sistemas operativos

 

Como resultado, esto crea un bucle cerrado de inteligencia.

 

La capa de IA observa la empresa, la entiende, recomienda o inicia acciones, pero las acciones controladas acaban afectando a los objetos y transacciones operativos del negocio.

 

Por lo tanto, la revolución de la IA empresarial no consiste simplemente en:

 

La IA reemplaza al ERP.

 

En cambio, una interpretación más defendible desde el punto de vista científico es:

 

La IA crea una capa inteligente de control y orquestación en torno a sistemas operativos cada vez más conectados.

 

8. Entonces, ¿Qué Tiene de Diferente ProjectVIEW ERP?

 

ProjectVIEW aborda el mismo problema desde la dirección opuesta.

 

En lugar de observar primero miles de transacciones desconectadas e intentar reconstruir su significado de proyecto después, ProjectVIEW parte de un modelo de dominio explícito para operaciones basadas en proyectos.

 

En particular, su arquitectura fundamental conecta:

 

BoQ ↔ WBS ↔ Cost Codes

 

Estos representan tres dimensiones diferentes de la realidad del proyecto:

 

BoQ = Alcance / Estructura comercial

 

¿Qué estamos contratados para construir y qué cantidades y valores implica?

 

WBS = Tiempo / Estructura de ejecución

 

¿Cuándo y mediante qué actividades lo construiremos?

 

Códigos de coste = Estructura de coste / recursos

 

¿Qué recursos y costes consume su entrega?

 

Lo importante es que el contratista define las relaciones antes de la ejecución.

 

Las transacciones generadas durante la ejecución heredan entonces este contexto de proyecto.

 

Por tanto, una transacción de material no es solo:

 

20 toneladas de acero consumidas.

 

En su lugar, puede convertirse en:

 

20 toneladas de acero → Proyecto X → Ítem Y del BoQ → Actividad Z del WBS → Código de coste C

 

Esa distinción es fundamental.

 

9. ProjectVIEW Genera Datos Operativos Estructurados en el Origen

 

Considere la diferencia.

 

Por ejemplo, una plataforma de inteligencia conectada a múltiples aplicaciones puede descubrir que:

 

El empleado A solicitó acero.

 

Después, el empleado B aprobó algo.

 

Compras emitió una OC.

 

A continuación, el almacén registró una entrega.

 

Un ingeniero de obra registró el consumo.

 

Finanzas registró posteriormente un coste.

 

La capa de IA/datos tiene entonces que correlacionar estos eventos y establecer sus relaciones.

 

En cambio, la arquitectura de ProjectVIEW hace que esas relaciones formen parte de la propia transacción operativa.

 

La estructura del proyecto no se infiere solo aguas abajo.

 

Se codifica aguas arriba.

 

Por eso la documentación de ProjectVIEW describe el presupuesto del proyecto y la asociación BoQ-WBS-Cost Code como la base estructural para compras, operaciones de obra, asignación de recursos, control de costes y contabilidad posteriores.

 

Como resultado, una transacción de obra puede transportar la asociación BoQ, WBS y Cost Code a posteriores análisis de costes y rendimiento.

 

10. Esto No Convierte a Palantir, ServiceNow o el Process Mining en Competidores del ERP

 

De hecho, la conclusión opuesta puede ser más interesante.

 

En cambio, pueden ser complementarios.

 

Por ejemplo, una empresa puede tener:

 

• SAP o Oracle gestionando las finanzas corporativas,
• ProjectVIEW gestionando la ejecución detallada de proyectos y el control de costes,
• Primavera P6 gestionando la planificación,
• BIM representando el activo físico,

 

y una plataforma de IA/Ontología/Inteligencia de procesos razonando sobre todos ellos.

 

La capa de IA resulta mucho más útil cuando los sistemas operativos subyacentes producen datos estructurados, gobernados y semánticamente ricos.

 

En consecuencia, esto conduce a un principio importante:

 

La inteligencia de IA depende en parte de la calidad de los datos operativos.

 

O, de forma más formal:

 

Mejor estructura operativa → Mejor contexto → Mejor razonamiento de IA → Automatización más segura

 

11. La Ventaja de ProjectVIEW No Es, Por Tanto, “ERP en Lugar de IA”

 

Al fin y al cabo, esa sería la posición equivocada.

 

En cambio, la propuesta más sólida es:

 

ProjectVIEW proporciona una base operativa determinista y específica del sector sobre la que la IA puede razonar.

 

La arquitectura documentada de ProjectVIEW establece la relación BoQ, WBS y Cost Code a nivel de presupuesto y propaga esa estructura a través de las transacciones posteriores. Por tanto, compras, gestión de construcción, RR. HH., maquinaria, subcontratación y finanzas pueden interactuar en torno a estructuras de proyecto compartidas. No necesitan reconstruir esas relaciones después.

 

Y ProjectVIEW AI puede ir más allá de las transacciones de ProjectVIEW: el diseño actual de DANAOS contempla explícitamente datos externos del proyecto, incluidos documentos, información de EDMS, Primavera P6, registros de obra, sistemas de calidad y correspondencia, manteniendo al mismo tiempo la lógica operativa específica de construcción heredada de ProjectVIEW ERP.

 

Esto produce una distinción arquitectónica potencialmente importante:

 

IA empresarial genérica

 

Observar → Extraer → Correlacionar → Modelar → Inferir → Recomendar → Actuar

 

ERP de dominio + IA

 

Estructurar → Transaccionar → Validar → Observar → Razonar → Predecir → Optimizar → Actuar

 

Ambos enfoques pueden coexistir.

 

Pero el segundo parte de un contexto de dominio considerablemente más explícito.

 

12. El Futuro No Es ERP frente a IA

 

Por tanto, quizá estemos planteando la pregunta equivocada cuando preguntamos:

 

“¿Reemplazará la IA al ERP?”

 

Sin duda, la IA absorberá muchas capacidades históricamente asociadas con BPM, RPA, analítica, integración e interfaces de usuario.

 

Del mismo modo, los agentes trabajarán cada vez más entre aplicaciones.

 

Como resultado, los procesos se volverán más dinámicos.

 

El lenguaje natural puede sustituir muchas pantallas tradicionales.

 

Y la IA descubrirá y rediseñará flujos de trabajo automáticamente cada vez más.

 

Pero bajo esa inteligencia, las empresas siguen necesitando representaciones controladas de:

 

• dinero,
• inventario,
• empleados,
• activos,
• contratos,
• producción,
• proyectos,
• compromisos,
• costes,
• e ingresos.

 

Esto requiere identidad, relaciones, permisos, validación, integridad referencial, integridad de transacciones y auditabilidad.

 

Por tanto, la arquitectura empresarial del futuro se parece menos a:

 

IA en lugar de ERP

 

y más a:

 

Sistemas operativos + malla de datos + IA + agentes = empresa inteligente

 

Para ProjectVIEW, lo expresaríamos de forma aún más específica:

 

ERP de proyecto determinista + IA integrada + orquestación agéntica = sistema operativo para industrias basadas en proyectos

 

La IA puede descubrir cómo funciona una organización.

 

También puede ayudar a determinar cómo podría funcionar mejor la organización.

 

Cada vez más, la IA también puede orquestar cómo los equipos hacen el trabajo.

 

Pero la plataforma operativa sigue siendo responsable de algo fundamentalmente distinto:

 

definir, generar y preservar la realidad empresarial gobernada de la que depende esa inteligencia.

 

La IA no debería tener que inferir cada mañana lo que la empresa ya sabe.