Tu ERP no debería hacerse más lento cada vez que tu empresa mejora un proceso
La primera personalización suele ser fácil de justificar: un campo adicional para el equipo de ventas, una validación especial en compras, una regla de aprovisionamiento o una integración que evita tener que introducir dos veces la misma información. La segunda también. A partir de cierto número de extensiones, sin embargo, el coste acumulado empieza a ser menos evidente. Cada cambio añade condiciones, dependencias, eventos, consultas, llamadas a otros sistemas y decisiones que alguien tendrá que mantener. Un ERP que funcionaba con veinte usuarios puede comportarse de forma muy distinta cuando atiende a ciento cincuenta, procesa miles de líneas al día o trabaja con sociedades adicionales.
Lo importante es evitar un diagnóstico fácil: que Business Central vaya lento no significa necesariamente que la plataforma sea el problema. Puede haber una extensión mal diseñada, una consulta ineficiente, demasiada lógica ejecutándose al abrir una página, un servicio externo que responde tarde, un dato maestro mal gobernado o varias tareas compitiendo por recursos. También puede existir una combinación de causas. Cambiar de infraestructura, ampliar servicios o culpar a la última versión sin medir suele aumentar el presupuesto sin resolver el origen.
En empresas industriales, constructoras, distribuidoras o grupos con varias sociedades, una demora pequeña repetida miles de veces tiene impacto real. En un proceso financiero ralentiza el cierre; en un almacén retrasa movimientos; en ventas reduce la agilidad; en un proyecto impide disponer de cifras fiables cuando hay que decidir. El rendimiento ya no es una conversación exclusiva de desarrolladores: afecta a productividad, servicio, rentabilidad y confianza en el ERP.
En Directions EMEA 2026, Microsoft puso el foco en cómo pasar de reparar incidencias de rendimiento a construir soluciones más robustas desde su diseño. Las iniciativas OptimAL y BCQuality aportan dos piezas complementarias a esa conversación: medición y mejora del código, por un lado, y criterios de calidad que los equipos pueden aplicar también con ayuda de IA, por otro.
¿Sabemos cuánto tarda hoy un proceso crítico, qué parte corresponde a nuestras extensiones y qué debería ocurrir cuando dupliquemos el número de operaciones? Si no podemos responder, estamos gestionando el rendimiento por sensaciones.
Seis señales de que una personalización está dejando de ser una ventaja
Los problemas de calidad rara vez aparecen con una etiqueta que diga “esta extensión está mal diseñada”. Suelen manifestarse como incidencias operativas aparentemente independientes. Un informe que cada mes tarda más; una pantalla que algunos días funciona bien y otros se queda esperando; un pedido que requiere demasiados segundos para registrar; un conector que repite solicitudes y acaba saturando un servicio. Cada equipo ve su propio síntoma y solicita una solución local. El resultado puede ser una colección de correcciones que nunca atacan el patrón común.
Antes de decidir un rediseño conviene distinguir síntomas que afectan a usuarios, procesos automáticos, integraciones y periodos de cierre. Cuando la degradación se concentra en un momento o en una transacción, la pista puede ser muy diferente de una lentitud generalizada. Además, no todos los problemas proceden de una extensión propia: también pueden estar relacionados con aplicaciones de terceros, configuración funcional, tamaño y distribución de datos o accesos externos.
La consolidación, los informes de control o las conciliaciones tardan cada vez más, aunque el volumen no haya crecido en la misma proporción.
Abrir una ficha, desplazarse por una lista o consultar un FactBox implica cálculos y accesos que el usuario no puede identificar.
Picos de recepción, picking o registro de movimientos aumentan esperas, colisiones y reintentos en operaciones que deberían ser repetibles.
Una API o conector responde bien en pruebas pequeñas, pero falla o agota límites cuando se incorporan más clientes, sociedades o productos.
Nadie dispone de un inventario fiable de dependencias, pruebas repetibles y criterios para saber si una nueva versión ha cambiado el comportamiento de un proceso.
Solo uno o dos técnicos conocen los desarrollos, las decisiones no están documentadas y cualquier mejora se convierte en una investigación.
OptimAL y BCQuality no son lo mismo. Y ninguna de las dos es una solución mágica.
Aunque ambos nombres hayan ganado visibilidad en la comunidad de Business Central, representan enfoques distintos. Confundirlos conduce a expectativas equivocadas: OptimAL no es una opción que se activa en una ficha del ERP; BCQuality no instala un agente autónomo que certifica automáticamente todas las extensiones. Entender el alcance de cada iniciativa ayuda a identificar dónde pueden aportar valor y dónde siguen siendo necesarias pruebas, mediciones y decisiones humanas.
Iniciativa impulsada por Microsoft y desarrollada con Ciellos y expertos de la comunidad para partners e ISVs. Trabaja sobre código real, patrones de rendimiento, telemetría, aprendizaje y validación de mejoras.
Repositorio de conocimiento y habilidades publicado por Microsoft. Puede ayudar a revisar código AL y planes de desarrollo mediante herramientas compatibles de IA, pero no sustituye al compilador, los analizadores, los tests ni a la revisión profesional.
El cliente obtiene valor cuando su partner aplica estas prácticas sobre procesos reales, mide los cambios y conserva la capacidad de mantenerlos. Que una herramienta esté disponible no implica que un proyecto concreto haya alcanzado mayor calidad.
OptimAL: de apagar incendios a entender por qué una solución no escala
OptimAL nace de una pregunta sencilla: ¿qué ocurriría con nuestras extensiones si el mayor cliente duplicara su volumen de actividad? La sesión anunciada en Directions EMEA 2026 habla de código real, patrones que frenan la escalabilidad y del uso de telemetría y herramientas asistidas por IA para detectar, proponer y validar mejoras. El propósito no se limita a optimizar una línea concreta; busca que el partner adquiera una disciplina de ingeniería del rendimiento sostenible.
Según la presentación pública de la iniciativa, OptimAL se dirige a partners e ISVs de Business Central que desarrollan extensiones y soluciones, especialmente cuando arrastran código heredado, atienden escenarios complejos o no tienen certeza de cómo escalará su producto. La iniciativa combina formación, análisis, acompañamiento práctico y trabajo sobre las soluciones del participante. No debe confundirse con una función incluida por defecto en todas las suscripciones de Business Central.
Waldo, MVP muy activo en la comunidad, ha explicado que el programa pretende trabajar con datos y con código propio: establecer una base, investigar mediante telemetría y modificar los patrones que realmente limitan el rendimiento. Su enfoque es relevante porque pone el acento en los resultados medibles y en la capacidad del equipo para seguir mejorando después del primer diagnóstico.
Para una empresa cliente, la implicación es clara: importa menos que su partner mencione OptimAL en una presentación y más que pueda demostrar que aplica una metodología de medición, optimización y validación. La velocidad de registro de un pedido antes y después de un cambio, el número de consultas innecesarias que se evitan o el comportamiento ante usuarios concurrentes son evidencias más útiles que una promesa de “ERP más rápido”.
¿Cuál es el proceso lento? ¿Qué datos lo demuestran? ¿Qué parte de la ejecución depende de código propio o de terceros? ¿Cómo se verificará la mejora? ¿Qué plan existe para detectar regresiones en las siguientes versiones?
La iniciativa se presenta en el espacio de OptimAL para partners y en la sesión de Directions sobre rendimiento y OptimAL. El análisis de Waldo sobre OptimAL aporta una perspectiva complementaria desde la experiencia de comunidad.
BCQuality: cuando el equipo y la IA comparten un criterio para revisar código
Una parte del coste de mantener Business Central nace de decisiones que se repiten: cómo consultar registros, dónde colocar una validación, qué filtros aplicar antes de recorrer una tabla, cuándo conviene separar procesos o cómo documentar una excepción. Si cada desarrollador resuelve esos asuntos por su cuenta, los resultados pueden ser inconsistentes. Si se incorpora IA generativa sin contexto específico, también pueden aparecer recomendaciones técnicamente plausibles pero incorrectas para la versión, localización o patrón AL correspondiente.
BCQuality intenta aportar una base común de conocimiento y habilidades para mejorar esas decisiones. Microsoft lo publica como un repositorio abierto con buenas prácticas, antipatrones, muestras y referencias. Su utilidad no reside en reemplazar a un arquitecto ni en convertir un informe automático en garantía de calidad; reside en ofrecer criterios especializados que las personas y las herramientas de IA pueden consultar y aplicar durante una revisión o una planificación de desarrollo.
El repositorio público documenta una capacidad de revisión de código AL mediante plugin para GitHub Copilot CLI, junto con orientación de planificación en preview. También indica que la revisión automática de pull requests integrada con AL-Go se encuentra en desarrollo. Conviene diferenciar lo disponible ahora de las integraciones anunciadas para no prometer procesos de calidad que todavía no estén incorporados al entorno concreto de cada partner.
Los hallazgos de una revisión pueden incluir ubicación, gravedad, confianza y referencia a la recomendación que los sustenta. Pero un resultado sin incidencias detectadas no demuestra por sí solo ausencia de errores. La cobertura del conocimiento es parcial, y compilar, ejecutar pruebas y revisar el comportamiento de negocio siguen siendo pasos imprescindibles.
Revisar si la solución propuesta respeta patrones AL, estructuras de datos y límites de la versión objetivo; aclarar criterios de aceptación.
Examinar recorridos de tablas, filtros, cálculos, concurrencia y dependencias; contrastar los avisos con el código y con el proceso real.
Compilar, analizar, probar escenarios funcionales, medir rendimiento y validar que la nueva extensión no altera procesos existentes.
Mantener telemetría, registrar incidencias, actualizar pruebas y revisar si los cambios de Microsoft o de terceros afectan a la solución.
El punto de partida es el repositorio oficial BCQuality, que explica su alcance, la integración disponible y los límites del análisis.
Una cadena de calidad que empieza mucho antes de pulsar «Publicar»
OptimAL y BCQuality son útiles en momentos distintos, pero el proceso correcto incluye bastantes más piezas. No hay una sola herramienta capaz de detectar toda la deuda técnica: una anomalía funcional puede no manifestarse como problema de rendimiento, un informe puede ser rápido pero ofrecer datos equivocados y una prueba automática puede ejecutarse sin cubrir un caso crítico que nadie haya definido.
La estrategia más sólida empieza por acordar con las áreas de negocio qué resultados deben mantenerse estables. Después se revisa el diseño técnico, se analiza el código, se verifica el comportamiento funcional y se mide la respuesta con datos y volúmenes que representen el entorno real. Solo entonces tiene sentido comparar resultados y decidir si una actualización es aceptable.
Estándar o extensión, permisos, integración, proceso de aprobación, datos, responsabilidad y requisitos de mantenimiento.
Compilador y analizadores AL, revisión humana, buenas prácticas y habilidades BCQuality cuando resulten apropiadas.
Test codeunits, recorridos críticos de usuario, Page Scripting y validación de resultados contables u operativos.
Telemetría, perfiladores AL y Performance Toolkit en entornos controlados; comparación con la línea de base.
Versiones, dependencias, pruebas de regresión, ventana de publicación y plan de recuperación acordado.
Alertas, revisión de incidencias, evolución de tiempos y mediciones después de cada cambio relevante.
La frase “esta actualización mejora el rendimiento” solo tiene valor cuando conocemos el escenario probado, el volumen, los tiempos, la versión y las condiciones de la comparación.
Page Scripting, AL Tests y Performance Toolkit: tres preguntas distintas
Uno de los errores más habituales es utilizar “hacer pruebas” como si todas las pruebas fueran equivalentes. No lo son. Una grabación de una secuencia de usuario no demuestra que cien personas puedan ejecutar el mismo proceso a la vez; una medición de carga no garantiza que los importes contables sean correctos; y un test unitario satisfactorio no sustituye una validación de extremo a extremo en la interfaz.
Para un director de sistemas, la utilidad está en exigir una combinación proporcionada al riesgo. Un cambio en el cálculo de impuestos requiere evidencias diferentes a una mejora visual de una ficha. Una extensión de almacén sometida a picos de concurrencia necesita un plan distinto al de un informe que se ejecuta una vez al mes. La selección de pruebas debe justificarse por impacto potencial y por probabilidad de fallo.
Permite grabar y reproducir recorridos del cliente web y comprobar pasos de procesos relevantes. Es útil para regresiones y UAT, pero no es una prueba de carga ni automatiza todo el ecosistema externo.
Los tests AL permiten verificar reglas y resultados de una extensión; en versiones compatibles pueden ejecutarse desde Test Explorer en Visual Studio Code. Su alcance depende de qué se haya programado para probar.
Ayuda a simular determinadas cargas de trabajo y comparar tiempos y comportamiento entre versiones o escenarios en un entorno de pruebas adecuado.
Registra señales de uso, errores y operaciones costosas; aporta trazabilidad a incidentes reales, aunque debe estar configurada antes de que ocurran.
Para profundizar: Page Scripting en Business Central, ejecución de AL Tests en Visual Studio Code y telemetría del Performance Toolkit.
Cómo diagnosticar una extensión lenta sin empezar por reescribirla
La tentación inicial consiste en abrir el código y buscar un fragmento sospechoso. A veces funciona, pero como método general es insuficiente. Primero hay que delimitar el síntoma, reproducirlo y obtener una línea de base. Sin esa secuencia resulta muy fácil “optimizar” una operación que apenas influye en la demora real o mejorar el tiempo de una prueba irrelevante para el usuario.
El diagnóstico comienza con una ficha del problema: nombre del proceso, usuarios afectados, sociedad, momento del día, volumen, extensiones relacionadas, dependencias, versión, duración esperada y duración observada. Se deben recoger escenarios en los que funciona bien y otros en los que falla. Esas diferencias ayudan a distinguir datos, concurrencia, integraciones o comportamiento de ciertas páginas.
Después se combina la telemetría ya configurada con perfiladores de ejecución y revisión técnica. Microsoft documenta herramientas para localizar consultas SQL lentas, métodos AL costosos, bloqueos y procesos que se ejecutan más veces de lo necesario. El objetivo no es obtener el mayor número posible de métricas, sino identificar una causa plausible, modificarla de manera controlada y demostrar que el resultado mejora sin alterar la lógica.
La propia documentación de Microsoft propone un ciclo continuo de medir, localizar el cuello de botella y eliminarlo, como explica Cómo trabajar con un problema de rendimiento en Business Central.
Application Insights: dejar de descubrir problemas únicamente cuando alguien llama
Sin datos históricos, una incidencia intermitente acaba convirtiéndose en una discusión de percepciones. El departamento comercial asegura que los pedidos van lentos; Finanzas observa demoras de cierre; el proveedor pide repetir la operación cuando ya funciona. La telemetría permite investigar qué ocurrió y cómo cambió el comportamiento respecto a periodos anteriores.
Business Central puede enviar información de actividad y rendimiento a Azure Application Insights tanto a nivel de entorno como, cuando está configurado, a nivel de extensión. Entre las señales disponibles están determinadas operaciones prolongadas, llamadas a servicios web, informes, bloqueos y eventos de ciclo de vida de extensiones. No registra mágicamente toda la lógica ni garantiza que cada problema quede capturado: hay que saber qué observar y definir umbrales que tengan sentido.
Para una empresa, la gobernanza de estos datos debe incluir propietarios, acceso adecuado, retención razonable y protección de información sensible. Los indicadores técnicos se vuelven útiles cuando se asocian con un resultado de negocio. Saber que un método ha consumido muchos milisegundos tiene menos valor que demostrar que la creación de un pedido se degrada de manera sistemática y está afectando a un proceso comercial.
En equipos de desarrollo, recursos comunitarios como BC Telemetry Buddy, impulsado por Waldo, exploran cómo consultar telemetría de Application Insights mediante herramientas e interfaces que facilitan la investigación. Su existencia no elimina la necesidad de entender los datos, validar consultas y evitar conclusiones precipitadas a partir de una sola sesión.
Duración de registros, demoras de informes críticos, errores por proceso, llamadas repetidas, tiempos de respuesta de integraciones y comportamiento después de actualizar.
Umbrales relacionados con compromisos operativos, señales persistentes y escenarios reproducibles, evitando alarmas constantes por variaciones normales.
Correlacionar versión, extensión, volumen, empresa, usuario autorizado y hora sin revelar más información de la necesaria.
Comparar condiciones equivalentes antes y después y mantener una ventana de observación para detectar regresiones.
Documentación: telemetría oficial de Business Central; iniciativa comunitaria: BC Telemetry Buddy.
Los patrones AL que más conviene revisar cuando crece el volumen
Hay decisiones de desarrollo que apenas se perciben con un conjunto de pruebas pequeño y que empeoran mucho al aumentar las operaciones. No todas representan un error: a veces obedecen a requisitos de negocio legítimos. El trabajo de ingeniería consiste en entender cuándo una elección introduce coste y si existe una alternativa que preserve exactamente el resultado esperado.
Microsoft mantiene una guía extensa de patrones de rendimiento AL: filtrar antes de recorrer registros, evitar consultas o cálculos repetidos, emplear datos parciales cuando solo se necesitan determinados campos, controlar los trabajos en segundo plano, revisar las llamadas a servicios externos y reducir los bloqueos derivados de operaciones concurrentes. Ninguna regla debe aplicarse de manera ciega. Cambiar el orden de una operación o introducir paralelismo sin entender las transacciones puede generar problemas mayores que los que pretendía resolver.
Recorrer tablas completas para después descartar elementos en AL puede provocar accesos innecesarios. En ocasiones conviene aplicar filtros con SetRange o SetFilter antes de FindSet.
En ciertos escenarios, SetLoadFields ayuda a trabajar con registros parciales y reduce lecturas; exige conocer qué campos serán necesarios y sus limitaciones.
FlowFields, FactBoxes, cálculos o consultas ejecutados repetidamente al abrir una página pueden empeorar la respuesta de usuarios.
Operaciones que mantienen transacciones abiertas o llamadas concurrentes sobre datos comunes pueden introducir esperas, conflictos y reintentos.
Picos de APIs, reintentos mal gestionados y llamadas externas síncronas pueden afectar a la experiencia, especialmente ante errores 429, 503 o 504.
Colas de tareas, procesos batch y extracciones que recalculan todo el histórico cuando solo necesitan cambios pueden ocupar recursos innecesarios.
Microsoft desarrolla estos ejemplos en patrones de rendimiento para desarrolladores AL.
Lo que una revisión con IA puede detectar y lo que no debería decidir sola
La inteligencia artificial puede acelerar la identificación de un antipatrón, resumir una ruta de ejecución o sugerir alternativas al analizar una extensión compleja. Pero encontrar una posible ineficiencia no implica conocer la totalidad de la regla de negocio. Una rutina que parece redundante podría responder a un requisito fiscal; un filtro añadido para mejorar el tiempo podría excluir operaciones válidas; y una refactorización que compila puede alterar el orden de contabilización.
Por eso, el valor de BCQuality y de las nuevas capacidades de desarrollo asistido crece cuando funcionan dentro de un método. Hay que solicitar razones y referencias, identificar las condiciones bajo las que se aplica una recomendación, verificar que corresponda a la versión de Business Central utilizada y medir el comportamiento con datos. Un aviso de confianza alta no equivale a una autorización para cambiar producción.
La comparación con un auditor técnico resulta útil: revisar documentos puede encontrar inconsistencias, pero el resultado debe interpretarse junto a las reglas del proyecto, los controles funcionales y la responsabilidad del equipo. La revisión humana y la validación con usuarios responsables siguen siendo esenciales cuando se afectan inventarios, pagos, fiscalidad, precios o trazabilidad.
Aplicar cambios sugeridos por un agente directamente sobre una extensión utilizada en producción, sin revisión del código, pruebas, evidencia de mejora y vía de recuperación.
AL-Go: que una revisión no dependa de acordarse el viernes
En un equipo con varios desarrolladores y aplicaciones interdependientes, la calidad no puede descansar únicamente en la experiencia de una persona. Se necesitan procesos repetibles que identifiquen cambios, preparen paquetes, ejecuten verificaciones y registren qué versión se ha aprobado. AL-Go para GitHub ofrece plantillas y automatizaciones destinadas a organizar trabajo de DevOps en proyectos AL.
La automatización aporta consistencia, no infalibilidad. Un proceso puede compilar perfectamente y mantener un problema de negocio; también puede ejecutar tests correctamente mientras el rendimiento se degrada en una combinación de usuarios que nadie simuló. Por ello, un flujo maduro reúne controles automáticos, aprobación profesional y una verificación basada en riesgos.
La integración de revisiones de BCQuality con pull requests dentro de AL-Go aparece descrita como trabajo en curso en el repositorio público de Microsoft. No debe venderse como una prestación completamente desplegada para cualquier repositorio. Las organizaciones pueden utilizar capacidades disponibles y preparar un modelo de gobierno que incorpore mejoras futuras sin depender de ellas para empezar a trabajar bien hoy.
Referencia oficial: recursos de desarrollo y AL-Go para Business Central.
El coste de una extensión no es lo que costó programarla: es lo que exige cada año para seguir funcionando
Un desarrollo a medida puede ser perfectamente rentable. El error consiste en evaluarlo solo por el importe inicial y olvidar el mantenimiento de versiones, la complejidad que añade a los tests, la dependencia del equipo que lo conoce o la carga que introduce en procesos cotidianos. La decisión entre estándar, extensión, Power Platform e integración no tiene una única respuesta. Tiene que basarse en cuánto valor aporta el requisito y cuánto cuesta mantenerlo sin riesgo desproporcionado.
Análisis, diseño, desarrollo, licencias relacionadas, integración, formación y pruebas iniciales.
Evolución de versiones, soporte de incidencias, actualización de dependencias, mantenimiento de tests y telemetría.
Tiempo acumulado de usuarios esperando, procesos manuales alternativos, fallos y conciliaciones correctivas.
Capacidad del equipo consumida manteniendo código heredado en lugar de mejorar operaciones o desarrollar nuevos servicios.
En una revisión de TCO, estos cuatro grupos deben analizarse juntos. Es frecuente que el beneficio de refactorizar no esté en eliminar una aplicación sino en simplificar una ruta crítica, reducir una dependencia externa o facilitar actualizaciones futuras. Otras veces, el código puede seguir intacto y la mejora real estar en la configuración o el uso del producto.
La rentabilidad debe calcularse sobre operaciones y riesgos evitados, no sobre el número de líneas de código eliminadas o la cantidad de advertencias que encuentra una herramienta.
Un proceso que tarda segundos de más puede costar muchas horas al año
Pongamos un ejemplo hipotético, no una estimación de rendimiento de Business Central. Una distribuidora registra 400 pedidos al día. Una personalización añade ocho segundos innecesarios al proceso de confirmación. Si cada pedido recorre esa ruta una vez, el tiempo acumulado alcanza 3.200 segundos diarios, aproximadamente 53 minutos de espera distribuida entre distintos usuarios. En 220 días de actividad serían unas 196 horas teóricas de tiempo de proceso.
Esta cuenta no equivale automáticamente a 196 horas de productividad recuperable: hay que comprobar si el retraso bloquea realmente el trabajo, si las operaciones se ejecutan en paralelo y qué parte es imputable al desarrollo. Tampoco informa de por sí cuánto costaría corregir el problema. Su utilidad está en mostrar cómo se convierte un pequeño deterioro repetitivo en una pregunta económica que merece medirse.
Una evaluación real debería registrar operaciones por periodo, tiempo por ejecución, variación entre escenarios, esfuerzo de usuarios, incidencias asociadas y coste de intervención. Después se contrastaría con una versión corregida en condiciones equivalentes. La diferencia entre una mejora aparente y un caso de inversión defendible es precisamente esa trazabilidad.
Registrar escenarios, volumen representativo, duración mediana y casos lentos, errores y costes de soporte.
Repetir los mismos casos, validar resultados y comprobar que no se introduce un nuevo cuello de botella.
Estimar únicamente el tiempo de espera que tiene efecto operativo y valorar su recuperación con criterios aprobados por el negocio.
Incluir diagnóstico, desarrollo, pruebas, puesta en marcha, seguimiento y posibles riesgos de reversión.
Una prueba con diez registros en un entorno vacío no demuestra que la misma mejora exista con cientos de miles de movimientos, varias sociedades y decenas de usuarios.
Fabricación: la personalización que optimiza una orden pero ralentiza toda la planta
En fabricación, el coste de un desarrollo ineficiente puede pasar inadvertido hasta que crece el volumen. Una validación adicional en una orden de producción parece inofensiva cuando se ejecuta ocasionalmente; si se activa en cada movimiento de consumo, registro de producción o actualización de disponibilidad, su efecto puede multiplicarse. Además, los procesos industriales suelen conectarse con dispositivos, datos externos, planificación y reglas de trazabilidad que elevan la complejidad.
La evaluación debe comenzar por identificar dónde se concentra la espera: planificación, liberación de órdenes, consumos, cálculo de necesidades, integración MES, valoración o reporting. Después conviene comprobar si la extensión recorre más registros de los necesarios, recalcula información idéntica, actualiza datos bloqueados por otros procesos o depende de servicios con tiempos variables.
Una buena solución preserva el criterio funcional y prueba un volumen cercano al previsto para la actividad futura. Cuando una empresa abre otra planta, amplía almacenes o incorpora procesos de producción adicionales, el objetivo no es exigir al ERP que responda “más o menos” sino definir requisitos técnicos coherentes con el crecimiento. La capacidad de mantener ese comportamiento forma parte del valor de una implantación especializada.
Consulta también Business Central para fabricación y el hub de Dynamics 365 Business Central.
Construcción: cuando cada obra añade nuevas excepciones al ERP
Una constructora puede necesitar reglas de certificación, revisión de costes, gestión de subcontratas, validación de compras, control de maquinaria y seguimiento por obra. Son procesos legítimamente complejos. El riesgo aparece cuando se convierten en extensiones superpuestas sin revisar su interacción: un cálculo adicional en cada partida, una validación repetida al registrar documentos o un informe que cruza información de cientos de obras puede degradarse justo cuando la empresa necesita mayor visibilidad.
El rendimiento no se mide únicamente en la pantalla del técnico. Debe observarse la cadena completa: parte de trabajo, imputación de costes, avance de certificación, aprobación, contabilización y analítica. Una mejora local que retrasa una tarea posterior no representa necesariamente una mejora del proceso. La relación entre módulos, extensiones e integraciones debe formar parte de las pruebas.
Un caso especialmente delicado aparece cuando se añade IA sobre datos de obras y proyectos. Si la información se extrae mediante procesos costosos, repetidos o no gobernados, la nueva interfaz puede amplificar los problemas que ya existían. La preparación para automatización e IA debe comenzar por datos, arquitectura, permisos y rendimiento de los flujos relevantes.
Para valorar el contexto sectorial, IB Building 365 conecta los procesos de obra con la gestión empresarial.
¿Cuándo una validación mejora realmente el control de la obra y cuándo está replicando una regla que debería resolverse en otro punto del proceso?
Distribución: inventario, pedidos y APIs sometidos a picos
La distribución combina transacciones rápidas y volúmenes variables. Un pedido de comercio electrónico puede parecer sencillo, pero antes de entregarse conecta disponibilidad, almacén, precio, impuestos, cliente, condiciones comerciales y transporte. Una extensión que consulta información repetidamente o que realiza llamadas externas síncronas en una operación crítica puede convertirse en una fuente de latencia incluso cuando cada sistema individual funciona según lo esperado.
En este contexto, optimizar una sola consulta no siempre basta. Hay que revisar el diseño de las integraciones, la gestión de picos, los reintentos, la idempotencia y el tratamiento de errores. Una aplicación externa que recibe un 429 o un 503 debe responder de forma controlada; reintentar continuamente puede empeorar la saturación. También hay que separar las operaciones que necesitan respuesta inmediata de las que pueden realizarse mediante procesos desacoplados o colas, cuando el negocio lo permita.
Los resultados deben comprobarse con escenarios realistas de alta actividad, múltiples usuarios y movimientos simultáneos. El éxito no consiste solo en que el procesamiento sea rápido, sino en que la información resulte consistente: ningún pedido duplicado, reserva incorrecta o desajuste de inventario justifica una mejora de milisegundos.
Microsoft documenta las prácticas de rendimiento para APIs, OData y procesos AL, incluidas recomendaciones para gestionar límites y reintentos.
Empresas de servicios: proyectos, hojas de horas y facturación recurrente
En organizaciones de servicios, la complejidad suele esconderse en reglas comerciales, imputaciones a proyectos, aprobaciones, previsión de ingresos y facturación recurrente. Cuando cada cliente exige una excepción distinta, el equipo puede acumular lógica especial en varias extensiones. El problema no es tener particularidades: es permitir que se conviertan en una estructura difícil de entender y comprobar.
Un diagnóstico útil separa la captura de horas, los criterios de aprobación, la facturación, la contabilización y el reporting. Si las validaciones se repiten a lo largo de toda la cadena, cada cambio de política obliga a revisar varios puntos del sistema. La mejora puede consistir en simplificar el modelo y mantener las reglas en lugares coherentes, no necesariamente en buscar una técnica de programación más rápida.
A medida que se incorporan agentes o automatizaciones para preparar partes, propuestas o informes, una arquitectura limpia facilita rastrear decisiones. Cuando el proceso está mal documentado, la IA no elimina esa falta de claridad: puede distribuirla a mayor velocidad. La calidad del desarrollo debe evaluarse también por su transparencia y capacidad de auditoría.
Una personalización fiable debe ser además comprensible, trazable, segura y sencilla de evolucionar. Un proceso rápido que calcula mal una factura no es una buena solución.
¿Hace falta una extensión AL o el requisito se resuelve mejor de otra forma?
Una de las mayores fuentes de deuda técnica nace antes de escribir la primera línea de código: elegir una personalización sin comprobar si el estándar ya ofrece el comportamiento necesario, si existe una configuración funcional, si una solución sectorial cubre el escenario o si una integración desacoplada sería más apropiada. El coste de esa decisión puede acompañar a la empresa durante años.
Business Central permite extender procesos mediante AL, conectarse con Power Platform y trabajar con servicios externos cuando el modelo lo requiere. No existe una tecnología universalmente superior: una regla transaccional crítica puede necesitar ejecutarse muy cerca del ERP; una aplicación de captura especializada quizá encaje mejor en Power Apps; una automatización de aprobación entre varios sistemas puede requerir Power Automate; un análisis de gran volumen puede ser más adecuado en una plataforma de datos.
El criterio debe abarcar integridad de los datos, volumen de llamadas, experiencia de usuario, permisos, gobierno, coste de licencias, rendimiento bajo carga, mantenibilidad y efectos durante una actualización. Un diseño que parece más rápido al principio puede tener un coste muy elevado cuando cambia un proceso o cuando la compañía se internacionaliza.
Preferible cuando cubre el requisito sin perder diferenciación y permite mantener un proceso comprensible.
Adecuada cuando la lógica exige integración profunda con las transacciones y controles propios de Business Central.
Útil para experiencias, flujos o aplicaciones conectadas, valorando licencias, límites, gobierno e integración.
Recomendable cuando el procesamiento masivo, el análisis o el intercambio entre sistemas requieren una arquitectura diferenciada.
La visión de conjunto se desarrolla en Power Platform y Business Central y modernización ERP Microsoft.
Qué pedir a un partner antes de ampliar las personalizaciones
Un partner de Business Central no debería limitarse a estimar cuántas horas necesita para construir una función. Debe explicar qué consecuencias tendrá después: sobre las actualizaciones de Microsoft, sobre la carga operativa, sobre la dependencia técnica, sobre las pruebas y sobre la capacidad de conectar nuevas soluciones. La conversación puede ser directa y comprensible para quienes no desarrollan código.
Qué extensiones existen, quién es responsable, qué versión tienen, qué procesos afectan y de qué otras aplicaciones dependen.
Qué resultados funcionales se comprobarán, qué usuarios validarán, qué volumen se utilizará y cuáles son los criterios de rechazo.
Tiempos de procesos críticos, incidencias relevantes, comportamiento de integraciones y señales de rendimiento antes y después.
Plan de compatibilidad con futuras versiones, documentación, gestión de cambios y procedimiento de recuperación.
La clave es que todas estas evidencias formen parte del servicio, no de una investigación extraordinaria que solo aparece cuando existe una crisis. Una empresa que estudia cambiar de partner también debería pedir esta información para entender la sostenibilidad del entorno que hereda.
Si estás valorando ese escenario, cambiar de partner Dynamics 365 aborda la transición y la continuidad del servicio.
Cuándo merece la pena optimizar y cuándo conviene rediseñar
No todas las extensiones que acumulan años necesitan una reescritura. La edad del código no demuestra por sí sola que sea incorrecto, igual que un desarrollo reciente no garantiza calidad. Una revisión útil clasifica problemas por impacto, frecuencia, posibilidad de reproducción, dependencia, riesgo funcional y esfuerzo de corrección. A menudo, pequeños cambios medidos sobre consultas o cálculos aportan más que un rediseño masivo de procesos estables.
Cuando existen múltiples extensiones que replican reglas, integraciones rígidas, ausencia de pruebas y dependencias de versiones sin soporte, el coste de mantener lo actual puede justificar una revisión arquitectónica. Pero incluso ahí conviene diseñar una transición por procesos, proteger la continuidad del negocio y no acumular cambios simultáneos que dificulten identificar el origen de una incidencia.
La priorización debería comenzar por los procesos donde un fallo tiene efecto económico o contractual: contabilización, pagos, inventario, facturación, expediciones, integridad de datos y cierres. Después se revisan los cuellos de botella que generan espera recurrente. Las mejoras puramente técnicas sin impacto demostrable pueden programarse cuando exista capacidad, pero no deberían desplazar problemas operativos críticos.
Síntoma localizado, causa confirmada y mejora verificable sin alterar la arquitectura principal.
Procesos críticos que cumplen hoy, pero podrían degradarse con crecimiento previsto o una actualización.
Código complejo, duplicaciones y dependencias que hacen costoso mantener nuevas versiones.
Acumulación de problemas estructurales o requisitos nuevos que ya no encajan en el modelo anterior.
No convertir la revisión técnica en una sucesión interminable de mejoras menores. Priorizar el efecto real sobre productividad, continuidad, seguridad y coste total.
Un método de evaluación en cuatro fases, sin detener la operación
Para decidir con rigor no hace falta comenzar con un proyecto de transformación completo. Puede plantearse una evaluación acotada sobre un conjunto pequeño de procesos críticos y un inventario técnico de las extensiones implicadas. La condición es que el alcance quede claro desde el primer día: qué se medirá, qué evidencias tendremos y qué decisiones podremos tomar al terminar.
Primero se seleccionan procesos representativos y se recopila información sobre versiones, extensiones, cargas y síntomas. Después se obtienen mediciones en condiciones reales o razonablemente representativas y se analiza la relación entre los problemas y el código. En una tercera fase se proponen correcciones, estimando esfuerzo, dependencia, riesgo y beneficio potencial. Por último se valida un conjunto limitado de mejoras, se documentan los resultados y se establece un plan de evolución.
El informe de salida debe poder leerse tanto desde Dirección de Sistemas como desde Finanzas u Operaciones. No basta con listar advertencias de análisis estático o tiempos de CPU: hay que interpretar qué procesos están en riesgo, cuáles funcionan correctamente, dónde conviene invertir primero y qué cambios pueden esperar. Cuando se trata de un entorno crítico, las pruebas deben realizarse en condiciones seguras y con un mecanismo de retorno apropiado.
Inventario, procesos, responsables, síntomas, extensiones, dependencias y objetivos de negocio.
Líneas de base, telemetría, perfiles AL, escenarios de carga y revisión del código relevante.
Hallazgos confirmados, causas probables, riesgos, presupuesto y opciones de mejora.
Pruebas en sandbox, comparación de resultados y decisión informada sobre despliegues.
En el marco de una decisión de inversión más amplia, los talleres Business Value permiten estructurar prioridades y resultados esperados.
La IA puede escribir más código. Eso hace todavía más importante saber revisarlo.
La llegada de asistentes de programación a Business Central puede disminuir el esfuerzo necesario para generar un primer borrador, explorar una API o preparar pruebas. Pero la velocidad de producción no es equivalente a la calidad del diseño. De hecho, si las organizaciones incorporan más extensiones sin mejorar arquitectura, controles y telemetría, podrían aumentar más deprisa su deuda técnica.
La combinación de asistencia con IA, revisión basada en criterios especializados y pruebas reales ofrece una perspectiva más sólida. BCQuality aporta conocimiento que puede utilizarse para examinar patrones AL; OptimAL enfatiza la ingeniería continua del rendimiento; las herramientas Microsoft permiten medir y probar. Esa combinación no sustituye el conocimiento del negocio: una regla de impuestos, una excepción de contratos o una condición de trazabilidad requieren especialistas que validen el resultado.
En la evolución prevista de Business Central también aparece Customize with Copilot, una propuesta de personalización asistida mediante lenguaje natural. La promesa de acelerar la adaptación de aplicaciones refuerza precisamente la necesidad de separar una idea funcional, un prototipo y un desarrollo empresarial mantenible. Antes de aprobar un cambio, la organización debe poder entender su impacto, cómo se prueba y quién responde por él.
Será entregar cambios útiles más deprisa, con menos incidencias, pruebas que cubran los procesos relevantes y visibilidad del rendimiento después de publicarlos.
Diez preguntas que un CIO puede hacer sin entrar en el código AL
Una dirección de tecnología no necesita dominar cada sintaxis de AL para gobernar correctamente su plataforma. Necesita un conjunto de preguntas que conviertan una discusión técnica en decisiones verificables. Las respuestas deben permitir distinguir riesgos conocidos, hipótesis que requieren investigación y situaciones donde el sistema ya demuestra un funcionamiento adecuado.
Cuando el proveedor responde exclusivamente con jerga, falta contexto para decidir. Cuando promete una mejora de rendimiento sin fijar un escenario y una forma de medirla, falta evidencia. Y cuando una actualización crítica se plantea sin pruebas de regresión, sin dependencias inventariadas o sin responsables, falta control operativo.
Responder con precisión a estas preguntas permite transformar una sensación de lentitud en un plan de mejora con propietarios y prioridades. Si las respuestas no existen todavía, ese es precisamente el punto de partida de un diagnóstico útil.
De la herramienta a la capacidad de acompañar un ERP que evoluciona
Business Central se actualiza, las operaciones cambian, aparecen nuevas integraciones y las organizaciones incorporan automatización e inteligencia artificial. El valor de un partner no consiste únicamente en conocer las novedades de cada versión, sino en traducirlas en decisiones sostenibles para una empresa concreta. Una extensión puede ser necesaria para diferenciar el negocio; mantenerla fiable y eficiente es parte inseparable de ese proyecto.
Ayesa combina conocimiento de procesos empresariales y de las tecnologías Microsoft para acompañar la evolución de entornos ERP, CRM, datos, automatización y servicios en Azure. Ese enfoque integrado permite considerar las personalizaciones no como islas técnicas, sino como elementos que deben convivir con operaciones, reporting, seguridad y futuras capacidades de IA.
El objetivo de una revisión no es eliminar sin criterio lo desarrollado ni presentar cualquier solución estándar como suficiente. Es conservar aquello que aporta valor, corregir lo que crea problemas y construir una arquitectura que pueda seguir creciendo sin convertir cada actualización en una incertidumbre.
Preguntas frecuentes sobre rendimiento, OptimAL y BCQuality
La combinación de nuevas herramientas de IA, desarrollo AL, telemetría y pruebas puede generar confusión. Estas son las cuestiones más frecuentes que aparecen cuando una empresa quiere mejorar su Business Central sin perder continuidad ni crear dependencias innecesarias.
Es un paquete de desarrollo que permite ampliar o adaptar funcionalidades de Business Central mediante el lenguaje AL. Su valor y sus riesgos dependen de qué proceso modifica, cómo interactúa con el estándar y cómo se prueba y mantiene.
Es una iniciativa de rendimiento dirigida a partners e ISVs de Business Central, impulsada con participación de Microsoft, Ciellos y expertos de la comunidad. Aporta metodología, formación y trabajo práctico para identificar y mejorar problemas de código y escalabilidad; no es un botón del ERP.
No. Microsoft presenta BCQuality como conocimiento y habilidades reutilizables para revisión y planificación de desarrollo AL con herramientas compatibles. No es un agente autónomo ni reemplaza compilador, tests y revisión humana.
El repositorio público describe las revisiones mediante plugin Copilot CLI como una vía disponible y la integración automatizada de pull requests en AL-Go como trabajo en curso. El estado exacto debe comprobarse antes de adoptar un flujo.
Puede deberse a consultas ineficientes, cálculos repetidos, bloqueos, llamadas externas, ampliación de datos o diversas dependencias. También puede haber causas que no proceden del desarrollo. Se necesita medición y diagnóstico antes de atribuir responsabilidades.
Conviene delimitar un proceso, medirlo, revisar telemetría y perfilar las ejecuciones relevantes. Si es posible, se comparan escenarios equivalentes para aislar el efecto de la extensión, con especial precaución en entornos críticos.
No. Ayuda a validar recorridos y operaciones en el cliente web, pero no sustituye pruebas de carga, test unitarios, comprobaciones de datos y verificación de integraciones.
Microsoft documenta AL Profiler, perfiles desde el cliente, telemetría en Application Insights y Performance Toolkit, entre otras. Cada herramienta responde a un tipo de pregunta y requiere una configuración adecuada.
No necesariamente. La edad por sí sola no es un criterio suficiente. Deben priorizarse los problemas confirmados, el coste de mantenimiento, la compatibilidad futura y el valor real del proceso.
No. Puede ayudar a analizar o proponer cambios, pero la arquitectura, la validación del negocio, la seguridad y la responsabilidad de la puesta en producción siguen requiriendo supervisión especializada.
Hay que verificar compatibilidad, dependencias y funcionamiento con pruebas pertinentes antes del despliegue, definir responsables y disponer de un plan de recuperación acorde con el riesgo.
En muchos casos es posible optimizar consultas, procesos y arquitectura existente. Pero no debe prometerse una mejora concreta sin investigar el entorno y validar los resultados.
Con indicadores acordados de tiempos, incidencias, continuidad y esfuerzo operativo, comparando escenarios equivalentes y considerando tanto el coste de la intervención como los beneficios demostrables.
Cuando no existe visibilidad sobre las extensiones, faltan pruebas, se acumulan incidencias sin diagnóstico o no hay una estrategia de mantenimiento, conviene evaluar la relación y la continuidad. El cambio debe gestionarse de forma ordenada y sin interrumpir la operación.
Fuentes y recursos para profundizar
La mejora de una solución empresarial exige documentación, revisión y mediciones adaptadas a cada entorno. Para profundizar en las iniciativas y herramientas mencionadas, pueden consultarse las siguientes referencias de Microsoft, Directions y la comunidad de especialistas.
Sigue conectado con la evolución de Business Central
El rendimiento de las extensiones debe revisarse junto con la estrategia general del ERP: modernización, pruebas, integración, capacidad de evolución y adopción responsable de IA. Estas páginas amplían los distintos aspectos sin repetir el mismo contenido.
¿Cuánto te cuestan hoy las extensiones que nadie se atreve a tocar?
Si Business Central se ha vuelto lento, cada actualización genera incertidumbre o los desarrollos dependen de demasiadas excepciones, merece la pena revisar el entorno con evidencia y criterios de negocio.
Hablemos de tu Business Central
Indica qué procesos se han ralentizado, qué extensiones utilizáis o qué cambios tenéis previstos.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)