La evolución del mercado de aplicaciones empresariales
Durante los años sesenta se comenzó el desarrollo a gran escala de aplicaciones para empresas. En principio eran soluciones de propósito específico que servían a un área funcional concreta de la empresa: contabilidad, fabricación. Fue así como se fueron naciendo los MRP y las suites financieras. Con el paso de los años las corporaciones fueron conscientes de la complejidad que suponía tener integrados varios sistemas y esa así como surgieron los ERP, grandes paquetes de aplicaciones que integraban en una única solución todas las áreas funcionales de la empresa.
Los ERP son por naturalezas modulares y extensibles, lo que permiten incluir desarrollos específicos para adaptarlos a las necesidades de cada compañía. Parecía que los modelos de arquitectura de soluciones de negocio habían alcanzado su cenit. Pero no fue así.
Lo realmente curioso es que el siguiente movimiento fue una involución. Comenzaron a surgir aplicaciones de nicho que cubrían las necesidades muy específicas en determinadas áreas de cada empresa. En cierto modo las aplicaciones CRM fueron las primeras en romper esta brecha. Las ventas son en el área más difícil de estandarizar de una empresa. Los departamentos de ventas están en contacto continuo con el entorno de la empresa. Han de captar rápidamente los cambios y adaptarse al vuelo para poder dar respuesta. Los ERP en cierta medida suponen una burocratización de la empresa y esto no deja crear cierta urticaria en los vendedores, que siempre han visto los sistemas de gestión como unos ladrones de tiempo y una forma de control. Unos ladrones de tiempo que les hacen perder una o dos horas de tiempo al día rellenando partes y unas herramientas de control que intentan fiscalizar su trabajo como si fuera operarios de máquina.
Sea como sea, el surgimiento del CRM evidencia un cierto fracaso en la filosofía del ERP ya que a día de hoy todavía no he conocido un solo paquete que haya conseguido una total integración del área de ventas satisfactoria. En el hueco de esta brecha han ido aflorando aplicaciones como Salesforce, Sugar CRM y un largo etc.. Pero esto sólo fue el principio, otras áreas funcionales les han seguido como el Marketing, la gestión de transportes, los SGA.
Los suites de inteligencia de negocios, disociados del propio ERP también son una muestra más de la incapacidad de estos paquetes transaccionales para dar respuesta a un importante requisito en la empresa actual: la explotación analítica de todos los datos que genera la empresa en sus multiples operaciones.
Las razones de una involución: ¿Quién mucho abarca poco aprieta?
Si la evolución de la tecnología y la gestión en las empresas habían conducido de manera clara a la filosofía de integración del ERP, ¿cómo puede haber tenencias totalmente contrarias en el mercado? Las razones son de los más dispares.
Para comenzar, no hay una fórmula mágica que funcione para todos. Cada empresa es un mundo, incluso compañías que compiten en los mismos mercados tienen modelos de negocio totalmente diferentes. A veces la complejidad y el sobrecoste que genera tener varios sistemas dentro de la empresa se ve compensada por la capacidad operativa y la funcionalidad específica que incorporan-
En segundo lugar debemos, los sistemas ERP son complejísimos y a veces la única manera de integrar muchas áreas funcionales es base de que cada una de ellas renuncie a un poco. El ejemplo más claro lo vemos en las interfaces gráficas. Lo idóneo sería que existiera una interfaz gráfica para cada rol de usuario: gestión de pedidos, colección de deudas, planificación de fabricación, etc.. Lo que en realidad sucede es que con unos pocos elementos comunes se construyen todas las interfaces de usuario, lo que hace que al final todas sean bastante inespecíficas, poco diferenciadas y estén pobremente adaptadas a las necesidades de cada usuario. A la postre la experiencia de usuario tiende a ser muy pobre nicho a pesar de que los fabricantes se están esforzando últimamente por salvar este escollo, algo que no sucede en las aplicaciones de nicho.
Pero existe todavía una razón más de fondo, que hace muy complejo el modelo de desarrollo puesto en práctica por los grandes ERP´s. Este es el funcionamiento a la inversa de la ley de economías de escala en cuanto al desarrollo de software se refiere, o lo que es lo mismo. Las economías de escala no funcionan en absoluto en este negocio.
La programación es principalmente un proceso mental e interno que se traduce en output externo: el código. Para trabajar varios programadores juntos tienen en cierta medida sincronizar sus mentes. Tener una visión clara del proyecto, saber con precisión que tiene que hacer cada uno y establecer una metodología para que el código desarrollado por distintos programadores pueda ser integrado. Además cuando se trabaja en grupos de desarrollo es necesario documentar exhaustivamente el proyecto lo que ralentiza la velocidad de desarrollo de cada programador.
Este fenómeno ya fue notado en los años 70 por Fred Brooks que escribió su mítico libro: “El mítico hombre mes”, donde nos viene a decir que en el desarrollo de software menos es más. Cuanta más gente añadamos a un proyecto que va retrasado más se retrasará.
El problema surge no solamente de la dificultad de coordinar el trabajo tantos programadores debido a la gran cantidad de canales de comunicación que se abren con cada nuevo fichaje. La clave está también en que para que un sistema sea realmente utilizable ha de tener integridad conceptual. Lograr esto en un gran sistema como un ERP no es una tarea imposible pero casi….
Aplicando la lógica descubrimos por tanto que las aplicaciones desarrolladas por equipos pequeños y que se ocupan de cuestiones más específicas siempre estarán más cerca de satisfacer las necesidades de los usuarios. Si cogemos a un equipo de desarrollo que está haciendo un módulo de CRM para un ERP y lo ponemos a desarrollar un CRM como aplicación independiente, seguramente el resultado del último será mucho más satisfactorio. Los programadores tendrán menos restricciones debidas a la necesidad de integrar el módulo con el resto del paquete, mayor libertad a la hora de elegir plataformas tecnologías y un largo etc… Y sobre todo una menor carga burocrática y por tanto una mayor productividad.
Nos encontramos ante un encrucijada por un lado las pequeñas aplicaciones centradas en un área específica de la empresa cumplen mejor con su cometido. Por el otro la acumulación de sistema e islas de datos provoca una complejidad difícil de gestionar y de mantener. Y sobre todo una falta de una visión única en cuanto a la realidad de la empresa.
La respuesta de Oracle: Fusion
A parte de estas tendencias la irrupción de los dispositivos móviles, las tecnologías de búsqueda y el comercio social han trastocado profundamente la forma de hacer negocios con multiples y profundas implicaciones. Por tan sólo citar un ejemplo, la experiencia de usuario que nos han brindado las aplicaciones móviles ha marcado un nuevo estándar en usabilidad y adaptabilidad del software. Esto ha hecho que los usuarios de aplicaciones empresariales tengan una percepción negativa sobre las estas, ya que consideran que las interfaces de usuario son funcionalmente pobres y su diseño está poco cuidado.
De forma paralela ha habido importantes avances en la integración de aplicaciones tipo SOA, web Services e incluso JSON. El middleware o los sistemas encargados de la integración de otros sistemas han experimentado un importante avance en los últimos, Oracle cuenta con un liderazgo claro en este tipo de tecnologías.
En resumen las empresas demandan cada vez más funcionalidad más específica, mejor experiencia de usuario y menores costes de despliegue, mantenimiento y formación. Vamos que lo quieren todo. Para dar respuesta a todos estos retos Oracle ha lanzado su nueva familia de aplicaciones: Fusion