Un estudio de McKinsey en el 2012 encontró que en promedio el 45% de los proyectos grandes de TI exceden su presupuesto y un 7% se retrasa, y entregan 56% menos del valor esperado. Otro 17% resultaron tan mal que la propia existencia de la compañía estuvo amenazada. Los grandes proyectos de ERP son el ejemplo clásico del fracaso de los proyectos TI, con un índice de fracaso de al menos 25%.
Si cree que eso es malo, los proyectos de nube y big data son aún peores. Un desconcertante reporte de CapGemini afirmó que solo el 13% de los proyectos de big data alcanzaron el nivel de producción a escala completa. Solo el 27% de los que respondieron al estudio describieron sus iniciativas de big data como “exitosas”, y solo un 8% las describió como “muy exitosas”.
El analista de Gartner, Tom Bittman, quien encuestó a 140 clientes de Gartner y reportó en una entrada de blog que solo el 5% tuvieron un resultado sin problemas en su despliegue de proyectos de nube. El otro 95% tuvo uno de seis diferentes problemas.
¿Por qué estas compañías están experimentando un índice tan alto de fracasos? Existen varias razones, pero ellas tienen una causa raíz: Las compañías se están involucrando en proyectos de nube y big data porque está de moda, y no se molestan en preguntarse si de hecho los necesitan.
“Comienza en el inicio con un buen caso de negocios”, señaló Bittman. “¿Definió los servicios que se beneficiarían? Ahí es donde la mayoría falla. Segundo, más que tecnología, la nube privada tiene que ver más con la gente y los procesos. Muy frecuentemente las organizaciones dicen ‘Quiero una nube privada, ¿qué compro?’ El hardware es la parte más sencilla. La parte más difícil es el cambio de procesos y de la gente. Así que concéntrese en eso primero. Haga esas dos cosas y enfóquelas correctamente, eso resolverá la vasta mayoría de estos temas.
Gordon Haff, vicepresidente de estrategia de nube en Red Hat, está de acuerdo. “Yo atribuyo una gran cantidad de los fracasos que ocurren en el campo de los proyectos de big data a no tener una meta clara y un camino claro hacia esa meta”, anotó.
“Muchas organizaciones están llevando a cabo proyectos de big data mayormente porque es algo que creen que deberían estar haciendo, inclusive si no saben cómo o por qué. Por supuesto que no van tener éxito”, añadió.
Haff afirmó que le recuerda a la promoción en torno al almacenamiento de datos y fuente abierta en décadas pasadas. “Existe este sentimiento de que con todo los datos que hay, debemos ser capaces de hacer algo con ellos, inclusive si no sabemos las preguntas correctas que hacer o los modelos correctos para aplicar”, dijo.
El primer paso de un proyecto de big data o nube debería ser preguntar, “¿realmente necesitamos esto?” Puede haber varias razones respecto a por qué las compañías no lo hacen: No hay los suficientes datos para justificar un sistema de big data, existe dependencia de sistemas más antiguos como los ERP que no encajan muy bien en la nube, existen regulaciones que requieren mantener los datos on premise, y así por el estilo.
“Los usuarios dicen que van a optar por la nube porque es el próximo paso a tomar cuando no se trata del caso de negocio. Ellos no se están preguntando ‘¿dónde necesito incrementar mi agilidad inclusive más de lo que la virtualización lo hizo y que cargas de trabajo no estoy entregando?’”, señaló Bittman.
Otro problemas
No identificar una necesidad del negocio es una razón para que se produzcan los fracasos de nube y big data. Hay otras razones también. Estas incluyen las coordinaciones poco eficaces entre el lado del negocio y el de la tecnología, lidiar con compartimentos estancos de datos dispersos, una coordinación ineficiente de iniciativas de analítica, falta de un argumento de negocio claro para el financiamiento del big data, y la dependencia de sistemas legacy para procesar y analizar big data, de acuerdo a Jeff Hunter, líder de North American para administración de información de negocios en CapGemini.
Él dijo muchas veces que encuentra clientes que quieren usar big data de una forma, cuando ve que es la mejor opción para rescatar esos compartimentos estancos de datos. “¿Necesitan big data para alimentar la próxima generación de analítica que alimente el paradigma de su negocio? La respuesta puede ser no, pero ¿la pueden usar para la inteligencia de negocio y la toma de decisiones?”, anotó.
Entonces, CapGemini les dice volteen sus prioridades y en lugar de usar big data para crear conjuntos de datos, deben ir en sentido contrario y usarlo para arreglar temas con los datos existente del ERP, CRM y otras fuentes tradicionales de datos que han sido mantenidos en compartimentos estancos y por lo tanto se han mantenido separados.
“Un cliente podrá tener 50 instancias de datos de clientes de todo el mundo en diferentes formatos para aplicaciones distintas. Algunas veces cuando usted resuelve ese tema primero, hace que la conversación sea más significativa y atractiva para el cliente”, señaló Hunter.
Después está la brecha de las habilidades, que ha sido bien documentada. Si los miembros de un equipo que se encuentra detrás de un proyecto de nube o big data no tienen las habilidades requeridas para desplegar el proyecto, puede apostar a que va a fallar.
“Las tecnologías de big data son bastante diferentes a la mayoría de plataformas de datos que la mayoría de personas está acostumbrada a usar”, señaló Yaniv Mor, CEO y cofundador de Xplenty, que hace despliegues de big data para compañías como un despliegue SaaS.
“SQL no resalta en big data pero todos tienen habilidades SQL. Asimismo, son bastante dependientes de tecnologías de código abierto, algo completamente nuevo para un muchacho Microsoft. Entonces, necesita contratar nuevas personas que son caras y difíciles de encontrar, o entrenar a sus empleados”, añadió Mor.
Esto lleva a otro problema. Las empresas frecuentemente ven la nube o el big data como una extensión de las tecnologías existentes. Un proyecto de nube no puede ser simplemente una extensión de su infraestructura de virtualización existente.
Aunque las nubes usan virtualización frecuentemente, requieren de nuevos acercamientos y nuevas tecnologías. La virtualización de empresa e infraestructura nativa de nube están optimizadas para diferentes cargas de trabajo que proveen disponibilidad a través de software, que puede escalar, y que están fundamentalmente basadas en una arquitectura distribuida más dinámica y flexiblemente emparejada. Esto es diferente de la infraestructura tradicional de TI, donde se usa la frase “despliega y no toques”.
Asimismo, la firmas no cambian sus procesos o modelos operativos cuando se mudan a la nube, lo que desencadena el problema antes mencionado. Del 80% al 90% de lo que se despliega en AWS no es contenido nuevo, indicó Bittman. Son cargas escalables horizontalmente que son de vida corta.
“El tiempo de vida promedio de una máquina virtual on premises es de unos pocos años. En la época de las aplicaciones físicas era de una década. Una máquina virtual en Amazon tiene un tiempo de vida de días o semanas”, anotó. El problema es que muchas firmas encienden una máquina virtual en AWS y se olvidan de apagarla cuando han terminado. Usted termina con una factura por los ciclos de inactividad. Él estimó que del 30% al 50% de los costos de uso de máquinas virtuales de nube es desperdicio, porque la gente se olvida de apagar la máquina virtual cuando han acabado o no la están usando.
Qué hacer
Entonces ¿qué deben hacer las compañías para reducir la probabilidad del fracaso? Existen varios pasos que dar y no le costarán mucho, o nada.
“En primer lugar, pregúntese si necesita un proyecto de big data”, señaló Mor. “Con big data, existe tanta promoción que creo que la gente no entiende lo que puede obtener de un proyecto big data, entonces no saben cómo definir las métricas. No saben que es lo que quieren obtener del proyecto”.
El paso siguiente es tener a un líder que pueda crear y dirigir una visión para el proyecto, agregó Hunter. “La visión es más importante que el liderazgo. Puede venir de cualquier nivel. Si hay una visión que claramente articula por qué queremos ir tras el big data y cómo avanzaremos, y siempre y cuando se impregne en la compañía y se acepte, se tendrá más éxito”, expresó.
En tercer lugar, reconozca que existen dos modos básicos para las aplicaciones y las infraestructuras en las empresas típicas: La tradicional y la nube. Tratar de montarse en las dos sin reconocer las diferencias esenciales va a causar problemas.
“Los despliegues de nube deberían concentrarse en las nuevas cargas de trabajo nativas de la nube, mientras que al mismo tiempo deberían conectarse con los servicios clásicos existentes de TI, los flujos de trabajo, y los almacenes de datos y proporcionar administración unificada. No deberían, sin embargo, tratar de ser todas las cosas para todas las aplicaciones”, mencionó Haff.
Y en ese respecto, las organizaciones necesitan darse cuenta de que no hay una sola forma para todo lo que entrega TI. “Llamamos a esto bimodal”, anotó Bittman. “Uno tiene que acostumbrarse a la idea de diferentes arquitecturas on premises y diferentes proveedores off premises. Entonces, en lugar de poner todo en una arquitectura grande, necesitan pensar en administrar fuentes y arquitecturas heterogéneas”.
Asimismo, comience tan pequeño como pueda. No intente resolver todos sus problemas de datos al comenzar un proyecto de big data. “Solo escoja un caso de negocio, asegúrese de que las fuentes de datos se encuentren limitadas a unas cuantas fuentes de datos. Defina exactamente qué es lo que quiere conseguir con este proyecto. Necesita comenzar poco a poco porque cuando piensa en big data, no debería intentar resolver todos los problemas de datos de su organización de una sola vez”, finalizó Mor.
