Las adquisiciones empresariales o institucionales de tecnología de información pueden ser bastante complicadas. Típicamente se deben evaluar tres dimensiones de cada alternativa, costo, calidad y riesgo. Dependiendo si se trata de adquirir hardware, software o servicios (o una combinación, “soluciones”), la evaluación de la calidad y el riesgo de las diferentes alternativas puede ser algo bastante subjetivo. Tal vez por ese motivo, en el sector público es frecuente ver licitaciones que se adjudican por precio, habiendo definido (o, por lo menos intentado) la calidad y el riesgo deseables, dentro de los criterios de admisibilidad.
El costo, podría suponerse, es la variable más sencilla de evaluar, pero es bastante más complejo que el precio del equipo o el costo de las licencias. Hace como veinte años, precisamente alrededor de la discusión del software libre, acuñaron el término “costo total de propiedad” (TCO por sus siglas en inglés), el cual busca calcular todos los costos asociados a una tecnología durante su vida útil.
La vida útil de la tecnología se acorta proporcionalmente a la velocidad de los desarrollos de nuevas tecnologías. En el caso de los equipos, la vida útil se estima actualmente en unos pocos años, y se suele utilizar, para fines comparativos, el número de años que permite la Tributación Directa para su depreciación. Durante la vida útil de un equipo, los costos asociados van desde la electricidad, hasta el mantenimiento (repuestos y reparaciones) y los servicios asociados con la instalación de nuevas versiones de software.
En el caso del software, la vida útil es mucho más discutible ya que el software no se gasta ni se deteriora ( ciertamente no se rompe, cuando un software falla es porque está malo, alguien puso en él instrucciones o parámetros erróneos). En algunos países han reconocido que, en la falta de definición de la vida útil del software radican los enormes problemas que traen los sistemas legados (tecnologías totalmente obsoletas, pero con funcionalidad vigente) y, hasta cierto punto de manera arbitraria, han definido la vida útil de los sistemas de software en 5 o 7 años – por lo general han llegado a ese número calculando en qué momento se torna más caro mantener un software que reemplazarlo–.
Pero antes de llegar al costo de reemplazo, el software atrae costos de soporte y mantenimiento, desde contestar el teléfono al usuario que no entiende como salir de una opción, hasta visitar todos los equipos de una organización para instalar (o reinstalar) nuevas versiones. De ahí, se hace obvio que el software libre no es siempre más barato que el software de programa privativo. Para complicar un poco más el panorama ahora se puede adquirir el software como servicios, en cuyo caso pierde total relevancia si es libre o privativo.
Los servicios tecnológicos, ya sean por tiempo o por producto, son mucho más fáciles de costear, ya que el costo está directamente asociado al servicio y este tiene niveles de calidad que deben cumplirse.
Sin embargo, y a pesar de todo lo que se ha estudiado y documentado este tema, con cierta frecuencia vemos situaciones en las que el costo más importante de todos no se considera. Cuando un sistema (o “solución”) es requerido para aumentar ingresos o para reducir costos (lo cual de alguna manera incluye, o debería incluir, a todos los sistemas), el costo de oportunidad puede ser el más importante, por mucho.
Si bien los casos más sonados suelen ser en el sector público, estoy seguro de que lo mismo ocurre, aunque a otra escala, en el sector privado. Intentar justificar un desarrollo interno, o local, como medida de reducción de costos, que alarga el proyecto muchos años, no tiene ni pies ni cabeza. El costo de no contar, durante 10 años, con sistemas, como el expediente electrónico de salud, o la declaración y cobro de impuestos en línea, es muchas veces mayor que el costo de comprar e instalar cualquier sistema.
El argumento de evitar dependencia de proveedores tampoco tiene asidero, ya que el costo de la dependencia es pequeño comparado con el costo de no tener los sistemas, además, una vez que se cuente con los sistemas se podría justificar el cambio para eliminar la dependencia. Es obvio que hay sistemas, que por su naturaleza y escala, deben implementarse a la mayor brevedad, el software que se utilice, es mucho menos importante que el tiempo que consuma el proyecto. Es imperdonable es que pasen décadas sin los beneficios de los sistemas (en algunos casos cientos de millones de dólares) porque están viendo cómo hacerlo más bonito, o más barato, en una escala muchísimo menor.
Artículo publicado en el periódico La Nación
