Customize with Copilot: ¿podrás adaptar Business Central explicando lo que necesitas?

Customize with Copilot: qué ha presentado Microsoft y qué todavía no ha prometido

En Directions EMEA 2026, Microsoft situó Customize with Copilot dentro de su evolución hacia una personalización más accesible de Business Central. La idea expuesta es que consultores y equipos funcionales puedan describir una necesidad mediante lenguaje natural, obtener una aproximación funcional y trasladar ese resultado al proceso profesional de desarrollo. El enfoque abre un escenario diferente al tradicional: la conversación con el usuario puede convertirse antes en algo tangible, comprensible y revisable.

La referencia comunicada para el acceso anticipado a partners es enero de 2027. Esa fecha es una previsión de hoja de ruta y puede cambiar; no equivale a disponibilidad general, ni a una promesa de que cualquier usuario vaya a poder instalar directamente extensiones terminadas en su ERP. La propia agenda de Directions incluyó una mesa redonda de Microsoft dedicada a personalización asistida, Visual Studio Code, consultores, usuarios de negocio y los límites de los nuevos flujos con agentes.

Esta precisión importa para quienes planifican inversiones. Una demostración en un evento sirve para entender una dirección tecnológica, pero no sustituye una ficha de requisitos técnicos, una política de licenciamiento, compromisos de soporte o una prueba con los datos y las extensiones de cada cliente. Es preferible preparar una estrategia viable ahora y confirmar los detalles de producto cuando Microsoft los publique.

La presentación encaja en la evolución general que Microsoft explicó en Directions EMEA 2026, pero merece un análisis propio porque afecta a una decisión concreta: cómo adaptar el ERP sin multiplicar la deuda técnica.

Personalizar más rápido no significa personalizar mejor

Las empresas rara vez se levantan una mañana pensando que necesitan otra extensión AL. Necesitan bloquear pedidos por riesgo comercial, incorporar aprobaciones, medir rentabilidad por proyecto, registrar atributos sectoriales o conectar la documentación de un proveedor con un proceso de compras. El desarrollo es el medio para resolver esa necesidad. Si el debate empieza por el código, corremos el riesgo de ignorar el problema de negocio que le da sentido.

Hasta ahora, una petición aparentemente sencilla podía atravesar varias reuniones: el usuario explicaba el proceso, un consultor traducía la necesidad a requisitos, el equipo técnico estimaba el alcance y, semanas después, presentaba una primera solución. Cada transición podía introducir interpretaciones distintas. Las herramientas de prototipado asistido permiten imaginar una conversación más cercana: el responsable comercial explica el requisito, el consultor modela un comportamiento preliminar y ambos corrigen en el momento qué se ha entendido mal.

Pero acelerar el primer prototipo también puede multiplicar las ideas equivocadas. Si producir un borrador es fácil, aumenta la tentación de construir antes de comprobar si Business Central ya resuelve el caso con configuración estándar, extensiones existentes o un cambio de proceso. La primera pregunta no debe ser “¿cuánto tarda Copilot en programarlo?”, sino “¿necesitamos realmente programarlo?”.

Customize with Copilot no es Edit with Copilot, ni GitHub Copilot

Los nombres se parecen, pero describen problemas distintos. Customize with Copilot se relaciona con adaptar el comportamiento del ERP mediante un proceso asistido de construcción de personalizaciones. Edit with Copilot se enfoca en la posibilidad de que un asistente ayude a introducir o modificar información de negocio. Y GitHub Copilot, integrado en herramientas de desarrollo como Visual Studio Code, apoya tareas de ingeniería de software. Confundir estos ámbitos crea expectativas equivocadas sobre qué producto cambia datos, cuál desarrolla aplicaciones y quién asume la validación.

Si lo que preocupa es que un asistente pueda modificar pedidos o proveedores, la lectura específica es Edit with Copilot: control y permisos. Si la necesidad es diseñar una funcionalidad adicional del ERP, el debate es otro: requisitos, arquitectura, AL, pruebas, despliegue y mantenimiento.

Cómo podría cambiar una petición real de negocio

Imaginemos una distribuidora que necesita avisar a sus comerciales cuando una oferta supera determinados límites de descuento y el cliente acumula facturas vencidas. El requisito parece sencillo: mostrar una advertencia en la oferta y pedir una revisión si el riesgo supera el umbral autorizado. Pero hay varias preguntas decisivas: ¿el descuento es por línea o por documento? ¿Qué se considera deuda vencida? ¿Se incluyen pedidos ya servidos? ¿Hay excepciones por grupos de clientes? ¿Se debe impedir el registro o solo advertir?

Con un enfoque de personalización asistida, un consultor podría utilizar una descripción inicial para obtener una estructura de solución y discutirla con el responsable comercial. La IA ayudaría a convertir la idea en una primera especificación y, cuando las capacidades estén disponibles, en elementos de una extensión. El beneficio no sería que desaparezca el trabajo funcional; sería que las ambigüedades aparezcan antes de programar y puedan resolverse delante del usuario.

El ejemplo también muestra por qué hace falta un equipo experto. Si la regla se construye sobre la cifra equivocada, podría bloquear operaciones sanas o permitir descuentos que destruyan margen. Si el desarrollo intercepta un evento inadecuado, podría afectar a integraciones o procesos masivos. Si los permisos se definen mal, un usuario podría modificar la excepción sin autorización. Ninguno de esos riesgos desaparece por haber redactado el requisito en lenguaje natural.

Estándar, configuración, extensión o integración: cuatro respuestas distintas

Antes de convertir cualquier petición en desarrollo, conviene ordenar las alternativas. Business Central incorpora una gran cantidad de capacidades de configuración, flujos de aprobación, dimensiones, series, perfiles, personalización de páginas, informes y aplicaciones de su ecosistema. Muchas necesidades se pueden resolver sin modificar el comportamiento de la aplicación. Cuando una solución estándar es suficiente, añadir código crea un coste que nadie necesita.

Cuando el estándar no cubre una regla diferenciadora, una extensión AL puede ser la respuesta. Sin embargo, no todas las necesidades requieren ejecutarse dentro del ERP. Una aplicación externa de captura, una automatización en Power Platform o una integración bien definida pueden reducir acoplamiento, aunque también añaden licencias, gobierno y costes de operación. Elegir bien exige analizar la naturaleza de los datos, la frecuencia de uso, las transacciones, la criticidad y el lugar donde debe residir la lógica.

En escenarios de aplicaciones complementarias, Power Platform y Business Central ofrece otra ruta posible. La decisión debe hacerse por proceso, no por preferencia de herramienta.

Una extensión sigue necesitando arquitectura AL y pruebas

Microsoft ha desarrollado herramientas para que agentes de IA compatibles con el modelo de trabajo de Visual Studio Code puedan ejecutar tareas del ciclo AL: buscar símbolos, compilar, recuperar diagnósticos, depurar y publicar extensiones. Esas capacidades ya están documentadas y son una muestra de que la ingeniería asistida por IA está avanzando. Sin embargo, documentar herramientas de construcción no significa que cualquier requisito esté resuelto de forma autónoma ni que una compilación satisfactoria garantice la corrección funcional.

Una extensión puede compilar y seguir estando mal diseñada. Puede pasar una prueba sencilla y crear bloqueos de base de datos con miles de registros. Puede funcionar en una empresa y fallar en un escenario multicompañía. Puede mostrar correctamente un aviso y omitir un caso de contabilización desde un proceso automático. Puede utilizar el evento correcto para una pantalla y el equivocado para procesos API. Por eso es imprescindible diferenciar validación sintáctica, pruebas de negocio, seguridad y comportamiento real en producción.

El responsable técnico debe decidir qué objetos se extienden, cómo se versionan los datos, qué eventos son apropiados, cómo se tratan los errores y qué dependencias se introducen. El equipo funcional tiene que verificar qué resultado espera el usuario en situaciones ordinarias y excepcionales. La IA puede colaborar en ambos ámbitos, pero no debería convertirse en un atajo para evitar esa responsabilidad.

La documentación de Microsoft sobre herramientas de agentes para AL describe procesos reales de compilación y diagnóstico, pero también deja claro que deben ejecutarse con identidad y acceso adecuados. La automatización no sustituye un proceso de revisión.

Cinco solicitudes habituales que una empresa podría formular en lenguaje natural

Una parte de la revolución de la personalización está en la accesibilidad del lenguaje. Un responsable de almacén no suele hablar de suscriptores de eventos ni de páginas AL. Explica que necesita registrar una razón de bloqueo antes de liberar una expedición. Un director financiero no pide una tabla adicional: pide comprender qué partida está pendiente y quién debe desbloquearla. Acercar estas descripciones a un prototipo puede reducir las traducciones, pero también obliga a expresar reglas de forma completa.

Cada caso abre una discusión que va más allá de generar una pantalla. En una empresa industrial, una regla de calidad puede afectar a la disponibilidad y al inventario. En construcción, el control económico debe respetar la estructura de proyectos y certificaciones. La diferencia entre una personalización útil y una fuente de problemas suele estar en esos detalles, invisibles en un prompt breve.

Quién puede proponer, aprobar, instalar y utilizar una personalización

Cuanto más accesible sea la creación de prototipos, más importante será separar responsabilidades. Un usuario experto en compras debe poder explicar necesidades y validar comportamientos, pero eso no significa que deba desplegar una extensión que afecte a toda la organización. Del mismo modo, un desarrollador que conoce AL no necesariamente puede decidir por sí solo las condiciones comerciales de una compañía. La agilidad mejora cuando ambas funciones colaboran dentro de reglas claras.

La política debería diferenciar al menos cuatro decisiones: quién puede iniciar una solicitud; quién confirma su pertinencia funcional; quién revisa su diseño técnico y controles; y quién autoriza el paso a un entorno operativo. Esas autorizaciones pueden variar en una modificación meramente visual frente a una regla de contabilización, una integración bancaria o un proceso de inventario. No todos los cambios merecen el mismo nivel de gobierno.

También hay que conocer qué información utiliza una herramienta de IA durante el prototipado. ¿Incluye datos de clientes o precios reales? ¿Accede al código completo de las extensiones? ¿Qué mecanismos de aislamiento y registro están documentados? ¿Qué identidad ejecuta las herramientas? Antes de abrir un proceso de prueba, estas respuestas deben obtenerse de la documentación vigente y de la configuración concreta del servicio. No es correcto asumir permisos o garantías que todavía no hayan sido publicados para la experiencia anunciada.

¿Reducirá Customize with Copilot el precio de personalizar Business Central?

La respuesta razonable es que podría reducir una parte del esfuerzo de análisis y prototipado, pero no existe una cifra oficial que permita prometer un porcentaje determinado de ahorro a cualquier cliente. El coste de una personalización no se limita a escribir AL. Incluye entender el proceso, decidir si conviene desarrollarlo, configurar entornos, integrar datos, probar, documentar, formar usuarios, desplegar, atender incidencias y mantenerla durante años.

En una petición sencilla, el tiempo de preparación del prototipo puede representar una parte importante del esfuerzo. En una integración crítica o una validación de facturación, quizá el mayor coste siga estando en las pruebas, el tratamiento de excepciones y la coordinación con otros sistemas. La IA tampoco elimina costes asociados al consumo de herramientas, licencias de desarrollo o infraestructura; su tratamiento concreto deberá contrastarse cuando Microsoft publique las condiciones comerciales de Customize with Copilot.

La pregunta financiera correcta no es “¿cuánto código genera la IA por minuto?”, sino “¿qué parte del coste total de la funcionalidad se evita, y qué nuevos controles o consumos añadimos?”. Un ahorro de construcción no es interesante si aumenta el tiempo de soporte o si cada actualización requiere corregir una extensión que nadie comprende.

Una evaluación financiera defendible debe comparar al menos tres rutas: no hacer nada y mantener el proceso actual; ajustar configuración y herramientas existentes; o construir una extensión controlada. La velocidad del prototipo es un argumento a favor de una de esas rutas, no una justificación suficiente para escogerla.

El peligro de que cada necesidad termine convertida en una extensión

En muchas organizaciones, la historia del ERP es una sucesión de soluciones razonables tomadas de una en una. Una validación para un cliente importante, una pantalla específica para un departamento, una importación temporal que se quedó y una tabla adicional para resolver una urgencia. Cada cambio funcionó en su momento. Años después, nadie sabe cuáles son imprescindibles, cuáles duplican el estándar y cuáles generan retrasos al actualizar. Ese es el problema que ninguna inteligencia artificial debería acelerar.

Si el esfuerzo necesario para producir una personalización disminuye, también puede reducirse la barrera para pedir cambios de poco valor. Los equipos de sistemas necesitan introducir una regla previa: ninguna funcionalidad nueva debe aprobarse sin identificar su propietario, su objetivo medible, su alcance, sus dependencias y cómo se retirará cuando deje de ser necesaria. La documentación de por qué se creó una excepción es tan importante como el código que la implementa.

Las extensiones modernas de Business Central ofrecen una arquitectura más flexible que las modificaciones históricas del núcleo, pero no son gratuitas desde la perspectiva de mantenimiento. Pueden depender entre sí, afectar al rendimiento o exigir ajustes por cambios de plataforma. Un diseño profesional debería minimizar el acoplamiento, emplear puntos de extensión soportados, respetar contratos de interfaces y mantener pruebas de los procesos críticos.

Cuando la compañía arrastra años de modificaciones, la conversación se conecta con modernización del ERP Microsoft. El objetivo no debería ser trasladar toda la complejidad a una herramienta de IA, sino eliminar la que ya no aporta valor.

La perspectiva de la comunidad MVP: acelerar sin renunciar al criterio

La comunidad de Microsoft Dynamics ha empezado a documentar los límites prácticos del desarrollo asistido por IA. Stefano Demiliani, Microsoft MVP especializado en Business Central, ha explicado en su blog que los asistentes pueden acelerar tareas de programación, pero que su utilidad depende de disponer de profesionales capaces de comprender, revisar y mantener lo generado. Su advertencia tiene particular sentido en un ERP: crear código rápidamente no resuelve por sí mismo transacciones, seguridad, integraciones y soporte.

En otro análisis, Demiliani llama la atención sobre los costes que pueden aparecer cuando el uso indiscriminado de agentes multiplica consumo, iteraciones y dependencia de la herramienta. Su recomendación no consiste en rechazar la IA, sino en utilizarla con patrones reutilizables, revisión humana y conocimiento sólido de la plataforma. Es un punto importante para responsables de tecnología que evalúan cuánto cambiarán las funciones de sus equipos.

Stefan Šošić, también Microsoft MVP, publica investigaciones detalladas sobre testing, lenguaje AL, rendimiento y uso de IA en Business Central. Su trabajo ilustra otra idea decisiva: una plataforma empresarial exige comprobar la implementación contra símbolos, versiones y comportamientos concretos, no solo contra el resultado que un modelo predice. El salto desde un ejemplo atractivo hasta una solución verificable es una tarea de ingeniería.

Y en BC TechDays 2026, especialistas de la comunidad han dedicado sesiones a los agentes en desarrollo AL, las pruebas automatizadas y los problemas de calidad del código. No existe consenso documentado de que la IA vaya a sustituir la experiencia de desarrollo; sí existe una conversación técnica activa sobre cómo integrarla en procesos profesionales más rigurosos.

Lecturas recomendadas: Stefano Demiliani: Vibe coding, yes or no?, The hidden cost of asking AI to do everything y Stefan Šošić: Business Central, in depth.

Qué ocurre con las personalizaciones heredadas de Navision y las extensiones actuales

Para una compañía que trabaja con Business Central desde hace tiempo, la primera oportunidad no tiene por qué ser crear nuevas funcionalidades. Puede resultar más rentable inventariar lo que ya utiliza: qué modificaciones proceden de Navision, cuáles se convirtieron en extensiones modernas, cuáles dependen de integraciones y qué procesos siguen operando con ajustes manuales. La futura personalización asistida puede aportar valor al documentar o prototipar alternativas, pero no debería tratarse como una conversión automática de código heredado.

La migración desde NAV plantea dificultades que van mucho más allá de la sintaxis AL. Existen modelos de datos, funcionalidades sectoriales, interfaces con terceros y decisiones de operación que necesitan reinterpretarse. Un desarrollo antiguo puede incluir reglas comerciales implícitas que nadie documentó, y una herramienta de IA podría generar una solución aparentemente equivalente que no respete sus excepciones. Por eso hay que reconstruir el requisito funcional antes de transformar el código.

En Business Central online, las extensiones existentes también tienen su propio ciclo de vida. Hay que saber qué versión utilizan, qué dependencias requieren, cómo se validan y si la plataforma dispone ya de una capacidad estándar que vuelva innecesario el desarrollo. La personalización futura tiene sentido como parte de una cartera ordenada y gobernada de cambios, no como un almacén de prototipos acumulados.

Para empresas que aún utilizan Navision o Dynamics NAV, la ruta comienza en migrar de Navision a Business Central. No conviene esperar a una funcionalidad futura para iniciar el análisis de procesos y dependencias.

¿Podrá un responsable funcional desarrollar sin conocer AL?

La aspiración de acercar la personalización a consultores y usuarios de negocio es atractiva, pero debe explicarse con cuidado. Una persona que conoce muy bien el proceso puede aportar valor extraordinario al describir reglas y validar una maqueta. Sin embargo, diseñar una aplicación que contabiliza, mueve inventario o altera permisos requiere comprender consecuencias que no siempre se reflejan en una descripción escrita. La experiencia funcional y la ingeniería son complementarias, no intercambiables.

Lo más probable es que emerjan nuevos modos de colaboración. El consultor podrá participar antes en el prototipado; los usuarios podrán corregir el resultado esperado sin esperar a una implantación completa; y los desarrolladores dedicarán una parte mayor de su tiempo a arquitectura, integración, calidad y revisión de soluciones asistidas por IA. Eso no elimina el desarrollo profesional; desplaza el valor hacia las tareas difíciles de automatizar.

Conviene distinguir también entre experimentar y operar. Una propuesta de modificación en un entorno aislado puede ser útil para evaluar una idea. Una extensión que se instala en la compañía debe superar controles de acceso, calidad y aprobación. Cuanto más flexible resulte el prototipado, más visibles deben ser los límites entre ambas actividades.

El éxito de este modelo no dependerá solo de cómo responda una interfaz conversacional. Dependerá de que todos los participantes compartan el mismo significado de “listo”: una regla validada, documentada, soportada y comprobada bajo las condiciones reales del negocio.

De la primera demostración a una extensión lista para trabajar

La distancia entre prototipo y producción suele infravalorarse. Una pantalla puede mostrar el dato esperado en una demostración y fallar al tratar registros sin completar, usuarios con roles restringidos o datos de varias sociedades. Las pruebas deben cubrir tanto la intención funcional como la compatibilidad técnica. Una personalización útil incluye definiciones de éxito y fracaso que puedan verificarse cada vez que el entorno cambie.

Microsoft documenta el uso de test codeunits, test pages y otros recursos de automatización AL para validar soluciones. Estos mecanismos permiten ejecutar pruebas repetibles de lógica de negocio y detectar regresiones. Page Scripting añade otra perspectiva de validación de recorridos de usuario y aceptación funcional. Ninguna de estas capacidades sustituye por sí sola las comprobaciones de carga, integraciones externas o seguridad, pero juntas pueden ofrecer un control mucho más sólido.

En una compañía con operaciones críticas, antes de desplegar una extensión generada o asistida por IA habría que responder preguntas concretas: ¿se han comprobado documentos abiertos y contabilizados? ¿Qué sucede si la API externa no responde? ¿Cómo se comporta el sistema con monedas diferentes? ¿Puede el usuario repetir una operación sin duplicarla? ¿Existe una estrategia de rollback si la extensión afecta a la contabilización? Una compilación correcta nunca cubre por sí sola esos casos.

Para profundizar en la aceptación funcional, el artículo sobre Page Scripting y pruebas UAT en Business Central explica cómo estructurar recorridos reproducibles antes de una actualización. Es una disciplina especialmente relevante para cualquier ampliación del uso de IA en el desarrollo.

Personalizaciones que se actualizan sin convertir cada release en una crisis

En un ERP cloud, la capacidad de evolucionar con la plataforma es una ventaja importante. También obliga a diseñar desarrollos que soporten un calendario de actualizaciones. La empresa no debería depender de parar indefinidamente las nuevas versiones para conservar una regla construida años atrás. Cuando una extensión está excesivamente acoplada o carece de pruebas, cada actualización se transforma en una negociación entre seguridad, continuidad y presupuesto.

La personalización asistida por IA puede ser una oportunidad para adoptar mejores prácticas desde el primer momento. Por ejemplo, organizar requisitos en un repositorio, vincular cada funcionalidad a casos de prueba, utilizar entornos sandbox representativos, revisar dependencias, compilar contra las versiones correspondientes y documentar qué comportamiento se espera. El valor de una herramienta futura será mayor cuando entre en una disciplina que ya funciona.

También es necesario preparar la respuesta cuando algo sale mal. No basta con conservar el código fuente: hay que conocer cómo desactivar una característica, gestionar los datos que haya modificado, recuperar integraciones y comunicar a los usuarios un procedimiento alternativo. La reversión de una extensión no siempre implica revertir automáticamente los registros o efectos producidos durante su ejecución.

Qué puede hacer una empresa hoy, sin depender del calendario de lanzamiento

No hace falta esperar al acceso anticipado para mejorar el modo en que una compañía decide y mantiene sus personalizaciones. De hecho, conviene utilizar estos meses para resolver cuestiones que suelen bloquear los proyectos: solicitudes poco definidas, falta de propietarios, desarrollos duplicados, pruebas insuficientes y ausencia de un catálogo actualizado de extensiones.

El primer paso es identificar procesos que exigen modificaciones frecuentes y analizar por qué. Si cada semana se solicita un campo o una excepción, quizá el problema sea de diseño funcional, parametrización o gobierno de datos. Si cada actualización requiere corregir integraciones, puede ser necesaria una revisión de arquitectura. Si los usuarios no participan en las pruebas, el foco debe estar en el modelo de validación y no en generar más prototipos.

Una organización preparada para probar nuevas capacidades de IA debería contar con un sandbox adecuado, datos de demostración no sensibles, criterios de permisos, un repositorio de versiones, un conjunto mínimo de pruebas automáticas y una persona responsable de confirmar la disponibilidad de producto, licencias y restricciones de cada fase. Sin estos elementos, la herramienta llegará antes que la capacidad de utilizarla correctamente.

La preparación no busca convertir cada departamento en un equipo de desarrollo. Busca que una idea bien formulada pueda llegar más rápido a una decisión y, cuando corresponda, a una solución fiable.

Cómo evaluar una personalización asistida sin convertirla en un proyecto interminable

El mejor punto de partida no es elegir la funcionalidad más espectacular, sino un caso acotado que tenga una regla de negocio clara y pueda verificarse en poco tiempo. Una validación de ofertas, un campo sectorial con restricciones o una notificación condicionada pueden ser mejores candidatos iniciales que una integración que mueve miles de transacciones. Un piloto debe permitir aprender de la herramienta sin colocar una operación crítica en una situación innecesariamente frágil.

La primera fase consiste en expresar el problema con precisión. Deben quedar identificados el usuario, la decisión que quiere tomar, los datos que necesita, las excepciones conocidas y los indicadores de éxito. La segunda fase revisa las alternativas sin desarrollo, porque un prototipo técnicamente atractivo carece de valor si resuelve peor algo que ya estaba disponible. Solo después debe evaluarse la generación asistida, su revisión y la estrategia de despliegue.

Para decidir si continuar, conviene comparar el resultado con un procedimiento de trabajo existente: tiempo de clarificación, número de cambios funcionales, defectos detectados, esfuerzo de pruebas, tiempo de revisión del código y soporte posterior. No tiene sentido declarar éxito porque una demo funcionó una vez; tampoco sería razonable rechazar la IA porque un primer prototipo necesitó intervención técnica. El juicio debe basarse en el coste y la calidad del resultado completo.

Los errores más habituales cuando una empresa introduce IA en el desarrollo del ERP

La experiencia con herramientas de programación asistida ya muestra que la velocidad puede generar una sensación engañosa de seguridad. Cuando un borrador parece convincente, tendemos a dedicar menos tiempo a comprobar sus supuestos. En sistemas de gestión empresarial, esa confianza prematura resulta especialmente peligrosa porque muchas reglas de negocio están distribuidas entre la aplicación estándar, extensiones, integraciones y prácticas del usuario.

Estos riesgos no son argumentos para detener la innovación. Son motivos para profesionalizarla. Un proceso de personalización con reglas claras permite probar nuevas herramientas con más libertad, porque delimita las consecuencias de equivocarse y facilita aprender de los resultados.

La oportunidad de 2027 no es que desaparezca el trabajo humano. Es que una parte del esfuerzo repetitivo pueda reducirse y liberar capacidad para entender mejor el negocio, diseñar buenas reglas y acompañar a los usuarios. Esa transformación será más valiosa en organizaciones que ya hayan establecido criterios de calidad y control.

Cómo presentar el caso ante un CIO, un CFO y la dirección de operaciones

Los responsables de tecnología suelen valorar la mantenibilidad, la seguridad, la compatibilidad de versiones y la capacidad de responder a nuevas necesidades. Los responsables financieros necesitan entender cuánto cuesta mantener el ERP y qué resultados genera la inversión. Operaciones quiere que los procesos funcionen sin fricción y sin interrupciones. Customize with Copilot puede conectar esas preocupaciones, pero para ello la conversación debe plantearse en términos comprensibles para las tres áreas.

Para un CIO, el caso debe explicar cómo se evita la proliferación de extensiones y cómo mejorará la disciplina de desarrollo. Para un CFO, tiene que distinguir reducción de esfuerzo inicial de coste total de propiedad, incorporando formación, controles, consumo y soporte. Para Operaciones, debe mostrar qué decisión se tomará antes o qué trabajo dejará de repetirse, sin introducir nuevos pasos innecesarios.

No conviene presentar porcentajes de ahorro generales si no están respaldados por mediciones propias. Una compañía que tarda semanas en aclarar los requisitos puede obtener grandes beneficios del prototipado temprano; otra cuyo problema reside en integraciones complejas tendrá una economía diferente. La manera profesional de construir una propuesta es establecer una línea base y comparar proyectos semejantes con y sin asistencia de IA cuando las capacidades estén disponibles.

En el ecosistema de Dynamics 365 Business Central, el diseño de una solución debe valorar además su relación con Microsoft 365, Power Platform, datos y herramientas de análisis. Una buena personalización no debería convertirse en una isla nueva.

Qué cambia cuando Business Central forma parte de una arquitectura Microsoft integrada

Una decisión sobre extensiones no puede tomarse aislando el ERP de todo lo demás. En muchas empresas, Business Central intercambia información con CRM, Power Platform, almacenes de datos, sistemas industriales, soluciones de construcción o aplicaciones de clientes y proveedores. Una pequeña modificación de una tabla o regla de validación puede propagarse a informes, automatizaciones o integraciones. Ese alcance es precisamente lo que necesita ser visible antes de aceptar un cambio.

Cuando la personalización afecta a un proceso transversal, puede ser más adecuado ajustar el diseño de APIs, eventos, dataverse o la capa de integración que insertar lógica en una pantalla. También es posible que el problema sea de calidad de datos y no de desarrollo: una nueva extensión no arregla clientes duplicados, artículos mal categorizados o responsabilidades ambiguas. El diagnóstico inicial debería contemplar esos factores.

El potencial de la IA aumenta cuando existe un modelo claro de datos, procesos y servicios. De lo contrario, cada nueva herramienta se enfrenta a una red de excepciones que ni el equipo técnico comprende por completo. Preparar Business Central para un desarrollo asistido significa, en la práctica, preparar su arquitectura para seguir evolucionando.

Para profundizar en los patrones de conexión y agentes, pueden consultarse Business Central y MCP, Power Platform integrado con Business Central y IA sobre Business Central.

Respuestas para empresas que se plantean Customize with Copilot

Fuentes para seguir la evolución de la personalización asistida

Los anuncios relacionados con herramientas de IA deben contrastarse con la documentación de producto y con las experiencias prácticas de desarrolladores y consultores. Las sesiones de Directions muestran la dirección de innovación; Microsoft Learn detalla capacidades publicadas y sus requisitos; la comunidad especializada aporta pruebas de campo, limitaciones y buenas prácticas que ayudan a interpretar las novedades.

La disponibilidad y los plazos de las capacidades anunciadas pueden cambiar. Antes de contratar, activar o planificar una funcionalidad nueva, conviene comprobar los requisitos publicados para la versión y los programas de acceso correspondientes.

Un Business Central más adaptable necesita una organización más preparada

Customize with Copilot apunta a reducir una de las distancias habituales en proyectos ERP: la que existe entre explicar lo que necesita el negocio y visualizar una solución. Si esa distancia disminuye, las empresas podrán explorar alternativas antes, revisar requisitos con más precisión y concentrar el esfuerzo técnico en construir lo que realmente aporta valor. Es una oportunidad relevante para organizaciones que necesitan seguir cambiando sin convertir su ERP en una sucesión interminable de excepciones.

El elemento decisivo será la calidad del proceso que rodee a la nueva tecnología. Una compañía con datos fiables, procedimientos definidos, permisos claros y extensiones bien gobernadas estará mejor situada para aprovecharla. Una compañía con personalizaciones acumuladas, dependencias desconocidas y poca disciplina de pruebas puede terminar haciendo más rápido precisamente aquello que le genera problemas.

La preparación empieza con decisiones que ya pueden tomarse: identificar el valor de cada personalización, recuperar el conocimiento funcional, evaluar qué debe quedar en el estándar y desarrollar un modelo consistente de pruebas y soporte. Cuando Microsoft concrete el acceso y las capacidades, será posible medir qué parte del proceso mejora realmente y qué límites deben seguir bajo responsabilidad humana.

Desde Dynamics 365 Business Central hasta Copilot y agentes en el ERP, el valor aparece cuando tecnología, datos, procesos y personas se diseñan como una arquitectura coherente. La IA puede acelerar ese trabajo. El criterio empresarial y técnico sigue siendo indispensable.

De la idea al ERP preparado para evolucionar