¿El software a medida para la industria es CAPEX u OPEX? ¿Cómo planificar el presupuesto de la inversión?

La cuestión de si el software a medida para la industria debe clasificarse como CAPEX u OPEX ya no es solo un debate contable al final del proceso de compra. Es una decisión que influye en la forma de poner en marcha el proyecto, en el reparto de responsabilidades entre el cliente y el proveedor, y en el coste real de toda la iniciativa. En el entorno industrial, el software deja cada vez más de ser un simple complemento de la máquina o de la línea para convertirse en un elemento de la función operativa, la seguridad, la trazabilidad de auditoría, el mantenimiento y la conformidad. Si la clasificación financiera se adopta demasiado pronto o sin relación con la arquitectura de la solución, el proyecto entra rápidamente en el patrón habitual de pérdidas: el presupuesto encaja formalmente, pero no cubre la integración, la validación, el mantenimiento de versiones, la respuesta a vulnerabilidades ni los cambios necesarios tras la recepción.

En la práctica, esta cuestión debe resolverse en paralelo al diseño de la solución, y no después de elegir al proveedor. La situación es distinta cuando se desarrolla un software inseparable de un activo fijo concreto, de un proceso tecnológico o de una obligación regulatoria, y distinta también cuando lo que se contrata es un servicio de desarrollo y evolución de un sistema que se irá adaptando de forma continua a la producción, la calidad o la ciberseguridad. Esta diferencia determina no solo el presupuesto de inversión y el operativo, sino también quién debe financiar las pruebas de aceptación, la corrección de defectos, las actualizaciones tras cambios en el entorno, el mantenimiento de la conformidad y la respuesta a incidentes. En este punto, el tema enlaza de forma natural con el análisis de riesgos del proyecto: si no está claro qué costes son puntuales y cuáles se repetirán durante todo el ciclo de vida de la solución, el riesgo de plazo y contractual ya está infravalorado.

Un criterio práctico útil es preguntarse cuál es la función empresarial y técnica predominante de ese alcance. Si el objetivo principal es desarrollar un componente identificable de la solución, del que dependen la puesta en marcha del activo, la recepción de la instalación o el cumplimiento de los requisitos del proceso, el argumento para considerar el gasto como inversión suele ser más sólido. En cambio, si la característica principal es la prestación continua de trabajos de desarrollo, administración, mantenimiento o adaptación, el peso se desplaza hacia los costes operativos. Esto no sustituye la evaluación contable y fiscal, pero sí ordena la decisión desde la perspectiva del proyecto. Para el equipo, esto implica desglosar el alcance en un componente de desarrollo, otro de implantación y otro de mantenimiento, y asignar a cada uno indicadores diferenciados: criterios de aceptación, responsabilidad sobre los cambios, tiempo de respuesta, coste de mantenimiento e impacto en la continuidad operativa.

A nivel de ejecución, esto se aprecia con especial claridad en un sistema creado para una línea de producción. El propio módulo de control o la capa de integración pueden tratarse como parte de la inversión, sin la cual no es posible poner en marcha el proceso. Pero la evolución de informes, la gestión de nuevas interfaces, el mantenimiento de la compatibilidad con versiones sucesivas de la infraestructura, las correcciones derivadas de cambios organizativos o la respuesta a nuevos requisitos de seguridad suelen tener un carácter recurrente. Si todo se mete en el mismo saco, el director del proyecto pierde la capacidad de controlar los puntos de frontera: cuándo termina la implantación, cuándo empieza el mantenimiento, qué está sujeto a aceptación y qué debería quedar cubierto por una financiación permanente. Es precisamente aquí donde la función del Project Manager deja de ser administrativa y pasa a ser decisoria: debe asegurarse de que la estructura del alcance, el cronograma y el contrato reflejen el ciclo de vida real del software, y no solo una división presupuestaria cómoda.

Desde el punto de vista de la conformidad, no existe una única respuesta universal, porque la clasificación depende de la finalidad del gasto, de la forma de uso de la solución, de la política contable y de la estructura del contrato. En los proyectos industriales, esto basta para tratar el asunto como un ámbito que requiere una decisión al inicio, y no una corrección a posteriori. Si el software influye en la seguridad del proceso, la trazabilidad de las operaciones, la integridad de los datos de producción o las obligaciones de auditoría, una clasificación financiera errónea se convierte rápidamente en un problema de responsabilidad: no queda claro quién financia las actuaciones necesarias, pero invisibles en la fase de compra. Por eso, ya desde el arranque conviene comprobar una cosa: si en el presupuesto y en el contrato se han separado el coste de desarrollo, el coste de implantación y el coste de mantenimiento durante todo el periodo de uso previsto. Si no es así, el riesgo de incremento de costes y de retraso del proyecto es alto, y el siguiente paso debería ser precisamente un análisis formal de riesgos y una revisión de los errores más frecuentes que elevan el coste y la responsabilidad operativa.

Dónde suelen aumentar con más frecuencia el coste o el riesgo

El mayor incremento de costes en los proyectos de software a medida para la industria rara vez se debe al propio desarrollo. El problema empieza antes: cuando la decisión sobre qué se considera gasto de inversión y qué coste operativo se toma a nivel de partida presupuestaria, sin desglosar el ciclo de vida completo de la solución. Si el CAPEX cubre únicamente «la construcción del sistema» y el OPEX queda sin definir o infravalorado, el proyecto aparentemente encaja en el plan, pero tras la implantación afloran gastos necesarios para utilizar el sistema de forma legal, segura y estable. En la práctica, esto genera tensiones entre finanzas, mantenimiento, automatización industrial, calidad y las personas responsables del cumplimiento, porque cada área da por supuesto un alcance de responsabilidad distinto. Para el equipo del proyecto, el criterio de evaluación debería ser sencillo: si puede identificarse quién financia y aprueba cada actividad necesaria tras la puesta en marcha del sistema, incluidas las correcciones, la validación de cambios, el mantenimiento de las integraciones, las copias de seguridad, el registro de eventos y la recuperación tras un fallo. Si no es así, la clasificación CAPEX/OPEX sigue sin estar cerrada, con independencia de cómo se haya descrito en el plan financiero.

El segundo ámbito de riesgo habitual es un planteamiento erróneo del alcance. En la industria, un sistema a medida casi nunca funciona de forma aislada: interactúa con la máquina, el controlador, la red industrial, el sistema superior, los mecanismos de permisos y el flujo de datos de calidad o de producción. Cada una de esas conexiones genera un coste, pero no todos los costes pueden encajarse del mismo modo en CAPEX y OPEX. Los gastos puntuales suelen verse con claridad, mientras que los costes de los cambios impuestos por el entorno operativo aparecen más tarde: después de las recepciones, al modificar recetas, tras una modernización de la línea, durante una auditoría o después de un incidente operativo. Es precisamente aquí donde el papel del jefe de proyecto deja de ser administrativo y pasa a ser técnico y decisorio: debe velar por que el alcance se defina por la función y la responsabilidad del sistema, y no por una lista de pantallas o módulos. El criterio práctico es el siguiente: si el equipo no sabe describir qué cambios en el entorno industrial activan trabajos en el software y quién responde de ellos, el presupuesto es demasiado optimista y el riesgo de retraso es alto.

Un buen ejemplo es una aplicación de control y supervisión preparada para una línea concreta. En la fase de compra es fácil tratar su desarrollo como una inversión puntual, pero una vez puesta en marcha se comprueba que hacen falta trabajos adicionales relacionados con la gestión de excepciones del proceso, la sincronización con datos de otros sistemas, los cambios de permisos, el ajuste de informes y la reconstrucción de la trazabilidad de las decisiones del operador. Si el sistema influye en la seguridad del proceso o en la trazabilidad de las operaciones, cada una de esas modificaciones no es un «pequeño ajuste de mantenimiento», sino un cambio que requiere evaluación de impacto, pruebas y, no pocas veces, una nueva aprobación. En este punto, el asunto entra ya de lleno en el ámbito de los errores más frecuentes que aumentan el coste y el riesgo del proyecto: la infraestimación de las integraciones, la omisión de escenarios de fallo, la falta de protecciones frente al error del usuario y la suposición de que la recepción pone fin a la responsabilidad del proveedor. En los proyectos de maquinaria, una función similar la cumplen las soluciones que previenen errores en la fase de diseño; en el software, su equivalente es limitar de forma consciente la posibilidad de funcionamiento incorrecto antes de que el sistema llegue a producción.

Desde el punto de vista del cumplimiento y la responsabilidad, la mayoría de los problemas aparecen cuando el contrato y el presupuesto no separan expresamente tres aspectos: el desarrollo de la solución, su implantación en el entorno industrial y el mantenimiento de los cambios durante el periodo de uso. No se trata de una regla contable rígida, porque eso depende de la política contable adoptada y de la finalidad del gasto, sino de trazabilidad operativa. Si el sistema procesa datos relevantes para la calidad, la seguridad, la trazabilidad o la auditoría, no distinguir estas capas dificulta demostrar si el proyecto se planificó correctamente y si los costes posteriores eran previsibles. Por eso, antes de aprobar el presupuesto conviene revisar no solo el valor de la oferta, sino también los indicadores que gobiernan el proyecto: el número de puntos de integración, el número de cambios que requieren pruebas de regresión, el tiempo necesario para restablecer el funcionamiento tras un fallo, el número de componentes dependientes de proveedores externos y el tiempo de respuesta ante un incidente. Son métricas que muestran antes que una hoja de costes si el proyecto es realmente una inversión cerrada o apenas el comienzo de una carga operativa permanente.

Cómo abordar el tema en la práctica

En la práctica, la pregunta de si el software a medida para la industria es un gasto de inversión o un coste operativo debe empezar por otra cuestión: qué compra exactamente la organización y qué estado final quiere alcanzar. Si el objetivo es desarrollar un componente identificable de la solución que, tras la recepción, quedará bajo el control del cliente y se utilizará en el proceso durante un periodo prolongado, normalmente está justificado un enfoque de inversión para una parte de los desembolsos. En cambio, si la esencia del gasto es el mantenimiento continuo del funcionamiento, la corrección de los efectos de los cambios del entorno, la garantía de continuidad del servicio o la respuesta a incidentes, el peso del presupuesto se desplaza hacia el coste operativo. Esta distinción tiene consecuencias directas en el proyecto: de ella dependen la forma de aprobar el presupuesto, el calendario de recepciones, el alcance de la documentación, la responsabilidad sobre los cambios tras la puesta en marcha y si al equipo se le evaluará por entregar un resultado o por garantizar la disponibilidad continua del sistema.

Por eso, en la fase de planificación no conviene preguntar únicamente por el coste de desarrollar la aplicación. Hay que separar el presupuesto en bloques de decisión: una parte correspondiente al desarrollo y la implantación de la solución, y otra destinada a su mantenimiento posterior, evolución y conformidad. El criterio práctico es sencillo: si un gasto genera una nueva funcionalidad verificable o la documentación imprescindible sin la cual el sistema no puede ponerse en servicio, debe evaluarse como parte de la inversión. Si el gasto se refiere a la gestión de cambios tras la recepción, a la adaptación a nuevas versiones de otros sistemas, a la supervisión operativa o al soporte continuo, debe reflejarse como coste operativo. La falta de esta separación casi siempre difumina las responsabilidades. Entonces el proveedor sostiene que el proyecto ha sido entregado, mientras que el usuario final se queda con costes que no se habían contemplado en la justificación de la inversión.

Esto se aprecia claramente en el ejemplo de un sistema que trabaja con una máquina, una base de datos de lotes de producción y un mecanismo de alarmas. La preparación de la lógica del proceso, las interfaces, las pruebas de aceptación y la documentación posterior a la implantación suele poder tratarse como un alcance de suministro cerrado. Sin embargo, mantener la compatibilidad tras un cambio de controlador, adaptarse a una nueva versión de la base de datos, modificar permisos después de una reorganización de la planta o analizar eventos tras un incidente no son el mismo tipo de trabajo. Si todo se mete en una única partida presupuestaria, el proyecto solo parece más barato sobre el papel. En la práctica, aumenta el riesgo de disputas sobre el alcance, se retrasa la recepción y el director del proyecto pierde la posibilidad de gestionar con criterio la reserva para cambios. En este punto, el tema enlaza de forma natural con el papel del Project Manager en el éxito del proyecto: es quien debe velar por que el límite entre el alcance de la inversión y la responsabilidad operativa quede recogido en el cronograma, en las actas de recepción y en las reglas de gestión del cambio.

Desde la perspectiva del manager o del propietario del producto, lo más sensato es aprobar el presupuesto solo después de pasar una breve prueba de decisión. Hay que determinar qué elementos tienen criterios de aceptación inequívocos, cuáles requerirán actualizaciones periódicas, cuáles dependen de proveedores externos y cuáles pueden generar un efecto regulatorio o de calidad tras un cambio. Esto ya no es solo una clasificación del coste, sino un análisis de riesgos completo dentro del proyecto. Si el sistema afecta a la seguridad del proceso, a la trazabilidad de los datos, a la continuidad de la producción o a la capacidad de demostrar la conformidad, cualquier elemento presupuestario insuficientemente definido se convierte en un riesgo del propietario, y no solo en un problema del proveedor. Es precisamente aquí donde aparecen los errores más frecuentes que incrementan el coste y el riesgo del proyecto: una descripción demasiado general del alcance, la ausencia de un presupuesto separado para la validación y las pruebas de regresión, y la suposición de que la integración tras la puesta en marcha será «menor».

Desde el punto de vista formal, no existe una única respuesta universal válida para todas las organizaciones, porque la clasificación depende de la política contable adoptada, del objetivo económico del gasto y del modo de control sobre el resultado de los trabajos. Sin embargo, en el entorno industrial es más importante que la documentación del proyecto y del contrato permita defender la división de costes adoptada. Si el equipo puede demostrar qué fue un desarrollo puntual de un componente de la solución, qué constituyó la puesta en marcha en un entorno concreto y qué es una prestación continua tras la recepción, resulta más fácil gestionar el presupuesto y las responsabilidades. Si no puede hacerlo, CAPEX y OPEX dejan de ser herramientas de planificación y se convierten en una fuente de ajustes, conflictos y retrasos.

Qué tener en cuenta durante la implantación

La mayor trampa en una implantación consiste en que la clasificación del gasto como CAPEX u OPEX suele tratarse como una decisión contable tomada al final, cuando en la práctica viene determinada por la forma en que se diseña todo el proyecto. Si el software a medida para la industria debe presupuestarse con criterio, desde el inicio hay que separar qué forma parte del desarrollo y la puesta en marcha de la solución bajo el control del cliente, y qué sigue siendo un servicio de mantenimiento, evolución u operación tras la recepción. Sin ello, el proyecto pierde muy rápido su capacidad de control: los cambios de alcance empiezan a parecer una «parte natural de la implantación», los costes de pruebas y validación desaparecen en partidas generales, y la responsabilidad sobre la conformidad, la disponibilidad y la seguridad queda diluida entre el proveedor, el integrador y el usuario final. Para el equipo, esto no solo implica el riesgo de superar el presupuesto, sino también el problema de defender el modelo de costes adoptado ante una auditoría interna, el departamento financiero o el propietario del proceso.

En la práctica, lo decisivo no es cómo llamemos a la fase de trabajo, sino si el resultado puede recibirse, describirse y asignarse de forma inequívoca a una función de negocio o técnica concreta. Ese es un buen criterio para evaluar la situación: si puede señalarse un alcance funcional cerrado, unas condiciones de aceptación, un conjunto completo de entregables y el momento en que se transfiere la responsabilidad operativa, resulta más fácil justificar la parte de inversión. Si, por el contrario, el alcance depende de decisiones corrientes de los usuarios, de iteraciones posteriores a la puesta en marcha y del trabajo continuo del proveedor, aumenta la proporción de costes de carácter operativo. Este punto entra muy rápidamente en el ámbito del análisis de riesgos en el proyecto, porque un modelo de responsabilidades insuficientemente definido suele hacerse visible solo cuando se produce una avería, un cambio de requisitos o la recepción. Entonces, la pregunta «¿sigue siendo implantación o ya es mantenimiento?» deja de ser una cuestión semántica y se convierte en una disputa sobre el plazo, el coste y quién debe resolver el problema por su cuenta.

Un buen ejemplo es un sistema que recopila datos de la línea, registra el historial de eventos y transmite la información a los sistemas corporativos de nivel superior de la planta. El propio desarrollo del software y su puesta en marcha sobre la arquitectura acordada puede tener carácter de inversión, pero el ajuste fino de los informes tras varios meses de funcionamiento, la gestión de cambios en interfaces externas o las modificaciones corrientes derivadas de cambios organizativos ya no suelen encajar en esa misma lógica. Si en la fase de contrato y del plan del proyecto no se separaron estas capas, el Project Manager pierde su herramienta básica de control: deja de ser posible medir con fiabilidad las desviaciones presupuestarias, evaluar el impacto de los cambios en el cronograma o asignar un responsable de la decisión. Por eso conviene medir desde el principio no solo el coste total, sino también el coste del cambio tras la aceptación, el número de cambios que afectan a la validación, el tiempo desde la notificación hasta la decisión y la proporción de trabajos no cubiertos por los criterios de aceptación originales. Son indicadores que, incluso antes que la propia factura, muestran que el proyecto empieza a apartarse del modelo de financiación previsto.

Desde el punto de vista formal, también es necesaria cautela porque, en el entorno industrial, el software rara vez funciona de forma aislada. Si influye en los parámetros del proceso, en la integridad de los registros, en la posibilidad de reconstruir los eventos o en las obligaciones de conformidad, la implantación requiere no solo una puesta en marcha técnica, sino también documentar los cambios, las pruebas, los permisos y las reglas de explotación. En estos casos, la frontera entre una decisión presupuestaria y el análisis de riesgos del proyecto se vuelve muy fina: cualquier ahorro conseguido por omitir una fase formal reaparece después como coste de retrasos, nuevas pruebas o ajustes contractuales. No existe una única respuesta válida para todas las organizaciones, porque la forma de imputar los costes depende de la política contable y de la naturaleza real de la prestación, pero la condición para poder defender la decisión es siempre la misma: la documentación técnica, de proyecto y contractual debe mostrar de forma coherente qué se ha desarrollado, cuándo se produjo la aceptación, qué riesgos se asumieron y qué actividades, a partir de ese momento, pasan a ser ya un coste operativo. Allí donde esa frontera no está clara, es donde con más frecuencia empiezan los errores que incrementan el coste y el riesgo del proyecto.