Alternativas a Excel para el seguimiento de una cartera de proyectos renovables

Casi todas las carteras de proyectos renovables empiezan en Excel, y con razón: es flexible, todo el mundo lo entiende y el primer promotor de la empresa lo tenía abierto el día que firmó la primera opción de suelo. El problema no aparece con la primera hoja. Aparece con la decimoquinta, cuando hay una por país, otra por tecnología, una del comité y una "buena" que solo conoce una persona.

Antes de buscar alternativas conviene nombrar bien el problema. Excel no es la causa de que la dirección reciba la realidad tarde y resumida; es el síntoma de la distancia que crece entre quien ejecuta el proyecto y quien decide sobre la cartera. Cambiar la hoja por otra herramienta sin cerrar esa distancia solo cambia dónde se pierde la información.

Lo que Excel no puede hacer, por diseño

• Conservar la fecha anterior. Una celda tiene un valor; cuando se escribe el nuevo, el antiguo desaparece. No hay línea base, así que no hay desviación — solo la fecha de hoy.
• Decir quién cambió qué y por qué. El historial de versiones de un archivo no es un registro de decisiones.
• Relacionar objetos con significado propio. Una parcela, un permiso, una SPV y un PPA no son filas: tienen ciclo de vida, estados legales y dependencias entre sí.
• Agregar sin reconstruir. La vista de cartera se monta cada mes copiando de las hojas de cada país; cuando está lista, ya es vieja.
• Dar acceso con control. O todos ven todo, o nadie ve nada; no hay roles, ni trazabilidad, ni un único lugar que los sistemas corporativos y la IA puedan leer.

Las cuatro familias de alternativas

Las herramientas que un promotor evalúa cuando sale de Excel se agrupan en cuatro familias, y conviene saber cuál es cuál antes de ver demos:

• Gestores de proyectos genéricos (Jira, Asana, Monday, Microsoft Project y similares). Modelan tareas, responsables, plazos y presupuestos. Los permisos se emulan con campos personalizados, el suelo se queda en el GIS, el accionariado en otra hoja. Ganas colaboración y notificaciones; no ganas un modelo de datos del sector ni líneas base con desviación medida.
• Sistemas de suelo (Quorum, Pandell, IFS, PakEnergy, Gridlync). El contrato es el objeto principal: arrendamientos, opciones, servidumbres y obligaciones como un libro vivo con alertas y pagos. Profundos y maduros, sobre todo en Norteamérica; no dan control de hitos de permisos contra una línea base aprobada.
• Plataformas de ejecución (Sitetracker y similares). El emplazamiento es el objeto principal: un flujo de despliegue repetible, desde la evaluación hasta la construcción, aplicado a gran volumen y en varios sectores. Excelentes para desplegar muchos sitios parecidos; tratan el suelo como una carpeta de documentos.
• Plataformas de desarrollo. El proyecto es el objeto principal: suelo, permisos, líneas base, riesgos, accionariado y contexto financiero en un único modelo gobernado, de modo que una parcela que bloquea el ready-to-build y un permiso que se desvía de su línea base se ven en el mismo sitio. Es la familia construida para la fase de desarrollo; es también la menos numerosa.

Dos familias más conviven con estas sin sustituirlas: las herramientas de originación y diseño (cribado de emplazamientos, layouts preliminares, cuadros de mando de pipeline), útiles antes de que un emplazamiento sea un proyecto, y las plataformas de operación (SCADA, rendimiento, facturación), que toman el relevo tras la puesta en marcha.

Los criterios que separan una alternativa de otra

• Líneas base aprobadas y desviación medida: la prueba más simple es pedir, en la demo, la fecha que tenía un hito hace seis meses y quién la cambió.
• Un modelo de datos del sector: parcelas, permisos, SPVs, PPAs y riesgos como objetos propios, no como campos personalizados.
• Procesos configurables por país, comunidad autónoma y tecnología, sin cambios de código.
• Riesgo en días y en euros, agregado a nivel de cartera, antes y después de la mitigación.
• Integración con el ERP y el BI en lugar de un nuevo silo: la plataforma gobierna la capa de desarrollo; la contabilidad sigue en el ERP.
• IA sobre datos gobernados: que tus propias herramientas de IA puedan consultar la cartera de forma segura y de solo lectura.
• Tiempo de implantación: semanas, con el proveedor migrando tus hojas actuales, no un programa de varios trimestres.

Cuándo quedarse en Excel

Hay carteras para las que la hoja sigue siendo la respuesta correcta: menos de diez proyectos activos, un solo país, una tramitación que lleva una persona que también decide, y ningún inversor externo que pida trazabilidad. En ese contexto, el coste de una plataforma supera lo que la distancia entre ejecución y decisión está costando. Cambiar demasiado pronto es tan caro como cambiar demasiado tarde.

El momento de salir suele llegar con la segunda comunidad autónoma o el segundo país, con el primer comité de inversión que pregunta por qué un hito se movió tres veces, o con la primera venta de una SPV en la que la estructura accionarial hubo que reconstruirla en una hoja nueva. En ese punto, la hoja no es el problema — pero sí es el lugar donde el problema se nota primero.

Dónde encaja Navorda

Navorda está en la cuarta familia: la plataforma operativa para el desarrollo de proyectos energéticos y la gobernanza de carteras. Mantiene conectadas la ejecución y la dirección a medida que el promotor crece — suelo, permisos, hitos y líneas base, riesgos, SPVs y SPAs, contratos de venta de energía y contexto financiero en una única realidad de proyecto gobernada —, importa las hojas actuales en el onboarding y coexiste con el ERP, el GIS y las herramientas de diseño en lugar de sustituirlos. No es la herramienta adecuada para todo el mundo: las comparativas explican cuándo un sistema de suelo o una plataforma de ejecución encajan mejor.

La guía de compra en español: software de desarrollo de proyectos de energía renovable

Navorda frente a las alternativas (en inglés)

Excel is excellent — por qué las hojas de cálculo ganan y dónde se detienen (en inglés)