Qué información necesita un programador para crear una macro Excel

Introducción

Para crear una macro Excel útil no basta con indicar que una tarea es repetitiva o que se desea automatizar un libro. El programador necesita comprender qué información entra en el proceso, qué operaciones se realizan, qué resultados deben obtenerse y bajo qué condiciones se ejecutará la herramienta.

Contenido

Cuanto mejor definida esté esta información, más fácil será estimar el trabajo, diseñar una solución estable y evitar modificaciones innecesarias durante el desarrollo. Una descripción incompleta suele provocar dudas, retrabajos, funciones mal interpretadas y macros que solo funcionan correctamente en el ejemplo utilizado durante las primeras pruebas.

Esto no significa que el cliente deba redactar una especificación informática compleja. En muchas pequeñas empresas basta con reunir los archivos reales, explicar el procedimiento actual, mostrar varios casos representativos y señalar qué problemas se quieren resolver. El programador puede ayudar después a ordenar esa información y convertirla en requisitos técnicos.

Antes de encargar el desarrollo también conviene comprobar que el trabajo está suficientemente definido y que realmente merece la pena automatizarlo. Para ello puede resultar útil revisar qué tareas de Excel deberían automatizarse y estimar el ahorro de tiempo que podría proporcionar la macro.

Definir el proceso antes de programar

Una macro Excel automatiza un procedimiento. Por tanto, el punto de partida no debería ser el código, sino la definición del proceso que se desea ejecutar.

El programador necesita saber qué hace actualmente la persona encargada del trabajo, en qué orden realiza las operaciones, qué decisiones toma y qué comprobaciones aplica antes de considerar terminado el resultado. Si el procedimiento no está claro para la propia empresa, será difícil trasladarlo a una macro de manera fiable.

Conviene describir el proceso mediante una secuencia ordenada de pasos. Por ejemplo:

El usuario selecciona un archivo de movimientos.
La macro comprueba que contiene las columnas obligatorias.
Elimina registros duplicados.
Descarta las filas anuladas.
Agrupa los importes por cliente y trimestre.
Aplica una tabla de correspondencias.
Genera un libro independiente para cada delegación.
Guarda los resultados en una carpeta determinada.
Presenta un resumen de registros procesados y errores encontrados.

Este nivel de detalle permite identificar operaciones que de otro modo podrían quedar ocultas. Expresiones como “ordenar los datos”, “preparar el informe” o “hacer lo mismo de siempre” suelen contener numerosas reglas que deben aclararse.

También es importante distinguir entre el proceso oficial y las soluciones improvisadas que se han ido incorporando con el tiempo. Una automatización no debería reproducir de manera ciega todos los defectos del procedimiento manual. En algunos casos, antes de programar conviene simplificar, ordenar o normalizar la forma de trabajar.

Objetivo, alcance y resultado esperado

El programador debe conocer el objetivo empresarial de la macro. No es lo mismo reducir cinco minutos en una tarea ocasional que automatizar un trabajo que consume varias jornadas cada mes, afecta a la facturación o condiciona la entrega de información a un cliente.

El objetivo puede ser, entre otros:

Reducir el tiempo de preparación de informes.
Evitar errores de copia y pegado.
Unificar documentos creados por diferentes empleados.
Aumentar el número de expedientes que puede procesar la empresa.
Facilitar el uso de una plantilla compleja.
Validar datos antes de importarlos en otro sistema.
Generar presupuestos, pedidos, facturas o informes repetitivos.
Consolidar información procedente de varios archivos.
Preparar datos para un programa de gestión o un ERP.

Junto al objetivo debe definirse el alcance. El alcance establece qué hará la macro y, con la misma importancia, qué quedará fuera de la primera versión.

Por ejemplo, una macro puede incluir la importación de datos, su validación y la generación de un informe, pero no la integración automática con el programa contable. Si esta frontera no se establece desde el principio, durante el desarrollo pueden aparecer nuevas expectativas que alteren el presupuesto y los plazos.

Para evitar confusiones conviene redactar una frase que resuma el resultado esperado. Un ejemplo podría ser: “La macro debe leer los archivos mensuales de movimientos, validar su estructura, agrupar los importes por proyecto y generar un informe independiente para cada responsable”.

Plantillas de los formatos de entrada

Los formatos de entrada son todos los archivos, hojas, tablas o datos que la macro debe leer. El programador necesita disponer de muestras reales y, siempre que sea posible, de plantillas que representen la estructura habitual.

No suele ser suficiente entregar un único archivo perfectamente preparado. La macro debe diseñarse considerando las variaciones que aparecen en el trabajo real.

Archivos de ejemplo representativos

Conviene proporcionar varios ejemplos:

Un archivo habitual correctamente cumplimentado.
Un archivo con muchas filas.
Un archivo con campos vacíos.
Un archivo con valores incorrectos.
Un archivo correspondiente a un caso poco frecuente.
Un archivo antiguo si todavía debe ser compatible.
Un archivo procedente de cada proveedor o sistema de origen.

Estos ejemplos permiten comprobar si la estructura es verdaderamente estable o si cambia según el mes, el usuario, el cliente o el programa que exporta los datos.

Ubicación de los datos

Debe indicarse dónde se encuentra cada dato relevante:

Nombre de la hoja.
Fila en la que comienzan los encabezados.
Columnas obligatorias.
Columnas opcionales.
Rangos con nombre.
Tablas estructuradas de Excel.
Celdas de configuración.
Hojas ocultas que contienen información auxiliar.

Si la macro debe localizar la información por el nombre del encabezado, hay que definir qué nombres son válidos. Si, por el contrario, se espera que una columna ocupe siempre una posición concreta, debe quedar igualmente documentado.

Tipos y formatos de datos

El programador también necesita saber qué tipo de valor contiene cada campo:

Texto.
Números enteros o decimales.
Porcentajes.
Importes monetarios.
Fechas y horas.
Códigos que pueden comenzar por cero.
Identificadores alfanuméricos.
Valores lógicos como sí, no, verdadero o falso.

Una columna aparentemente numérica puede contener códigos que no deben convertirse a número. Por ejemplo, el código 00125 no es equivalente a 125 si los ceros iniciales forman parte del identificador.

Nombre y ubicación de los archivos

Debe explicarse cómo se nombran y dónde se guardan los archivos de entrada. La macro puede necesitar localizar documentos mediante una carpeta, una fecha, un código de cliente o una parte concreta del nombre.

También hay que indicar si el usuario seleccionará manualmente los archivos, si la macro buscará automáticamente en una carpeta o si deberá recorrer varias subcarpetas.

Estabilidad del formato de origen

Es esencial saber quién genera los archivos de entrada y si su formato puede cambiar. Una exportación producida por un programa de gestión suele ser más predecible que una hoja elaborada manualmente por distintos colaboradores.

Cuando el origen no está controlado, puede ser necesario añadir validaciones, mecanismos de correspondencia de columnas y mensajes de error más detallados. Esto aumenta la robustez, pero también el trabajo de desarrollo.

Plantillas de los formatos de salida

Las plantillas de salida muestran cómo debe quedar el resultado producido por la macro. Son tan importantes como los archivos de entrada, porque permiten entender qué información debe generarse, cómo debe organizarse y qué nivel de presentación se espera.

Conviene entregar un ejemplo completado manualmente y señalar qué partes son fijas y cuáles debe rellenar la macro.

Contenido del resultado

El programador debe saber:

Qué campos deben aparecer.
En qué orden deben mostrarse.
Qué cálculos deben incluirse.
Qué agrupaciones y subtotales son necesarios.
Qué registros deben excluirse.
Qué textos, observaciones o advertencias deben incorporarse.
Qué información debe aparecer en cada hoja.

Formato visual

También debe aclararse si la apariencia forma parte del requisito. Una salida puede necesitar:

Encabezados y pies de página.
Logotipo corporativo.
Colores determinados.
Anchuras de columna.
Alturas de fila.
Formatos de fecha, porcentaje o moneda.
Saltos de página.
Área de impresión.
Orientación horizontal o vertical.
Filas repetidas en cada página impresa.
Bloqueo o protección de determinadas celdas.

Si la salida se imprimirá, se enviará a un cliente o se importará en otro programa, el formato debe definirse con especial precisión. Un archivo visualmente correcto puede ser inútil para una importación si contiene columnas adicionales, celdas combinadas o valores formateados de manera incompatible.

Tipo de archivo generado

Debe indicarse si el resultado será:

Un libro de Excel con macros.
Un libro de Excel sin macros.
Un archivo CSV.
Un documento PDF.
Varios archivos separados.
Una actualización del libro original.
Una hoja añadida al archivo existente.

También es necesario definir el nombre de los archivos, la carpeta de destino y el comportamiento cuando ya existe un archivo con el mismo nombre.

Ejemplo completo de salida

La mejor referencia suele ser una salida real que la empresa considere correcta. El programador puede utilizarla para comparar los resultados de la macro y detectar diferencias durante las pruebas.

Cuando no existe un ejemplo terminado, conviene preparar al menos un esquema. Programar sin saber cómo debe quedar el resultado obliga a tomar decisiones que deberían corresponder al cliente.

Reglas de cálculo y transformación

Entre los archivos de entrada y los resultados existe un conjunto de reglas. Estas reglas son el núcleo del proceso y deben explicarse con suficiente precisión para que puedan convertirse en instrucciones programables.

Algunas reglas habituales son:

Cómo se calculan importes, porcentajes y totales.
Qué registros deben agruparse.
Cómo se identifican los duplicados.
Qué criterios determinan que una fila sea válida.
Qué correspondencias se aplican entre códigos.
Cómo se redondean los resultados.
Qué fechas delimitan cada periodo.
Cómo se tratan los valores negativos.
Qué prioridad tienen unas condiciones respecto de otras.

Evitar expresiones ambiguas

Indicaciones como “aplicar el descuento habitual”, “eliminar los duplicados” o “clasificar cada operación” pueden parecer claras para quien realiza diariamente el trabajo, pero no definen una regla completa.

Por ejemplo, para eliminar duplicados hay que indicar qué campos deben coincidir. Dos registros pueden considerarse duplicados por compartir número de factura, fecha e importe, aunque presenten diferencias en otras columnas.

Orden de aplicación

El orden de las reglas puede modificar el resultado. No siempre es equivalente filtrar antes de agrupar que agrupar antes de filtrar. Por eso conviene describir la secuencia real del procedimiento.

Tablas auxiliares

Si el proceso utiliza listas de precios, equivalencias, porcentajes, categorías, códigos de cliente o cualquier otra tabla de referencia, estas deben entregarse al programador.

También hay que indicar quién las actualiza, con qué frecuencia cambian y si deben quedar integradas en el libro o almacenadas en un archivo independiente.

Excepciones, errores y casos especiales

Una macro profesional no debe diseñarse únicamente para el caso ideal. Debe saber qué hacer cuando faltan datos, los archivos no tienen la estructura prevista o aparece una situación que no puede procesar automáticamente.

El cliente debería explicar los errores conocidos y las excepciones que ya aparecen durante el trabajo manual.

Datos incompletos o incorrectos

Hay que definir el comportamiento esperado cuando:

Falta una columna obligatoria.
Una fecha no es válida.
Un código no existe en la tabla de correspondencias.
Una celda obligatoria está vacía.
Un importe contiene texto.
El archivo no tiene ninguna fila procesable.
Se encuentran registros duplicados.

Según el proceso, la macro puede detenerse, omitir la fila, pedir una corrección al usuario o generar un informe de incidencias.

Casos que requieren decisión humana

No todas las decisiones tienen que automatizarse. Puede ser preferible que la macro detecte una situación dudosa y solicite la intervención del usuario.

Por ejemplo, si un código puede asignarse a dos categorías, la herramienta puede mostrar ambas opciones en lugar de aplicar una decisión arbitraria.

Registro de incidencias

En procesos importantes conviene generar una hoja o archivo de incidencias con información como:

Número de fila.
Archivo de origen.
Dato problemático.
Motivo del rechazo.
Acción aplicada.
Fecha y hora del procesamiento.

Este registro facilita la revisión y evita que los errores desaparezcan silenciosamente.

Tiempos máximos de procesamiento

El tiempo de ejecución esperado influye en la arquitectura de la macro. No es lo mismo procesar cien filas una vez al mes que consolidar cientos de archivos con varios millones de celdas todos los días.

El programador necesita conocer cuánto tarda actualmente el proceso manual y cuál sería un tiempo aceptable para la ejecución automatizada.

Definir un objetivo realista

Puede establecerse un requisito como:

El proceso debe completarse en menos de dos minutos.
La generación de cada informe no debe superar treinta segundos.
La macro puede ejecutarse durante quince minutos si no requiere intervención.
El usuario debe recibir información de progreso durante procesos largos.

Un tiempo máximo muy exigente puede obligar a emplear técnicas adicionales de optimización, reducir interacciones con las hojas, trabajar con matrices en memoria o modificar el diseño del proceso.

Tiempo total frente a tiempo de intervención

En una pequeña empresa no siempre es necesario que la macro termine inmediatamente. Puede ser aceptable que tarde varios minutos si el usuario puede continuar con otro trabajo y no necesita intervenir.

Por eso conviene distinguir entre:

Tiempo de ejecución: duración total de la macro.
Tiempo de atención: tiempo durante el cual el trabajador debe seleccionar opciones, responder mensajes o vigilar el proceso.

Una macro que tarda diez minutos sin intervención puede resultar más eficiente que otra que tarda cinco minutos pero exige constantes decisiones del usuario.

Equipos en los que se ejecutará

Los tiempos también dependen del ordenador, la versión de Excel, la velocidad de la red y la ubicación de los archivos. Las pruebas deben realizarse en un entorno parecido al que utilizará realmente la empresa.

Parámetros de configuración general

Los parámetros de configuración general son valores que determinan el funcionamiento habitual de la macro y que no deberían estar dispersos dentro del código.

Algunos ejemplos son:

Carpeta predeterminada de entrada.
Carpeta de salida.
Ruta de las plantillas.
Nombre de las hojas de trabajo.
Formato de las fechas.
Separador decimal.
Porcentaje general aplicable.
Número máximo de registros.
Nombre de la empresa.
Ejercicio contable activo.
Lista de usuarios autorizados.

Qué valores pueden cambiar

El cliente debe indicar qué parámetros podrían modificarse en el futuro. Si una ruta, un porcentaje o un código cambia con frecuencia, conviene permitir su edición desde una hoja de configuración o un formulario.

Si un valor será permanente y no debe alterarse, puede quedar protegido o gestionarse internamente por la macro.

Quién puede modificar la configuración

También hay que definir si cualquier usuario puede cambiar los parámetros o si esta función debe reservarse a una persona responsable.

Una configuración demasiado abierta puede provocar errores. Una configuración completamente oculta puede obligar a modificar el código cada vez que cambia una carpeta o un criterio menor. El diseño debe buscar un equilibrio razonable.

Parámetros de ejecución

Los parámetros de ejecución son las opciones que el usuario selecciona cada vez que utiliza la macro. Permiten adaptar una misma herramienta a distintos periodos, clientes, centros de trabajo o tipos de informe.

Pueden incluir:

Fecha inicial y fecha final.
Cliente o proyecto.
Delegación.
Tipo de documento.
Archivo que se procesará.
Carpeta de destino.
Incluir o excluir determinados registros.
Generar un resumen o un informe detallado.
Sobrescribir archivos existentes.
Ejecutar en modo de prueba o definitivo.

Valores obligatorios y opcionales

Debe definirse qué parámetros son imprescindibles y qué valores puede utilizar la macro por defecto. También conviene establecer las validaciones necesarias.

Por ejemplo, una fecha final no debería ser anterior a la inicial, y un código de proyecto debería comprobarse antes de iniciar el procesamiento.

Forma de introducir los parámetros

Los parámetros pueden facilitarse mediante:

Celdas de una hoja de control.
Listas desplegables.
Botones y formularios.
Cuadros de selección de archivos.
Valores tomados del propio documento.

La elección depende del número de opciones, la experiencia de los usuarios y la frecuencia de utilización. Para una macro sencilla, una hoja de control bien diseñada puede ser más fácil de mantener que un formulario complejo.

Entorno técnico de la empresa

Una macro puede comportarse de manera diferente según el entorno en el que se ejecute. Por eso el programador debe conocer las características técnicas de los equipos y del sistema de trabajo.

Versiones de Excel y Microsoft Office

Conviene indicar:

Versión de Excel instalada.
Edición de Microsoft Office.
Arquitectura de 32 o 64 bits.
Uso de Microsoft 365 o licencias perpetuas.
Versiones diferentes entre los distintos usuarios.

Determinadas funciones, controles, bibliotecas o características no están disponibles en todas las versiones. Si la macro debe funcionar en equipos antiguos, esta limitación debe considerarse desde el principio.

Sistema operativo

Debe confirmarse si se utilizará Excel para Windows o Excel para Mac. Una macro desarrollada para Windows puede depender de componentes, rutas o llamadas que no funcionan en macOS.

Ubicación de los archivos

El programador necesita saber si los archivos estarán almacenados en:

El disco local.
Una carpeta compartida de red.
Un servidor de archivos.
OneDrive.
SharePoint.
Una unidad sincronizada.
Un dispositivo externo.

La ubicación influye en las rutas, los permisos, la velocidad y los posibles bloqueos cuando varias personas acceden simultáneamente.

Política de seguridad de macros

La empresa debe comprobar si sus equipos permiten ejecutar macros, si los archivos deben estar firmados digitalmente o si existen restricciones establecidas por el administrador.

Desarrollar una herramienta que después no puede ejecutarse por la política de seguridad de la organización es un problema evitable si esta información se revisa al principio.

Aplicaciones externas

Si la macro debe comunicarse con otros programas, bases de datos o archivos especiales, hay que identificar:

Nombre y versión de la aplicación.
Formato de intercambio disponible.
Método de acceso permitido.
Credenciales y permisos necesarios.
Documentación técnica existente.
Responsable del sistema externo.

Una integración con un ERP, una base de datos o un servicio externo requiere más información que una macro limitada a procesar hojas de cálculo locales.

Volumen de datos y frecuencia de uso

El volumen esperado ayuda a determinar si Excel y VBA son adecuados para el trabajo y qué medidas de rendimiento serán necesarias.

Conviene informar sobre:

Número habitual de filas por archivo.
Número máximo previsto de filas.
Cantidad de columnas.
Número de archivos procesados en cada ejecución.
Tamaño aproximado de los archivos.
Número de hojas de cada libro.
Frecuencia de ejecución diaria, semanal o mensual.
Crecimiento esperado durante los próximos años.

Volumen habitual y volumen máximo

No basta con indicar el promedio. La macro debe poder gestionar los periodos de mayor carga. Un proceso que habitualmente recibe cinco mil filas puede encontrarse al cierre del año con cincuenta mil.

Crecimiento futuro

Si la empresa espera aumentar clientes, operaciones o documentos, conviene facilitar una estimación. Así puede evitarse una solución que funcione hoy pero quede rápidamente superada.

En algunos casos, el análisis del volumen puede revelar que Excel es adecuado para la interfaz o para el informe final, pero no para almacenar y procesar toda la información. La decisión debe tomarse antes de invertir en una macro demasiado limitada.

Usuarios, permisos y forma de utilización

El programador necesita saber quién utilizará la macro y en qué condiciones. Una herramienta para una única persona experta puede diseñarse de forma distinta a otra que utilizarán diez empleados con niveles de experiencia diferentes.

Número y perfil de los usuarios

Conviene describir:

Cuántas personas utilizarán la macro.
Qué conocimientos tienen de Excel.
Si conocen el proceso completo.
Si necesitan instrucciones paso a paso.
Si trabajan en equipos diferentes.
Si utilizarán la herramienta simultáneamente.

Permisos de acceso

Si los archivos contienen información sensible o si determinados usuarios no deben modificar la configuración, hay que definir los permisos necesarios.

Excel permite aplicar ciertas protecciones, pero no debe confundirse la protección de hojas con un sistema completo de control de acceso. Si existen requisitos estrictos de seguridad, quizá sea necesario recurrir a una arquitectura diferente.

Proceso manual alternativo

También conviene saber qué ocurrirá si la macro no puede ejecutarse. En procesos críticos, la empresa debería conservar un procedimiento de contingencia o una forma manual de obtener el resultado.

Posibilidad de escalabilidad

La escalabilidad se refiere a la capacidad de la solución para asumir más datos, más usuarios, más archivos o una mayor frecuencia de ejecución sin tener que rehacerla por completo.

El cliente debería explicar cómo podría crecer el proceso durante los próximos meses o años.

Escalabilidad del volumen

Hay que estimar si aumentarán:

Las filas procesadas.
El número de clientes.
Las delegaciones.
Los archivos de origen.
Las ejecuciones diarias.
Los informes generados.

Si el crecimiento será moderado, una macro Excel bien optimizada puede seguir siendo suficiente. Si se prevén volúmenes muy elevados, procesos concurrentes o almacenamiento histórico masivo, puede ser recomendable separar parte del trabajo en una base de datos o en otra aplicación.

Escalabilidad organizativa

La macro también puede tener que pasar de un único usuario a varias personas. Esto plantea cuestiones como:

Ubicación centralizada de las plantillas.
Distribución de nuevas versiones.
Control de la configuración.
Acceso simultáneo a archivos.
Registro de quién ejecutó cada proceso.
Separación de permisos.

Diseñar para crecer sin sobredimensionar

Preparar una macro para el futuro no significa incorporar desde el primer día todas las funciones imaginables. Sobredimensionar el proyecto puede aumentar el coste y complicar el uso.

La opción más equilibrada suele consistir en diseñar una base ordenada, separar configuración y lógica, evitar dependencias innecesarias y dejar identificados los puntos donde probablemente se producirán ampliaciones.

Posibilidad de ampliar funciones

Muchas macros comienzan resolviendo una necesidad concreta y después incorporan nuevos informes, formatos, cálculos o fuentes de datos. Si existe esa posibilidad, conviene advertirlo desde el principio.

Funciones previstas para fases posteriores

El cliente puede preparar una lista separando:

Funciones obligatorias para la primera versión.
Funciones deseables si el presupuesto lo permite.
Funciones previstas para una fase posterior.
Ideas todavía no definidas.

Esta clasificación evita que todas las posibilidades se conviertan en requisitos inmediatos.

Elementos que probablemente cambiarán

Debe señalarse si es probable que cambien:

Las columnas de entrada.
Los modelos de informe.
Las reglas de cálculo.
Los porcentajes y tarifas.
Los programas externos.
La estructura de carpetas.
Los usuarios responsables.

Conocer estas zonas variables permite diseñarlas de forma más configurable y reducir futuras modificaciones del código.

Compatibilidad con nuevos formatos

Si se prevé recibir archivos de nuevos proveedores o generar informes diferentes para cada cliente, puede ser útil plantear una arquitectura modular. Cada formato puede tratarse mediante una parte diferenciada de la macro en lugar de acumular condiciones desordenadas dentro de un único procedimiento.

Límites razonables de Excel

La posibilidad de ampliación no es ilimitada. Una macro puede crecer hasta convertirse en una aplicación difícil de mantener. Cuando aparecen numerosos usuarios, datos históricos, permisos avanzados, ejecución simultánea o integraciones complejas, conviene evaluar si Excel sigue siendo la herramienta adecuada.

Para entender mejor esta cuestión puede consultarse el análisis sobre las ventajas, los límites y los casos de uso de las macros Excel para empresas.

Pruebas y criterios de aceptación

Antes de comenzar el desarrollo conviene acordar cómo se comprobará que la macro funciona correctamente. Sin criterios de aceptación, el concepto de “terminada” puede variar entre el cliente y el programador.

Resultados de referencia

La empresa debería proporcionar casos para los que ya conoce el resultado correcto. Estos casos sirven para comparar la salida automática con el trabajo manual.

Un conjunto de pruebas puede incluir:

Un caso sencillo.
Un caso habitual.
Un caso con el volumen máximo esperado.
Un caso con datos incorrectos.
Un caso con excepciones conocidas.
Un caso sin registros válidos.

Criterios medibles

Los criterios de aceptación deberían ser concretos. Por ejemplo:

Los totales generados deben coincidir con el informe validado.
La macro debe identificar todas las filas con códigos desconocidos.
No debe modificar el archivo original.
Debe funcionar en las versiones de Excel indicadas.
Debe procesar cincuenta mil filas en menos de cinco minutos.
Debe guardar los archivos con el patrón de nombre acordado.

Responsable de validar

La empresa debe designar a una persona que conozca el proceso y pueda revisar los resultados. La validación no debería recaer exclusivamente en alguien que nunca realiza la tarea.

El programador puede comprobar que el código ejecuta las reglas descritas, pero el cliente debe confirmar que esas reglas representan correctamente la operativa del negocio.

Mantenimiento y responsabilidad sobre los cambios

Una macro Excel no queda aislada del resto de la empresa. Puede verse afectada por cambios en las plantillas, las versiones de Office, las carpetas, los programas de origen o las reglas del negocio.

Por ello conviene hablar del mantenimiento desde el comienzo.

Cambios que pueden afectar a la macro

Nuevas columnas en los archivos de entrada.
Cambio de nombre de las hojas.
Nuevos modelos de salida.
Modificación de fórmulas o criterios.
Migración a otra versión de Office.
Cambio de servidor o estructura de carpetas.
Nuevas políticas de seguridad.
Sustitución del ERP o programa de gestión.

Comunicación de modificaciones

La empresa debería evitar cambiar unilateralmente las plantillas que utiliza la macro sin comprobar antes sus consecuencias. Incluso una modificación aparentemente pequeña, como cambiar un encabezado, puede impedir que el programa identifique una columna.

Entrega del código y soporte

Conviene acordar:

Si se entregará el código fuente.
Si estará protegido.
Qué documentación acompañará a la macro.
Qué periodo de corrección de errores se incluye.
Qué se considera una incidencia y qué se considera una ampliación.
Cómo se solicitarán futuras modificaciones.

Una incidencia se produce cuando la macro no cumple un requisito acordado. Una ampliación aparece cuando se solicita una función, formato o comportamiento que no formaba parte del alcance inicial.

Documentación que conviene entregar al programador

La información puede organizarse en una carpeta de proyecto para facilitar su revisión. No es necesario preparar un documento excesivamente formal, pero sí conviene evitar que los requisitos queden repartidos entre mensajes, llamadas y versiones contradictorias de los archivos.

Una carpeta inicial podría contener:

Descripción del objetivo.
Explicación del proceso actual.
Archivos reales de entrada.
Plantillas vacías de entrada.
Ejemplos de salida correcta.
Tablas auxiliares y correspondencias.
Lista de reglas de cálculo.
Relación de errores conocidos.
Datos sobre versiones de Excel y Windows.
Volumen habitual y máximo.
Lista de usuarios.
Funciones obligatorias y futuras.
Criterios de aceptación.

Controlar las versiones de los documentos

Los archivos deberían identificarse con claridad para evitar que el programador trabaje sobre una plantilla antigua. Puede utilizarse una estructura sencilla de nombres, como:

entrada_clientes_version_2026-07.xlsx
salida_informe_validada_2026-07.xlsx
reglas_proceso_version_03.docx

Cuando se sustituya un documento, conviene señalar expresamente cuál deja de ser válido.

Anonimizar información sensible

Si los archivos contienen datos personales, información financiera o datos confidenciales de clientes, la empresa debería valorar la entrega de copias anonimizadas.

La anonimización debe conservar la estructura y variedad de los datos. Sustituir todo por valores idénticos puede ocultar problemas que solo aparecen con fechas, textos largos, caracteres especiales o importes de distintos tipos.

Errores habituales al explicar el encargo

Entregar un único ejemplo demasiado limpio

Un archivo perfecto no representa necesariamente la realidad. Si después aparecen columnas desplazadas, celdas vacías o formatos diferentes, la macro puede fallar aunque haya superado las pruebas iniciales.

Explicar solo el resultado y no el procedimiento

Mostrar un informe final ayuda, pero el programador también necesita conocer cómo se obtiene cada dato y qué reglas se aplican.

Suponer que las reglas son evidentes

Las reglas internas de una empresa no son universales. Lo que un empleado considera obvio puede depender de años de experiencia y de conocimientos que nunca se han documentado.

Cambiar el formato durante el desarrollo

Modificar repetidamente las plantillas obliga a revisar el código y las pruebas. Algunos cambios son inevitables, pero deben comunicarse, analizarse y valorarse.

No informar sobre el volumen máximo

Una macro probada con cien filas puede comportarse de forma muy diferente con cien mil. El volumen debe conocerse antes de elegir el método de procesamiento.

Confundir una idea futura con un requisito actual

Las posibles ampliaciones deben registrarse, pero no conviene incorporarlas de manera informal al alcance. Separar fases ayuda a controlar presupuesto y complejidad.

No designar a una persona responsable

Si cada usuario transmite reglas diferentes, el programador puede recibir instrucciones contradictorias. La empresa debería nombrar a una persona capaz de consolidar decisiones y validar resultados.

Pedir que la macro decida sin explicar el criterio

Una macro puede aplicar criterios definidos, pero no puede adivinar decisiones empresariales. Cuando una situación exige juicio profesional, debe describirse la regla o mantenerse la intervención humana.

Lista de información para solicitar una macro Excel

Antes de encargar el desarrollo puede utilizarse la siguiente lista de comprobación:

¿Está claro el objetivo empresarial de la macro?
¿Se ha descrito el proceso paso a paso?
¿Se ha definido qué funciones están incluidas?
¿Se ha indicado qué funciones quedan fuera?
¿Se han entregado varias muestras de los archivos de entrada?
¿Se conocen las columnas obligatorias y opcionales?
¿Se han definido los tipos y formatos de los datos?
¿Existe una plantilla o ejemplo correcto de salida?
¿Se han documentado los cálculos y reglas de transformación?
¿Se han explicado las excepciones conocidas?
¿Se ha decidido qué hacer ante datos incorrectos?
¿Se ha indicado el volumen habitual y máximo?
¿Se ha establecido un tiempo máximo de procesamiento?
¿Se conocen las versiones de Excel y del sistema operativo?
¿Se sabe dónde estarán almacenados los archivos?
¿Se han identificado las restricciones de seguridad?
¿Están definidos los parámetros de configuración general?
¿Están definidos los parámetros que elegirá el usuario en cada ejecución?
¿Se conoce el número y perfil de los usuarios?
¿Se ha estimado el crecimiento futuro del proceso?
¿Se han separado las funciones actuales de las posibles ampliaciones?
¿Existen casos de prueba con resultados conocidos?
¿Se han acordado criterios de aceptación?
¿Se ha designado a una persona responsable de validar?
¿Se han acordado las condiciones de mantenimiento y soporte?

No es imprescindible responder por completo a todas las preguntas antes de contactar con un programador. Sin embargo, esta lista ayuda a detectar qué aspectos requieren análisis y permite que las primeras conversaciones sean más productivas.

Conclusión

La calidad de una macro Excel depende en gran medida de la calidad de la información utilizada para definirla. Los ejemplos de entrada y salida, las reglas de cálculo, los casos especiales, los volúmenes de datos y las condiciones de ejecución son elementos esenciales para transformar una necesidad empresarial en una herramienta fiable.

Una pequeña empresa no necesita redactar una especificación informática de cientos de páginas. Sí necesita explicar su proceso con ejemplos reales, diferenciar los requisitos obligatorios de las ideas futuras y contar con una persona que pueda resolver dudas y validar resultados.

La preparación inicial reduce el riesgo de malentendidos, mejora la estimación del proyecto y permite dedicar el tiempo de desarrollo a resolver el problema, en lugar de descubrir continuamente qué debía hacer la macro.

Cuando la información está ordenada, el programador puede valorar mejor si Excel y VBA son adecuados, proponer una arquitectura razonable y crear una solución que no solo funcione con el primer archivo, sino que sea útil en la operativa diaria de la empresa.

Para conocer aplicaciones concretas de este tipo de desarrollo puede consultarse el artículo sobre automatización de Excel para pequeñas empresas y sus ejemplos prácticos.

Preguntas frecuentes

¿Es necesario redactar un documento técnico antes de pedir una macro?

No siempre. En proyectos pequeños puede ser suficiente entregar archivos reales, explicar el procedimiento paso a paso y mostrar el resultado esperado. El programador puede ayudar a convertir esa información en una especificación más ordenada.

¿Cuántos archivos de ejemplo conviene entregar?

Conviene entregar varios archivos que representen tanto el funcionamiento habitual como los casos problemáticos. Un único archivo puede ocultar variaciones de formato, valores vacíos, errores o situaciones poco frecuentes.

¿Debo entregar datos reales de clientes?

No necesariamente. Pueden utilizarse copias anonimizadas, siempre que conserven la misma estructura, variedad y complejidad que los datos reales.

¿Qué ocurre si todavía no están claras todas las reglas?

Las reglas pendientes deben identificarse antes de programar la parte afectada. Puede desarrollarse primero un prototipo o una fase limitada, pero no conviene ocultar las decisiones no resueltas mediante suposiciones.

¿Por qué el programador necesita conocer el número máximo de filas?

Porque el volumen influye en el rendimiento y en la forma de programar. Un método adecuado para unos cientos de filas puede ser demasiado lento para procesar decenas o cientos de miles.

¿Es importante indicar la versión de Excel?

Sí. Algunas funciones, bibliotecas y características pueden variar entre versiones, entre instalaciones de 32 y 64 bits y entre Excel para Windows y Excel para Mac.

¿La macro puede adaptarse automáticamente si cambian las columnas?

Puede diseñarse para localizar columnas mediante encabezados y tolerar determinadas variaciones, pero deben definirse los cambios admisibles. No es posible garantizar compatibilidad con cualquier estructura desconocida.

¿Conviene incluir desde el principio todas las funciones futuras?

No. Es mejor definir una primera versión útil y dejar previstas las posibles ampliaciones. Incorporar funciones todavía poco claras puede aumentar el coste y hacer la macro más difícil de utilizar y mantener.

¿Quién debe validar el resultado de la macro?

Una persona de la empresa que conozca bien el proceso y pueda confirmar que los cálculos, filtros, agrupaciones y documentos generados son correctos.

¿Una modificación de la plantilla se considera mantenimiento?

Normalmente sí, porque un cambio en las columnas, hojas, nombres o formatos puede requerir adaptar el código y repetir parte de las pruebas. El alcance concreto dependerá de las condiciones acordadas para el proyecto.