¿ El proyecto de TI estuvo al borde de un abismo ?

Numerosos Proyectos de Tecnologías de la Información tienen problemas delicados que hacen temer por su éxito, llegando “al borde del abismo” y después, con mucho esfuerzo, logran salir adelante.

En las historias narradas en estos textos hay un buen número de proyectos que fueron exitosos, que tuvieron diferentes grados de complejidad, duración y fueron realizados en instituciones de diferente tipo.

Como es lo normal, todas las iniciativas tienen dificultades durante su realización, unas más, otras menos.

Un proyecto de TI que está “al borde del abismo” merece salir adelante.

Estas iniciativas tenían problemas delicados que hacían temer por su éxito y después de lograr superar estos obstáculos, consiguieron los objetivos propuestos.

Este es un resumen de algunos de ellos:

1.Pasaron de las herramientas básicas a un ERP internacional

Este sistema estuvo al borde del abismo porque tenía varios riesgos importantes durante los últimos meses de implementación y finalmente consiguieron los resultados con el alcance, los costos y los tiempos previstos.

Los tiempos planeados eran muy cortos e hicieron desarrollos específicos muy críticos para iniciar el sistema.

Además, hubo dificultades en la implementación de un sistema de Presupuestos de otro proveedor y en la interfase con el ERP .

2. Contrataron el ERP y un desarrollo a la medida

Sin el desarrollo a la medida de este módulo no era posible salir en vivo porque con él se ingresaban los Pedidos de Clientes para entregárselos al ERP y hacer allí los demás pasos del proceso.

El módulo era propio del negocio, lo desarrolló el proveedor y los plazos eran estrechos.

Hubo dificultades para tenerlo disponible al momento de salir en vivo, al inicio del año.

La parametrización del ERP estándar avanzaba bien y paralelamente el contratista elaboraba el módulo de Pedidos pero no había garantía que estuviera terminado para la fecha de salida en vivo lo que finalmente lograron, con buenos resultados.

3. El usuario no le creyó al proyecto

La actitud de los dos usuarios, que eran los jefes de las áreas intervenidas, frente al nuevo sistema no fue la adecuada para utilizar la tecnología que soportaría las necesidades de información del área.

Con el manejo de otros usuarios y de un directivo, el proyecto siguió su curso y logró el objetivo.

4. No usamos bien el ERP actual, cambiémoslo por otro más moderno

La empresa estuvo considerando esta posibilidad porque los usuarios no usaban bien el sistema pero esta no era una razón suficiente para cambiar el ERP sin darle solución a aspectos como los procesos, el entrenamiento de usuarios, la definición e implementación de la información táctica y estratégica, entre otras.

Con frecuencia se cambian las herramientas y esa no es la solución adecuada.

5. Trasladaron el proceso de datos de un Service a sus propios sistemas

Después de casi dos años de preparación de todo lo necesario para iniciar el proceso de datos en sus instalaciones, el proyecto consiguió los objetivos propuestos.

Sin embargo, en primera instancia los directivos le asignaron un presupuesto muy bajo al hardware y software adquirido en esta fase de la implementación y un año después fue necesario cambiarse a otra plataforma más adecuada y reacomodar el software desarrollado a la medida para la entidad.

Este sistema no fracasó porque los directivos hicieron una inversión para cambiar la plataforma.

6. Hicieron un paralelo entre dos sistemas y fue difícil terminarlo

Durante más de dos años usaron un modelo en Excel que la empresa tenía en funcionamiento y, en forma simultánea, un nuevo aplicativo de producción desarrollado a la medida el cual no lograba reemplazar el modelo en Excel porque los usuarios seguían apegados al sistema existente.

Fue difícil superar el paralelo porque el sistema en Excel tenía una buena funcionalidad pero no era corporativo (lo operaba un solo usuario) y ellos no valoraban este aspecto.

Los usuarios tenían unas expectativas más altas de lo que podía resolver la aplicación.

7. Lo perfecto es enemigo de lo bueno

El sistema desarrollado a la medida para la empresa ya tenía una buena versión funcional que se podía usar por el usuario.

La Gerencia pidió incluir una funcionalidad y eso demoró el proyecto seis meses.

Los usuarios pudieron salir en vivo con la primera versión y con más tiempo desarrollar el módulo solicitado por la Gerencia pero no lo hicieron así y el proyecto fue cuestionado y casi se pierde el esfuerzo realizado.

8. Usaron una terminal portátil para la gestión del vendedor

A comienzos de los años 90, un grupo de trabajo de una empresa industrial y comercial estudió la factibilidad de utilizar un equipo portátil para soportar las ventas de los vendedores, compró una terminal portátil, hizo una primera versión del aplicativo, buscó una solución a la impresión portátil y obtuvo el prototipo de la solución.

Luego vino un período de tiempo sin avance por diversos motivos el cual fue superado mediante unas demostraciones a las áreas comerciales, de mercadeo y la Presidencia y estas instancias aprobaron el proyecto y le dieron el impulso necesario para lograr el resultado esperado.

La iniciativa venció la incertidumbre del cambio y los aspectos técnicos.

En general

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