BPM, ¿Mito o Realidad?
Compartir
Hace años la sigla BPM ya se ha grabado en nuestro vocabulario como sinónimo genérico de procesos, probablemente queriendo referirse a BPMN que es la notación para diagramarlos. Aun así, a pesar de su masificación, no siento que el verdadero sentido de BPM esté entendido por todos quienes hablan de ello, es más, no creo que esté entendido ni siquiera por gran parte de quienes trabajan en áreas de procesos y no es la pretensión de este artículo explicarlo tampoco, sino desmitificar algunos temas.
Es común escuchar que las personas hablan o ponen en su currículum“Conocimientos en BPM”, pero que al intercambiar un par de frases te das cuenta que incluso hablar de “nociones” es ser generoso.
Esta falta de conocimiento de la promesa de BPM ha llevado a cosas buenas y malas, las buenas es que los consultores han ganado bastante dinero, de forma sencilla, vendiendo su interpretación de lo que es BPM y la mala es que se ha generado una gran desilusión en las empresas que lo han adoptado, producto que confiaron en una promesa rimbombante que va dirigida ni más ni menos que a las áreas de negocio y operaciones. Por una parte, se les promete a las áreas estratégicas un mejor Time-to-Market, Gobernance y la más manoseada de todas… “agregar valor”, y por otro lado a las áreas de operaciones se les promete un ahorro significativo de tiempos y esfuerzos en la ejecución de sus proyectos. Es fácil que te crean, porque son anhelos de todas las organizaciones, porque hay mucha literatura que lo ratifica y sobretodo porque las empresas que desarrollan BPMS (Oracle, IBM, RedHat, BizAgi, Pega, Software AG, etc.) tienen muy buenos discursos de venta. Es como la dieta milagrosa a un mes del verano.
¿Cuál es el problema entonces?, el problema es que te contaron el final del libro y no te leyeron el prólogo.
El Prólogo
La realidad de gran parte de las empresas que están interesadas en comenzar a gestionar sus proyectos con BPM es que no poseen un área de procesos o esta es muy joven, no tienen debidamente documentados sus procesos o no tienen definida su plataforma BPMS donde puedan implementar sus proyectos y toman la decisión de hacer todo al mismo tiempo. En este escenario es muy difícil y casi imposible evitar ciertos errores, sobre todo los referentes a las definiciones del proceso, alcance del proyecto, madurez del proceso, inclusión de actores clave y a esto le sumamos una plataforma inestable que debe soportar un desarrollo en constante cambio, lo que es una pesadilla para el área de tecnología. ¿Resultado? amanecidas, discusiones, peleas, despidos y finalmente una solución que no nos soluciona nada y un gran presupuesto a la basura.
Las recomendaciones para evitarlo son de sentido común, pero ya sabemos que este es el menos común de los sentidos a la hora de implementar una transformación fuerte dentro de una empresa. Compartiré a continuación las que encuentro vitales, pero no me las crean a mí, créanle a los que saben: Bernhard Hitpass Heyl, Director Ejecutivo, y Diego Moya, Investigador y Profesor, ambos de BPM Center, recomiendan los siguiente:
1. Identificar el tipo de proyecto BPM que se abordará (BPM Governance, BPM Operacional, gestión del cambio, creación de un área de BPM o instalación y configuración de plataformas).
2. Elaborar y definir el plan de proyecto identificando claramente su alcance, evitando traspasar los límites naturales entre los tipos de proyectos mencionados en el punto anterior.
3. Obtener el apoyo y compromiso de la alta dirección de la organización, permitiendo alinear las distintas unidades y áreas en un esfuerzo transversal.
4. Definir un equipo de trabajo multidisciplinario que involucre transversalmente las áreas funcionales que participan en el proceso que se desee analizar, implementar u optimizar.
5. Identificar lo que se requiere y desea controlar, validando tanto que el modelo de proceso como el conjunto de reportes definidos cubran eficazmente este propósito.
6. Identificar mejoras deseables, pero no urgentes. Con esto se evita incluir retrasos en búsqueda de un proceso ideal; es relevante que toda la organización comprenda que el fin último es la mejora continua, por lo cual no todo se debe ni se puede corregir durante la implementación del proceso.
7. No forzar la adaptación de metodologías tradicionales en ingeniería de software para el control y gestión de etapas del proyecto de implementación sobre la plataforma BPMS.
8. El modelo de procesos es y debe ser el documento principal para comprender el sistema a construir.
9. Evitar mezclar roles de administración de sistemas en los modelos de procesos.
10. Separar las reglas de negocio durante el análisis y el diseño del proceso facilita una correcta implementación.
Pueden encontrar el artículo completo en el siguiente link recomendado!.
Otro punto que vale la pena destacar es que gran parte de la literatura y de las recomendaciones están habladas desde el punto de vista de una organización autovalente que posee todos los recursos dentro de su estructura. A día de hoy esto está extremadamente alejado de la realidad, ya que las empresas externalizan servicios, tanto de procesos como de tecnología y se apoyan en empresas de consultoría en materias específicas y de desarrollo de aplicaciones para implementar los procesos BPM. Aquí surge un nuevo problema. ¿Quién lidera estas iniciativas? Si la respondemos desde la arrogancia de una consultoría de procesos, responderemos que el área de negocios; si la respondemos desde la heroica sacrificada y abnegada área de operaciones, responderemos de TI… y lo más seguro es que en ambas nos equivoquemos.
Ver los procesos sólo desde el punto de vista de negocios nos genera unos hermosos modelos llenos de buenas intenciones, llenos de todo ese valor que queremos agregar, pero que por regla general no se alinean a la estrategia tecnológica de la empresa, son inviables de implementar o de costos muy elevados y el proyecto se entrampa en resolver esos problemas antes que lo que queremos atacar. Por consiguiente, al valor final que agregaste debes quitarle todo el que restaste y da gracias si es que la operación aún es positiva.
En contraparte, verlos sólo como proyectos de tecnología, obtenemos procesos de compleja lectura (generalmente con actividades con nombres crípticos), pero que adolecen de la inclusión de todas las reglas de negocio y que terminan en aplicaciones perfectamente automatizadas que no responden a las verdaderas necesidades de los usuarios.
La solución es hacer caso y fuerte énfasis en la recomendación n°4 que leímos más arriba, y una las mejor manera de conseguirlo es teniendo a la cabeza del equipo al Arquitecto Empresarial, él sabrá a quien subir o no a la mesa y cuando estamos perdiendo el rumbo entre lo bueno, lo excelente y lo realmente necesario. Si una empresa quiere tener éxito en una transformación estratégica y su modelo de trabajo incluye a los proveedores como socios clave, es vital que se cuente con un buen arquitecto empresarial, que tenga el dominio de la estrategia de la empresa, el conocimiento de los procesos y reglas de negocio, junto con una forma clara de proceder con las iniciativas de cambio ya que estas las debe orquestar él.
En resumen (por fin), BPM ¿mito o realidad? es una realidad, el problema es que hay demasiado charlatán pregonando BPM (por una módica suma) sin entender el trasfondo de la disciplina, ni cuál es la forma en que realmente puede ayudar a una empresa, lo tratan de explicar desde distintas formas y adaptarlo a su conocimiento, lo transforma en una cosa y tratan de incorporarlo a su experiencia antes de entender. BPM es una realidad, es útil y la promesa es cierta, pero requiere preparación, constancia, estrategia y paciencia. Los resultados saldrán, pero no por arte de magia. Programar una aplicación en una BPMS NO ES BPM, es sólo ocupar una herramienta. Dibujar en BPMN NO ES BPM, es solo ocupar símbolos para expresar una idea (y que por lo general es muy mal ocupada por los encargados de procesos). BPM involucra un gran cambio en la empresa, es por eso que todos están invitados a participar y el flautista de Hamelin es el Arquitecto Empresarial.