Si eres un actor involucrado en procesos de compras para el sector público o privado debes hacer tu tarea para obtener el mayor retorno sobre la inversión al momento de comprar software a la media o contratar servicios de desarrollo. Esta debida diligencia requiere de personal con experiencia en la construcción de software, el aseguramiento y el control de la calidad de activos de software. No todas las organizaciones cuentan con el personal, la experiencia y recursos necesarios para realizar una compra inteligente pudiendo fiscalizar efectivamente los productos a recibir por los suplidores.
En esta serie de artículos te presento una pequeña guiá para poder diseñar procesos de compra eficientes y efectivos abarcando desde la definición de los términos de referencia hasta la recepción y operación de los activos de software contratados. Este contenido lo presento en tres partes:
- Primera parte
- Objetivos a Corto vs a Largo Plazo
- Factibilidad técnica del proceso de compra
- Segunda parte
- Recepción y mantenimiento de los activos de software
- Arbitraje y asesoría
- Tercera parte
- Realidad latinoamericana y del caribe
Primera Parte
1. Objetivos a Corto vs a Largo Plazo
El primer mito que quiero desmontar es que existan objetivos a corto plazo en torno a los activos de software. En raras ocasiones se estructuran procesos de compra mayores, digamos de siete o más cifras (USD$) para adquirir o construir un activo de software con un tiempo de vida útil muy corto (menor a seis meses). Claro, podemos tener “problemas de presupuesto” en el corto o mediano plazo para contratar servicios de desarrollo de software. Es decir, su organización no puede cubrir los costos de los servicios requeridos aun estando estos aun precio justo o competitivo. En ese escenario nos toca revisar nuestro caso de negocio en especial la factibilidad financiera, pero la solución no debe ser buscar barateras.
Entonces, la posición de sacrificar calidad para obtener tiempos de entrega cortos o un precio por debajo del mercado es un disparo en el pie. todo activo de software debe ser operado y mantenido (actualizaciones y correcciones) en el tiempo y mientras mas rápido, barato y con baja calidad se realiza su primera versión mucho mas alto sera el impacto negativo a futuro.
Cerrando el punto, no hay tal disyuntiva entre objetivos a corto plazo y a largo plazo, mas bien la intención de diferir el gasto y una aceptación implícita o explicita, y casi siempre negligente de los riesgos asociados a la mala calidad de los procesos y productos.
2. Factibilidad Técnica del Proceso de Compra
Si no ha quedado claro, aprovecho estas lineas para enfatizar el concepto: No es posible hacer una compra inteligente de software o servicios de desarrollo basándonos solamente en precio y/o estimaciones sobre duración del proyecto. Debemos poder evaluar la calidad del software tanto interna como externa, además de los procesos utilizados por los equipos de construcción.
No es buena idea comprar un vehículo sin consultar un mecánico. Una obra de ingeniería civil debe ser supervisada de manera meticulosa en su ejecución técnica. Nadie quiere que un suplidor utilice el tipo de hormigón inapropiado o no respete el tiempo de fraguado para entregar ante o reducir los costos.
Entonces las personas y equipos que diseñan los procesos de compra deben contar con los medios para pre-evaluar la supuesta capacidad de los proveedores, pero aun mas importante deben poder medir a intervalos regulares tanto la calidad del proceso y producto de software que están recibiendo. Esto requiere experiencia técnica apropiada y un conjunto de herramientas de soporte. Es decir, el proceso de compra y monitoreo a suplidores de software y servicios de desarrollo a la medida debe ser técnicamente factible.
Muchas empresas e instituciones no cuentan con el personal capacitado para diseñar estos procesos ni servir de fiscalizadores durante la ejecución. Esto no las exime de su debida diligencia. Las alternativas para cubrir estas carencias son dos “hacer” o “comprar”. Hacer significa contratar el talento necesario y darles los recursos apropiados para cumplir esas funciones. Comprar es buscar un tercero que sirva de representante del comprador ante los suplidores.
La estrategia de mitigación clásica para los riesgos asociados a un proceso de compra deficiente como las multas y la obligación de cubrir el tiempo y costo de las “no conformidades” son útiles para casos extremos de incumplimiento, mas no atacan la causa raíz del problema. Los retrasos y la mala calidad del producto terminan impactando negativamente los servicios que se pretenden soportar sobre los activos de software en cuestión. En este contexto, literalmente, es mejor prevenir que reparar.
Para la próxima entrega hablare sobre la recepción de los activos (productos) de software, también, sobre los costos asociados a su mantenimiento y operación en el tiempo. Estos son elementos clave que inciden en el costo total de propiedad y sobre los cuales se debe incidir desde el diseño del proceso de compras.
2 Comments