La serie
- 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
Esta serie de artículos esta dirigida a personas involucradas en los procesos de compras de software a la medida o servicios de desarrollo. La primera parte trata sobre los objetivos a tener en cuenta a la hora de confeccionar un proceso de compras y la factibilidad técnica del mismo. La segunda parte trata los elementos a considerar a la hora de recibir, o rechazar, un activo de software creado por un tercero y la necesidad de contar con la ayuda de un arbitro que nos ayude a dirimir diferencias con los suplidores. Finalmente, en esta entrega hablaremos de la realidad del caribe y latinoamericana.
Tercera parte
1. Realidad latinoamericana y del caribe
Coloquialmente los ingenieros de software hablamos utilizamos la frase “coche bomba” para describir una pieza de software (producto, modulo, componente, etc.) la cual se entrega, generalmente rápido, con apariencia de cumplir con todos los atributos de calidad exigidos pero que tiene problemas estructurales los cuales saldrán a la luz cuando se intente modificar o este en operación bajo condiciones de estrés. Es común encontrar este tipo de proyectos, ya sean internos o tercerizados en nuestros países por dos razones clave: negligencia del solicitante o comprador en cuando a su deber de realizar una inspección apropiada de lo que recibe, y por otro lado la corrupción ya sea de instituciones publicas o privadas mediante la cual se favorece al suplidor con el cual se tienen algún acuerdo ilegal sobre los que pueden entregar un producto de mayor calidad.
Comprador negligente
Estoy utilizando la palabra negligente en el sentido de descuidado, es decir un comprador el cual no hizo tu tarea para asegurar que este haciendo una buena inversión. Recordemos que los compradores deben asegurar, en ultima instancia, la obtención del mejor producto tanto a corto, como a largo plazo. Para ello deben seleccionar suplidores capacitados para la tarea y, mas importante aun, tener la capacidad de inspeccionar tanto el interior como el exterior de los productos de software recibidos.
Los compradores que no se preparan para cubrir estas tres bases están destinados al fracaso.
Comprador corrupto
Esta realidad existe en todo el mundo, pero en nuestros países tenemos altos indices de corrupción administrativa tanto en el entorno privado como estatal. Generalmente aquí la persona o grupo de personas que inician los actos ilícitos son los responsables de orquestar los procesos de compra, no necesariamente los dueños de las empresas o el estado como un conglomerado. Esquemas hay muchos, pero los mas comunes son la manipulación de los procesos para favorecer algún suplidor el cual luego pagara con favores y/o dinero al responsable del proceso de compra.
Cuando los bienes o servicios ofrecidos no son tan especializados como el software, auditores sin mucho conocimiento técnico o el publico en general (ámbito estatal) pueden detectar este tipo de practicas ya sea al evaluar los procesos de compra, la calidad y precios de los productos y servicios con relación al mercado. El problema del software es que establecer un valor (precio de producto o costo de servicios), como el grado de calidad calidad depende enteramente del juicio de expertos, excepto la calidad funcional la cual puede ser evaluada por cualquier usuario o agente externo.
Identificando software de mala calidad
Veamos un ejemplo para ilustrar el punto fijando la mirada en productos de software de consumo masivo. Es vox populi que Windows (Microsoft) es un producto de calidad interna inferior a MacOS (Apple) y a Linux, representado por uno de sus “sabores” mas conocido Ubuntu. ¿Cómo se entera el consumidor común, no experto, de este dato? Simple percepción. Casi siempre que Microsoft libera una corrección (fix, patch) para una versión de Windows termina introduciendo muchos otros errores. Uno de los casos recientes mas representativo es la perdida de datos de usuario luego de algún update, como este caso reportado por Forbes: New Windows 10 Update Is Deleting Data For Some Users.
En estos casos el consumidor final percibe, y la experiencia lo valida, que los componentes internos de este software (MS Windows), o la forma en que trabajan los equipos de ingenieros encargados de su mantenimiento, tiene bastante problemas. El riesgo de fallos en la operación es alto, el costo también pues hay que agregar mas personas y puntos de validación a los procesos. Si a esto agregamos el costo de las licencias, Windows termina siendo la peor opción frente a, por ejemplo, Ubuntu que es gratuito.
Total Cost of Ownership (TCO) aka “Coche Bomba”
El problema de fondo es lo costoso que resulta mantener en operación un software de mala calidad. Los reportes de errores se incrementan, es necesario tener equipos numerosos de personas atendiendo los incidentes. Cuando se debe modificar o reparar tarda mas tiempo que si fuera un producto de alta calidad. Al final todo ese tiempo, recursos y personas terminan siendo parte del Costo de Operación del aplicativo. Estos problemas comienzan a salir en el mediano plazo y se agudizan en el largo plazo. Para eso momento probablemente los actores responsables de las irregularidades del proceso de compra original ya estarán fuera de la institución. Efectivamente dejan que les explote el problema a otros en la cara.
Otra vertiente de este esquema es atar al cliente (empresa o institución estatal) a contratos de mantenimiento monopólicos con el suplidor original. Aunque la propiedad intelectual del aplicativo sea del comprador en la practica lo mas factible es que el software sea modificado por quienes lo construyeron pues son los que mas lo conocen. En especial cuando existe poca o ninguna documentación técnica o no se siguieron las buenas practicas de ingeniería de software haciendo el producto difícil de entender, modificar o reparar por un equipo distinto al original. Es como tener un automóvil viejo, con muchos remiendos que solo conoce su mecánico poco ético: la única opción es seguir llevando el auto al mismo técnico siempre que presente un defecto.
Consecuencias para las empresas y dependencias públicas
Al final todo termina en un gasto mayor. En los casos de un comprador negligente pudiéramos tener un gasto menor, relativo al precio de mercado, pero a largo plazo en ambos casos terminaremos erogando mucho mas fruto de la mala calidad del software. Con los compradores corruptos el cuadro es peor. Podemos pagar al precio del mercado, y muchas veces a sobreprecio, el servicio y también terminamos pagando mucho mas largo plazo por no haber elegido el suplidor con mayor capacidad técnica.
Si el lector cree que no es posible que estos temas impactes a empresas privadas y gobiernos enteros veamos algunos ejemplos citados en mi articulo de Catástrofes Causadas por el Código Sucio (Bad Code) y la Mala Gestión de Proyectos:
Problemas causados por baja calidad del código fuente
- Caso 1 – Prisioneros del sistema carcelario de USA liberados antes de tiempo debido a bug en el software: Muchos prisioneros fueron liberados, en promedio, 49 días antes de la fecha real de salida. El problema fue detectado trece (13) años después de su introducción. Ampliar.
- …
- Caso 4 – Hackers revelan graves fallas en transacciones online del Banco de Chile: [estudiantes] “Comprobaron que era posible vulnerar la autorización de una transferencia desde la cuenta de uno de los contactos agregados a la agenda del cliente. Es decir, que con el mismo código con el que se aprueba el ingreso de un nuevo contacto a la agenda de la cuenta, se pueden realizar transacciones.”. Ampliar.
Problemas causados por una mala gestión de proyectos (de software)
- Caso 1 – Sustitución plataforma para gestión de licencias de vehículos de motor en el estado de Minnesota: Duración del proyecto 11+ años; USD$136 millones (Seis mil ochocientos millones de Pesos Dominicanos DOP$6,800 MM). Ampliar.
- …
- Caso 3 – Desastre de TI en el Trustee Savings Bank (TSB) en el Reino Unido (UK): 2,500 años-hombre invertidos en desarrollo del software y 1,000+ personas involucradas en el proyecto; 1.9 millones de clientes no pudieron acceder a su cuenta con la nueva plataforma, 402 personas pudieron ver informaciones de otros clientes durante unos 20 minutos, 44,000 quejas se registraron en solo 10 días. Ampliar.
¿Cómo prevenirlo?
Para no llover sobre mojado, simplemente déjese asesorar para orquestar un buen proceso de compras. El aspecto de la corrupción es una realidad que toca a todas las industrias y las estrategias para mitigarla pueden funcionar igual de bien en casi todas. Sin embargo, por la naturaleza intangible del software y la dependencia en el juicio de expertos para la evaluación de su calidad es importante contar con expertos que le ayuden a saber si lo que esta adquiriendo o recibiendo tiene el nivel de calidad esperada.
Ya sea que los responsables de los procesos de compra tengan las mejores intenciones del mundo, o que transiten las vías de la ilegalidad, la opinión de terceros sin asociaciones conocidas con los oferentes, es primordial para mitigar el riesgo de adquirir un mal producto o trabajar con un mal proveedor.
