Escribiendo desde la conferencia del Dr. August Scheer en el Instituto de Empresa. El Prof. Scheer es uno de los gurús internacionales de la gestión de procesos (Business Process Management, BPM). Ha empezado comentando como los ERPs, por su orientación, dejaron un hueco importante para la aparición de aplicaciones de gestión de una serie de procesos, como los encargados de la gestión de clientes (CRM) o de la cadena de suministros (SCM) que no estaban previstos en la idea inicial de los ERP, pero que necesitaban integrarse con los mismos. La gestión de procesos arranca, por tanto, de la necesidad de integrar procesos que son alimentados por diferentes herramientas, procesos que cruzan varias plataformas tecnológicas, configurando un problema que aunque tiene, obviamente, una base tecnológica y de integración, se trata en realidad de un proceso managerial, que además debe adaptarse a frecuentes cambios de estrategia de negocio.
Dada esta orientación a procesos y el enorme crecimiento del volumen de datos gestionados por las empresas (en torno al 40% anual), el Profesor prevé enormes procesos de concentración en la industria de las herramientas corporativas. Muchos fabricantes quedarán reducidos a nichos muy pequeños, y el sector se verá reducido a pocos fabricantes, concretamente SAP (el Prof. Scheer forma parte del Consejo de SAP), Microsoft, IBM y Oracle, capaces de plantear una gestión de procesos completa. El tipo de procesos que describe, completamente integrados a través de diferentes herramientas, precisan de definiciones de reglas de negocio en permanente evolución (un rules engine maneja dichas definiciones y las traslada a los diferentes módulos para su operacionalización), con capacidad de adaptación dinámica, un nivel de flexibilidad que excede con mucho lo que un conjunto de herramientas integradas en una arquitectura rígida puede dar. De hecho, ahora lo está entroncando con Sarbanes-Oxley, dado que sólo mediante adecuadas estructuras de gestión de procesos se puede alcanzar el nivel de reporting que la norma de la SEC exige.
La idea del proceso como unidad de análisis me resulta muy interesante, y la de plantear la arquitectura de sistemas como arquitectura de procesos, enormemente provocativa. La de que esto requiera un tipo de herramientas determinadas, la veo menos sólida, con un punto más «comercial». Pero sí puedo entender como un planteamiento de este tipo obtiene mejoras en las empresas en las que se implanta, que contaban en general con una integración de herramientas centrada en el nivel de las herramientas y la tecnología, no en el de los procesos de negocio. Y la idea de ver de un modo tangible y práctico la gestión de procesos horizontales, a través de diferentes departamentos y herramientas en la práctica, tal y como lo contamos en clase en la teoría (el cambio de «business as usual» a la idea de e-Business), me ha gustado mucho.
Ha terminado con un vídeo divertidísimo sobre la historia de su compañía, veré si lo puedo encontrar… Sí, lo acabo de encontrar, pero veo que no les funciona el servidor de streaming. El link, por si lo arreglan, es este.
El caso práctico de Damm, que ha contado su experiencia con la gestión de procesos, ha estado interesantísimo.
El CRM es una de las áreas que más ha crecido de SAP (http://www.sap.com/company/press/press.epx?PressID=4486) e indudablemente sigue de moda.
Aunque discrepo de la idea de que la concentración aporte valor.
Los vendedores se están fagocitando porque no habrá espacio para todos en el futuro cuando la industria termine de madurar y la deslocalización de la producción avance.
Y, por lo menos en España, los megaproyectossuperintegrados de ERP+CRM+SCM+PLM tienen tendencia a acabar en tortazo gordo (véase la evolución de Siebel fuera del sector energía).
Es mejor fomentar proyectos tácticos, que sean ágiles y manejables, pero desde la previsión de una arquitectura que permita hacerlos interoperables para dar sentido a la estrategia de sistemas.
De esto va el city planning y el SOA del que Gartner lleva varios años hablando.
Creo que hay cosas discutibles en lo expuesto por Scheer, como que la gestión por procesos arrancó de tener que hacer cosas como el integrar SCM (1982) y ERP (1990). Supongo que los constructores de la antigüedad gestionarían bien sus procesos constructivos (pirámides, templos, acueductos, etc.). En administración de empresas, hace unos 100 años que Taylor y Fayol escribieron sobre los procesos de gestión en las organizaciones. Los aliados planificaron los suministros del desembarco en Normandía con la ayuda de ordenadores primigenios en 1943, y los ‘ingenieros de la productividad’ de los 50 abrieron camino en España para los especialistas en organización industrial (1964), que han estudiado bien los procesos operacionales de las empresas y sus dependencias (de clientes y proveedores).
Scheer es ‘proveedor’ de SAP desde hace más de 10 años, y siempre lo he visto como un comercial cualificado. Su razonamiento sobre la concentración de fabricantes de herramientas corporativas casa mal con la arquitectura de servicios (SOA) que ahora predican como fervientes conversos (R/3 es supermonolítico). ¿Qué pensarán de la reducción de ‘fabricantes’ Torvalds, Cohen, Mozilla, Six Apart, etc.?
¿No os contó Scheer que SAP no consideró las relaciones con proveedores y clientes en 1988 (diseño migración del R/2 System a la arquitectura C/S) porque los apuntes que necesitaban para el control financiero ‘en tiempo real’ partían de pedido y orden de reposición?. Lo no contabilizable no existía para su aplicación (que entonces no etiquetaban como ERP). Los ‘procesos de negocio’, no obstante, ya eran bien conocidos por los directivos e ingenieros (aunque no los llamasen así porque el libro del BPR que difundieron las consultoras es de 1993).
Por cierto, Malone también explica que el “e-business” es “business as usual”. Scheer, en cualquier caso, creo que hace bien llevando a distinguir entre proceso, relación, gestión, regla y herramienta.