El éxito en un proyecto BPM

Este artículo de Gartner publicado en Computing me ha parecido muy interesante, en él comentan siete claves de éxito para el proyecto BPM, estoy de acuerdo básicamente con él pero creo que está enfocado a grandes proyectos BPM en mega-compañías y no es fácil extrapolar esos proyectos al caso de la empresa media española ni para el caso en que se utiliza BPM como tecnología base para un problema concreto. También creo que peca en exceso de “vicios de consultoría”… En realidad creo que Gartner no se refiere a implantaciones de tecnología BPM sino a proyectos de IT con “cambios culturales” donde la gestión por procesos sea el núcleo del cambio. Pero puede aplicarse en una gran parte a los proyectos de tecnología.

Hablemos sobre cada punto:

Alcance limitado

se debe empezar poco a poco. El marco de tiempo debe ser, relativamente, a corto plazo, no más de 60 a 90 días. No debe ser un desafío complejo

Gartner propone empezar con proyectos cortos de 60 a 90 días y que no sean “un desafio complejo”.  De ese modo podremos “obtener el enfoque centrado”, bien, estoy de acuerdo si la empresa es una gran corporación que pretende automatizar más de veinte o treinta procesos, pero si nuestro cliente solo necesita automatizar dos, tres o cuatro procesos inicialmente (como es el caso de muchas empresas) no podemos marear el proyecto con alcances “que no desafien” para aprender, porque podemos matar directamente el proyecto si lo único que logramos es automatizar el procesos de reserva de salas o la petición de vacaciones.

Si creo que esto vale como indicador, si tu proyecto requiere más de 60 o 90 días, entonces empieza por otro más pequeño y aprende. Pero cien o más días son muchos para darte cuenta de un error al inicio, el BPM no debe ser un “segundo proyecto SAP”.

Alto valor

“Sólo una fracción de todos los procesos de negocio es percibida como de alto valor”

Estoy de acuerdo, el BPM como filosofía tiene sentido cuando persigue obtener rendimientos para la compañía porque requiere esfuerzos que no se hacen por beneficios menores, aunque considero que se puede usar la tecnología BPM como “commodity” en algunos casos, volveré sobre esto en futuros artículos.

Claro alineamiento con los objetivos

Vicio de consultor, decir algo que siempre es cierto como muletilla en las claves de éxito, todo debe estar alineado con los objetivos, digo yo, vale, recordarlo no está de más.

La métrica correcta.

“Sólo a través de la medición, las empresas pueden obtener el conocimiento y la credibilidad necesarias”

Ok, medir es mejor que intuir, y se gestiona mejor con datos, pero recuerdo que leí una vez hablando de ITIL un artículo que afirmaba que esto es una falacia, gestionamos al día miles de cosas sin medirlas, la vida es en gran parte algo que no admite métricas.
Si tienes que mejorar un proceso que estás midiendo, obtener las nuevas métricas aportará visibilidad a la mejora, estoy de acuerdo, pero ¿y si no tienes métrica alguna hoy? Puede iniciar un proyecto de medición previo a la mejora, pero eso puede hacerte perder un año muy valioso. Las métricas no suelen ser ni de cerca parecidas a las presunciones de la dirección en general.

Acuerdo de objetivos.

“Todas las partes interesadas en el proceso deben trabajar juntos para decidir cuál es la mejora del rendimiento”

Más métrica y más alineamiento, más vicio de consultor, evidentemente, para todo acto en la empresa, que rememos todos al mismo sitio y todos queramos llegar allí es mejor que tener a dos enemigos dentro. 

Patrocinador de empresarios entusiastas.

No recuerdo un proyecto que impacte en la empresa de un modo considerable que no requiera de un patrocinador dentro de la compañía con entusiasmo, ya sea el traslado a un nuevo edificio, la implantación de un sistema de información, el desarrollo de un nuevo producto, ¿es que algo se puede hacer sin que la dirección lo respalde? Si fuera director general me preocuparía que la empresa pudiera cambiar radicalmente sin mi respaldo.

Participación de los usuarios de negocios.

Este sí es un punto crítico (igualmente repetitivo eso si) pero muy importante, hay proyectos de IT que se pueden implantar sin involucrar a usuarios y ser un éxito, un proyecto BPM desde luego no es ese tipo, los procesos que se implantan tienen miles de particularidades críticas que solo conocen los usuarios de negocio, si no están involucrados las probabilidades de proyectos problemáticos e incluso fracasados son muy elevadas.

Otro día volveré sobre este tema, al que yo (modestamente) querría añadir algunos puntos que pueden ser indicativos.