Mega Tendencia - Big Data

El barril rebosa. SAP ya no está en condiciones de servir a todas las obras. La innovación es buena y correcta, pero el ritmo temerario de SAP es perturbador. Ahora el "tiempo real" se está vengando.

SAP ha descuidado su deber de atención hacia los clientes existentes en favor de "Run Simple". El resultado son numerosos proyectos que se les están yendo de las manos y que sólo pueden rescatarse con la ayuda intensiva de consultores y socios externos.

Sin citar nombres, hay socios de SAP que han alquilado a SAP la mayoría de sus consultores y programadores.

Hace algún tiempo informé aquí sobre un colega del sector minorista cuyo sistema Hana estuvo parado durante casi diez días: aún no era productivo con él.

Ni siquiera SAP pudo ayudar, solo cuando se trajo a un experto externo en Hana el sistema empezó a volar de nuevo -adivinaste bien, era el socio de SAP que también impulsa a la mundialmente famosa cervecera y que estuvo en el escenario de Sapphire en Madrid en 2011-.

Esta y otras ayudas externas a las obras de SAP han adquirido proporciones tan espectaculares que han dejado su impronta en el balance del primer trimestre de este año.

El Director Financiero, Luka Mucic, ha prometido que se trata de gastos puntuales, pero en Walldorf todo el mundo quedó obviamente sorprendido por la dimensión de la ayuda externa.

No sin regodearse, nuestra mesa de habituales de SAP ha comentado: Ahora SAP también siente lo amargo que es pagar cuotas de mantenimiento por el soporte de la empresa.

No estoy de acuerdo con el director financiero de SAP, Mucic, en que el enorme desembolso financiero para la asistencia externa a los proyectos de SAP pueda localizarse en el primer trimestre de este año. Sólo estamos al principio de un megadesarrollo de datos.

Si 150 sistemas S/4 para clientes nuevos y existentes ya desbordan las capacidades de consultoría de SAP, de modo que hay que recurrir al apoyo masivo de los socios, ¿qué cabe esperar en los próximos años?

En una columna anterior predije que no se cumpliría el plazo de 2025. Debido a los recursos disponibles, el plazo no puede cumplirse, ni por la propia SAP, ni con los socios, ni con los clientes existentes.

La mesa de nuestros habituales puede ser una buena vara de medir: algunos no son reacios al concepto de "Hana & S/4", pero este año y el próximo se caracterizarán por PoCs más pequeñas, después comenzará una fase de evaluación, habrá que disponer de fondos presupuestarios y planificar un cambio de versión para la infraestructura, para Linux, para Hana, para Abap y para el ERP.

Del mismo modo, hay que planificar Mega Data: Celebramos una conferencia interna con los directores de producción, los responsables de CCC, los CDO y los CIO. Uno de los temas fue IoT y cómo gestionar la cantidad de datos. Tenemos fresadoras CNC que suministran hasta dos terabytes de datos al día.

¿Los datos deben transportarse más lejos o permanecer in situ?

¿Puede proporcionar localmente suficiente memoria y potencia de servidor para realizar evaluaciones e interacciones en tiempo real?

Las máquinas CNC modernas son extremadamente rápidas, ¿qué pasa si la línea de datos es demasiado fina y Hana demasiado lento?

Encontramos buenas respuestas a la mayoría de las preguntas, pero al final quedó sin respuesta una cuestión relacionada con los megadatos: si computación local o en la nube, ¿dónde colocar los volúmenes de datos y qué debe, debería, puede archivarse?

Hana es suficientemente rápido para IoT, pero los datos de CNC no pueden almacenarse aquí, ni archivarse en IQ/ASE, porque es demasiado caro en términos de licencias. La propia SAP conoce este reto y ha contentado a la comunidad con Vora, un motor de consulta en memoria.

Vora se basa en el marco de ejecución Apache Spark y permite analizar datos de Hadoop. Por desgracia, ya estamos llegando a los límites de Hadoop, por lo que necesitaremos más alternativas en un futuro próximo. Hadoop en combinación con Hana es excelente, pero IoT es un proyecto de megadatos.

Creo que se reduce a un concepto similar al de la recogida de datos en el centro internacional de investigación Cern. En ningún lugar se generan tantos datos de sensores como en los detectores subterráneos del Cern.

Aquí hay dos retos: cantidad y velocidad.

La capacidad de almacenamiento de los centros informáticos del Cern no es ni de lejos suficiente para la avalancha de datos que se genera en muy poco tiempo. Así que se recurre a un truco teóricamente sencillo: clasificar y olvidar antes de almacenar.

En la práctica, este proceso es extremadamente complejo y solo puede gestionarse con el máximo esfuerzo técnico, pero el principio es convincente y también podría ayudarnos con miles de máquinas CNC. Así que antes de que Hana/Hadoop ponga sus manos en los datos, debería limpiarlos. Me pregunto si alguien en SAP ha pensado en ello.