Sifco | Riesgos de desarrollar software desde cero para cooperativas y asociaciones solidaristas
15994
post-template-default,single,single-post,postid-15994,single-format-standard,ajax_fade,page_not_loaded,,hide_top_bar_on_mobile_header,qode-child-theme-ver-1.0.0,qode-theme-ver-10.1.2,wpb-js-composer js-comp-ver-5.1,vc_responsive
 

Riesgos de desarrollar software desde cero para cooperativas y asociaciones solidaristas

Riesgos de desarrollar software desde cero para cooperativas y asociaciones solidaristas

Invertir tiempo y esfuerzo en un software desde cero tiene múltiples riesgos. ¿Por qué inventar la rueda si ya hay productos que están funcionando en cooperativas y asociaciones solidaristas?

El software permite realizar procesos en forma ágil y eficiente.  Ingresar empleados, calcular capacidad de pago, consultar información, entre otras actividades,  se efectúan en cuestión de segundos. Ejecutar estos procedimientos manualmente tomaría algunos días, semanas o meses según como este organizada la documentación. Y no queremos dejar esperando por una respuesta a un socio que tenga una emergencia.

La lentitud de los procesos afecta negativamente la  visión que tienen los miembros de las cooperativas de  ahorro y crédito de empleados y asociaciones solidaristas. Es indudable la necesidad de contar con un software de gestión que permita administrar los recursos y dar soluciones oportunas a los asociados.

Para agilizar sus procesos las cooperativas y asociaciones pueden optar por desarrollar software desde cero.  Sin embargo, esta modalidad tiene muchos inconvenientes que pueden evitarse. Los riesgos a los que se enfrentan las organizaciones al contratar un desarrollo de software desde cero son:

1.      Software no cumple con las necesidades de la asociación.

El personal de la asociación debe explicar cuáles son las funciones que debe realizar el software, qué datos se deben almacenar, cómo validar esa información para que sea consistente, cuáles fórmulas de cálculo aplicar, cuáles son las relaciones –interfaces- que debe tener con otras aplicaciones, cuáles reportes y consultas requiere del sistema, etc. Se debe exponer –lo más preciso posible- las necesidades que debe satisfacer el producto.

Dejar sobre entendidas las características del software puede dejar procesos no contemplados y por ende, no desarrollados en el producto final. El  impacto de agregar funcionalidad después de completado el sistema generalmente es muy alto.  

Veamos un ejemplo de la vida real: la confección de un traje. Vamos al sastre con una idea de la prenda que queremos. Si no explicamos cada detalle de la pieza, preferiblemente con un modelo impreso, lo más probable es que el resultado final sea muy distinto al que imaginamos. En ocasiones para modificar un vestido es mejor volver a hacerlo.

2.      No terminar en el tiempo estimado el software.

La cooperativa de  ahorro y crédito de empleados planificó iniciar operaciones para principios de año. Los posibles miembros están deseosos por inscribirse para disfrutar de los beneficios que han mencionado en toda la organización.  Empieza enero, pasa febrero, termina el semestre y aún el sistema no está listo. Otra cooperativa empezó a crecer y comprende la necesidad de automatización para mejorar sus procesos. Pero pasa el tiempo y también sufre la espera por el desarrollo de un software desde cero.

Los analistas de sistemas deben comprender el proceso del negocio. Para ello, el personal de las cooperativas y asociaciones solidaristas deben acompañarlos en todo el desarrollo del software. Debe ser una persona o grupo de personas que conozcan la gestión de la asociación lo que implica atender actividades extras a las rutinarias.

Los proyectos de creación de software pueden verse afectados por muchos factores: especificaciones muy generales, disponibilidad de los especialistas de la cooperativa, cambios en las normas reglamentarias, poco entendimiento del negocio, etc. La planificación del tiempo se queda corta y afecta negativamente la fecha de finalización estimada.

Se requieren muchas horas hombres para desarrollar un software desde cero. Se necesitan completar actividades de análisis, diseño, construcción, pruebas e implementación para tener el sistema listo para usar.

Este riesgo no se minimiza al desarrollarlo dentro de la empresa a la cual pertenece la cooperativa. Incluso puede aumentar su probabilidad de ocurrencia, dado que se subestima el tiempo requerido y la prioridad del proyecto estará después de los procesos medulares de la organización.  

3.      Software con errores e inconsistencia de datos.

El sistema está en funcionamiento en un cien por ciento. Un socio requiere un préstamo y la capacidad de pago mostrada es tres veces mayor al monto real. ¡Qué inconveniente para la salud financiera de la cooperativa!

Para asegurar la funcionalidad de una aplicación se requiere probar exhaustivamente todo el proceso. Es necesario controlar los datos para validar la respuesta del sistema. El primer grupo de usuarios que interactuará con el aplicativo será el pionero que garantice la calidad del software desarrollado a la medida. Adquirir un sistema probado por múltiples cooperativas y asociaciones reduce el riesgo de fallas y errores.

4.      Los usuarios no utilizan el software.

Después de mucho esfuerzo, tiempo y dinero invertido en el desarrollo de un sistema los encargados consideran que no les ayuda en mejorar la productividad de la asociación. Los empleados rechazan por completo utilizar el aplicativo.

Son muchos los factores por los que el personal puede rechazar la solución tecnológica: diseño no acorde a las necesidades, tiempo de respuesta de la aplicación, falta de motivación. La no aceptación de un  software desarrollado es una pérdida de dinero importante para cualquier empresa.

En los proyectos siempre existen riesgos que deben ser gestionados a los fines de minimizar su impacto. Buscar paquetes de software ya desarrollados disminuye los inconvenientes planteados. Una demostración de las funcionalidades del sistema servirá para determinar si cumple con las necesidades de la asociación. Es como medirse un traje sin ningún compromiso. El tiempo requerido para disponer del software será solo lo que se lleve el proceso de instalación y adiestramiento.

En las aplicaciones desarrolladas para gestionar las cooperativas y asociaciones se tomaron en cuenta las mejores prácticas de un conjunto de organizaciones de este tipo. Cuando se construye un software desde cero se diseña según los requerimientos planteados por una sola asociación. La experiencia de todo un grupo siempre será mejor.

Invertir tiempo, esfuerzo y recursos en un software desde cero tiene múltiples riesgos. ¿Por qué inventar la rueda si ya hay productos que están funcionando en cooperativas y asociaciones?, ¿por qué mejor no utilizar aplicaciones probadas por organizaciones que tienen la misma funcionalidad?