Fracasos en TI – No gastamos en lo que importa

Aunque 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.

Cuando un BPM es solo un Workflow

De un mini-artículo del Blog de Marcos Milanesio me traigo un concepto que creo que es interesante.

Hoy en día el BPM es un «trending topic» en los negocios. De modo que ante la duda cuando las organizaciones están en el proceso de selección entre una herramienta de worflow y una de  BPM tiende a escoger la segunda porque es «más potente» pero luego implanta un Workflow simplemente. Es como si en vez de contratar un mensajero comprasen un Ferrari y contratasen un chofer. Pero el problema es de enfoque en el proyecto, porque un BPM da más beneficios potencial que un Workflow.

De la lista del artículo de Marcos me quedo con dos puntos: «Los trabajadores toman decisiones» y «Se reducen las verificaciones y los controles» para mi ejemplo. Y estos dos puntos verán como diferencian el resultado de un modo notable.

Vamos a considerar la implantación de un sistema de autorización de viajes en una compañía. Como ejemplo la petición de un viaje para un comercial a una presentación de ventas.

Workflow

Una implantación típica que se puede hacer con una herramienta de Workflow ejecuta más o menos estos pasos:

1. El comercial soliciante solicita un viaje Madrid-Bilbao para el lunes 11 de Octubre.
2. La solicitud llega a la persona responsable de compras que le devuelve los horarios disponibles notificados por la agencia al solicitante.
3. El solicitante del viaje escoge salir a las 7.00 am y volver a las 19:40 de entre la multitud de opciones con un precio de 189 €.
4. Envía la solicitud de aprobación a su responsable.
5. El director comercial comprueba la solicitud y aprueba el viaje porque es un proceso de ventas en una cuenta estrátegica, hay presupuesto disponible y el coste del viaje es reducido.
6. La persona responsable de compras confirma la reserva a la agencia.
7. El solicitante recibe la confirmación.

Nuestro estupendo sistema de Workflow ha facilitado el proceso de gestión, esto es indudable, se podría hacer lo mismo con correos electrónicos pero no tendríamos trazabilidad ni control del estado.

Han intervenido tres personas de la compañía, un externo, se han dado siete pasos que han precisado de 30 minutos de tiempo en total y posiblemente se ha necesitado de cinco a ocho horas entre el primer paso y el último.

BPM

1. El comercial solicita un viaje Madrid-Bilbao para el lunes 11 de Octubre.
2. Conectando a un web-service disponible (Iberia, Amadeus o la agencia de viajes) la aplicación selecciona los viajes disponibles y el precio de cada uno y le comunica (de modo instantaneo) al solicitante sus opciones.
3. El solicitante del viaje escoge salir a las 7.00 am y volver a las 19:40 de entre la multitud de opciones con un precio de 189 €.
4. El BPM accede al sistema financiero y comprueba que el presupuesto de la unidad comercial está dentro de lo establecido, verifica que el comercial no ha solicitado la combinación más cara de las disponibles y además el sistema BPM accede al CRM para comprobar la categoría de la cuenta, dado que es estrátegica autoriza por defecto el viaje  y lo comunica de inmediato al comerical que la reserva se ha realizado.
5. Se envía la petición de reserva por el web-service correspondiente a la agencia, el localizador de viaje se envía al solicitante. En incluye la compra en el ERP.
6. Se envía una notificación diaria de todos los viajes contratados al departamento de compras.
7. Se envía una notificación diaria de todos los viajes de sus comerciales al director comercial.
8. Se actualiza en el CRM la visita comercial.

Podría parecer que no se ha seguido un proceso, pero si lo dibujan completo verán que si, hay un flujo completo de datos y decisiones en este caso. El responsable de compras interviene con la misma capacidad de decisión pero lo hace estableciendo parametros de selección de viajes y negociando acuerdos, no pidiendo precios y horarios Madrid-Bilbao. El director comercial interviene estbleciendo presupuestos y margenes de maniobra, definiendos cuentas estrátegicas y conociendo los planes de viaje. El solicitante ha terminado su solicitud en cinco minutos, solo ha intervenido él en la ejecución del proceso.

Comparen el resultado final, el ahorro de tiempo y la mejora de la eficacia, evidentemente en el caso de que el viaje no se aprueba de modo automático necesitaremos más pasos y se parecerán mucho más los dos casos, pero eso ocurre en el 10% de las peticiones, donde el BPM no aporta mejoras, pero sobre el 90% de las ocurrencias el beneficio es sustancial.

Es importante ver que en la primera implantación se puede hacer sobre una herramienta BPM, y se hace tal cual por desgracia, porque no es la herramienta lo que diferencia el resultado, es lo que hacemos con ella y como llevamos la decisión al punto donde se dispone de los datos para tomarla (el director comercial o el departamento de compras no añaden nada, hacen una verificación automática pero se les obliga a intervenir sin necesidad.

Una pista del resultado.

Un último modo de saber que resultará de la implantación (un workflow o un BPM) es fijarse en el equipo de implantación, si su proveedor le envía un analista de desarrollo y un programador de formularios web apueste porque acabarán implantando un Workflow sobre su Tibco, Webmethods o Ultimus… un equipo de desarrollo hace desarrollos, no optimiza procesos, el perfil del equipo da pistas sólidas sobre el resultado.