Participo en el Bizz Summit 2026: 25 años de proyectos ERP

Cinco proyectos reales, un marco para clasificar clientes y una ficha de veinte minutos que cabe en una página. Esto es lo que Lorena Sanchis y yo contamos en el BIZZ SUMMIT, y lo que nos gustaría que os llevarais a vuestra próxima preventa.

Hay charlas que se preparan con diapositivas y charlas que se preparan con experiencias. La que di en el BIZZ SUMMIT 2026 con Lorena Sanchis era de las segundas.

Os cuento cómo fue, y sobre todo qué contamos.

Una folclórica que cuenta su vida

Abrimos sin demo, sin agenda y sin una sola captura de producto. La sesión empezó con Rocío Jurado porque hay una edad a partir de la cual a una folclórica se le permite dejar de cantar y ponerse a contar su vida. Y Lorena y yo estamos en esa edad. Y por eso, en lugar de hablar de una metodología, veníamos a contar 25 años de proyectos, de Navision a Business Central, con lo que salió bien y con lo que no.

A partir de ahí la sesión fue exactamente lo que prometía: la memoria de dos profesionales contados en primera persona, con el marco teórico como lo que aprendió por el camino. Cinco episodios reales, uno por bloque, y una ficha final para llevarse a casa.

La tesis: el producto cambia, los motivos de fracaso no

Proyectamos el roadmap del producto. Empieza en 1984 con PC Plus, una contabilidad para MS-DOS; pasa por Navigator en 1987, por Navision en 1989 y 1990, por Navision Financials en 1995 y Navision Attain en 2001; llega a Microsoft en 2002 con la adquisición; se convierte en Dynamics NAV en 2005 y 2006; da el salto a la nube como Dynamics 365 for Financials en 2016 y 2017; y en 2018 se llama Business Central, que es como lo conocemos hoy.

Cinco nombres, dos lenguajes (C/AL y AL), dos modelos de despliegue (servidor propio y SaaS) y, ahora, Copilot. Y sin embargo, dijo Lorena, los motivos por los que fallan los proyectos no han cambiado ni una vez, y ninguno es el producto.

Fallan por el encaje entre tres elementos: el tipo de cliente, el tipo de proyecto y la estrategia de ejecución, sostenidos por el equipo que implanta. El éxito está en el centro del triángulo. Cada vez que uno de los tres se decide sin mirar a los otros dos, el proyecto se desplaza hacia una esquina. La misma estrategia funciona con un cliente y fracasa con otro; el mismo cliente sale bien con un tipo de proyecto y mal con otro. Y nada de eso lo arregla la metodología que está escrita en la propuesta.

Los cinco proyectos que todos hemos visto

Primer bloque. Dibujamos cinco proyectos que cualquiera del sector reconoce:

1. El proyecto réplica. El objetivo real, aunque nadie lo diga, es que Business Central se comporte como el sistema anterior.
2. El proyecto sin dueño. Un sponsor que aparece en el kickoff y en la crisis, y usuarios clave «a tiempo parcial», que en la práctica es tiempo cero.
3. El proyecto vendido como rápido a un cliente que no podía ir rápido: sin procesos definidos, sin capacidad de decisión y sin datos.
4. La plantilla sin gobierno. Un roll-out internacional en el que cada filial renegocia el core y la plantilla se disuelve en la tercera implantación.
5. Los datos al final. La migración se planifica para «las últimas semanas» y acaba siendo el motivo del retraso.

Aquí surgió la primera pregunta: «¿y eso no se ve venir?»

Su respuesta fue el primer episodio. Una empresa de distribución que estuvo tres años haciendo análisis y desarrollos que nunca terminaban, porque lo que querían era que replicáramos lo que tenían en su AS400. «Era imposible», dijo. Tres años de proyecto réplica en estado puro. Y la conclusión de ese bloque, que resume cualquier diapositiva: nada de esto depende de la versión, ni de AL frente a C/AL, ni de SaaS frente a on-premise, ni de la metodología. Todo depende de haber aplicado un enfoque que no encajaba con ese cliente y ese proyecto.

Clasificar al cliente: seis factores y cuatro arquetipos

Aquí empezó la parte más práctica. Proponemos puntuar de 1 a 5 seis factores, divididos en dos grupos.

• Qué es el cliente: madurez organizativa, estandarización de procesos y complejidad del negocio.
• Cómo se va a comportar: dependencias con sistemas heredados, expectativas de personalización y disposición al cambio.

La observación clave es que los proyectos fallan mucho más por los tres últimos, y que son justo los que menos se cualifican en preventa. En una primera reunión se pregunta por presupuesto, plazo y módulos. Casi nunca se pregunta cuántas horas semanales tiene liberadas el responsable de finanzas, y esa respuesta predice más retrasos que cualquier otra. Si solo pudiéramos medir un factor, mediríamos ese: la disposición al cambio, y en concreto las horas liberadas con nombre y apellido.

Cada factor tiene una pregunta de discovery que lo desvela. Son, probablemente, lo más útil que se llevaron los asistentes:

Factor	La pregunta	Señal de puntuación baja
Madurez organizativa	«¿Quién decide si cambia el flujo de aprobación de compras?»	La respuesta es «depende» o hay que preguntar a tres personas
Estandarización de procesos	«Enséñame cómo hacéis hoy un pedido de venta» (verlo, no que lo cuenten)	Cada persona lo hace distinto y el proceso vive en un Excel
Complejidad del negocio	«¿De cuántas formas distintas facturáis?»	Más de tres respuestas y ninguna documentada
Dependencias heredadas	«¿Qué pasaría mañana si apagamos el sistema actual?»	Nadie lo sabe con seguridad
Expectativas de personalización	«¿Qué es lo que no estáis dispuestos a cambiar?»	La lista es larga y empieza por pantallas e informes
Disposición al cambio	«¿Cuántas horas semanales tiene liberadas el responsable de finanzas para este proyecto?»	Silencio, o «las que hagan falta»

De la combinación de factores salen cuatro arquetipos de cliente, a los que Lorena puso nombre para que cualquiera pudiera usarlos al día siguiente:

• El que crece. Sale de Excel o de un programa de contabilidad. Procesos poco formalizados y por tanto maleables, pocas dependencias y muchas ganas. Su riesgo: crecer más rápido que el proyecto y no tener dueños de proceso.
• El veterano de NAV. Quince o veinte años con Navision, dos décadas de customizaciones y dependencias altas. Su riesgo: replicar NAV con otro logo.
• El grupo. Multiempresa o multipaís, con madurez alta en central y desigual en filiales. Su riesgo: perder el gobierno del core.
• El herido. Viene de un proyecto fallido a medias, con la confianza rota, urgencia y una frase peligrosa: «ya sabemos lo que queremos». Su riesgo: repetir el mismo error con otro partner.

Y una variante: el que cambia de ERP, que viene de SAP Business One, Sage, a3ERP o un vertical y lo compara todo con lo que tenía, sin conocer la lógica de NAV.

Episodio 2: el cliente que parecía un arquetipo y era otro

Para ilustrarlo, contamos un proyecto de 2008 en el sector de la restauración y la gestión hotelera. Un grupo con 80 empresas, muy tecnológico y muy organizado, que necesitaba implantar NAV, que era lo que había en aquel momento, en ocho de ellas, las de gestión de reservas.

En preventa, todo apuntaba a «el que crece». Parecía un cliente maduro, conocedor de la tecnología y de la funcionalidad. Tenía un equipo de IT que daba soporte y que estaba al frente del proyecto de implantación, y había otras empresas del grupo funcionando ya con el sistema. Parecía un proyecto «fácil, rápido y para todas las familias». Fueron con su equipo preparado para hacer un proyecto superestratégico y centralizado.

Entonces llegó el discovery. Los usuarios de las otras empresas habían «rechazado» Navision. El equipo de IT quedaba fuera del plan de implantación, porque pertenecía al bloque de servicios centrales y ese bloque de empresas no tenía previsto implantar todavía. Y la dirección no quería «aparatitos» para obtener datos.

¿Qué habrían cambiado en la propuesta? Una propuesta menos ambiciosa, centrada en una transición controlada del grupo de empresas y faseada, para que la dirección del cliente pudiera tener el control. En otras palabras, haberlo abordado como lo que era: un cliente veterano.

La frase de todas las preventas

El tercer bloque lo arrancamos con una frase que seguro habéis oído en más de una primera reunión, dicha con la entonación exacta del cliente:

«Nosotros somos muy sencillos. Lo nuestro es todo estándar.»

Y a continuación, casi siempre, la segunda parte: «Lo que no entiendo es por qué el presupuesto es tan alto.»

La tesis es que el cliente no miente. Su negocio es sencillo para él porque lo hace cada día y nunca lo ha visto desde fuera. Lo que llama «estándar» es su costumbre, no el estándar de Business Central. Cuando le pides que enseñe cómo factura, aparecen tres formas de facturar y un Excel.

Además, el presupuesto que él ve y el que hacemos nosotros no miden lo mismo. Él suma módulos. Nosotros sumamos datos, integraciones, informes, días de su equipo y tipo de proyecto. Por eso dos propuestas «de finanzas, compras y ventas» pueden diferir en el doble y ser las dos correctas.

La respuesta no es defender el precio. Es cambiar la conversación: enseñarle el estándar funcionando con sus datos antes de discutir cifras, desglosar el presupuesto por lo que no son módulos, y preguntarle de cuántas formas factura. Esa misma frase, dicho sea de paso, está en la tabla de señales de alarma que veremos más abajo.

De ahí pasamos a los cinco tipos de proyecto, cada uno con su alcance, su gobierno y su riesgo dominante:

• Implantación desde cero. Sin ERP previo o con una herramienta básica. El riesgo: el cliente no sabe lo que no sabe y el alcance crece con el descubrimiento.
• Migración desde NAV, en dos subtipos: upgrade técnico (conservar) o reimplantación (rediseñar). El riesgo: replicar customizaciones, arrastrar datos históricos y que el fin de soporte marque el plazo.
• Sustitución de otro ERP. Un cambio de plataforma sin conocer la lógica de NAV. El riesgo: la comparación permanente con el sistema anterior.
• Despliegue internacional o multientidad. Varias empresas o países sobre un mismo modelo. El riesgo: perder el control del core y los requisitos legales locales.
• Rescate o reconducción. Un proyecto parado, retrasado o con la confianza rota. El riesgo: la presión de plazo, el coste hundido y las decisiones tomadas por agotamiento.

Las segundas fases merecen mención aparte: heredan el arquetipo del cliente, pero el gobierno se relaja porque «ya nos conocemos», y ahí es donde aparecen los sobrecostes.

La diapositiva que mejor lo resumió se llamaba «Mismos módulos, distinto proyecto». Finanzas, compras y ventas en una implantación desde cero para «el que crece» frente a la misma lista en una migración desde NAV para «el veterano». En el primer caso hay pocos datos, desde Excel, y una o ninguna integración; las decisiones son rápidas, con un dueño claro. En el segundo hay años de histórico y maestros sin limpiar, varias integraciones sin documentar, decisiones del tipo «como en NAV» que se reabren cada semana, y muchos días de cliente para revisar cada customización. Comparar propuestas por días de consultor no tiene sentido si antes no se compara el tipo de proyecto.

Elegir la estrategia: ninguna es la buena

Cuarto bloque con cinco estrategias de ejecución:

1. Implantación rápida orientada al estándar. Adoptar, no adaptar: alcance cerrado, apps de AppSource antes que desarrollo y arranque en pocos meses. Funciona con «el que crece» con disposición al cambio alta, y con las filiales de un grupo después del piloto. Falla con veteranos de NAV con expectativas de personalización altas, o cuando se vende como rápida a quien no puede decidir en días. Se gobierna con una lista corta de decisiones con fecha y una regla explícita: el estándar gana salvo justificación de negocio cuantificada.
2. Transformación por fases. Por dominio (finanzas, operaciones, producción) o por unidad de negocio, con un go-live real en cada fase. Funciona con complejidad alta, madurez media y dependencias altas.
3. Despliegue basado en plantillas, core más local. Una empresa modelo con configuración maestra y extensiones core, y las localizaciones como capas. Funciona en grupos con gobierno central fuerte, y siempre después de un piloto.
4. Proyecto centrado en la migración. Datos y código primero, con un inventario de customizaciones en tres cubos: eliminar, sustituir por estándar o por app, o reescribir en AL. Funciona con clientes que valoran la continuidad y cuyo NAV está razonablemente sano. Falla cuando se usa para evitar la conversación de rediseño. Aquí Lorena dejó una frase que volvería a aparecer más tarde: «solo es un upgrade» es la frase más cara de la profesión. Y una pista para saber cuándo no lo es: si nadie sabe para qué sirve la mitad de las customizaciones, la decisión entre upgrade técnico y reimplantación ya está tomada.
5. Recuperación. Parar, diagnosticar con independencia, estabilizar, redefinir y arrancar algo en corto. Funciona cuando hay honestidad sobre el estado real y el sponsor asume que habrá decisiones incómodas.

También hay combinaciones habituales: rápida más fases, plantillas más fases (piloto y roll-out) y migración más fases.

Para conectar cada estrategia con cada cliente hicimos un ejercicio a dos voces. Yo nombraba un arquetipo y Lorena dictaba qué estrategia le tocaba y por qué:

• El que crece: rápida y estándar, y de plantillas ni hablar.
• El veterano de NAV: por fases, o migración si su NAV está sano; rápida y estándar solo si acepta un rediseño.
• El grupo: plantillas, pero después del piloto, con el core por fases y las filiales en estándar.
• El herido: recuperación, antes que cualquier otra cosa.
• El que cambia de ERP: estándar o fases, pero nunca migración.

La idea que lo sostiene todo es esta: cada estrategia asume un comportamiento del cliente. Velocidad de decisión, aceptación del estándar, capacidad de gobierno y horas disponibles. Si ese comportamiento no está, la estrategia no funciona aunque el partner, el equipo y la metodología sean los mismos. No es que la estrategia sea mala; es que se ha aplicado a alguien que no puede ejecutarla.

Episodio 3: la migración que funcionó con cinco empresas y falló con tres

Illustrado con un caso de 2018: un fabricante de cocinas con un grupo de ocho empresas. Cinco ya habían migrado a Dynamics NAV y tres seguían en la versión anterior de Navision. Plantearon la migración de las tres que faltaban, que, a diferencia de las otras cinco, eran fabricantes.

Con las primeras cinco la migración había sido técnica y prácticamente limpia. Los usuarios recibieron una formación básica de uso, pero el conocimiento de la estructura de datos y de los procesos lo tenían interiorizado. Todo salió bien.

Cuando el mismo equipo fue a preparar las otras tres, empezaron los problemas: integraciones que no podían migrarse, funcionalidades ad hoc de fabricación que eran incompatibles con las de las empresas que ya estaban en Dynamics NAV, y usuarios reacios al cambio.

¿Qué factor del radar era distinto? El momento. Entre una migración y otra había pasado más de un año y las empresas habían evolucionado de forma diferente: las ya migradas se habían adaptado y habían hecho avances funcionales, mientras que las que se quedaron en Navision conservaban procesos sin modernizar, de modo que integrarlas en la nueva operativa requería reingeniería, no migración pura. Ni el cliente ni el equipo de Lorena lo calibraron. La misma estrategia, el mismo equipo, el mismo cliente, y un resultado distinto porque la situación había cambiado y nadie volvió a clasificar.

El equipo que implanta: la parte que más suele faltar

Quinto bloque. El planteamiento: el equipo es parte del encaje, no un recurso. Cada estrategia exige un perfil distinto, y se asigna por encaje con la estrategia, no por disponibilidad, porque «está libre» no es un criterio.

Algunos ejemplos que dimos:

• En una implantación rápida hace falta quien conozca el estándar a fondo y sepa decir «no» con argumentos. El perfil que la hunde es el consultor que dice sí a todo, o el desarrollador que programa lo que se podía configurar.
• En una migración desde NAV hay que saber leer C/AL y entender por qué se hizo cada customización. Lo que la hunde es un consultor que solo conoce Business Central SaaS y no sabe de dónde viene el cliente.
• En un despliegue internacional hace falta un arquitecto de core con autoridad, un jefe de programa y alguien que hable el idioma de cada filial, literal y figurado. Lo que lo hunde es un equipo central que no ha pisado una filial.
• En un rescate hace falta un senior con credibilidad para decir verdades incómodas, y menos gente con más peso. Lo que lo hunde es un equipo grande de perfiles junior «para recuperar el retraso».

Hablamos también de tres errores de asignación que se repiten. El primero, el consultor de la demo no es el del proyecto: si va a pasar, se dice en preventa. El segundo, el equipo espejo: la química con el cliente se ve en las tres primeras semanas y no mejora sola. El tercero, confundir antigüedad con encaje: un rescate necesita credibilidad y una implantación rápida necesita velocidad de decisión, y no siempre van juntas.

Y las señales de que un equipo no funciona, antes de que lo diga el cliente: las mismas decisiones se reabren cada semana; el cliente deja de escribir al consultor y escribe al comercial, o pide «alguien más senior»; el desarrollador está desarrollando lo que el consultor debería haber configurado; el jefe de proyecto reporta verde tres semanas seguidas mientras las pruebas del cliente no han empezado; las actas no existen o nadie las lee; alguien del equipo ya está mentalmente en el siguiente proyecto; y, en el lado del cliente, el usuario clave no aparece o delega en alguien sin criterio ni autoridad.

Entonces tocó la pregunta incómoda: «¿Y cuántas veces lo habéis cambiado tarde?» La respuesta es el cuarto episodio, contado desde el lado inesperado: el de la persona a la que cambiaron.

Episodio 4: la vez que cambiaron a Lorena

Fue en 2020, con una empresa de referencia en el sector tecnológico, con muchos proyectos vivos y una complejidad de procesos muy alta. Tenían Navision 2.60 y querían una reimplantación a Dynamics NAV 18.

Lorena lideró el proyecto, según sus palabras, «desde el absoluto convencimiento de mi buen hacer». Diseñó una solución impecable para cada proceso, analizó con el cliente cada área y documentó una y otra vez. Y, dijo, falló. Estuvieron mucho tiempo analizando, documentando y recogiendo información. Análisis infinitos, revisiones de las revisiones, cambios de alcance, «pequeños matices» que te hunden un FDD, reuniones con 15 usuarios poco dispuestos al cambio.

Tuvo que cambiar de proyecto y salió de él. Había muy buena afinidad con los usuarios y pensó que el proyecto iba a sufrir. Pero llegó otro consultor que recondujo el proyecto: acotó los alcances, fijó fechas de validación de documentos y procesos y, al cabo del año, arrancaron con éxito. Lorena dijo que tiene su más profunda admiración, y que siguen siendo amigos.

Si hay una escena de la charla que explique por qué el equipo es parte del encaje, es esta. Y de ahí salieron las ocho reglas para cambiar un equipo a tiempo:

1. La revisión de equipo se fija en el kickoff, a las cuatro o seis semanas, como un hito más. Cambiar entonces no es un fracaso, es el plan.
2. Se decide con datos: decisiones reabiertas, retrasos atribuibles y feedback del cliente recogido de forma explícita.
3. Cambiar roles antes que personas: el consultor equivocado para liderar finanzas puede ser el adecuado para datos.
4. Nunca todo el equipo a la vez: una persona, con solapamiento y traspaso documentado.
5. Al cliente se le dice antes de que lo pida, con el motivo real y con lo que cambia para él desde el lunes.
6. Banquillo en los roles críticos: jefe de proyecto y consultor líder, aunque cueste tenerlo.
7. En el contrato, perfiles y no nombres, o una cláusula de sustitución por perfil equivalente.
8. El equipo del cliente también se cambia. Un usuario clave sin tiempo o sin autoridad no se gestiona: se sustituye.

Cerramos el bloque con una frase: al cliente no lo puedes cambiar; a quien lo atiende, sí.

Señales de alarma, y «escuchamos, pero no juzgamos»

Antes de entrar en las confesiones repasamos las señales tempranas que deberían hacer cambiar el modelo de entrega. Algunas:

• «Nuestro proceso es único» más de tres veces en el discovery. Baja estandarización y alta personalización. Invertir el fit-gap: mostrar el estándar antes de recoger requisitos.
• Usuarios clave sin horas liberadas. Descartar la implantación rápida; reducir la fase 1 o retrasar el arranque.
• Una lista de requisitos antes de haber visto el producto. Proyecto réplica en gestación: sesiones fit-to-standard antes de estimar nada.
• Nadie conoce la calidad de los datos. Workstream de datos desde la semana 1 y, en NAV, migración de prueba antes del diseño.
• Un plazo marcado por fin de soporte, licencias o requisito fiscal. Fases: el mínimo legal y operativo primero.
• El sponsor delega en IT. Proyecto tecnológico, no de negocio: renegociar el gobierno antes de firmar.
• Proyecto fallido y «ya sabemos lo que queremos». Diagnóstico independiente antes de aceptar el alcance.
• «Somos muy sencillos, todo estándar, ¿por qué es tan caro?» Nadie ha visto todavía sus procesos. No discutir el precio: estándar con sus datos, desglose y clasificación antes de recotizar.

Y después, el formato más distinto de la sesión. Tomamos prestada la frase del momento, «escuchamos, pero no juzgamos», para confesar en voz alta los errores de preventa, estimación, alcance y arranque que todos hemos cometido. Uno dice una confesión en primera persona, la remata con la frase, y la respuesta es siempre la misma. Yo confesé los de preventa:

• «He vendido un proyecto como rápido y estándar sin haber visto un solo proceso del cliente.»
• «He creído al cliente cuando me dijo que todo era sencillo y estándar.»
• «He hecho una demo de dos horas y lo he llamado discovery.»
• «He prometido estándar y he presupuestado desarrollos. Y también al revés.»
• «He bajado el precio para igualar una propuesta que no era del mismo tipo de proyecto.»
• «He cualificado presupuesto y plazo, y nunca he preguntado cuántas horas tenía liberadas el responsable de finanzas.»

Lorena confesó los de estimación, alcance y arranque:

• «He estimado por módulos, como si compras costara lo mismo en una empresa que sale de Excel que en un veterano de NAV.»
• «He estimado días de consultor y ni un solo día de cliente.»
• «He escondido la contingencia dentro de las tareas.»
• «He dicho: solo es un upgrade.»
• «He aceptado como alcance todo lo que hace el sistema actual.»
• «No he escrito nunca lo que no estaba incluido.»
• «He dicho: ya que estamos.»
• «He hecho un kickoff de una hora con cafés y ninguna decisión.»
• «He arrancado el proyecto que se vendió, no el que encontré en el discovery.»

Para cerrar, le pasamos la pregunta a la sala: que levantara la mano quien alguna vez hubiera vendido un proyecto como rápido y estándar sin ver un solo proceso, quien hubiera dicho «solo es un upgrade» o quien hubiera dicho «ya que estamos». La reflexión con la que lo resumió Lorena: todos hemos hecho todo esto. La diferencia entre un proyecto que sale y uno que no es cuántas de estas cosas se hacen a la vez.

Y para que no quedara en un juego, cada confesión tiene su «qué habría que haber hecho»:

• Preventa: clasificar antes de vender la estrategia; tratar el «sencillo y estándar» como una hipótesis y no como un dato; discovery, no demo; comparar el tipo de proyecto antes que los días; cualificar las horas liberadas y no solo el presupuesto.
• Estimación: por perfil de cliente y tipo de proyecto, no por catálogo; datos, integraciones e informes al principio; días de cliente, no solo de consultor; contingencia visible y negociada. Y recordar que «solo es un upgrade» no existe.
• Alcance: procesos con resultado esperado en lugar de listas de funciones; escribir lo que no está incluido; criterios de aceptación antes de arrancar; y que el «ya que estamos» tenga coste, fecha y dueño.
• Arranque: el kickoff como acuerdo de gobierno; re-validar la clasificación tras el discovery; equipo del cliente con nombres, horas y sustitutos; y reglas de decisión firmadas, que digan quién decide, en cuánto tiempo y qué pasa si no se decide.

Episodio 5: «Sí podemos implantar LS Retail»

El quinto y último episodio llegó justo después de las confesiones: el error de preventa que se paga en el arranque.

Fue en 2015, con un cliente del sector de la distribución y venta de vinos que ya tenía NAV implantado y que nos pidió implantar LS Retail para su tienda de vinos. Un proyecto pequeño: una inversión de unos 20 k por parte del cliente y cuatro o cinco usuarios. La frase que se dijo en preventa fue esta:

«Sí podemos implantar LS Retail porque tenemos experiencia en la aplicación.»

El plan era implantar en tres meses, dando solución en NAV para poder hacerlo. La realidad: más de siete meses para poner en marcha el TPV. Muchísimas más horas de las previstas, con lo que acabaron con margen negativo, y además tuvieron que pagar soporte al fabricante para que les ayudara con algunas incidencias.

Un proyecto pequeño, una frase en preventa y más de siete meses para pagarla. Es la mejor ilustración de por qué el momento de la preventa es donde se condiciona todo lo demás.

La ficha de encaje: veinte minutos antes de abrir la plantilla de propuesta

Todo lo anterior se resume en una ficha de una página. Se rellena en discovery, se revisa en preventa, se firma en el alcance y se vuelve a mirar en el kickoff:

1. Puntuar los seis factores de 1 a 5.
2. Identificar el arquetipo, y en qué se aleja del arquetipo puro.
3. Identificar el tipo de proyecto, y el subtipo si es una migración.
4. Elegir la estrategia con la matriz; si es una combinación, escribir el orden.
5. Listar las tres señales a vigilar y qué cambiaría en el modelo si aparecen.
6. Definir el gobierno mínimo y el equipo: sponsor con nombre, reglas de decisión, cadencia, perfiles críticos y fecha de revisión de equipo.
7. Re-validar en cada momento. Si el arquetipo cambia, cambia la estrategia.

Y las cuatro preguntas que acompañan a cada momento del proyecto:

Momento	Pregunta clave
Discovery	¿Quién es realmente este cliente?
Preventa	¿Qué proyecto es y qué estrategia encaja?
Definición de alcance	¿Qué entra, qué no, y cómo sabremos que está hecho?
Kickoff	¿Sigue siendo el mismo cliente que en preventa, y es este el equipo para él?

La propuesta es sencilla: antes de abrir la plantilla de propuesta, rellenad la ficha. Tarda veinte minutos y ahorra dieciocho meses.

Lo que cambia con la IA, y lo que no

Cerramos con Copilot, y no por casualidad. Cambian cosas importantes: la configuración asistida por Copilot, el desarrollo en AL con ayuda de agentes, la documentación y el análisis de datos, que pasan a hacerse en minutos, y la preventa, donde una demo con los datos del cliente puede estar lista en horas y no en semanas.

En 25 años han cambiado el nombre del producto, el lenguaje, el modelo de despliegue y ahora la IA, pero los proyectos siguen fallando por el encaje y no por el producto. Un cliente que no puede decidir no decide más rápido con IA, y un usuario clave sin horas sigue sin horas.

La IA acelera la configuración y el desarrollo. No acelera a un cliente que no puede decidir.

La frase final

Lorena cerró con una sola línea, que es también la que me llevo yo:

No elijas la estrategia que mejor sabes hacer. Elige la que tu cliente puede ejecutar.

La PPT de la sesión

Gracias a la organización del BIZZ SUMMIT, a los sponsors por su confianza y su apoyo, y a todos los que dedicasteis vuestros cincuenta minutos a escucharnos contando nuestra vida. Y gracias a Lorena, por estar a mi lado.

¿Quieres saber más sobre las soluciones de inteligencia artificial generativa de Microsoft? Yo te asesoro. ¿Por qué no me preguntas cómo puedo ayudarte?

Más información en la web oficial del Bizz Summit.