Fracasos en TI – No gastamos en lo que importa

Dinero QuemadoAunque hay una trampa evidente(1) en el cálculo me ha gustado mucho la idea que nos presenta IT Skeptic en este artículo.

Se dice muy habitualmente que la importancia en un proyecto está el 70% en las personas y los procesos y el 30% en la tecnología (los números cambian ligeramente del 80%-20% al 70%-30%).

Sin embargo el gasto en TI no se distribuye siguiendo ni mucho menos esas cantidades, el gasto terriblemente volcado sobre el coste de la tecnología, como se ve en la imagen (tomada de su blog)

Las cantidades no tienen coherencia, si lo importante son las personas y los procesos, ¿no deberían significar la mayor parte de la inversión? pero no es así, gastamos mucho en tecnología y luego se ahorra en los proyectos en la inversión en las personas y en volver a pensar los procesos. Un caso habitual es muy habitual implantar un nuevo ERP (o CRM) y dejar los mismos procesos empresariales exactamente igual que antes, lo que en si mismo puede solventar los problemas derivados de la anterior tecnología (si los tenía) pero no tiene lógica no aprovechar el momento para atacar los procesos que vamos a seguir utilizando.

Yo comparto la idea de que debemos mejorar la distribución de las inversiones, si su empresa comienza un nuevo proyecto de implantación de un sistema de información, revise como ha distribuido su inversión, la tecnología por si sola no soluciona nada salvo en casos muy puntuales.

(1) En mi opinión la trampa es doble, primero confunde valor con precio, la tecnología puede ser más cara que su relevancia en el proyecto, no es un cálculo que se deba establecer solo en dinero. Además de eso, la segunda y mayor trampa es que habitualmente los costes de personal interno de los proyectos se quedan ocultos y no son tenidos en cuenta de un modo correcto. Y de nuevo desvirtua terriblemente esta idea.

Anuncios

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.