7 decisiones tecnológicas que tu empresa debería revisar antes de 2027
No se trata de comprar más tecnología. Se trata de decidir qué arquitectura permitirá aprovecharla.
IA y agentes, ERP, datos, costes, regulación, aplicaciones y seguridad: siete decisiones que conviene tomar ahora para llegar a 2027 con más control, menos complejidad y capacidad real de ejecución.
2027 no espera al próximo presupuesto
2027 no empieza el 1 de enero. Para muchas empresas empieza cuando aprueban el presupuesto de tecnología, renuevan un contrato de software, deciden qué hacer con su ERP o autorizan el primer agente capaz de acceder a información financiera. Las decisiones que parecen independientes terminan construyendo —o limitando— la misma arquitectura de negocio.
Una compañía puede disponer de Microsoft 365, un ERP veterano, varias herramientas de análisis, un CRM que solo utiliza ventas y una docena de automatizaciones útiles. Sobre el papel está digitalizada. En la práctica, cerrar un mes exige hojas Excel, las oportunidades comerciales no hablan con finanzas y la IA necesita datos que nadie sabe poner a su alcance con garantías.
Ante ese escenario, preguntar qué tecnologías serán tendencia en 2027 es quedarse en la superficie. La pregunta útil para un CIO, un CFO o una dirección general es otra: ¿qué decisiones conviene tomar hoy para que las inversiones de mañana funcionen juntas? No se trata de activar todas las herramientas ni de sustituir todos los sistemas; se trata de eliminar dependencias, proteger información y financiar capacidades que respondan a problemas reconocibles.
El valor aparece cuando las capas trabajan juntas
Un mapa útil para priorizar no coloca siete productos en una fila. Distingue el sistema que registra la operación, la capa que interpreta la información, las aplicaciones que movilizan procesos y la IA que puede ayudar a decidir o actuar. Seguridad y gobierno deben existir en todos los niveles.
El diagrama no prescribe un orden obligatorio de implantación. Muestra dependencias: para ejecutar una acción de negocio con IA se necesitan sistemas de referencia, información comprensible, interfaces controladas y una responsabilidad clara sobre el resultado.
Pasar de probar IA a decidir dónde puede actuar
Copilot puede ayudar a preparar el trabajo. Un agente puede participar en la ejecución. Esa diferencia obliga a definir límites, responsabilidades y valor antes de escalar.
Durante la primera etapa de adopción, muchas organizaciones midieron la inteligencia artificial por usuarios activados, prompts realizados o sesiones de formación. Son métricas útiles para observar interés, pero no explican si el negocio trabaja mejor. La siguiente decisión es escoger procesos completos en los que la IA reduzca una fricción real: búsqueda de condiciones contractuales, preparación de propuestas, clasificación de incidencias, conciliación de documentos o detección de excepciones en compras.
La distinción entre Microsoft 365 Copilot y agentes de IA no es una carrera para ver cuál sustituye al otro. Copilot puede acelerar actividades personales y colaborativas: reuniones, documentos, correo, análisis y recuperación de conocimiento. Un agente diseñado con Copilot Studio o Microsoft Foundry puede consultar fuentes, seleccionar herramientas y participar en flujos de varios pasos. Cuanto más cerca esté de modificar datos, aprobar operaciones o desencadenar pagos, mayor deberá ser el control sobre identidad, permisos y validación.
Un ejemplo financiero lo explica bien. Consultar la política de gastos es una acción de bajo riesgo. Preparar un borrador de aprobación exige más contexto. Autorizar automáticamente una factura que supera un umbral o cambia los datos bancarios de un proveedor es otra categoría de riesgo. La arquitectura no debería conceder a las tres tareas el mismo nivel de autonomía. Las autorizaciones deben respetar las reglas del proceso y la segregación de funciones, aunque la interfaz sea conversacional.
Antes de producir un agente hay que fijar una línea base: tiempo medio del proceso, coste por caso, errores, excepciones, tasa de resolución y tiempo dedicado a revisar salidas de IA. Después, probarlo con casos habituales y casos adversos, registrar qué herramientas utiliza y definir a quién se deriva una excepción. La documentación de Microsoft Foundry contempla evaluación y observabilidad; la configuración concreta depende del escenario y de la disponibilidad de cada capacidad.
Si no se decide el nivel de autonomía, los equipos acumularán pilotos con expectativas ambiguas, gastos difíciles de atribuir y permisos que nadie revisa.
Determinar si el ERP está preparado para la IA
Un ERP que todavía cierra, compra y factura puede seguir siendo crítico. El problema es si permite conectar decisiones y procesos sin multiplicar integraciones frágiles.
La conversación sobre un ERP suele comenzar con la pregunta de si ha llegado el momento de cambiarlo. Pero la edad por sí sola no determina la decisión. Hay entornos de NAV, AX, Business Central on-premises y aplicaciones heredadas que cumplen funciones esenciales, mientras que otros ya dependen de extensiones que nadie se atreve a tocar. La evaluación debería empezar por la deuda que imponen al negocio: retrasos de cierre, datos duplicados, cambios costosos, vulnerabilidades, interfaces inestables y dificultad para introducir automatización.
La IA operacional necesita una fuente confiable de pedidos, facturas, clientes, disponibilidad, márgenes y estados de proceso. Si ventas utiliza un cliente distinto del que identifica finanzas; si el stock se actualiza mediante ficheros; o si una factura tiene varias versiones repartidas entre carpetas, un agente puede recuperar información incorrecta con aparente seguridad. El problema no se soluciona únicamente cambiando el modelo de IA. Hay que ordenar los procesos, las claves de negocio, las integraciones y los permisos.
Dynamics 365 Business Central puede encajar como núcleo financiero y operativo de empresas medianas que buscan procesos más conectados y una evolución sostenible. En organizaciones con grupos complejos, operaciones multinacionales y exigencias avanzadas de cadena de suministro, conviene evaluar Dynamics 365 Finance y Supply Chain Management. No existe un destino universal. Migrar de Dynamics AX puede requerir rediseñar procesos; evolucionar desde NAV puede aconsejar una transición por fases o una reimplantación selectiva.
Imaginemos una empresa de distribución donde un comercial promete una entrega sin conocer el coste actualizado ni la disponibilidad. Un CRM conectado a ERP puede consultar condiciones comerciales, stock y pedidos. Una capa analítica puede identificar patrones de retraso. Más adelante, un agente podría preparar alternativas sujetas a condiciones y autorización. Ese recorrido ofrece valor precisamente porque el ERP funciona como referencia transaccional y las otras capacidades se conectan de forma coherente.
Un core fragmentado termina trasladando inconsistencias a dashboards, automatizaciones y agentes, multiplicando su coste en cada capa.
Dejar de tratar los datos como un proyecto independiente
Unificar pantallas no equivale a unificar criterios. La IA necesita identificar la versión válida del dato y comprender el significado empresarial de cada cifra.
Microsoft Fabric y OneLake pueden ayudar a ordenar fuentes, ingeniería, analítica y modelos semánticos. Power BI acerca esa lectura al negocio. Pero ninguna herramienta resuelve automáticamente la propiedad de los datos ni la semántica financiera. Un dato puede estar perfectamente integrado y seguir siendo incorrecto. El trabajo empieza identificando sistemas maestros, responsables, indicadores comunes, frecuencia de actualización, calidad y políticas de acceso.
Cuando entra la IA, conviene distinguir tipos de consulta. Para conocer el estado actual de una orden de compra, el sistema transaccional puede ser la referencia apropiada. Para estudiar la evolución de márgenes por región durante dos años, el modelo analítico probablemente aporte más valor. Para recuperar una cláusula contractual de un repositorio documental, Azure AI Search y patrones como RAG pueden resultar útiles. Un agente empresarial no debería acceder indiscriminadamente a todo ni tratar un índice documental como sustituto del ERP.
Pensemos en un comité de operaciones que pregunta por qué una planta pierde rentabilidad. Puede necesitar ventas y costes del ERP, incidencias de mantenimiento, reclamaciones de CRM, consumos históricos y documentación de calidad. La respuesta exige relaciones entre fuentes y una definición compartida del margen. Si cada departamento mantiene su propia versión, la IA no convertirá la discrepancia en verdad: la presentará con más velocidad.
La decisión es construir un pequeño conjunto de productos de datos orientados a procesos: margen por pedido, rentabilidad por proyecto, previsión comercial, compras comprometidas o riesgo de cliente. Cada uno debe tener dueño, reglas y un uso concreto. Solo después tiene sentido ampliar la arquitectura de datos hacia otros dominios y habilitar nuevas experiencias de IA, manteniendo separación entre lectura analítica y ejecución transaccional.
Sin semántica y gobierno del dato, multiplicar fuentes o modelos solo acelera respuestas inconsistentes.
Revisar cuánto cuesta realmente el stack tecnológico
Esta es una de las decisiones con impacto más inmediato: saber qué se utiliza, qué se duplica y cuánto cuesta operar todo el conjunto, no solo renovar licencias.
El presupuesto tecnológico suele presentarse por proveedor, contrato o centro de coste. El negocio, sin embargo, paga por capacidades: proteger identidades, gestionar dispositivos, compartir documentos, automatizar aprobaciones, analizar datos, hospedar aplicaciones y atender incidencias. Cuando una empresa suma herramientas sin revisar las anteriores, puede terminar financiando varias respuestas para el mismo problema. El coste no es solo la factura de suscripción: también se multiplican integraciones, administración, soporte, formación, riesgo y renovaciones.
Microsoft 365 ilustra bien esta situación. Algunas organizaciones han contratado herramientas de colaboración, gestión de endpoints, seguridad, identidad o cumplimiento que se solapan parcial o totalmente con capacidades de las licencias Microsoft que ya poseen. Eso no implica que deban eliminar de inmediato esas soluciones. Las ediciones, los complementos, las funciones activadas y los requisitos de cada empresa cambian el resultado. Pero sí justifica una revisión rigurosa de derechos de uso, adopción, cobertura técnica y contratos.
En Azure ocurre algo parecido. Máquinas sobredimensionadas, entornos de prueba encendidos sin necesidad, almacenamiento sin ciclo de vida, recursos huérfanos o falta de etiquetado pueden elevar el gasto sin añadir capacidad empresarial. En Power Platform, los costes pueden depender de licencias, conectores premium, capacidad y modelo de despliegue. Y en IA se suman consumo de modelos, llamadas a herramientas, búsqueda, almacenamiento, observabilidad y trabajo humano de supervisión. No conviene sumar importes indiscriminadamente, pero sí asignarlos al servicio o proceso que los origina.
Para un CFO, la cuestión importante es cuánto cuesta realmente proporcionar una capacidad y qué alternativa conserva el nivel de servicio. Para un CIO, también importa el riesgo de consolidar: cambiar una herramienta de seguridad sin comparar cobertura efectiva, migración, registros, respuesta a incidentes y necesidades regulatorias puede salir más caro que mantenerla. Ahorrar licencias y deteriorar protección no es optimizar. Tampoco lo es reducir costes cloud a costa de resiliencia.
Un ejercicio útil consiste en construir un inventario por función, no solo por fabricante. Para cada capacidad hay que anotar propietario, usuarios asignados, usuarios activos, uso real, integración, contratos, coste de salida, riesgos, fechas de renovación y dependencia operativa. Después, identificar tres categorías: herramientas imprescindibles, capacidades infrautilizadas y solapamientos que merecen una prueba de consolidación. Las recomendaciones deben incluir un caso económico y un plan de transición, no solo un descuento potencial.
Es precisamente el enfoque del webinar de Ayesa del 12 de noviembre de 2026 sobre optimización de licencias y seguridad Microsoft 365: revisar redundancias y costes desde el conjunto del puesto de trabajo, sin comprometer cobertura. Esta conversación puede liberar presupuesto para financiar datos, modernización o IA con mayor retorno. Antes de comprar otra plataforma para 2027, merece la pena comprobar si ya estamos pagando por una parte de sus capacidades.
Sin inventario de capacidades, la organización puede invertir en innovación mientras mantiene duplicidades que consumen presupuesto.
Prepararse para los cambios regulatorios antes de que sean urgentes
El cumplimiento no debería llegar en forma de proyecto a contrarreloj: exige revisar procesos, aplicaciones, datos, responsables y evidencias.
Una obligación normativa rara vez afecta a una sola pantalla. Suele atravesar procesos, integraciones, datos, roles, registros, proveedores y contratos. Si se espera hasta el último trimestre, IT puede terminar desarrollando una solución rápida sin tiempo para revisar calidad, seguridad ni continuidad. Por eso dirección debe tratar el calendario regulatorio como una entrada del plan de arquitectura, no como un asunto aislado del departamento jurídico.
En España, la facturación electrónica obligatoria entre empresarios y profesionales es un ejemplo inmediato. La Orden HAC/1028/2026, publicada el 5 de octubre de 2026, completa el desarrollo de la solución pública y activa el cómputo de los plazos. Según la Agencia Tributaria, el 6 de octubre de 2027 comienza la obligación para quienes superen ocho millones de euros de volumen de operaciones; el 6 de octubre de 2028, para el resto en emisión, remisión y recepción, con matices adicionales relativos a la comunicación de estados y pagos. Determinadas personas físicas y entidades en atribución de rentas tienen un hito posterior en 2029 para esos estados.
La decisión tecnológica no consiste solo en generar un fichero. Habrá que examinar cómo se emiten y reciben facturas, qué sistema mantiene su estado, cómo se gestionan errores, qué plataforma intermedia, qué trazabilidad se conserva y cómo afecta al ERP actual. Para compañías con NAV o Business Central on-premises conviene evaluar pronto el esfuerzo de adaptación frente a una posible modernización. No debe suponerse que un formato de facturación ya soportado equivale automáticamente a cobertura completa de todos los nuevos requisitos.
También hay que revisar la normativa que afecta al uso de IA, privacidad, resiliencia y ciberseguridad según sector, tamaño, rol y ámbito de operación. No todas las empresas están sujetas a las mismas obligaciones ni todos los sistemas de IA tienen el mismo nivel de riesgo. El trabajo consiste en hacer una matriz de aplicabilidad con apoyo de las áreas jurídicas y de seguridad: qué norma afecta, a qué actividad, qué evidencia exige, quién responde y cuándo debe demostrarse el cumplimiento.
El coste de actuar tarde suele aparecer en integraciones precipitadas, interrupciones, urgencias de proveedor y validaciones insuficientes.
Decidir qué aplicaciones merece la pena modernizar
La modernización no consiste en sustituir todo el software antiguo. Consiste en elegir dónde cambiar la arquitectura desbloquea integración, agilidad y nuevas capacidades.
El primer paso es construir un mapa de aplicaciones y procesos. ¿Qué sistemas sostienen ingresos o cumplimiento? ¿Cuáles concentran incidencias? ¿Cuáles obligan a exportar y volver a introducir información? ¿Cuáles tienen APIs estables? ¿Qué contratos o tecnologías estarán sin soporte? Un inventario sin relación con procesos ayuda poco. Un mapa que conecta cada aplicación con usuarios, riesgos, dependencias e impacto permite priorizar de forma razonada.
No todo requiere una migración completa a Azure. A veces merece la pena encapsular una función, exponer servicios mediante APIs, mejorar identidad, automatizar una aprobación con Power Platform o retirar un aplicativo que ya no aporta valor. En otros casos será necesario refactorizar, sustituir componentes o rediseñar la solución. Azure ofrece servicios de computación, integración, datos, seguridad y observabilidad, pero el diseño correcto depende del estado y del objetivo de cada carga.
Un fabricante puede tener un sistema propio que calcula especificaciones de producto con gran precisión. Sustituirlo puede no mejorar el resultado. El problema aparece si solo se puede consultar desde un equipo concreto o si no comparte información con presupuesto, pedido y servicio. Integrarlo de forma gobernada puede liberar valor antes de plantear su reemplazo. En contraste, una aplicación que almacena información crítica sin soporte ni controles suficientes exige una evaluación prioritaria aunque nadie se queje de su interfaz.
La IA añade un criterio nuevo: ¿puede la aplicación proporcionar información y acciones mediante interfaces seguras, respetar identidad y permisos, registrar operaciones y operar con continuidad? Si no puede, la solución no siempre es rehacerla entera. Puede requerir una capa de integración o una modernización selectiva. Lo esencial es evitar que cada nuevo caso de uso de IA obligue a construir una conexión propietaria distinta y difícil de mantener.
Aplazar indefinidamente la deuda técnica convierte cada mejora futura en un proyecto caro y lento.
Pasar de proyectos aislados a un sistema empresarial conectado
La ventaja no está en disponer de más herramientas. Está en que cada una cumpla su función y todas trabajen con datos, procesos y responsabilidades coherentes.
La secuencia no es necesariamente una implantación lineal. El ERP sostiene transacciones y control económico; el CRM gestiona relación, oportunidades y servicio; las plataformas de datos aportan visión histórica y semántica; Azure y las integraciones habilitan aplicaciones y servicios; Power Platform extiende procesos y automatización; Copilot y los agentes acercan información o acciones al usuario. Seguridad, identidad, gobierno, observabilidad y adopción atraviesan todas esas capas. No existe un único producto que deba hacerlo todo.
Pensemos en una promotora con información comercial de reservas, previsiones de obra, facturas de subcontratas, disponibilidad de unidades y tesorería repartidas entre herramientas. Unificar toda esa gestión en una sola pantalla no garantiza coherencia. En cambio, una arquitectura sectorial puede permitir que CRM, ERP y analítica compartan estados relevantes y que dirección disponga de una lectura más completa del margen y de la caja. La IA, cuando se incorpore, podrá consultar y actuar sobre ese contexto siguiendo permisos definidos.
La misma lógica funciona en industria, logística, banca, servicios o administración: cada dominio necesita procesos propios, pero la decisión de arquitectura debe evitar duplicar datos y responsabilidades. Una iniciativa de agentes se vuelve más asequible cuando existe un patrón reutilizable de identidad, acceso a sistemas, recuperación de conocimiento, registro de acciones y evaluación. Un programa de modernización produce más valor cuando prepara esas condiciones para varios casos futuros.
Ayesa puede aportar una visión transversal de Business Central, Dynamics 365 Finance & Operations, Dynamics 365 Sales, Power Platform, Microsoft Fabric, Azure, Microsoft 365, Copilot y soluciones sectoriales. El resultado que importa no es cuántas tecnologías aparecen en el proyecto, sino cuántas decisiones y procesos dejan de estar desconectados. Una buena arquitectura puede desplegarse por fases: resolver primero el cuello de botella más costoso, dejar preparadas las integraciones necesarias y ampliar solo cuando haya evidencia de valor.
Si se siguen aprobando iniciativas por producto y por departamento, la organización crecerá en número de herramientas, no necesariamente en capacidad de ejecución.
No todas las iniciativas deberían entrar en el presupuesto con la misma urgencia
La siguiente matriz es un criterio de decisión, no una clasificación universal de tecnologías. Sitúa cada iniciativa según el impacto de mantener el problema y la viabilidad de resolverlo. El equipo directivo debe completar la valoración con sus propios datos.
Un inventario de treinta iniciativas puede terminar convertido en una cartera de cinco decisiones con verdadero patrocinio: por ejemplo, corregir permisos antes de ampliar Copilot; reducir solapamientos en seguridad; definir el sistema maestro de clientes; modernizar la integración con ERP; y validar un caso de agente sobre compras. El beneficio de priorizar no es hacer menos por principio, sino liberar capacidad para ejecutar bien lo que importa.
De aquí a 2027: una secuencia de decisiones, no siete proyectos simultáneos
El calendario debería traducirse en compromisos verificables. No hace falta esperar a disponer de una arquitectura perfecta; sí conviene evitar que cada equipo avance por su cuenta. Una ruta razonable combina diagnóstico, corrección de fricciones y despliegue medido.
El resultado de esta primera etapa debería poder presentarse a dirección en una sola página: iniciativas aprobadas, problemas que resuelven, costes estimados, beneficios esperados, riesgos, responsables y calendario de revisión. Un proyecto que no puede explicarse así probablemente necesita más definición. También conviene reservar capacidad para formación y adopción: una arquitectura conectada no aporta valor si los usuarios siguen reconstruyendo los procesos por fuera.
Dos conversaciones útiles para tomar decisiones
Antes de aprobar el presupuesto tecnológico de 2027
La ventaja no está en tener más herramientas.
Está en conseguir que datos, procesos, aplicaciones e IA trabajen como un sistema.
Llegar preparado a 2027 no exige apostar por todas las novedades. Exige reconocer qué está frenando el negocio y tomar decisiones que se refuercen entre sí. Una licencia bien aprovechada puede financiar una mejora del dato. Un ERP conectado puede eliminar trabajo manual. Una aplicación modernizada puede habilitar automatizaciones. Un agente puede aportar valor cuando conoce el proceso, dispone del contexto correcto y actúa dentro de límites claros.
Ayesa ayuda a revisar ese conjunto desde negocio, arquitectura y capacidad de ejecución: ERP, CRM, Azure, datos, automatización, Microsoft 365, Copilot, agentes, seguridad y soluciones sectoriales. El primer paso no tiene por qué ser una gran implantación. Puede ser una evaluación ejecutiva que identifique qué conservar, qué conectar, qué cambiar y qué dejar para después.
Evaluar las prioridades tecnológicas de tu empresa para 2027 →
Documentación para contrastar las decisiones
Las capacidades y los calendarios deben comprobarse siempre frente a la documentación aplicable y a la configuración de cada empresa. Estas fuentes oficiales ayudan a profundizar en los fundamentos.
Evalúa las prioridades tecnológicas de tu empresa para 2027
Cuéntanos qué sistemas utilizas, qué decisiones tienes pendientes y qué te preocupa: ERP, datos, IA, automatización, aplicaciones, costes o riesgos. Podremos ayudarte a delimitar una evaluación inicial y ordenar los próximos pasos.
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)