El problema primero, la tecnología después
Desde hace unos tres o cuatro años venimos viendo crecer la tasa de falla de proyectos tecnológicos grandes. Quiero mostrarles un breve análisis de qué identificamos como causantes de estas fallas y qué podemos hacer para disminuir la proporción de falla de la que todos somos parte.
Cuando hablo de falla de proyectos tecnológicos, no hablo de actualizaciones de implementaciones ya en marcha, sino de la adopción de nuevas tecnologías por parte de las empresas.
Después de darle mucha vuelta a la idea de por qué es que fallan estos proyectos, identificamos diferentes niveles de falla.
El primero, y más evidente, es el tecnológico.
El segundo y que tiene tanta o más importancia, es el entendimiento de la problemática por parte de los responsables de la ingeniería y puesta en marcha de la solución.
Fracasos de proyectos por temas tecnológicos
El fracaso de un proyecto desde el punto de vista tecnológico tiene varias aristas dentro de las cuales podemos encontrar:
1. Falta de conocimiento por parte de los miembros de IT o del canal responsable de la puesta en marcha.
2. Falta de experiencia en ese tipo de implementaciones. Pueden tener el conocimiento porque tomaron un entrenamiento, pero no lo hicieron nunca.
3. El producto no se ajusta a las necesidades del negocio o de la problemática específica para el negocio.
4. Falta de compromiso.
Los dos primeros son claros. La falta de capacitación o experiencia al momento de la implementación tiene un peso muy importante y suele hundir a los proyectos.
Estos se resuelven relativamente fácil. Se contrata a un proveedor con experiencia en la implementación tecnológica y suficiente.
Ahora, ¿qué pasa con el tercer caso? Ese donde el producto no se ajusta realmente a las necesidades del negocio o de la problemática a resolver.
¿Cómo se llega a comprar un producto que no se ajusta a lo que necesitamos resolver?
De entrada, si compramos un producto que no se ajusta a lo que necesitamos hacer, es como tener un boleto para subirse al Titanic.
Son muy pocos los casos en que un producto o solución es tan versátil que nos permita torcerlo tanto como para cambiar lo que puede hacer.
La falta de compromiso es algo que estamos viendo cada vez más seguido.
Ya sea porque faltan recursos, sobran regulaciones sindicales, o bien, hay desinterés. El "no estoy capacitado" o el "es un problema de tal" o "ese es un problema de tal producto, no tengo nada que ver", están a la orden del día.
Este último, me preocupa, porque no tiene que ver con algo tecnológico, o una compra mal hecha, es simplemente un tema de actitud, incluso hasta cultural.
El problema es de otro, no mío.
Fracasos de proyectos por temas de problemática
¿Cómo llegamos a seleccionar tal o cual producto para el proyecto que queremos realizar o tecnología que queremos adoptar?
¿Qué evaluaciones se hacen?
En muchos casos, pocas o ninguna. Se lee el brochure, se investiga y se decide la compra tecnológica por medio de una compulsa de precios.
Se que es súper simplificado lo de arriba, pero se entiende la idea.
Sin hacer un anteproyecto consultivo es que vemos que fracasan los proyectos desde el punto de vista del entendimiento de la problemática.
Un proceso bien hecho debería tener un ante-proyecto para definir cuáles son las necesidades del negocio y tecnológicas para lo que se requiere resolver.
El punto de la problemática voy a desarrollarlo un poco más. A simple vista, el fracaso de la mayoría de los proyectos parece tecnológico. No es así.
Un plan de recuperación de desastres no se resuelve comprando tal o cual producto. Primero, se requiere de un análisis de los requerimientos tecnológicos que tenemos que volver a poner en línea, en cuánto tiempo y con qué tolerancia a la pérdida de datos podemos vivir.
La implementación de la estrategia de respaldo y recuperación inicia mucho antes de la compra de la tecnología. Se inicia entendiendo los requerimientos de negocio, de regulaciones que definen períodos de retención y ubicación de la información.
La optimización de costos de IT no se resuelve poniendo un producto para entender cómo estamos gastando. Es una parte, sí, pero antes de comprar, tenemos que definir qué puntos tenemos que atacar para poder hacer una compra inteligente.
Antes, mucho antes, de comprar tecnología, está entender la problemática de lo que queremos resolver.
¿Cuáles son las necesidades del negocio?, ¿a qué tenemos que responder?, ¿qué queremos lograr?
Como dice el título, el problema primero, la tecnología después.
Una vez que entendemos a la perfección las respuestas a esto, recién ahí podemos hacer una compra inteligente.
Si entendemos el problema, compramos tecnología adecuadamente y elegimos un proveedor correcto, la tasa de falla debería ser mucho menor.
Fracaso por falta de adopción
Hay un tercer tipo de fracaso que me gustaría mencionar y es el de la falla por falta de adopción.
Desde el punto de vista tecnológico el proyecto sale bien o simplemente el "producto queda implementado".
Desde el punto de vista de la problemática, puede cumplir con los requerimientos.
Está todo listo y en marcha, pero los usuarios no consumen el servicio. Este queda ahí y con el tiempo se vuelve obsoleto.
Esto se da, sobre todo, en iniciativas de implementación de soluciones nuevas que no son vitales, o donde ya existe otra solución que da servicios.
Hay dos factores que disparan esto. La falta de un sponsor interno que se haga dueño de la solución y sea responsable por su adopción. Y segundo, un proveedor que esté preparado para ir más allá de la puesta en marcha tecnológica.
Sin una persona que tenga a cargo la adopción de la tecnología, y si además el negocio puede seguir funcionando sin esta iniciativa, no vamos a ir muy lejos.
Si el proveedor que va a ser responsable del proyecto solo llega hasta la puesta en marcha y no te puede acompañar por el resto del camino, también es difícil.
Es por esto que la identificación de un sponsor y un proveedor que tenga una visión de la problemática más allá de la tecnológica es clave.
Para resumir, los posibles puntos de falla son o tecnológicos o de problemática. En todos los casos se debería contar con un sponsor interno y con un equipo o proveedor con una visión mucho más amplia que la tecnológica.
En el próximo proyecto que tengas por delante siempre primero el problema, ¡la tecnología viene después!