Business Central 29 para construcción: nuevos agentes de IA y automatización de procesos de obra

La inteligencia artificial no ahorra dinero por hablar. Lo hace cuando evita que una incidencia se convierta en coste.

Imaginemos un lunes en una constructora con ocho obras activas. A primera hora llega un camión con materiales para una promoción residencial. El pedido está en el ERP, la descarga la supervisa el encargado y el albarán termina en una carpeta compartida. Una parte del suministro presenta defectos. Se hace una fotografía, se avisa al proveedor y el equipo continúa trabajando. Nadie quiere detener la obra. Hasta ahí, todo parece razonable.

El problema aparece tres semanas después. Compras cree que se recibió todo el pedido. Administración registra la factura de las unidades facturadas. El jefe de obra tiene anotada una incidencia en una hoja de seguimiento. El responsable de calidad conserva las fotografías en otro entorno. Finanzas conoce el importe, pero no la historia. Lo que era una diferencia de recepción termina oculto entre apuntes, correos, pedidos y aprobaciones.

Business Central 29 no sustituye el criterio del encargado ni convierte automáticamente cada material en una inspección sectorial lista para usar. Lo que sí aporta, junto con capacidades ya existentes de Business Central, es una base más sólida para conectar controles de calidad, conciliación de compras, trabajo de agentes y supervisión humana. La pregunta interesante no es cuántos agentes presenta Microsoft, sino cuántas excepciones dejan de depender de que una persona persiga a otras por correo.

Esa diferencia es particularmente importante en construcción. La empresa no gestiona únicamente compras y facturas; gestiona obras con plazos contractuales, materiales que deben llegar en una fecha, subcontratistas, certificaciones, márgenes previstos y riesgo de caja. Una excepción que en otro sector es administrativa aquí puede paralizar una unidad de producción, exigir una nueva entrega o deteriorar el margen a terminación.

Business Central 29: capacidades reales, no promesas de ciencia ficción

La versión 29 de Dynamics 365 Business Central inicia la segunda ola de novedades de 2026. Microsoft confirma mejoras en la conciliación del Payables Agent, permisos de agentes, supervisión de tareas, revisión de contenidos generados, consultas al dato mediante MCP y automatización de informes. El nuevo chat alineado con la experiencia Microsoft Copilot figura en vista previa pública. Eso dibuja un ERP más accesible para asistentes y agentes, pero también con mayor necesidad de delimitar qué pueden consultar y ejecutar.

Es fundamental distinguir entre capacidad nativa, extensión de Microsoft y solución sectorial. Payables Agent es una funcionalidad de Microsoft orientada al procesamiento de facturas de compra. Quality Management es una extensión publicada por Microsoft que ya se introdujo en Business Central 28 y recibe mejoras en la versión 29. Expense Agent es otro agente de Microsoft, pero permanece en vista previa y requiere condiciones de disponibilidad, configuración y consumo. Ninguno de estos tres componentes constituye, por sí mismo, un agente estándar de jefe de obra, una solución completa de control de subcontratas o un asistente capaz de entender todas las certificaciones de una constructora.

Ahí interviene la especialización. Business Central gestiona la transacción y sus reglas; IB Building 365 incorpora procesos de obra; la automatización y los agentes conectan datos, alertas y acciones dentro de un marco de permisos. El resultado no debería ser una colección de demostraciones inconexas, sino una secuencia comprensible que empieza en el terreno y termina en una decisión económica documentada.

El cambio de enfoque importa para quien está evaluando inversiones. Prometer una función estándar inexistente genera frustración y compromete el proyecto. Explicar con claridad qué se puede activar, qué se puede extender y qué necesita un desarrollo acotado permite hacer pruebas reales, medir valor y construir una evolución sostenible.

Una entrega que no cumple: así debería viajar la incidencia desde el material hasta la factura

Empecemos por el control de calidad, una función aparentemente poco vistosa hasta que aparece un material rechazado. El equipo de obra necesita verificar que el suministro recibido cumple lo acordado: cantidad, referencia, lote cuando corresponda, estado, certificados y condiciones de aceptación. Esa información debe relacionarse con el pedido original, el proveedor y la obra. Si una parte no es conforme, el proceso necesita separar lo recibido de lo aceptado y dejar constancia de quién decidió qué hacer.

Quality Management permite configurar inspecciones en puntos de recepción, reglas y plantillas con criterios, resultados y acciones para artículos no conformes. Según la configuración, puede bloquear lotes o dirigir materiales a ubicaciones de cuarentena. Estas capacidades proceden de una aplicación Microsoft que se integra con procesos de compras y almacén. Aplicarlas a aceros, prefabricados, instalaciones o suministros específicos de obra exige mapear cómo se reciben realmente esos materiales en la solución sectorial; no basta con instalar una extensión.

Hay un asunto operativo que suele ignorarse en las presentaciones: una obra no es necesariamente un almacén convencional. Puede haber entregas directas, materiales consumidos inmediatamente, subcontratistas que suministran e instalan, certificados externos o acuerdos de recepción por hitos. Por eso conviene escoger un flujo piloto —por ejemplo, una familia de materiales con volumen y criticidad suficientes— antes de diseñar controles generalizados. La prueba debe respetar los movimientos de inventario y las formas de imputación del proyecto.

La intervención inteligente puede servir para resumir la evidencia, identificar documentos ausentes, avisar a compras y presentar al responsable la siguiente decisión. La decisión de rechazar definitivamente el material, liberar un lote bloqueado o abrir una reclamación formal requiere reglas explícitas, roles y trazabilidad. El objetivo no es que una IA asuma la responsabilidad técnica; es que el equipo disponga de los hechos pertinentes y no pierda días reconstruyendo la incidencia.

Lo que está en juego no es una incidencia aislada: es la diferencia entre lo recibido y lo que estamos a punto de pagar

Las cifras ayudan a entender por qué la conexión es más importante que el propio agente. Pensemos en una entrega de 1.000 unidades a 45 euros cada una. La empresa recibe la mercancía y, tras la revisión, detecta 90 unidades que no cumplen los criterios acordados. El problema económico directo es fácil de calcular, pero el coste real puede ser mayor si hace falta sustituir el material, aplazar una actividad o gestionar una devolución.

El control razonable consiste en que el resultado de la inspección forme parte de la conversación sobre el pedido y la factura. El personal de recepción confirma la evidencia; calidad registra el estado; compras gestiona al proveedor; administración revisa las discrepancias; finanzas tiene visibilidad de los compromisos. El agente puede ayudar a relacionar información y dirigir la excepción a la persona correcta, pero el sistema conserva las aprobaciones y la lógica transaccional.

Este escenario demuestra dónde se encuentra la oportunidad para una solución sectorial. No se necesita inventar otra base de datos para cada incidente; se necesita que la información producida por el trabajo real llegue con contexto económico y documental. En una constructora con docenas de pedidos por obra, esa disciplina puede ahorrar muchas conciliaciones, evitar pagos discutidos y dar a dirección señales antes de la reunión de cierre.

La factura que llega perfecta sobre el papel, pero no encaja con la realidad de obra

Una factura puede contener todos los datos fiscales correctos y seguir siendo incorrecta desde el punto de vista operativo. El proveedor factura el suministro completo; el pedido es válido; la recepción parcial o el rechazo aparecen documentados en otro circuito. Si el equipo solo revisa la factura contra el pedido inicial, puede dar por correcto un importe que exige aclaración. Es un problema muy habitual cuando las áreas de compras, almacén, obra y administración trabajan con distintos tiempos.

Microsoft ha mejorado en Business Central 29 las capacidades de correspondencia del Payables Agent con pedidos. El agente está diseñado para ayudar a procesar facturas de compra y facilitar su contraste con la información disponible. Eso es una mejora real del estándar. Pero una verificación comercial o financiera no reemplaza la aceptación técnica del material, y la capacidad de interpretar la no conformidad de una obra depende de que exista el dato, de cómo se haya modelado y de cómo se conecten los documentos relevantes.

Por ejemplo, ante la factura del suministro del caso anterior, el circuito deseado sería comprobar la factura contra el pedido, identificar el dato de recepción admitido en el ERP, recuperar la incidencia si está accesible y elevar una discrepancia a quien corresponda. Si hay una devolución acordada, un abono pendiente o un nuevo envío, esa circunstancia debe documentarse antes de cerrar la decisión. Automatizar el cotejo no significa automatizar una conformidad contractual que nadie ha validado.

Para una constructora, el gran avance no es introducir facturas sin teclear. Es reducir el tiempo que transcurre entre la incidencia en el terreno y la decisión sobre la obligación de pago. Ese tiempo afecta a proveedores, obra y tesorería. Una factura retenida sin explicación también cuesta dinero en forma de llamadas, duplicidades y conflictos. La tecnología tiene valor si acelera una resolución documentada y permite a cada interlocutor entender la misma historia.

Los equipos deberían medir no solo cuántas facturas procesa el agente, sino cuántas llegan a revisión por diferencias reales, cuánto tardan en resolverse, qué porcentaje exige corrección y qué importe está pendiente de aclaración. Esos indicadores permiten demostrar valor sin vender un porcentaje de ahorro inventado.

Los tickets pequeños que terminan convirtiéndose en un problema grande de imputación

La segunda oportunidad es menos espectacular, pero afecta a la vida diaria de muchas constructoras. Un encargado paga una compra urgente para no detener una actividad; un técnico adelanta un gasto de desplazamiento; un responsable de producción aporta un recibo que ha fotografiado con el móvil. La empresa recibe documentos desordenados que deben validarse, clasificarse y asignarse a la obra, proyecto, tarea o centro de coste correcto. El volumen puede ser pequeño individualmente y enorme cuando se multiplica por equipos y obras.

Expense Agent permite capturar justificantes mediante aplicación o correo, extraer datos, categorizar conceptos y preparar informes de gastos sujetos a revisión y aprobación. Microsoft lo documenta como funcionalidad en vista previa preparada para producción, bajo las condiciones aplicables, no como disponibilidad general sin restricciones. También documenta opciones para asociar gastos a proyectos y tareas. La disponibilidad por idioma y entorno debe comprobarse en cada cliente, así como los requisitos de configuración, permisos y consumo del servicio.

La capa sectorial introduce una pregunta adicional: ¿ese gasto pertenece realmente a la obra indicada? Una descripción genérica como «material de ferretería» no basta cuando la empresa trabaja con varias obras cercanas, sociedades distintas o tareas que exigen imputaciones separadas. El agente puede reconocer datos de un recibo, pero relacionarlos con un presupuesto de ejecución concreto requiere reglas, referencias y verificación; en algunos casos, una extensión o integración con IB Building 365.

Conviene evitar un error habitual: optimizar únicamente la digitalización del justificante. Si se captura en segundos pero se contabiliza con una dimensión incorrecta, el dato de margen puede empeorar. Por eso el piloto debería comprobar dos resultados distintos: cuánto tiempo tarda el empleado en registrar el gasto y cuántas rectificaciones necesita finanzas antes de que el coste esté correctamente situado en la obra. La trazabilidad del justificante y la clasificación económica son dos partes de la misma operación.

En construcción, los gastos menores importan precisamente porque suelen escapar a los circuitos formales de compra. La innovación sensata no consiste en permitir que cualquier persona comprometa gasto desde una conversación, sino en reducir la fricción administrativa sin perder imputación, política corporativa, responsabilidad ni evidencia.

¿Quién se hace responsable cuando un agente propone una operación?

La conversación sobre agentes necesita un capítulo incómodo: los permisos. Un agente que consulta una tabla para responder cuántas facturas están pendientes no plantea el mismo riesgo que otro que modifica un pedido, genera un documento o ejecuta una acción. Business Central incorpora mejoras para que el usuario pueda supervisar tareas y revisiones, y sus capacidades MCP permiten conectar clientes de IA con los datos y operaciones que se autoricen. Eso no convierte cada función del sistema en una operación segura por defecto.

La configuración habitual de acceso mediante MCP permite descubrir información de solo lectura expuesta por APIs elegibles y autorizadas. Para escribir o ejecutar acciones es necesario configurar los objetos y permisos correspondientes. Además, Microsoft documenta capacidades de consultas de datos cuyo estado puede depender de la versión y del entorno. La regla de negocio debe expresarse como una política concreta y verificable: qué operación se permite, sobre qué sociedades, hasta qué límite económico, con qué intervención humana y con qué registro de auditoría.

En el contexto de obra, aprobar un gasto de poca cuantía no equivale a liberar un material no conforme, modificar una certificación, aceptar una factura disputada o dar de baja un compromiso contractual. La criticidad no se determina solamente por el importe: importa la seguridad, el cumplimiento técnico, la responsabilidad contractual y la posibilidad de revertir la decisión. Diseñar límites por categoría y por rol suele ser más eficaz que pensar en un único porcentaje de autonomía.

La arquitectura de permisos es también una cuestión de confianza del usuario. Si los equipos sienten que una automatización actuará sin avisar, crearán controles paralelos y volverán a Excel. Si el agente muestra por qué propone algo, a qué fuentes ha acudido y qué aprobación falta, es más probable que la organización lo adopte. La buena automatización reduce la incertidumbre; no la desplaza a un cuadro negro.

La gestión de excepciones debe ser parte del diseño desde el principio. ¿Qué ocurre si falta el albarán? ¿Si no hay permisos para consultar un registro? ¿Si la inspección dice «pendiente»? ¿Si la sociedad de la factura no coincide con la sociedad del pedido? Un circuito estable debe poder detenerse, escalar la decisión y dejar constancia del motivo.

Por qué una constructora necesita algo más que un agente genérico de Business Central

Microsoft desarrolla agentes y funciones aplicables a muchas empresas. Una constructora, sin embargo, necesita que esas funciones comprendan la estructura específica del proyecto. El material no se compra simplemente para un almacén: puede estar reservado a una obra, una fase, un capítulo presupuestario o una unidad de producción. La factura de una subcontrata no es necesariamente una factura comercial cualquiera: puede depender de certificaciones, avances, retenciones y condiciones acordadas. Una alerta de gasto no dice suficiente si no se conoce el margen previsto de la obra.

IB Building 365 aporta precisamente el lenguaje que falta en un sistema genérico: presupuestos de estudio, reestudios, subcontratación, certificaciones, partes, costes, producción y cierres, conectados con la transacción económica de Business Central. Ayesa ya dispone de un agente sectorial que consulta datos, interpreta resultados y puede ejecutar determinados procesos. Esa capacidad es un punto de partida valioso, siempre que describamos con precisión lo que está implantado y lo que aún es evolución propuesta.

El salto que propone Ayesa no debería consistir en bautizar seis agentes nuevos. Debería traducirse en algunos recorridos con impacto claro: la recepción de un material no conforme; el gasto de obra que necesita clasificación y validación; la factura que requiere revisar lo que realmente se recibió; y la cartera de obras que exige priorizar desviaciones. Esos circuitos comparten una arquitectura, pero también necesitan controles y datos diferentes. Resolver dos correctamente aporta más credibilidad que presentar una docena de automatizaciones incompletas.

El hub Cloud Construction Microsoft explica la arquitectura y el impacto ejecutivo de ERP, CRM, datos e IA. El artículo que estás leyendo baja un nivel: muestra qué ocurre cuando esa arquitectura entra en compras, calidad y finanzas. Esa relación editorial evita repetir conceptos y ayuda a quien ya ha entendido la plataforma a concretar un proyecto con comienzo y fin.

Del agente que responde preguntas al que ayuda a decidir qué obra necesita atención primero

Hay una evolución especialmente relevante para la dirección de una constructora: pasar de preguntar por una obra a recibir una visión proactiva de la cartera. Es un enfoque diferente del control de materiales y facturas, pero puede apoyarse en las mismas incidencias una vez que están estructuradas. Dirección no necesita otra lista interminable de registros; necesita identificar qué proyecto requiere una decisión hoy y por qué.

Supongamos que tres obras muestran señales distintas. La primera acumula recepciones de material con incidencias que afectan a una actividad crítica. La segunda tiene un aumento de compromisos de compra frente al presupuesto actualizado. La tercera presenta retrasos de certificación que tensionan la caja prevista. Ordenarlas por volumen de actividad no es suficiente. El agente debería resumir el contexto, el importe o criticidad de la desviación, la persona responsable y la acción siguiente, teniendo en cuenta si el dato está actualizado.

La distinción entre un ranking útil y uno engañoso reside en sus reglas. Una obra puede tener una desviación porcentual pequeña sobre un importe muy grande; otra un problema de documentación que no afecta al margen, pero sí a una inspección o al cumplimiento. La dirección debe conocer qué criterios se han utilizado y poder profundizar desde la prioridad al registro original. Si la información de producción se actualiza semanalmente y las compras diariamente, el sistema debe mostrarlo en lugar de mezclar las fechas como si todo fuera simultáneo.

La idea de briefings diarios o semanales —riesgos, desviaciones, cobros, compras y decisiones pendientes— encaja con la necesidad de anticipar decisiones. Pero se trata de una evolución propuesta del activo sectorial, no de una función que Microsoft entrega lista para todas las constructoras con Business Central 29. Su viabilidad depende de fuentes, gobierno, calidad de los datos y un diseño de prioridades validado por dirección.

La oportunidad comercial es clara: para muchas empresas el reto no es incorporar otro cuadro de mando, sino acortar el tiempo que pasa entre registrar una señal, entender su consecuencia y actuar. Esa mejora puede empezar en calidad, gastos o compras y crecer hacia una visión consolidada de cartera sin rehacer toda la plataforma.

Qué activar primero: criterio económico, complejidad y disponibilidad real

A la hora de decidir por dónde comenzar, el entusiasmo tecnológico suele conducir a proyectos demasiado grandes. Se selecciona el caso que mejor se ve en una demo, aunque no sea el que aporta más valor o dispone de mejores datos. Para una constructora con Business Central e IB Building 365, conviene evaluar cada recorrido por volumen de excepciones, coste de gestión, frecuencia, madurez de la información, riesgo operativo y necesidad de integración.

El control de calidad de materiales puede tener un impacto alto cuando los rechazos generan disputas, paralizaciones o devoluciones frecuentes, pero no es el mejor primer caso si las recepciones no están estructuradas en el ERP. Expense Agent puede ser más rápido de validar cuando la empresa recibe muchos tickets y ya tiene políticas de gastos claras. El cotejo de facturas puede aportar un retorno relativamente fácil de observar, siempre que los pedidos y recepciones estén bien registrados. El briefing de cartera ofrece gran visibilidad a dirección, pero requiere más fuentes y una definición rigurosa de los indicadores.

Las capacidades del estándar deberían evaluarse antes de construir nuevas extensiones. No merece la pena desarrollar un agente propio que replica extracción de recibos si Microsoft ya ofrece un flujo adecuado y compatible con el escenario. Tampoco conviene forzar el estándar de calidad para representar una inspección técnica de obra que exige evidencias, normativa o actos de aceptación distintos. El diseño correcto distribuye responsabilidades entre funcionalidad nativa, vertical sectorial y automatización complementaria.

No existe una respuesta única para todas las compañías. En una constructora de obra pública puede ser prioritario controlar certificaciones, subcontratas y documentación. En otra dedicada a edificación residencial puede ser más urgente la trazabilidad de materiales y el circuito de incidencias. En empresas con fuerte dispersión geográfica, registrar correctamente tickets, desplazamientos y consumos puede mejorar de forma inmediata el dato de costes.

Un piloto de seis semanas que permita decidir si vale la pena escalar

La forma de probar la oportunidad no es desplegar tres agentes a la vez en todas las obras. Es escoger una obra o una familia de suministros, elegir responsables concretos y definir de antemano cómo se medirá el resultado. Un piloto que no tiene una línea de base puede producir una demostración excelente y, al mismo tiempo, dejar a dirección sin argumentos para invertir. La comparación con el proceso anterior debe incluir tiempo, calidad, riesgo y experiencia de usuario.

Esta secuencia funciona también para un agente de gastos o una mejora del agente sectorial. Lo esencial es que el patrocinador de la prueba no sea únicamente tecnología. Producción o compras deben validar el proceso, finanzas debe validar su efecto económico y sistemas debe asegurar el gobierno de accesos, datos y evolución. De otro modo, la demostración corre el riesgo de convertirse en una aplicación periférica más.

En Ayesa, el punto de partida puede ser más favorable cuando ya existe una base sectorial implantada. Pero no significa que todas las instalaciones tengan la misma versión, los mismos datos ni las mismas integraciones. El diagnóstico inicial debe reconocer esas diferencias. Un cliente con NAV antiguo, por ejemplo, tendrá un recorrido distinto de quien ya opera Business Central online con el vertical actualizado.

La métrica importante no es cuántos agentes tenemos, sino cuántas decisiones llegan a tiempo

Hay tres tipos de beneficio que conviene separar. El primero es administrativo: reducir el tiempo dedicado a copiar datos, preparar expedientes, localizar documentos y pedir aclaraciones. El segundo es operativo: evitar que una incidencia se pierda, que un suministro quede sin tratar o que una factura avance sin la revisión correspondiente. El tercero es financiero: mejorar la calidad de los costes imputados, reducir disputas y dar una visión más fiable del margen y de los compromisos. No son equivalentes y no deben mezclarse en un porcentaje de ahorro sin justificar.

Para medir el primer bloque pueden utilizarse minutos por justificante, facturas revisadas por persona o número de correos necesarios para cerrar una incidencia. Para el segundo, tiempo hasta la detección, antigüedad de las no conformidades y porcentaje de excepciones con responsable asignado. Para el tercero, importe de discrepancias pendientes, ajustes posteriores de costes, errores de imputación y desviaciones que llegan tarde a dirección. Estos indicadores permiten construir un caso económico serio sin inventar retornos garantizados.

También hay costes asociados a la nueva forma de trabajar: configuración de agentes y licencias aplicables, consumo de capacidades de IA, mantenimiento de integraciones, formación, revisión humana y control de excepciones. Una solución más automatizada no siempre es más barata si se diseña sin simplificar primero el proceso. El objetivo debe ser reducir coste total de operación y riesgo, no trasladar tareas de una pantalla a otra.

Un CFO evaluará la reducción de incertidumbre en costes, compromisos y caja. Un COO querrá que menos materiales e incidencias bloqueen producción. Un CIO necesitará una arquitectura gobernada, con integraciones mantenibles y permisos revisables. El director general querrá una respuesta sencilla: «¿Tomamos mejores decisiones antes que antes?». Un piloto que no puede responder a esas cuatro perspectivas no está preparado para convertirse en una inversión de plataforma.

En definitiva, la productividad no debería medirse por la cantidad de textos generados. Se mide por el recorrido completo de la excepción: aparece, se interpreta, se asigna, se decide y se refleja correctamente en el resultado económico de la obra.

Tres procesos que parecen independientes hasta que afectan al mismo margen

En las organizaciones que gestionan proyectos complejos, compras, calidad y subcontratación se organizan a menudo en equipos y herramientas distintas. Cada uno tiene sus procedimientos y documentos, pero todos pueden afectar al mismo capítulo de obra. Un material no conforme genera una devolución; la devolución puede retrasar una partida; el retraso puede exigir reprogramar una subcontrata; la factura puede llegar con importes discutidos; la tesorería refleja compromisos que ya no coinciden con el avance previsto. La oportunidad no está en crear un agente por departamento, sino en conectar decisiones que comparten consecuencias.

Business Central 29 también publica mejoras del estándar relacionadas con instrucciones en pedidos de subcontratación y operaciones de supply chain. Hay que interpretarlas con cuidado: muchas funcionalidades de subcontratación estándar se diseñaron para fabricación y no resuelven directamente la gestión contractual y certificación de subcontratas de construcción. Sería incorrecto anunciar que el estándar entrega de forma automática toda la operativa sectorial de una constructora. La aplicación a obra necesita diseño funcional y, cuando corresponda, las capacidades específicas de IB Building 365.

Lo mismo ocurre con las novedades de sostenibilidad. Business Central amplía el seguimiento de emisiones en distintas operaciones y registros, una base interesante para escenarios de construcción con materiales de impacto significativo. Sin embargo, obtener una huella de carbono por obra fiable exige reglas de asignación, factores de emisión, inventarios y una trazabilidad suficiente de los movimientos. No es un «agente de sostenibilidad de obra» nativo que aparezca instalado tras actualizar a la versión 29.

La coherencia entre procesos es particularmente valiosa para empresas que gestionan simultáneamente edificación, infraestructura, rehabilitación y mantenimiento. Las categorías de suministro, las evidencias requeridas y los modelos de subcontratación cambian. Una arquitectura sectorial permite adaptar el circuito a esas diferencias sin renunciar a un núcleo de compras y contabilidad común.

Antes de seleccionar un caso, conviene preguntar qué fuente es la que certifica cada hecho. El albarán indica una entrega; la inspección acredita un resultado; el contrato fija una obligación; la factura representa una reclamación de pago; el registro contable muestra una transacción; la previsión de obra intenta anticipar el resultado futuro. Un agente no debería borrar esas distinciones bajo una sola etiqueta de «dato del ERP».

Cinco errores que convertirían una buena novedad de Microsoft en otro proyecto frustrante

Hay un sexto error que aparece con frecuencia en el sector: diseñar la experiencia desde la oficina central sin observar la operativa real de la obra. El encargado puede tener conectividad irregular, trabajar con documentación heterogénea o necesitar registrar una incidencia en segundos. Un proceso excelente sobre papel puede fallar cuando exige veinte campos en una recepción o un permiso que solo tiene alguien que no está disponible.

Por eso conviene incorporar usuarios de campo desde la definición. No para cederles todas las decisiones de arquitectura, sino para comprobar que el circuito mejora su trabajo. La tecnología debe adaptarse a la disciplina necesaria del proceso sin introducir pasos artificiales. Cuando una incidencia bien registrada ahorra posteriores aclaraciones, la adopción deja de depender de pedir favores.

De las capacidades de BC29 a una plataforma conectada para construcción

La arquitectura debe poder responder una pregunta sencilla: si mañana cambiamos una herramienta de visualización, ¿seguimos conservando el control del negocio? El registro oficial de compras, contabilidad e inventario debe estar en el sistema correspondiente. Las reglas y datos sectoriales deben gestionarse dentro de IB Building 365 o en servicios claramente integrados. La automatización debe operar con interfaces y permisos definidos, sin copiar indiscriminadamente la información a repositorios que se vuelvan imposibles de gobernar.

Los agentes pueden ejecutarse desde diferentes experiencias, pero eso no significa que deban acceder directamente a todo. El servidor MCP de Business Central habilita formas de exponer APIs y consultas a clientes de IA conforme a una configuración. Power Platform puede servir para capturar datos, lanzar aprobaciones, integrar eventos y presentar formularios adaptados al campo. Azure puede aportar servicios complementarios de integración y gobierno. Power BI puede visualizar el estado de operaciones e indicadores. Cada capa cumple un papel diferente; ninguna sustituye al criterio operativo de la constructora.

Desde el punto de vista de datos, el desafío es menos glamuroso y más decisivo: proveedores únicos, materiales normalizados, referencias a obras consistentes, estados de compra claros y una relación trazable entre recepción, devolución, factura y coste. Si esos elementos no existen, los agentes responderán de forma inconsistente o exigirán demasiadas excepciones. Antes de construir interfaces conversacionales merece la pena limpiar las referencias necesarias para el caso seleccionado.

El valor de esta aproximación aparece cuando la empresa pasa del primer piloto al siguiente. La lógica de identidad, supervisión, observabilidad y permisos no debe reconstruirse desde cero para cada agente. El inventario de fuentes y los patrones de aprobación deberían reutilizarse. Así, el circuito de materiales puede compartir fundamentos con un caso de gastos y con un futuro resumen de cartera de obras.

En este punto, la propuesta de Cloud Industry Construcción y Real Estate ofrece una visión sectorial amplia, mientras que la página de Cloud Construction explica el impacto para dirección. Este contenido se concentra en una decisión mucho más concreta: cómo aprovechar las capacidades de la versión 29 para que una incidencia operativa llegue con el contexto correcto a quien debe resolverla.

Lo que conviene aclarar antes de invertir en agentes para una constructora

El denominador común de todas estas respuestas es el mismo: hay que evitar equiparar una capacidad tecnológica con un proceso industrial o constructivo completo. Una organización que hace esta distinción puede avanzar más deprisa porque reduce sorpresas en el despliegue. El resultado se vuelve medible y la conversación con dirección se desplaza de la promesa a la evidencia.

Para las compañías que ya utilizan Business Central, la decisión puede ser una evolución gradual con foco sectorial. Para quienes trabajan en NAV u otros ERP, será necesario evaluar primero el núcleo transaccional, la cobertura de procesos y la ruta de modernización. Incorporar agentes sobre una base fragmentada sin resolver los datos fundamentales suele añadir otra capa de complejidad en lugar de eliminarla.

De una presentación de innovación a un recorrido de negocio que se pueda enseñar y medir

La actualización de Business Central 29 abre nuevas posibilidades para las empresas que quieren automatizar tareas, consultar datos y gobernar mejor la intervención de agentes. Pero la verdadera novedad para construcción nace cuando ese potencial se conecta con la recepción de materiales, las compras, los gastos y los procesos que determinan el margen de cada obra. En ese punto, las mejoras genéricas de una plataforma se convierten en una propuesta empresarial diferenciada.

Ayesa parte de una ventaja práctica: conoce el modelo sectorial de IB Building 365 y dispone, de una experiencia de agente sobre procesos y datos reales. La evolución razonable consiste en incorporar capacidades de Microsoft donde ya resuelven parte del recorrido, aprovechar la lógica de obra donde aporta diferenciación y desplegar nuevas automatizaciones únicamente cuando el beneficio justifica el esfuerzo y el gobierno.

Una constructora que quiera explorar este potencial no necesita empezar con un programa masivo de inteligencia artificial. Puede empezar respondiendo tres preguntas: ¿qué proceso se repite lo suficiente como para merecer automatización?, ¿dónde se pierde actualmente el contexto entre las áreas?, y ¿qué decisión debe mantenerse en manos de una persona? Esas respuestas permiten definir un piloto con alcance, responsables, datos y resultado esperado.

Si el primer recorrido consigue relacionar correctamente un material rechazado con su expediente de compra y su factura, habrá demostrado algo mucho más valioso que una respuesta conversacional convincente: que la tecnología reduce la distancia entre detectar un problema y decidir sobre sus consecuencias económicas. Y ese mismo principio puede extenderse a gastos, subcontratas, certificaciones, cash flow y seguimiento de cartera.

Para profundizar en la plataforma completa, el punto de referencia es Cloud Construction Microsoft. Para conocer la cobertura funcional, IB Building 365. Y para entender cómo los asistentes y agentes se conectan al ERP de obra, agentes IA para construcción. Son lecturas complementarias que ayudan a pasar de la innovación a una hoja de ruta concreta.

Tres formas de avanzar desde aquí

Más información sobre las capacidades de Microsoft

La disponibilidad y los requisitos pueden variar según versión, localización, entorno y estado de despliegue. Estas referencias oficiales permiten comprobar la información del producto antes de decidir una implantación. Los escenarios de obra descritos en este artículo ilustran cómo podrían combinarse esas capacidades con procesos sectoriales; no certifican una funcionalidad concreta implantada en todas las versiones de IB Building 365.

Las decisiones de actualización y puesta en producción deben basarse en la documentación vigente, las pruebas en entorno controlado y la validación de los responsables funcionales. Ningún ejemplo de ahorro, control o autonomía sustituye esa comprobación en el entorno real del cliente.

¿En qué proceso de tu constructora tendría sentido empezar?

Recepciones de materiales, facturas con discrepancias, gastos pendientes de imputación, seguimiento de compras o visión de cartera. Ayesa puede ayudarte a identificar qué capacidades están disponibles, cómo conectarlas con IB Building 365 y dónde una prueba controlada puede aportar un resultado medible.