"Lo que no se separa en el presupuesto, se paga dos veces en la operación."
Ingeniería Bética Servicios es una empresa de 78 personas con sede en Sevilla que subcontrata proyectos de instalaciones para pliegos públicos. El director de operaciones lleva año y medio intentando cambiar el software con el que gestionan pliegos, ofertas, contratos y facturación por hitos. Ha visto cuatro demos. Ha recibido tres presupuestos. Todos rondaban los mismos números: entre 45.000 y 90.000 euros de implantación, más una cuota mensual entre 800 y 2.400 euros. Todos venían con la misma frase: "esto se adapta a vuestra operación".
Cuando pidió que le desglosaran qué parte era estándar, qué parte era configuración y qué parte era desarrollo específico, ninguno supo responder con claridad. Uno le pasó un Excel con partidas genéricas del tipo "parametrización avanzada" y "consultoría de proceso". Otro le dijo que "todo entra en la implantación". El tercero, con más honestidad, contestó que dependía de "lo que fuera saliendo".
Ese es el problema al que responde AVA.
AVA, Arquitectura Vertical Adaptativa, es un método de cinco fases que separa de forma explícita lo común productizado, lo diferencial configurable y lo excepcional que se desarrolla. El objetivo no es filosófico. Es contable. Cada línea del presupuesto y cada cláusula del contrato tiene que reflejar en qué capa vive lo que se está pagando. Sin esa separación, la implantación de un software vertical se convierte en una caja negra donde el proveedor cobra por horas indistinguibles y el cliente firma sin saber qué está firmando.
Qué es AVA y qué garantiza cada una de sus cinco fases
AVA se aplica sobre un cuerpo vertical, es decir, un software que ya resuelve el 70-80% de los procesos comunes de un sector (licitaciones, transporte por carretera, clínicas dentales, aduanas, aseguradoras de nicho) y que se adapta al 20-30% restante que hace única a cada empresa. Sin ese cuerpo base, no hay AVA que valga. Se estaría hablando de desarrollo a medida puro, y esa es otra conversación.
Las cinco fases son secuenciales, cada una con una salida verificable que el cliente firma antes de pasar a la siguiente:
- Fase 1. Diagnóstico. Salida: informe de encaje con el cuerpo vertical y clasificación de cada proceso en las tres capas (común, configurable, específico).
- Fase 2. Mapeo. Salida: catálogo de procesos reales de la organización cruzados contra el cuerpo vertical, con lista firmada de qué se activa, qué se configura y qué se desarrolla.
- Fase 3. Configuración. Salida: entorno preproducción con reglas, permisos, plantillas y flujos ajustados a la operación, más manual de administración interna.
- Fase 4. Migración y validación. Salida: datos históricos cargados, entorno productivo firmado con casos reales trabajados por el equipo del cliente, no por consultores.
- Fase 5. Operación con soporte y evolución. Salida: contrato de mantenimiento con SLA numérico, bolsa de evolución trimestral y política de versionado del cuerpo vertical.
Cada fase tiene una factura, un entregable y un criterio de aceptación. No se avanza a la siguiente hasta que la anterior está cerrada.
Regla: si un proveedor no puede desglosar su propuesta en estas cinco fases con importe por fase, no está vendiendo un cuerpo vertical adaptado. Está vendiendo horas.
Fase 1: qué entra en el diagnóstico y por qué es previo a firmar alcance
El diagnóstico es la única fase que se puede contratar de forma aislada, sin compromiso de continuidad. Es deliberado. Un cuerpo vertical puede no encajar con la operación de una empresa, y el diagnóstico es donde eso se detecta antes de que nadie firme un contrato de 50.000 euros. El coste del diagnóstico ronda entre el 5% y el 10% del presupuesto total estimado, según rangos de mercado publicados por Vertebra Gestión y Cero Ideas para implantaciones de ERP y CRM verticales.
En el caso de Ingeniería Bética, el diagnóstico duró tres semanas y produjo cuatro entregables concretos:
- Mapa de procesos actuales. No un diagrama vago, sino cada proceso descrito en formato entrada-salida-responsable. En Bética resultaron 34 procesos operativos, de los cuales 11 estaban documentados en el manual interno y 23 vivían solo en la cabeza de tres personas.
- Clasificación en tres capas. Cada proceso se etiqueta como común (cubierto por el cuerpo vertical sin tocar), configurable (cubierto tras ajustar parámetros y plantillas) o específico (requiere desarrollo). En Bética la distribución fue: 21 comunes, 9 configurables, 4 específicos.
- Estimación por capa. Los procesos comunes tienen coste cero de adaptación porque ya están productizados. Los configurables se estiman en horas de configuración con tarifa cerrada. Los específicos se estiman por desarrollo con alcance detallado o se marcan como "fuera de v1".
- Lista de riesgos y bloqueantes. Integraciones con sistemas antiguos, formatos de datos que no van a migrar limpios, permisos regulatorios que exigen validación externa. Cada riesgo va con probabilidad y coste de mitigación.
Con esos cuatro documentos, el director de operaciones tiene por primera vez una foto contable de qué está comprando. Puede llevarla a comité, puede pedir segunda opinión, puede decidir no seguir. Ese es el punto. Un diagnóstico que solo sirve para justificar un cierre de venta no es diagnóstico.
El diagnóstico existe para que el cliente pueda decir no con toda la información sobre la mesa.
Nota crítica: un diagnóstico honesto a veces concluye que el cuerpo vertical no encaja. Cuando eso pasa, se cobra el diagnóstico, se entrega el informe y se recomienda otra vía (otro proveedor, otro tipo de solución, desarrollo desde cero, seguir con lo que ya tienen). Rechazar un proyecto de 60.000 euros porque el encaje es del 45% no es generosidad. Es no envenenar una operación que va a fracasar en seis meses.
Fase 2: cómo se mapea el cuerpo vertical contra los procesos reales
El mapeo es la fase donde el cuerpo vertical se cruza, proceso a proceso, contra el catálogo real de la organización. No se hace en despacho. Se hace en la mesa donde ocurre el trabajo, con la persona que ejecuta el proceso, con las pantallas del cuerpo vertical abiertas y con los papeles y hojas de cálculo actuales delante.
En Bética el mapeo duró cinco semanas. El resultado fue un catálogo de 34 procesos con la siguiente distribución final, ajustada respecto al diagnóstico inicial:
- Procesos comunes que se activan sin tocar (22). Alta de proveedor, alta de cliente, ciclo de oferta, generación de contrato tipo, facturación por hito, conciliación bancaria básica, gestión documental, control de vencimientos, alertas de renovación, log de auditoría. Todo esto ya vive en el cuerpo vertical. Se activa con un permiso y se prueba con dos casos reales. Coste de adaptación: cero.
- Procesos configurables (8). Aquí se ajustan parámetros del cuerpo vertical para reflejar reglas propias. En Bética: escalado de aprobación de ofertas por importe (tres tramos), plantillas de contrato con cláusulas de subrogación específicas del sector, cálculo de baja temeraria con la fórmula de la Junta de Andalucía, integración con la plataforma de contratación pública para descargar pliegos automáticamente, generación de aval bancario con dos entidades preferentes, cierre de proyecto con retención del 5% durante 12 meses, informe de rentabilidad por obra con dos vistas (comercial y técnica), y notificación fiscal cuando una factura supera los 3.000 euros al mismo cliente en el trimestre.
- Procesos específicos que se desarrollan (4). Cálculo de una fianza especial que exige la administración autonómica según ordenanza propia, un sistema de partes de obra con firma biométrica del jefe de obra que se sincroniza contra el módulo estándar, una integración con el software de contabilidad heredado que la empresa no quiere sustituir en v1, y un informe reglamentario que exige un cliente institucional en formato XML propio.
El entregable de esta fase es un documento que el director de operaciones firma línea por línea. Cada proceso lleva capa, esfuerzo estimado en horas o días, responsable de aprobar cada configuración y persona del cliente que va a validar el resultado.
Traducción: si en esta fase alguien dice "eso lo vemos en la implantación", no se ha hecho el mapeo. Se ha hecho un powerpoint.
Fase 3: qué queda en manos del cliente al terminar la configuración
La fase de configuración es donde el cuerpo vertical se convierte en la herramienta que va a usar Ingeniería Bética. Se hace en un entorno de preproducción, con datos ficticios pero realistas, y produce dos cosas: un sistema funcional y un manual de administración interna.
El punto crítico es el segundo. La configuración no puede quedar solo en manos del proveedor, porque entonces cada cambio futuro obliga a llamar al proveedor y a pagarlo. AVA obliga a que, al cierre de la fase 3, el cliente tenga:
- Acceso completo a la capa de configuración. Panel de administración con permisos, plantillas, flujos de aprobación, tarifas, reglas de cálculo. Todo modificable por un administrador interno con formación media.
- Manual de administración escrito específico para la operación. No la documentación genérica del cuerpo vertical. Un manual donde pone: "para cambiar el escalado de aprobación de ofertas, entra en Configuración > Flujos > Aprobación de ofertas y modifica los tramos". Con capturas de la instalación real, no del entorno demo del proveedor.
- Formación a dos perfiles. Un administrador funcional (típicamente responsable de sistemas o de operaciones) que puede tocar la configuración. Y usuarios finales por rol (comercial, técnico de obra, administración) formados solo en su parte.
- Sesiones de trabajo grabadas. Cuando alguien nuevo entre en el equipo en dos años, tiene material de referencia sin depender de que el proveedor siga existiendo o siga siendo el mismo.
Al cerrar la fase 3, Ingeniería Bética puede cambiar tramos de aprobación, añadir plantillas de contrato, ajustar tarifas y crear nuevos informes sin abrir un ticket. Los cambios estructurales del cuerpo vertical siguen siendo del proveedor. La configuración operativa es del cliente. Esa es la línea.
El cliente que depende del proveedor para modificar un tramo de aprobación no ha comprado un software. Ha alquilado un rehén.
Ejemplo: a los cuatro meses de arrancar, Bética decidió cambiar el flujo de aprobación de ofertas para incluir un cuarto tramo por encima de 200.000 euros que exigía firma del CEO. Lo hizo el responsable de operaciones en 40 minutos. No hubo ticket, no hubo factura, no hubo espera. Esa autonomía es lo que se firma en el acta de cierre de fase 3.
Fase 4: cómo se migran los datos y por qué la validación la hace el equipo del cliente
La migración es la fase más subestimada y la que más proyectos hunde. En Ingeniería Bética había 11 años de historia: 4.200 clientes, 890 proveedores, 3.100 obras, 28.000 facturas, 14.000 documentos vinculados a contratos, un histórico de partes de obra en Excel de 2019 en adelante y una base de tarifas con 340 conceptos con precios que habían cambiado seis veces.
AVA descompone la migración en tres bloques claramente separados:
- Datos maestros. Clientes, proveedores, empleados, tarifas, plantillas. Se migran en primer lugar, se depuran (duplicados, códigos rotos, teléfonos mal formateados) y se validan contra el sistema origen con un informe de diferencias. Regla: si la migración deja más del 2% de registros no conciliados, se para y se investiga. En Bética el primer intento dejó 8% de duplicados de clientes por variantes del CIF con y sin guiones. Se pausó tres días para limpiar antes de seguir.
- Datos transaccionales. Obras, ofertas, contratos, facturas. Se migran con corte de fecha explícito. Todo lo anterior al corte se carga como histórico consultable pero cerrado. Todo lo posterior se opera ya en el sistema nuevo. Nunca se migra "el sistema entero" sin corte, porque garantiza inconsistencias.
- Documentos. PDFs de contratos, escaneos de facturas recibidas, planos, certificados. Se cargan vinculados a la entidad correspondiente. En Bética se cargaron 14.000 documentos con un script que los enlazaba por código de obra. Los 380 que no encontraron enlace se listaron en un informe para revisión manual.
La validación no la hace el proveedor. La hacen los operativos del cliente, trabajando con casos reales durante dos o tres semanas en paralelo al sistema anterior. Es lo que AVA llama fase de sombra. Cada mañana el equipo de Bética metía las mismas operaciones en los dos sistemas y comparaba resultados al cierre del día.
Las diferencias se documentaban en una hoja compartida. Al cabo de tres semanas, el número de diferencias había caído a cero durante cinco días consecutivos. Ese fue el criterio de corte. A partir del lunes siguiente, el sistema antiguo pasó a modo consulta y todo el trabajo nuevo entró por el sistema nuevo.
Síntoma: si la validación la hace solo el proveedor, con datos suyos y en su entorno demo, no es validación. Es una demo con más pantallas.
Regla: no hay corte de sistema sin cinco días consecutivos de cero diferencias sobre casos reales trabajados por el equipo del cliente.
Fase 5: cómo se opera con soporte y qué política de evolución se firma
La quinta fase no es un final. Es el modo permanente en el que el sistema convive con la operación. AVA impone que el contrato de operación tenga tres bloques separados con precios independientes: mantenimiento, evolución y versionado del cuerpo vertical.
- Mantenimiento. Cubre soporte a incidencias, corrección de errores atribuibles al proveedor, disponibilidad del sistema y respuesta ante fallos. Se firma con SLA numérico: tiempo máximo de respuesta por severidad (crítica, alta, media, baja), disponibilidad mensual mínima (habitualmente 99,5% para sistemas de gestión, no más), canal de comunicación (portal de tickets con trazabilidad, no correo electrónico). El coste ronda entre el 15% y el 22% anual del importe de implantación, según rangos publicados por Davisa y ASD Solutions para ERP y CRM verticales.
- Evolución. Es una bolsa trimestral de horas para cambios pequeños o medianos que la organización decide priorizar: un nuevo informe, un ajuste de un flujo, una integración menor. Se compra por adelantado y se consume contra tablero visible al cliente. Si sobran horas al trimestre, se acumulan un trimestre más. Si se acaban, se compra otra bolsa. Nunca se mezcla con mantenimiento, porque el mantenimiento es reactivo y la evolución es proactiva.
- Versionado del cuerpo vertical. El cuerpo vertical evoluciona con actualizaciones periódicas (nuevas funciones, cambios regulatorios, mejoras de seguridad). La política contractual define cada cuánto se aplican, quién decide, cómo se prueban en preproducción antes de pasar a producción y qué garantías hay sobre las configuraciones y desarrollos específicos del cliente. La regla en AVA: las configuraciones y los desarrollos específicos deben seguir funcionando tras cada nueva versión del cuerpo, o el proveedor asume el coste de adaptación.
Este último punto es el que más se olvida en los contratos. Un cuerpo vertical que se actualiza y rompe la configuración del cliente cada seis meses acaba siendo más caro que un desarrollo a medida. La cláusula de compatibilidad hacia atrás sobre configuraciones y specifics es lo que hace sostenible el modelo.
Nota crítica: un proveedor que no quiere firmar compatibilidad hacia atrás sobre configuraciones y desarrollos específicos está diciendo, sin decirlo, que la evolución de su cuerpo vertical va a generar facturas extra al cliente cada vez. Léelo así y decide con esa información.
Cómo se refleja AVA en el presupuesto y en el contrato
El director de operaciones de Ingeniería Bética recibió, tras el diagnóstico, un presupuesto AVA que no se parecía a los tres anteriores. Estaba estructurado por fase, con coste por capa dentro de cada fase, con horas estimadas por partida y con criterios de aceptación por entregable. Un resumen anonimizado:
- Fase 1. Diagnóstico: cerrada. 4.800 euros. Ya facturada al inicio del proceso.
- Fase 2. Mapeo: 8.400 euros. Cinco semanas. Entregable: catálogo firmado de 34 procesos con clasificación en tres capas.
- Fase 3. Configuración: 22.000 euros. Ocho semanas. Entregable: entorno preproducción firmado, manual de administración escrito, formación entregada a los dos perfiles.
- Fase 4. Migración y validación: 14.500 euros. Seis semanas. Entregable: sistema en producción con cinco días de cero diferencias sobre casos reales.
- Desarrollos específicos (4 procesos): 18.200 euros. Cotizados uno por uno. Cada uno con alcance detallado, aceptación por prueba unitaria y garantía de compatibilidad con próximas versiones del cuerpo.
- Fase 5. Operación año 1: cuota anual de mantenimiento 8.400 euros. Bolsa de evolución trimestral 40 horas a 65 euros hora, 2.600 euros por bolsa. Política de versionado documentada en anexo.
Ese presupuesto, sumado, era comparable en importe total a las tres propuestas anteriores. La diferencia estaba en la visibilidad. Cada partida tenía nombre, entregable, criterio de aceptación y responsable. No había líneas del tipo "consultoría de proceso" o "parametrización avanzada" que absorbieran horas indefinidas.
El contrato replicaba la misma estructura. Cada fase con su fecha de cierre, su entregable y su cláusula de pago. Los desarrollos específicos con anexo propio. La operación con SLA numérico, bolsa dimensionada y política de versionado. Un abogado mercantil externo, contratado por Bética para revisar, dedicó tres horas a leerlo y devolvió dos comentarios menores. Cuando la estructura contractual es clara, la revisión legal es corta.
Un presupuesto AVA se lee en veinte minutos. Un presupuesto opaco necesita seis reuniones para entenderlo.
Errores frecuentes en la aplicación de AVA
Error 1: Saltar la fase de diagnóstico para ir "más rápido". Síntoma: el proveedor propone empezar directamente por configuración con un pack cerrado. Solución: rechazar. Sin diagnóstico no hay separación entre capas y el proyecto entra en modo horas indistinguibles antes de terminar el segundo mes.
Error 2: Meter procesos específicos en la fase de configuración. Síntoma: aparece la frase "esto lo hacemos con una configuración creativa". Solución: si un proceso requiere lógica nueva, es desarrollo específico, tiene alcance propio, tiene su factura y tiene su garantía. Disfrazarlo de configuración esconde el coste real y traspasa a mantenimiento un riesgo que debía estar en desarrollo.
Error 3: Aceptar migración sin fase de sombra. Síntoma: el proveedor dice "migramos el fin de semana y el lunes arrancamos". Solución: exigir dos o tres semanas de trabajo en paralelo con validación diaria contra el sistema antiguo, y corte solo tras cinco días consecutivos de cero diferencias sobre casos reales.
Error 4: Contratar mantenimiento sin SLA numérico. Síntoma: el contrato habla de "soporte en horario laboral" sin tiempos ni severidades. Solución: SLA con severidades, tiempos máximos por severidad, disponibilidad mensual mínima, canal con trazabilidad y penalización proporcional al incumplimiento. Sin números, el SLA no existe.
Error 5: Firmar sin cláusula de compatibilidad hacia atrás sobre configuraciones y desarrollos específicos. Síntoma: la política de versionado dice que "las actualizaciones pueden requerir adaptaciones que se facturarán aparte". Solución: exigir que la compatibilidad hacia atrás sea responsabilidad del proveedor. Si el cuerpo vertical evoluciona y rompe una configuración del cliente, el coste de arreglarlo lo asume quien decidió cambiar el cuerpo.
Preguntas frecuentes
Qué es la Arquitectura Vertical Adaptativa
Es un método para adaptar un software vertical (un cuerpo que ya cubre el 70-80% de los procesos comunes de un sector) a la operación concreta de una organización. Lo hace separando cada proceso en tres capas (común, configurable, específico) y ejecutando cinco fases secuenciales (diagnóstico, mapeo, configuración, migración y validación, operación con soporte). El objetivo es que el presupuesto y el contrato reflejen con claridad qué se paga en cada capa y en cada fase.
Cómo se adapta un software vertical a la operación de una empresa concreta
Con las cinco fases de AVA. Primero se hace un diagnóstico que clasifica cada proceso de la empresa en las tres capas y estima esfuerzo por capa. Después se mapean los procesos contra el cuerpo vertical y se firma línea por línea qué se activa, qué se configura y qué se desarrolla. En la fase de configuración se ajustan parámetros, plantillas y flujos, y se entrega manual y formación para que el cliente pueda modificar la configuración por su cuenta. Luego se migran datos con corte de fecha y se validan tres semanas trabajando en paralelo. Y se opera con contrato de mantenimiento, bolsa de evolución y política de versionado.
Qué fases tiene la implantación de un software vertical propio
Cinco. Diagnóstico (informe de encaje y clasificación en tres capas). Mapeo (catálogo de procesos firmado línea a línea). Configuración (entorno preproducción, manual de administración, formación). Migración y validación (carga de datos con corte y fase de sombra hasta cero diferencias). Operación con soporte y evolución (mantenimiento con SLA, bolsa de evolución trimestral, política de versionado con compatibilidad hacia atrás).
Cómo se separa lo común de lo específico en un proyecto de software a medida
Con las tres capas de AVA. La capa común es todo lo que el cuerpo vertical resuelve de fábrica sin tocar (típicamente el 60-70% de los procesos): alta de entidades, ciclos estándar, gestión documental, auditoría. La capa configurable son procesos que existen en el cuerpo pero se ajustan con parámetros y plantillas para reflejar reglas propias (típicamente el 20-30%). La capa específica es todo aquello que requiere desarrollo nuevo porque no está cubierto (típicamente el 5-15%). Cada capa tiene coste distinto, esfuerzo distinto y garantía distinta.
Cuánto tiempo dura una implantación completa con AVA
Depende del tamaño de la organización y del número de procesos específicos. En una empresa de 60-100 personas con 30-40 procesos operativos, el total suele estar entre 5 y 8 meses desde la firma del diagnóstico hasta el cierre de la fase 4. Diagnóstico 3-4 semanas, mapeo 4-6 semanas, configuración 6-10 semanas, migración y validación 4-8 semanas.
Qué pasa si el diagnóstico concluye que el cuerpo vertical no encaja
Se cobra el diagnóstico (5-10% del presupuesto estimado), se entrega el informe con la clasificación por capas y las razones del desencaje, y se recomienda otra vía. Un diagnóstico honesto que dice "esto no encaja" ahorra al cliente 40.000-80.000 euros de proyecto fallido. Rechazar un proyecto que no encaja es parte del método.
Cierre
AVA no es una metodología nueva ni original. Es la aplicación disciplinada de una idea sencilla: si separas por escrito lo común, lo configurable y lo específico, y ejecutas cinco fases con entregable firmado en cada una, la implantación deja de ser una caja negra y pasa a ser un proyecto contable. Cada línea del presupuesto tiene nombre. Cada mes se sabe en qué fase se está. Cada cambio futuro se cotiza contra un catálogo firmado, no contra la memoria de una reunión.
Para el director de operaciones que gestiona la compra del sistema, esto se traduce en dos cosas concretas. La primera: puede llevar el presupuesto a comité sin tener que interpretarlo. La segunda: cuando el proyecto avance y aparezcan cambios (que aparecerán), puede negociarlos contra un documento que dice exactamente qué se firmó y qué queda fuera. Sin AVA, cualquier cambio es una discusión abierta. Con AVA, cualquier cambio es una anotación al catálogo con importe y aceptación.
Si estás valorando comprar un software vertical para tu operación y te han pasado un presupuesto que no puedes desglosar por fase, por capa y por proceso, pide un diagnóstico separado antes de firmar nada más grande. En la sesión gratuita de 30 minutos revisamos tu presupuesto actual, identificamos qué partidas están mezclando capas y qué preguntas concretas debes llevar al proveedor para que el contrato refleje lo que estás comprando de verdad. Y si quieres ver cómo se aplica AVA sobre un cuerpo vertical concreto, la página de Arquitectura Vertical Adaptativa tiene la descripción operativa completa de las cinco fases con sus entregables.
Próximos artículos de la serie SVP Fundamentos:
- Cuerpo vertical vs software a medida: por qué el 80% común cambia la economía del proyecto
- Bolsa de evolución trimestral: cómo dimensionarla sin regalar horas ni quedarse corto
Lecturas relacionadas:
