Open Source: El oro de los necios

Tibco Vs Open SourceUno de esos momentos gloriosos de la pelea entre el mundo del open source y los vendedores de licencias de uso.

El CEO de Tibco SW en una entrevista donde estaba glorificando la importancia de las interfaces abiertas (OPEN API) se ha lanzado con las siguientes declaraciones sobre el Open Source:

“Open-source is fool’s gold,” Ranadive said. “You think you are getting something for nothing but you are not.”

Es evidente que si vives de vender licencias no eres un mesías del software libre, pero la afirmación de Ranadive carece de sentido en un mundo donde Apache, Firefox, Android, Linux, MySQL han demostrado que son soluciones potentes tanto para el usuario final, las empresas o incluso los proveedores de tecnología. ¿Qué el SW libre no es la solución adecuada para todos los casos? Si, estoy de acuerdo, sin masa crítica suficiente (en mi opinión) no da fiabilidad, y en entornos críticos solo es viable para vendedores de tecnología o en modelos de suscripción de costes (y condiciones) similares al mundo de licencias privativas.

Pero decir que el SW libre no da nada es absurdo. Creo que algunos proveedores están nerviosos por la presencia de posibles competidores o la presión de los clientes para bajar los costes de soporte.

Tibco ha ingresado 99 millones $ por licencias y 155 millones $ por servicio de soporte y mantenimiento. De modo que para ellos vender la licencia es una parte fundamental, al igual que en el caso del soporte ser el único que proporciona el servicio con su software. Es conocida en el mercado sobre todo por su Enterprise Bus a pesar de su esfuerzo en BPM (lo que podría hacernos pensar que vive aún de las rentas de su base instalada).

Que es SAP Hana

Una de las últimas novedades en el mercado de software de gestión empresarial es la tecnologías que prometen llevar al tiempo real la ejecución de informes y el análisis de la información, de ellas dos de las más comentadas son SAP HANA y Oracle Exadata.

Mientras que el caso de Oracle parece más fácil (en realidad no lo es nada trivial) de comprender asimilándolo a un super servidor de datos se percibe en el mercado cierta incomprensión de que es SAP HANA, puede que el hecho de que la gente espera ver a SAP como un proveedor de soluciones de negocio y no de tecnología sea parte del problema.

Le prometí a una amiga (sin embargo competidora) hacer un breve resumen de que es SAP HANA, así que esta es mi pequeña colaboración.

SAP anuncia Hana como

Technology that allows the processing of massive quantities of real time data in the main memory of the server to provide immediate results from analyses and transactions

Hace tiempo me entrevistaron para colaborar en una empresa que estaba desarrollando un novedoso software, cuando me explicaron en qué consistía mi entrevistador dijo “somos una solución en busca de un problema”. SAP Hana tiene un poco de esto, aunque su aplicación es bastante evidente.

Desde que inicie mi carrera profesional la cantidad de datos que los sistemas de información almacenan no ha dejado de crecer, amparados en la mejora del hardware se pasó de manejar bases de datos de hasta 30Gb, a cientos de gigabytes, a ser común una base de datos de un Terabyte. El apetito por las empresas para manejar más y más datos ha sido continuo, a día de hoy somos adictos a la información, nunca es suficiente la que tenemos y nunca está suficientemente analizada.

Si bien los sistemas ERP o CRM (como SAP All-in-One o Oracle Siebel) manejan con cierta comodidad (hasta un límite) este volumen de información ya que gestionan fragmentos de la misma (los datos de un pedido, el histórico de un cliente) las herramientas de Business Intelligence por su uso de muchas más fuentes de datos y cantidades masivas de los mismos (no miro un cliente, los analizo a todos) se encuentran con limitaciones considerables en el manejo de la misma, de modo que cuando un cliente diseña un proyecto de BI habitualmente debe moverse dentro del mundo de lo posible y no dentro del mundo de sus deseos, intentar analizar masivamente sus cientos de gigabytes de información no es viable por limitaciones del hardware.

En este momento surgen las soluciones in-memory, el problema no es el hardware sino que las aplicaciones que usamos para manejar estos volúmenes de datos son las mismas desde hace 20 años mientras que los sistemas que las ejecutan están a años luz de aquellos servidores.

SAP Hana se puede considerar como un nuevo SW de base de datos (algunos analistas temen por el daño que le produzca a Oracle en este sector, yo creo que es una nueva categoría de producto) que está creado de forma que es capaz de manejar similares cantidades de información en un tiempo hasta 350 veces menor (SAP afirma que baja ejemplos de 77 minutos a 13 segundos).

El cambio potencial de este hecho es para las compañías que manejan o desearían manejar altos volúmenes de información es inmenso. Aunque es cierto que saber usar esa información no será sencillo.

Podemos dejar de trabajar con información agregada o datos históricos (como los clásicos datawarehouse) y analizar la información en tiempo real, incluso podemos analizar la información en tiempo real de 300 modos diferentes en el tiempo que antes lo hacíamos de uno para ver cuál de esos análisis nos dice algo relevante y tomar decisiones.

Un gran centro comercial puede analizar al detalle si las ventas de un producto han bajado porque se ha reducido el consumo (bañadores en otoño) o si se ha reemplazado por otro (una marca de detergente por otra nueva en el mercado) o si es debido a que los usuarios reducen sus gastos (comparando si las compras están reemplazando productos por otros de marca blanca) y hacerlo a nivel de detalle del ticket, incluso del usuario si pueden identificarlo.

Siendo más sencillos SAP Hana convierte en viables todos los informes que un cliente ha pedido en los últimos años que no se utilizan por el tiempo necesario para generarlos.

¿Solo cambian las cosas para los usuarios finales? No, ni mucho menos.

SAP Hana genera cambios en todos los participantes en el “ecosistema SAP”.

  • Los vendedores de hardware tienen una nueva categoría de sistemas que ofertar, además SAP Hana (al igual que Oracle Exadata) son servidores “appliance” dedicados. El cliente necesita nuevos sistemas. Y son grandes.
  • Las empresas de consultoría ven abierta la opción de proponer a los clientes esos proyectos que dejaron aparcados por inviables, con necesidades detectadas, usuarios insatisfechos y una cierta promesa de ROI detrás de ellos (si bien eso depende de que el cliente realmente sepa que quiere y no se lance a obtener información que no le sirve para tomar decisiones mejor o diferentes).
  • Los proveedores de outsourcing tienen un nuevo modo de ofrecerse, SAP Hana se puede proporcionar en modo cloud, dejando el ERP en el cliente, pero además al ser una tecnología nueva, compleja y de alto rendimiento es más fácil que los proveedores puedan dar mejor servicio en su explotación por la complejidad del aprendizaje de la misma.

Evento IBM START.012

image

Sólo IBM puede presumir de que es el año de su aniversario.

Es curioso ver como el que fue paradigma del hardware inicia hablando de la importancia del software sin que suene raro.

ERP “Download and Install”

En un foro de LinkedIn alguien ha preguntado por una recomendación de un ERP para “download and Install”, así, sacarlo de la caja y listo. No lo pedía para contabilidad (después de todo el famoso Contaplus era eso) sino para el proceso completo de fabricación discreta, compras, venta, MRP y por supuesto contabilidad.

Y no era una micropyme buscando una chapuza, el que preguntaba estaba dispuesto a un presupuesto de 50.000 $ que ya empieza a ser un gasto en TI para 5 usuarios considerable.

La mayoría de los que hemos contestado le hemos explicado que “descargar y dar al botón aceptar N veces” era un poco exageradamente díficil. Que debería recurrir a sistemas más o menos parametizables y a servicios de algún proveedor de tecnlogía. Esto no es sorprendente, es lo que habitualmente el mercado proporciona, con servicios de unas pocas semanas o de años.

Lo que me ha sorprendido es que alguien ha afirmado que es posible, y ha dado dos recomendaciones. Desde luego es posible que haya productos tan dirigidos a un caso concreto que pueden ser de muy sencilla implantación, pero desde luego dudo que se lo pueda configurar con facilidad un cliente por si solo.

Algunos ejemplos de problemas al respecto:

  • Regulación de impuestos, ¿en que país fabrica?, ¿importa materiales? ¿a qué países vende? ¿en cuantos países tiene actividad? Un tema tan complejo como la fiscalidad no es evidente, podemos obviarlo si la empresa compra todo en un solo país y vende en ese mismo seleccionando el país de uso, pero es una restricción considerable. Si la casuística es compleja, el cliente no solo necesita conocer el software sino además necesita saber bastante de fiscalidad como para llamarle “out-of-the-box”.
  • Contabilidad de costes, admito que la contabilidad financiera se la podemos dar “preconfigurada” a una Pyme, pero en cualquier caso las empresas deben diseñar su contabilidad de costes, y si alguien quiere un ERP en gran parte es para precisamente esto.
  • Carga de datos iniciales, saldos, clientes, stocks, materia en curso, proveedores, pedidos en curso, activos. Desde luego le puedes dar a un cliente una herramienta de carga, pero hacerle aprender con ensayo y error sin asistencia no es un favor precisamente.
  • Esquema de precios, ¿cómo vende su empresa?, ¿cómo se fijan precios y márgenes?, ¿le vende a todo el mundo en las mismas condiciones? Desde luego, puede definir el precio manualmente en cada pedido, pero llamarle a ese modelo de uso “ERP” es exagerado en mi opinión. Configurar un esquema de precios por sencillo que lo quieras hacer sin ayuda ni formación es infernal.
  • Proceso de fabricación, ¿cuantos pasos tiene su proceso? ¿cuanto material “intermedio”? ¿los consumos son fijos por lote o por cantidad terminada? Hay infinitas combinaciones de proceso productivo, suficientes como para que no se puedan configurar todas por modelos por defecto (además de la dificultad de elegir entre 1.000 opciones la correcta). Pretender que el proceso de fabricación y el MRP de cualquier compañía viene configurado en un software es un engaño.

Desde luego es posible diseñar un ERP con estas funciones orientado a un tipo de compañía concreto que requiera de pocos servicios de puesta en marcha, se puedan hacer en remoto o con asistencia. Pero pretender que un cliente disponga del personal cualificado para realizar un proyecto de puesta en marcha de un ERP o que lo haga sin tenerlo es un pésimo consejo.

A los usuarios de una compañía les cuesta configurar Outlook con un manual con pantallas detalladas, ¿en serio alguien pretende que se configuren un ERP completo con un libro de uso?

Precios confusos

Los precios en el software y el hardware son habitualmente incomprensibles, cada proveedor tiene complejos sistemas de configuración, variables aparentemente irrelevantes que disparan el precio o lo reducen o tablas de descuentos completamente incomprensibles.
Esta es la conversación que todo cliente debería tener con sus proveedores de tecnología.

Disfruten…

El coche de Google y las tres leyes de Asimov

A estas alturas si no han oído hablar del famoso coche de Google es que han estado ocupados, pero por si acaso pueden leer lo que dice Google aquí, pueden leer lo que dice Enrique Dans aquí o la reseña de Barrapunto aquí. De esta última tomo parte de la descripción:

Los coches usan cámaras de video, radares y lidares (medidores de distancia por láser) como sensores, y utilizan los centros de datos de Google para procesar la información en tiempo real. Por ahora el sistema no funciona en calles arbitrarias: un conductor repasó cada trayecto anticipadamente, anotando datos específicos para el coche autoconducido.

El desarrollo parece una maravilla y es un gran avance, aunque no es tan absolutamente novedoso porque ya en los noventa existían prototipos de vehículos similares aunque no entre el tráfico. La imagen de la izquierda muestra (en muy mala calidad) el aspecto del coche que se puede ver en un video muy breve en Youtube.

Al parecer Google tomó muchas precauciones y siempre había alguien listo para hacerse con los mandos, y el trayecto estaba más o menos prefijado de modo que no podemos saber cuanto de avanzado es el desarrollo respecto de las posibilidades reales de ponerlo en circulación de un modo comercial yo personalmente creo que al desarrollo le falta todavía mucho que andar, no soy tan entusiasta de pensar que esta década que viene habrá vehículos similares a la venta. Y la próxima tampoco, y hablo de antes de 2030.

Los riesgos y la gestión de la seguridad

Hay un análisis interesante sobre los aspectos de seguridad en el blog Seguridad y Gestión, traigo un extracto de la parte que para mi es más interesante:

¿Estaría dispuesto el fabricante del software a hacerse responsable de los errores de conducción que pudiera tener su software, o a responder de los accidentes que pudiera provocar un fallo de programación?
Las responsabilidades derivadas de fallos en los productos fabricados es algo que ha sido abordado de forma completamente opuesta por los fabricantes de automóviles y por los fabricantes de software.

Desde luego las políticas de calidad de la industria de automoción están a años luz de las políticas de calidad de la industria de software. Quiero decir como autodescargo por los informáticos que también el tiempo de evolución y la complejidad es muy diferente, las situaciones a las que se enfrenta un coche es un universo de posibilidades mucho más reducido (o más sencillo de modelar) que la casuística que sufre una aplicación. Del mismo modo aunque la automoción ha evolucionado mucho, si lo hiciera a la velocidad de la informática los coches consumirían CO2 y expulsarían oxigeno  con un consumo mínimo de energía mientras se mueven flotando en el aire con un suave silbido. 🙂

Las tres leyes

Además de las problemática de la seguridad a la que se refiere el anterior artículo debemos analizar la toma de decisiones de un sistema automático como este. Y siempre (desde 1942) que se habla de “robots” realizando tareas humanas salen a nuestro auxilio las famosas tres leyes de la robótica:

  1. Un robot no debe dañar a un ser humano o, por su inacción, dejar que un ser humano sufra daño.
  2. Un robot debe obedecer las órdenes que le son dadas por un ser humano, excepto si estas órdenes entran en conflicto con la Primera Ley.
  3. Un robot debe proteger su propia existencia, hasta donde esta protección no entre en conflicto con la Primera o la Segunda Ley.

Las situaciones complejas son infinitas:

  • Caso de la primera ley: ¿Cómo decide el sistema si esquiva a un niño que cruza para no provocar una muerte si el precio es chocar con una farola y lesionar a los pasajeros levemente? ¿Cuántos milisegundos tiene para tomar una decisión así de relevante? Los ejemplos en los libros de Asimov de robots bloqueados ante la disyuntiva de elegir entre dos situaciones donde en ambas se lesiona un humano son muy evidentes de la complejidad.
  • Caso de la segunda ley: ¿Cómo decide el robot que no hay seguridad para continuar con las ordenes (recorrido)? Un conductor humano nota la falta de adherencia en la nieve o hielo y para en  la cuneta, pero si ya no conducimos la decisión la debe tomar quién “nota” los mandos, y ese es el coche por si mismo.
  • Caso de la tercera ley: De nuevo el niño que cruza, pero ahora aunque podemos frenar la consecuencia del frenazo es un más que posible choque con otro vehículo, ¿cuanto debe o puede apurar la frenada a riesgo de acercarse al niño, ¿frena en sec0? ¿frena midiendo la distancia al límite? ¿hace sonar el claxón sin frenar? La opción de un coche que es sumamente seguro para los demás a costa de tener continuamente pequeños golpes transitando es poco atractiva.
  • Además de estos casos, tenemos las situaciones de aviso ¿Cuánto debe avanzar la inteligencia artificial para enseñarle que detrás de un balón viene un niño?  ¿qué si alguien se mete dentro del coche lo más probable es que salga de inmediato? ¿Que si un coche se acerca a un sitio para aparcar es muy posible que pare y aparque de repente? Porque conducir es una acción mecánica, lo realmente complejo es la toma de decisiones que no tiene que ver con la conducción.

Es muy posible que en una década podamos hacer un sistema que pilote un Formula 1 mejor que Fernando Alonso, trazando cada vuelta al límite, sin fallos, siendo capaz de adelantar a un doblado e incluso realizando adelantamientos a otro piloto en competición abierta, después de todo ese es un entorno cerrado, definible y donde las habilidades de un sistema automático pueden ser mejores que las humanas, tal como pone Enrique Dans de ejemplo a Deep Blue como ordenador que ha superado a los humanos. Pero es que el ajedrez es al igual que el circuito de un Formula 1  es “matemáticamente modelable” y sin embargo el tráfico real sería como poner a Deep Blue a luchar en una trinchera de la segunda guerra mundial.

Otro tema es que estamos a las puertas de más y mejores sistemas de asistencia a la conducción, que ayuden a un conductor a evitar cierto tipo de colisiones. Pero de ahí a que el coche vaya solo como en “Yo, Robot” o “Minority Report” queda mucho camino por recorrer. Sería una opción si todos los vehículos fueran automáticos y las vías fueran exclusivas, pero no se cambia algo así de la noche a la mañana de modo que el periodo transitorio es la principal barrera.

Cuando un BPM es solo un Workflow

De un mini-artículo del Blog de Marcos Milanesio me traigo un concepto que creo que es interesante.

Hoy en día el BPM es un “trending topic” en los negocios. De modo que ante la duda cuando las organizaciones están en el proceso de selección entre una herramienta de worflow y una de  BPM tiende a escoger la segunda porque es “más potente” pero luego implanta un Workflow simplemente. Es como si en vez de contratar un mensajero comprasen un Ferrari y contratasen un chofer. Pero el problema es de enfoque en el proyecto, porque un BPM da más beneficios potencial que un Workflow.

De la lista del artículo de Marcos me quedo con dos puntos: “Los trabajadores toman decisiones” y “Se reducen las verificaciones y los controles” para mi ejemplo. Y estos dos puntos verán como diferencian el resultado de un modo notable.

Vamos a considerar la implantación de un sistema de autorización de viajes en una compañía. Como ejemplo la petición de un viaje para un comercial a una presentación de ventas.

Workflow

Una implantación típica que se puede hacer con una herramienta de Workflow ejecuta más o menos estos pasos:

  1. El comercial soliciante solicita un viaje Madrid-Bilbao para el lunes 11 de Octubre.
  2. La solicitud llega a la persona responsable de compras que le devuelve los horarios disponibles notificados por la agencia al solicitante.
  3. El solicitante del viaje escoge salir a las 7.00 am y volver a las 19:40 de entre la multitud de opciones con un precio de 189 €.
  4. Envía la solicitud de aprobación a su responsable.
  5. El director comercial comprueba la solicitud y aprueba el viaje porque es un proceso de ventas en una cuenta estrátegica, hay presupuesto disponible y el coste del viaje es reducido.
  6. La persona responsable de compras confirma la reserva a la agencia.
  7. El solicitante recibe la confirmación.

Nuestro estupendo sistema de Workflow ha facilitado el proceso de gestión, esto es indudable, se podría hacer lo mismo con correos electrónicos pero no tendríamos trazabilidad ni control del estado.

Han intervenido tres personas de la compañía, un externo, se han dado siete pasos que han precisado de 30 minutos de tiempo en total y posiblemente se ha necesitado de cinco a ocho horas entre el primer paso y el último.

BPM

  1. El comercial solicita un viaje Madrid-Bilbao para el lunes 11 de Octubre.
  2. Conectando a un web-service disponible (Iberia, Amadeus o la agencia de viajes) la aplicación selecciona los viajes disponibles y el precio de cada uno y le comunica (de modo instantaneo) al solicitante sus opciones.
  3. El solicitante del viaje escoge salir a las 7.00 am y volver a las 19:40 de entre la multitud de opciones con un precio de 189 €.
  4. El BPM accede al sistema financiero y comprueba que el presupuesto de la unidad comercial está dentro de lo establecido, verifica que el comercial no ha solicitado la combinación más cara de las disponibles y además el sistema BPM accede al CRM para comprobar la categoría de la cuenta, dado que es estrátegica autoriza por defecto el viaje  y lo comunica de inmediato al comerical que la reserva se ha realizado.
  5. Se envía la petición de reserva por el web-service correspondiente a la agencia, el localizador de viaje se envía al solicitante. En incluye la compra en el ERP.
  6. Se envía una notificación diaria de todos los viajes contratados al departamento de compras.
  7. Se envía una notificación diaria de todos los viajes de sus comerciales al director comercial.
  8. Se actualiza en el CRM la visita comercial.

Podría parecer que no se ha seguido un proceso, pero si lo dibujan completo verán que si, hay un flujo completo de datos y decisiones en este caso. El responsable de compras interviene con la misma capacidad de decisión pero lo hace estableciendo parametros de selección de viajes y negociando acuerdos, no pidiendo precios y horarios Madrid-Bilbao. El director comercial interviene estbleciendo presupuestos y margenes de maniobra, definiendos cuentas estrátegicas y conociendo los planes de viaje. El solicitante ha terminado su solicitud en cinco minutos, solo ha intervenido él en la ejecución del proceso.

Comparen el resultado final, el ahorro de tiempo y la mejora de la eficacia, evidentemente en el caso de que el viaje no se aprueba de modo automático necesitaremos más pasos y se parecerán mucho más los dos casos, pero eso ocurre en el 10% de las peticiones, donde el BPM no aporta mejoras, pero sobre el 90% de las ocurrencias el beneficio es sustancial.

Es importante ver que en la primera implantación se puede hacer sobre una herramienta BPM, y se hace tal cual por desgracia, porque no es la herramienta lo que diferencia el resultado, es lo que hacemos con ella y como llevamos la decisión al punto donde se dispone de los datos para tomarla (el director comercial o el departamento de compras no añaden nada, hacen una verificación automática pero se les obliga a intervenir sin necesidad.

Una pista del resultado.

Un último modo de saber que resultará de la implantación (un workflow o un BPM) es fijarse en el equipo de implantación, si su proveedor le envía un analista de desarrollo y un programador de formularios web apueste porque acabarán implantando un Workflow sobre su Tibco, Webmethods o Ultimus… un equipo de desarrollo hace desarrollos, no optimiza procesos, el perfil del equipo da pistas sólidas sobre el resultado.