El proyecto llegó a un «callejón sin salida»

Este texto menciona algunos proyectos que fracasaron en el cumplimiento de los objetivos propuestos inicialmente.

El proyecto estaba en un callejón sin salida

Las historias incluidas en este Blog (ver el Sitio Web) ilustran, en detalle, algunos proyectos de mejoramiento de la TI en las organizaciones.

Este aparte del Blog presenta algunas situaciones y problemas presentados en la ejecución de unas iniciativas en las que se tomaron en su momento decisiones que más adelante les trajeron problemas a esas entidades en su avance hacia un modelo de información más adecuado a sus necesidades.

En cada una de ellas hubo diferentes manejos de las situaciones presentadas y obviamente intervinieron numerosos directivos/técnicos/usuarios, con variados criterios, actitudes, experiencias, conocimientos e intereses.

Muchos factores influyeron en las decisiones tomadas, entre ellos el talento humano, las necesidades, el uso de las herramientas, el nivel de inversión, las circunstancias del momento, la disponibilidad y selección de proveedores, la búsqueda y el entendimiento de las soluciones, la convicción para salir adelante y los lógicos aciertos y errores normales en este tipo de iniciativas.

Los proyectos planteados en este aparte tuvieron dificultades y en algunos casos, después de intentar las soluciones, fue necesario cancelarlos y en otros, se requirió replantearlos completamente para reiniciar su ejecución.

Aquí hay un resumen de algunos de ellos:

Se gastaron la plata y no resolvieron la necesidad

Después de estudiar la tecnología a utilizar, un grupo empresarial con necesidades comerciales y de varios tipos de industria, rechazó las posibilidades de usar un software internacional y tampoco analizó las opciones de software que había en el mercado en Colombia.

Inesperadamente, los directivos decidieron enviar dos personas a USA para comprar un aplicativo muy básico que costó solamente $us 20.000.

A este aplicativo le invirtieron varios millones de dólares porque no tenía resueltos muchos de los requerimientos propios de los negocios ni la parte fiscal y contable del país.

Finalmente, después de 5 años de realizar muchos esfuerzos, la empresa implementó un nuevo software ERP que ya era reconocido en el mundo.

Los equipos de trabajo y los directivos deben tener en cuenta todos los requerimientos antes de tomar las decisiones.

Cambiaron el software académico y cancelaron el BPM (1/2)

El software Académico, que estaba en operación, tenía muchas limitaciones y no había forma de cambiarlo debido al alto costo de las muy pocas opciones que había en el mercado y por ello decidieron llevar a cabo un proyecto de Business Process Management – BPM para apoyar y complementar la débil solución Académica.

La digitalización de la información (que estaba en papel) ya iba muy adelante y el modelo estaba prácticamente listo.

Pero surgió un software Académico muy moderno y práctico que resolvió bien una buena parte de las necesidades y entonces cancelaron la implementación del BPM.

Aunque el BPM era avanzado por la falta de madurez de la Universidad, pudieron haber aplazado aplazado y más adelante, retomar el objetivo.

La Universidad necesitaba un sistema BPM. 

¿ Utilizaron la nueva tecnología antes de tiempo ?

Al finalizar el año 2010, una empresa industrial, trasladó el procesamiento de todas sus aplicaciones a la nueva modalidad de hosting (en la nube, cloud computing) que se estaba iniciando en el país.

La organización estudió el proyecto, consideró que ya la tecnología y el servicio estaban maduros y decidió no actualizar sus servidores y más bien trasladó el procesamiento de sus sistemas a los servidores de una entidad especializada.

El nuevo esquema tuvo varios problemas, principalmente por el tiempo de respuesta a los click de los usuarios y fue necesario devolverse al procesamiento de la información en su plataforma propia.

Pruebe las nuevas tecnologías antes de usarlas en su organización.

El Excel fue mal utilizado

La Obra decidió hacer, desde cero, un modelo en Excel para resolver las necesidades de información de la Obra (Almacén, mano de obra, costos y presupuestos).

Este modelo fue mal diseñado e implementado y además, no aprovecharon la posibilidad de utilizar un aplicativo que estaba disponible en otras Obras de la empresa.

Este modelo era sencillo y fácil de implementar.

El Excel es una buena herramienta pero no resuelve algunas necesidades.

Le prometieron una funcionalidad que el sistema no tenía

El proveedor le prometió al cliente la facilidad para que sus puntos de venta pudieran hacer sus procesos en forma independiente del sistema central y, en la noche, realizar una consolidación diaria.

El sistema no podía operar en la forma prometida por el proveedor y por ello hubo serias dificultades entre el cliente, el partner del proveedor en Colombia y la casa matriz en USA.

Por lo anterior, el cliente tuvo que aumentar el presupuesto del costo mensual de la conexión permanente al sistema central y así resolver el problema, asumiendo así el incumplimiento de la promesa del proveedor.

Verifique la funcionalidad antes de firmar los contratos con el proveedor.

Desarrollaron el software y no lo utilizaron

El proyecto del manejo de la información de la construcción de una Represa iba bien en su avance, el desarrollo del software estaba muy avanzado y los resultados que mostraba el sistema en sus comienzos eran razonables.

No obstante, de un momento a otro, el proyecto fue cancelado por una decisión de las gerencias de las empresas del Consorcio.

O sea que, por razones que sólo conocían los directivos, la iniciativa estaba en un «callejón sin salida» y las personas que trabajaban en él no lo sabían.

Antes de desarrollar un software esté seguro que  los directivos lo apoyan en la forma esperada.

Al directivo sólo le interesaba una parte del piloto del software de Producción

Los usuarios y técnicos estaban realizando la primera parte de una implementación completa de la herramienta la cual mostraba buenos resultados.

Sin embargo, el directivo del área quería usar sólo una pequeña parte del sistema y por ello suspendió el avance al montaje de los otros módulos.

Los directivos, los usuarios y los técnicos deben tener claro el alcance antes de iniciar el proyecto. 

Cada una de estas historias está escrita en una forma más detallada en este mismo Blog (ver Historias de Proyectos de TI).