Cómo Controlar el Avance de un Proyecto Simple y Eficazmente

Una vez hecha la planificación de un proyecto, normalmente reflejada en una Carta Gantt, e iniciada su ejecución es un factor crítico que ésta se realice conforme, al menos,  a el alcance, calidad, plazos y presupuesto. Más de una vez me han preguntado si la planificación se cumple alguna vez. Y, aquí pasamos a la pregunta ¿Cómo aumentar la probabilidad de éxito de un proyecto?

Primero, existen muchas estadísticas sobre el éxito de los proyectos pero, he seleccionado la The Group Standish [1] por el tamaño de la muestras -50.000 proyectos de distinta envergadura ejecutados el 40% fuera de USA- y por que cubre varios años, como muestra la tabla siguiente:

control-avance-tabla

De aquí surgen dos estrategias: la primera “¿Cómo hacer proyectos exitosos? y, la otro ¿Cómo evitamos que los proyectos fallen?

Segundo, un proyecto exitoso depende del criterio de evaluación y de las expectativas de quién observa el resultado. En este caso establezco que los observadores han acordado los criterios siguientes para establecer el éxito del proyecto:

  • El proyecto se ejecutó en los plazos establecidos en la planificación.
  • El proyecto se ejecutó a un costo igual o menor al establecido en el presupuesto.
  • El proyecto produjo los entregables definidos en el alcance.

Modelo para Medir el Avance de un Proyecto
Para medir estos conceptos mi propuesta se basa en el mecanismo de control gerencial estándar siguiente [2]:

  • Definir un estándar
  • Medir el rendimiento
  • Comparar el estándar con el rendimiento.
  • Evaluar los resultados -comparación- y, si es necesario, tomar acciones.

Por consiguiente tenemos:

  1. Estándar, está es la base con la cual se comparará el rendimiento -avance- y para ello tenemos:

Plazo,  se establecen en la carta Gantt, específicamente en las tareas e hitos.

Entregables, se establecen asociando el entregable a una tarea en la Carta Gantt, es recomendable que sea una tarea correspondiente al nivel más bajo —Sin hijos.

Presupuesto, monto asignado y autorizado al proyecto en el documento Acta de Constitución del Proyecto o Project Charter o documento que autoriza la ejecución del proyecto.

2. Medir,  consiste en la acción de recolectar información sobre el avance, estados y eventos puntuales del proyecto, quién hace ésta es el PMO (Project Manager Officer), si se dispone, o en caso contrario el Gerente de Proyecto. Para ello ocupan:

Carta Gantt para medir los plazos y los entregables.

Información del área contable para medir el presupuesto consumido.

3. Comparar, es observar simultáneamente los valores planificados versus los valores reales -o medidos.

control-avance-formula4. Evaluar, después de comparar se tiene:

Plazo, se evalúan todas las tareas de la carta Gantt en curso o con fecha de término anterior a la fecha de Evaluación.

> 0 => Tarea adelantada.

= 0 => Tarea en el plazo.

< 0 => Tarea atrasada.

Presupuesto, después comparar el valor presupuestado versus el valor informado por Contabilidad se tiene:

> 0 => Gasto mayor al presupuestado

= 0 => Gasto igual al presupuestado (no queda presupuesto)

< 0 => Presupuesto disponible (igual a la diferencia ente el valor presupuestado y el valor real)

La forma más común para de controlar es medir el porcentaje de avance de las tareas especificadas en una Carta Gantt, pero en los proyectos de implementación su efectividad depende de la granularidad de la carta, a mayor nivel de detalle de las tareas es posible obtener una buena aproximación al avance real. Pero, en la práctica las tareas se agrupan por categorías para simplificar la complejidad de administrar la carta, con lo cual llegamos que a mayor simplicidad de la carta menor precisión en el avance.

Control de Avance de Entregables
Para ejemplificar estas ideas, supongamos que en una Gantt se tiene la actividad “Desarrollo Interfaces”.

Gantt Caso 1: Tarea Desarrollo Interfaces

Gantt Caso 2: Tarea Desarrollo Interfaces

  • Interfaz Factura electrónica
  • Interfaz Relojes y Control de Acceso
  • Interfaz Balanzas

Gantt Caso 3: Tarea Desarrollo Interfaces

  • Interfaz Factura electrónica
    • Especificación
    • Diseño
    • Desarrollo
    • Testing
  • Interfaz Relojes y Control de Acceso
  • Interfaz Balanzas

Para el Caso 1 al compararlo con los Casos 2 y 3 es fácil deducir que el Caso 3 nos dará mayor precisión pero, mayor complejidad en la programación y en el control, puesto que existe una cantidad mayor de tareas —mayor granularidad-  y recursos que controlar. Esto porque el caso 3 cada tarea puede estar relacionada con una persona y es posible comprobar que cada una de las tareas de la interfaz corresponden a actividades típicas de desarrollo de software, y que cada una de ellas tiene sus entregables específicos. De este modo introducimos el concepto del “entregable” como evidencia del término de la tarea, en otras palabras tangibilizamos el resultado de la tarea. Nótese que un Entregable corresponderá a una tarea sin hijos.

En mi experiencia para administrar un proyecto con el nivel de detalle de Caso 3, se debe tener que para las tareas sin hijos —Entregables- se aplican las características siguientes:

  • Cada tarea —sin hijos- es asignada a una única persona.
  • Cada tarea —sin hijos- tiene asociado un entregable.

Las alternativas posibles para administrar el proyecto con este nivel de detalle son: un programa administrador de proyecto o una lista jerárquica,  estableciendo una estructura de 4 niveles:

  • Tarea 1,1
    • Tarea 1,2
      • Tarea 1,3
        • Entregable 1,1
        • Entregable 1,2
  • Tarea Nivel n,1
    • Tarea Nivel n,2
      • Tarea Nivel n,3
        • Entregable n,1
        • Entregable n,2

El control se establece indicando el avance sólo para los entregables, de modo que el avance de las Tareas con hijos se calcula en base a los avance de los Entregables.

Reglas para Establecer el Avance
Para los Entregables (tareas sin hijos) se pueden usar distintas reglas [3] para indicar el avance, así se tiene:

  • Regla 50/50 – una vez iniciado, la tarea está marcada como 50% de avance, y el resto se obtuvo en total terminación de los trabajos.
  • Regla 20/80 – se utiliza para realizar un seguimiento de las tareas de mayor valor que toma un tiempo más largo para llegar a su finalización.
  • Regla 0/100 Regla – esta regla indica que el 100 por ciento  de avance se logra cuando la tarea se ha completado. Para cualquier otro estado distinto de completado o terminado el avance es igual a 0%.

Para los proyectos sobre Procesos de Negocios e Implementación de Sistemas Informáticos mi recomendación es ocupar la Regla 0/100. La razón principal es que la información de avance en valores intermedios, distintos de 0% y 100% son muy subjetivos. Por ejemplo, en una tarea correspondiente aun desarrollo de un programa se estableció una duración de 80 horas-hombre. En el último informe de avance se reporta un 80%, esto quiere decir que faltan 36 horas para terminar, o 4 días y medio. Es típico que el programa se entrega con 2 días de atraso, lo que es equivalente a un 5% de las HH consideradas en el plan. Esto ocurre por que los entregables de un proyecto de Implementación son intangibles, excepto la documentación, por ello al usar el avance 0/100 nos aseguramos que la tarea está tangibilizada, tiene una expresión física que podemos constatar. Y, por ende es un valor con más apego a la realidad.

Ejemplo:
La figura siguiente corresponde a un proyecto ejecutado en Coca-Cola Andina y que me tocó en suerte dirigir. Este control de avance está soportado por una aplicación ad-hoc [4] desarrollada en FileMaker.

control-avance-tutor

Aquí se muestra una estructura de control de 4 niveles, en que las tareas que reportan avance son las de nivel 4, las sin hijos. El avance posible de estas tareas nivel 4 es 0% ó 100%, como se puede observar en la figura. Por otra parte, el avance de las tareas con hijos, niveles 1; 2 y 3, es calculado a partir de los avances de las tareas nivel 4.

Referencias
[1] https://www.infoq.com/articles/standish-chaos-2015
[2]MANAGEMENT Third Edition (2012) – M. Hitt, J. Black & L. Porter – Prentice Hall – pág. 390)
[3] https://www.planacademy.com/measuring-project-progress-methods/
[4] http://www.macpro.cl/MacPRO/Proyectos.html

Algunos Puntos Sobre la Aplicación de BPM

Partiendo de la base que BPM [1] es una disciplina del Management y que al área Informática se le asigna la responsabilidad de la actualización de procesos de negocios: “pasar de silos a procesos E2E”. Quiero comentar algunos aspectos que me han llamado la atención en los proyectos de implementación de procesos de negocios que estoy supervisando.

La Limitación del Ámbito Tradicional de la Consultoría Funcional[1].

Un Consultor SAP tiene el entrenamiento y práctica para implementar procesos de negocios desde la perspectiva de un módulo SAP, por ejemplo Fi-CO, HR, SD, etc. Y, la forma estándar que tiene para hacer su proyecto de implementación es la metodología ASAP o alguna de sus múltiples variantes.

Por otra parte, el Consultor SAP con heridas de combate, partirá de alguna Best Practices provista por SAP, la cual podrá bajar a SolMan y eventualmente traspasarla a ARIS [2].

Ahora, si queremos que este Consultor Funcional efectivamente diseñe e implemente procesos de negocios E2E nos encontramos que tenemos que potenciarlo en:

  • Capacidad para modelar procesos de negocios con una herramienta ad-hoc, por ejemplo ARIS.
  • Conocimiento del proceso de negocios E2E en uso en la empresa (as-is).
  • Capacidad de uso efectivo de Best Practices como modelo to-be.
  • Capacidad para hacer análisis de brecha –gap– [3].
  • Capacidad de trabajo en un equipo multidisciplinario.

En mi experiencia, un Consultor Funcional tiene la capacidad y el potencial para incorporar a su bagaje profesional los puntos anteriores, sea con capacitaciones formales o mediante auto-aprendizaje.

Aplicando todas las capacidades antes mencionadas el Consultor Funcional es capaz de generar los modelos, por ejemplo  VAC y EPC, que representan un determinado proceso de negocios. Y, es al revisar en profundidad los modelos en cuestión cuando aparecen las limitaciones del ámbito de acción del Consultor Funcional y del Área Informática.

La revisión del modelo EPC nos lleva a visualizar claramente, al menos 3 dimensiones del proceso de negocios:

  • Organizacional, referida a los roles o estructuras organizativas. Se verifican mediante los símbolos:

  • Procedimental, referida a los procedimientos y reglas de negocios, se verifican con los símbolos:

  • Transaccional, referida a componentes de software y a transacciones, se verifican con los símbolos:

Para cada una de estas dimensiones es necesario hacer el análisis de GAP respectivo, así para la dimensión Organizacional se verificará como se corresponde la organización que hoy soporta al proceso versus la necesaria para el proceso a implementar. Y, aquí el Área Informática puede señalar las diferencias detectadas pero, no puede generar los cambios organizacionales pertinentes.

En el caso de los Procedimientos y Reglas  de Negocios el análisis de brecha establecerá, en términos generales, las diferencias entre el as-is y el to-be. Quedando pendiente la definición detallada tanto de los procedimientos como de las Reglas del Negocios, esto porque estás definiciones tienen que establecerlas las áreas de Procedimientos, o controles Internos o, la que antiguamente llamábamos Organización y Métodos.

Finalmente, solo la dimensión Transaccional es de total responsabilidad del Área Informática y aquí podemos darnos cuenta que lo que hemos llamado Implementación de Proceso de Negocios, antes de la introducción de BPM, no es más que la habilitación del software y sus correspondientes transacciones. Cuestión que técnicamente consiste en la instalación y parametrización del software.

Como reflexión queda una explicación de la razón porque muchos proyectos de implementación son exitosos pero, que no se usan debido a que no se trataron las dimensiones Organizacional y Procedimental, que típicamente no son consideradas por el Área Informática.

La Necesidad de Contar con una Herramienta Adecuada para el Modelamiento.

Es evidente que para hacer un buen trabajo se necesitan las herramientas adecuadas, el modelamiento no es la excepción. A mi juicio una herramienta es adecuada para el modelamiento cuando permite trabajar en todos los aspectos del cometido.

Tiene que permitir tratar con todas las dimensiones del proceso de negocios que la empresa. Necesita abarcar las tres dimensiones mencionadas en el párrafo anterior más Datos, KPI, Riesgos, Perfiles de Usuario, etc.

Y, además de incluir los diagramas típicos: VAC, EPC, BPMN, etc. Debe tener  un generador de reportes que permita producir informes y matrices, como ser: Manuales de Procedimientos, Especificaciones de Cargos, Matrices de Controles, etc. con los formatos ajustados a las necesidades de la organización.

También resulta conveniente que la herramienta facilite el trabajo concurrente en un mismo modelo, de modo que simultáneamente puedan trabajar distintas personas cada una en una dimensión. Y, aunque no es crítico, es muy útil contar con un mecanismo que automatice la publicación en la WEB de los modelos, para que queden a disposición de los usuarios.

El Trabajo Multidisciplinario

La implementación de un Proceso de Negocios requiere un equipo multidisciplinario tanto de la perspectiva de los especialistas como de los usuarios. Así se tiene que se necesitan especialistas para abordar cada una de las dimensiones principales, esto implica profesionales  expertos en diseño y especificación de procedimientos, expertos en el tema de descripción de cargos, roles y perfiles más lo consabidos consultores informáticos.

Para el caso de los consultores informáticos, en mi experiencia con SAP, resulta que se necesita uno por cada módulo involucrado, ya que por lo general los consultores funcionales SAP conocen en profundidad uno o dos módulos.

El equipo técnico por consiguiente estará conformado por varias personas que dependen de áreas distintas de la Informática y, esto impacta en la programación de actividades y en el liderazgo del proyecto.

En cuanto a los usuarios, se necesitará al Dueño del Proceso, que en nuestras organizaciones es prácticamente inexistente, más usuarios conocedores de los sub-procesos del proceso en uso en la empresa, el as-is. Aquí la dificultad está en que es difícil encontrar un usuario que tenga la visión completa u holística del proceso E2E.

De modo que, la conformación del equipo de trabajo para el proyecto de implementación del Proceso de Negocio es una tarea prioritaria y que requiere arduas negociaciones para comprometer los recursos requeridos. Y, su gestión como equipo precisa establecer un plan de apoyo y supervisión en el tema “trabajo en equipo”, dado lo variopinto de sus integrantes.

Temas pendientes

Del análisis de los proyectos realizados me quedan pendientes los siguientes tópicos:

  • El análisis de los tiempos requeridos por un proyecto de implementación tradicional versus una implementación  de proceso de negocios BPM.
  • La incorporación formal de las actividades relacionadas con la dimensión Organización y con la de Procedimientos, sea que la realice el área de Informática u otra.
  • La generación de la implementación simultánea de las transacciones y los workflows representados en los modelos EPC.
  • El medio más adecuado para capacitar en los principios del BPM a la organización.

Referencias

[1] https://msaffirio.wordpress.com/2006/05/07/bpm-business-process-management/

[2] https://msaffirio.wordpress.com/2009/06/06/mejores-practicas-best-prectices-practicas-propias-own-practices/

[3] https://msaffirio.wordpress.com/2009/07/04/as-is-to-be-gap/


[1] Me refiero a Consultores Funcional SAP, es decir especialistas en la implementación y uso de uno o más módulos SAP. Y, que además tiene certificación SAP.

El Anteproyecto de una Implementación BPM

Si Ud. encarga la construcción de su casa, ¿La iniciaría sin tener los planos de un arquitecto y el presupuesto de la empresa constructora? Y, ¿Por qué está dispuesto a permitir el inicio de la implementación de un proceso de negocios sin tener una definición precisa de lo que se necesita?. Hace pocos días, me preguntaron qué hacer para que los usuarios o la organización acepten realizar el Anteproyecto, y pretendo dar algunos argumentos a continuación.

La experiencia nos demuestra una y otra vez que cada vez que iniciamos un proyecto informático o de cualquier índole sin una definición formal de los objetivos, plazos y presupuestos la probabilidad de tener problemas graves e incluso fracasar es cercana a uno. Entonces, a contrario sensu es indispensable tener una definición precisa y documentada de los objetivos, plazos y presupuestos que significan la ejecución del proyecto. Este es nuestro primer argumento.

Etapas de un Proyecto

La literatura técnica [1, 2] nos dice que un proyecto tiene de cuatro a cinco etapas más un sistema de control. Esto independientemente de la metodología usada, la ejecución del proyecto tiene las etapas siguientes:

  • Anteproyecto (Initiation)
  • Planificación o desarrollo
  • Producción o Ejecución o Realización
  • Supervisión y Control
  • Cierre

Y, gráficamente se tiene:

Diagrama de las Fases de un Proyectos
Diagrama de las Fases de un Proyectos

Entonces aquí tenemos el segundo argumento: la disciplina de Project Management [3], que nos señala la necesidad de ejecutar como primera etapa de un proyecto el Anteproyecto.

El Anteproyecto es la etapa que determina la naturaleza y el alcance de lo que se pretende desarrollar. Si esta etapa no se ejecuta bien, es improbable que proyecto sea exitoso en cuanto satisfacer las necesidades del negocio. Los controles claves que aquí se necesitan son un entendimiento del ambiente del negocio y la realización de todo lo necesario para asegurar que todos los controles están incorporados al proyecto. Cualquier falencia que se detecte debe ser abordada y resuelta.

El Anteproyecto es la primera fase del Ciclo de Vida de un ProyectoProject Management Life Cycle– y por consiguiente establece la partida de la ejecución de un proyecto, aún cuando el proyecto en sí no se ejecute por razones de factibilidad técnica o económica.

Las tareas principales de la etapa Anteproyecto para un proyecto Informático son:

  • Levantamiento del requerimiento o de la necesidad del negocio.
  • Revisión de la operación actual.
  • Solución Conceptual
  • Dimensionamiento
  • Presupuesto
  • Planificación
  • Análisis de factibilidad y decisión de ejecutar

Para un proyecto de implementación de proceso de negocio, las tareas anteriores es necesario ajustarlas tal que reflejen los principios básicos de BPM, por ejemplo el alineamiento estratégico, el modelamiento, el enfoque holístico, la medición de performance –KPI-, etc. También es indispensable definir para cada tarea un entregable, a objeto de contar con documentos oficiales, que de alguna manera constituirán lo que los auditores llaman la evidencia.

Levantamiento del Requerimiento o de la Necesidad del Negocio.

Antes de hacer el Levantamiento es necesario verificar si existe una verdadera necesidad de implementar procesos de negocios, es decir si la empresa ya tiene internalizado que debe ir a procesos del tipo end-to-end, porque son indispensables para la viabilidad del negocios. Además está posición es respaldada por el Gerente General e idealmente, también por el Directorio. Si estos requisitos no se dan, entonces se debe suspender el Anteproyecto hasta cuando las condiciones indicadas se den.

Establecido que existen las condiciones de patrocinio e interés, el Levantamiento debe considerar:

  • Descripción detallada del requerimiento del usuario e identificación de objetivos cuantificables, por lo general KPI. En particular, es muy necesario establecer expec-tativas realistas.
  • Determinar cómo este requerimiento se alinea con la estrategia de la empresa.
  • Generar documento que describa el requerimiento.

Revisión de la Operación Actual.

La revisión de la situación actual significa documentar el proceso que actualmente tiene en operación la empresa, esta documentación es conocida como Modelos As-Is. Para esta operación es muy conveniente medir los KPI identificados durante el Levantamiento, pues ayudaran a establecer cuanto mejora la operación desde la situación actual, a la con el proceso rediseñado.

Generar el modelo As-Is requiere la participación de los usuarios operativos y, posteriormente la validación de los jefes, ésta a veces es difícil de obtener porque se generan discrepancias entre el proceso reportado por los usuarios y el de los Jefes. En todo caso, es necesario establecer una Verdad Oficial.

Solución Conceptual

Para establecerla es necesario desarrollar el Modelo To-Be, el cual debe satisfacer las necesidades establecidas en el Levantamiento. Para esta etapa es fundamental la participación de un Business Process Expert –BPX- a objeto que ayude a generar modelos adecuados.

En caso de no ser posible de generar el modelo To-Be una alternativa simple y económica es utilizar las Mejores Prácticas [4] provistas por fabricantes de software u otros.

Adicionalmente la Solución Conceptual debe incluir la plataforma tecnológica que soportará el software, las interfaces entre sistemas, la necesidades LLL (Legal, Localization, Language) y la definición de los roles necesarios para el nuevo proceso.

Es muy conveniente hacer una Análisis de Gap, éste consiste en establecer la brecha que media entre el modelo As-Is y el To-Be. La brecha es lo que en estricto rigor se necesita implementar.

También, es recomendable hacer un Análisis de Riesgo respecto a la implementación de esta Solución Conceptual, me refiero a un análisis de tipo cualitativo [5].

Dimensionamiento

Una vez establecida la Solución Conceptual se puede determinar cuáles son los elementos de infraestructura que la implementación requerirá, como ser: licencias, hardware, habilitación de componentes de software, comunicaciones, elementos de seguridad, etc.

El entregable de esta tarea es la lista de elementos de infraestructura requerida, la identificación de los elementos existentes y los que se necesitan adquirir, la lista de proveedores, etc.

También el dimensionamiento debe incluir una evaluación de los recursos de consultoría y programación, a objeto de determinar si estos pueden ser provistos por la propia área de Informática o se necesitará la contratación de servicios externos.

En caso de requerirse servicios externos se tendrá que hacer un llamado a propuesta –RFP- si el tema es complejo o, simplemente pedir cotizaciones. Por lo general, esta es una actividad que toma un par de semanas y, por esto es necesario tenerla muy presente.

Presupuesto

Esta actividad junto con el Dimensionamiento y la Planificación se realimentan entre sí y por tanto su ejecución tiene un cierto grado de paralelismo.

La determinación del costo del proyecto es necesario establecerla para aquellos ítems que corresponden a compras o a contratación de servicios de terceros. Es común que los costos de los recursos internos no sean considerados.

Los ítems más comunes son: Licencias de Software, Hardware, Gastos de Viajes y Servicios Externos (Consultoría, Desarrollo, Capacitación, etc.). La herramienta más usada para generar los presupuestos es MS Excel, y a veces se ocupan modelos matemáticos, como por ejemplo los Puntos de Función (para determinar el esfuerzo de los desarrollos).

Planificación

Con respecto a esta actividad, que normalmente es considerada un requisito burocrático, es necesario comentar:

  • El gran entregable de la planificación es la Gantt o más precisamente la lista de tareas con su secuencia de ejecución, con la identificación precisa de cada tarea, fechas, dependencias y recursos asignados.
  • La generación de la Gantt es un proceso de simulación de la ejecución del proyecto, por tanto ayuda a detectar puntos críticos, riesgos, disponibilidad de los recursos. Por lo mismo genera realimentación a las etapas de Dimensionamiento y Presupuesto.
  • Con la planificación se pueden negociar los compromisos de participación y apoyo tanto de los usuarios, recursos propios y recursos externos.
  • En definitiva, la Gantt debe ser formalmente aprobada por el Usuario –Cliente- a objeto que se transforme en el mecanismo oficial del control y supervisión del proyecto.

Análisis de Factibilidad y Decisión de Ejecutar

Establecidos los plazos, costos y riesgos es necesario hacer un balance entre el esfuerzo económico de realizar el proyecto versus los beneficios económicos que su ejecución conlleva. Por lo general la decisión de ejecutar se toma basada en la disponibilidad de presupuesto más un análisis cualitativo de los beneficios.

Si la organización es más sofisticada se incluye una valorización económica, para determinar que significa la ejecución del proyecto, este valor es asignado al proyecto para que compita con otros ya definidos y evaluados en el portafolio.

Un caso particular en la decisión de ejecutar son todos aquellos proyectos que obligatoriamente se deben ejecutar por razones de tipo legal o de alguna normativa (SoX, Basilea, IFRS, etc.)

Referencias

[1] http://en.wikipedia.org/wiki/Project_management

[2] New York State Proyect Management Guidebook

[3] http://www.pmi.org/Pages/default.aspx

[4] https://msaffirio.wordpress.com/2009/06/06/mejores-practicas-best-prectices-practicas-propias-own-practices/

[5] https://msaffirio.wordpress.com/2009/01/28/analisis-de-gestion-de-riesgos-en-proyectos-bpm/

El Factor Clave para un Proyecto BPM

A estas alturas del desarrollo informático cabe preguntarse donde está el mayor riesgo de un proyecto BPM y, en mi opinión, se pueden identificar tres áreas de riesgo: La Tecnología Informática, La Organización y los Informáticos. Para todo este análisis estoy suponiendo que el Proyecto BPM ya fue evaluado en su mérito y que la empresa tiene los recursos económicos para realizarlo. Y, que además el Área de Informática ya está preparada para abordar un proyecto de esta naturaleza [1]

La Tecnología Informática (TI), podemos decir que está compuesta por los tradicionales elementos de Hardware y Software. Y hoy, a diferencia de hace 25 años, la TI no es un riesgo, ahora difícilmente se frustrará un proyecto porque no tiene capacidad de discos suficiente y más raro aún es que un programa no funciones por memory exceded. Esto no quiere decir que la TI este totalmente libre de problemas, lo que sí es claro que con recursos técnicos competentes y el presupuesto correspondiente los problemas son solubles. Por consiguiente concluyo que las TI no son el factor clave para el éxito de un Proyecto BPM y sí son una condición necesaria pero no suficiente.

Los Informáticos, a la fecha el conjunto de profesionales de TI ya paso hace mucho tiempo la época de los Analistas de Sistemas, Programadores y Operadores. Hoy vemos que siguen existiendo los Operadores y los Programadores, que también se llaman Consultores Técnicos. Pero, tenemos Consultores  Funcionales, Arquitectos de distintos sabores, Business Process Experts, Jefes de Proyectos, Control de Calidad, etc. Con esto quiero decir que está disponible una oferta completa de profesionales Informáticos que cubren todas las áreas de especialidad de las TI. Luego en caso que en un proyecto se presente una complicación técnica grave, teniendo presupuesto, se puede recurrir al especialista pertinente sea de Chile o de otro país, dada la globalización de la oferta técnica. De modo que también podemos decir que los Informáticos no son el factor clave de éxito de un Proyecto BPM y sí son una condición necesaria pero no suficiente[1].

La Organización, para este análisis consideraré a los Gerentes y a los Usuarios, donde los primeros son los que detentan el poder formal y los segundos son quienes usan las TI para ejecutar sus funciones.  Es aquí donde encontramos el  factor crítico de éxito para el Proyecto BPM.  A continuación presentaré algunos elementos que refuerzan esta idea.

En una empresa típicamente los sistemas estas implementados por funciones –ventas, logísticas, producción, contabilidad, etc.- que se corresponden con la estructura organizacional –Gerencia Comercial, Gerencia Operaciones, Gerencia Producción, Gerencia de Administración y Finanzas, etc. es más estas funciones corresponden a módulos del software, por ejemplo en SAP ECC se tiene los módulos SD, MM, PP, FI, CO, etc . y a mayor abundamiento tenemos los Consultores Funcionales por módulo. De manera que estamos en presencia de un orden claramente establecido configurado en lo que se ha dado en llamar silos de información.

El proceso de negocios rompe totalmente con este orden, dado que al tener la visión holística de una actividad hace un análisis independiente de la estructura organizacional y de los componentes de software.  El gráfico publicado en [2] muestra esta realidad.

Modelo Operacional Matricial
Modelo Operacional Matricial

Luego, aquí detectamos el primer escollo del Proyecto BPM: los procesos de negocios rompen el orden establecido.

Para la implementación de un Proceso de Negocios se necesitan Business Process Expert (BPX) [3], este tipo de profesional tiene un dominio del negocio y de TI, y por tanto para la implementación de un Proceso de Negocios tendrá que interactuar con los Gerentes cuyas áreas participan en el nuevo modelo. Aquí se presenta otro riesgo potencial, al definirse procesos de negocios cada Gerente verá que ya no tiene un control total sobre cómo se implementan las funciones de su área, esto porque él es uno más de los que participan en la definición del modelo del proceso. Es decir, al eliminar los silos funcionales el Gerente de un área ya no puede definir de manera omnímoda la forma de operación de su área, y tiene que hacerlo en conjunto con otros Gerentes, con BPX y los Dueños de Procesos.

El otro fenómeno que afecta a los Gerentes es que el proyecto BPM implica una administración con un aspecto matricial que es dado por los Dueños de Procesos [4], que al responsabilizarce de un proceso –accountability– tienen autoridad sobre quienes operan el proceso independiente de la gerencia a la que pertenezcan. Este simple hecho generará tensión en los ejecutivos y el los usuarios.

Luego, tenemos que considerar que por causa de un proyecto BPM, independientemente de los beneficios racionales que éste pueda significar para cada Gerente, tenemos que tener en consideración las fuerzas que, de alguna manera, afectaran al Proyecto BPM y que se muestran en el diagrama siguiente:

Fuerzas que Afectan el Proyecto BPM
Fuerzas que Afectan el Proyecto BPM

Por otra parte tenemos a los Usuarios que participan en el proyecto sea para validación del modelo, para entregar información de detalles operativos y legales o para el testing de la implementación. En mi opinión ellos son afectados, al igual que en cualquier proyecto de implementación de sistemas, porque son sacados de su zona de confort.

En consecuencia, el factor crítico de éxito para un proyecto BPM son las personas [5], en este análisis las he identificado como los Gerentes y los Usuarios, y ellos tendrán especial participación en:

  • Tomar las decisiones de negocios.
  • Diseñar los procesos de negocios.
  • Monitorear la ejecución de los procesos de negocios.

Conclusión. En un área Informática, de una empresa grande, nos encontramos con recursos profesionalizados, centralizados y estandarizados. Estos recursos deberán actualizarse y agilizarse para poder incluir tópicos tan importantes como la Gestión del Cambio, entre otros, para poder abordar con éxito los Proyectos BPM. Como  asimismo el CIO deberá aplicar su capacidad política y de negociación para facilitar el patrocinio de los ejecutivos superiores. Sin el patrocinio de los ejecutivos superiores es muy difícil que el Área Informática logre alinear a los Gerentes con el Proyecto BPM.

Referencias

[1] https://msaffirio.wordpress.com/2008/11/08/algunas-dudas-respecto-a-un-proyecto-bpm/

[2] https://msaffirio.wordpress.com/2008/01/20/dueno-de-proceso-de-negocio-%E2%80%93-business-process-owner/

[3] https://msaffirio.wordpress.com/2008/09/30/business-process-expert-%E2%80%93-bpx/

[4] https://msaffirio.wordpress.com/2008/01/20/dueno-de-proceso-de-negocio-%E2%80%93-business-process-owner/

[5] Business Process Management The SAP Roadmap – Snabe, Rosenberg, Moller, Scavillo – Galileo Press 2009


[1] Se entiende que el Área Informática ya se ha preparado para abordar el Proyecto BPM.

Análisis de Gestión de Riesgos en Proyectos BPM

Casi todo lo que hoy día se hace en el mundo de los negocios involucra algún riesgo: los hábitos de los clientes cambian, surgen nuevos competidores, existen factores fuera su control, es necesario incorporar una nueva tecnología, etc. Cualquiera de éstos puede generar una demora o complicación en los proyectos. Pero, el análisis formal de los riesgos, y su posterior gestión, pueden ayudar a abordar los riesgos con acciones específicas que contribuirán a disminuir los impactos en los proyectos. En otras palabras, la anticipación del riesgo permite hacer acciones de mitigación, que son mucho más baratas de hacer que las acciones correctiva cuando se presenta el riesgo.

 

En particular, la implementación de proyectos BPM nos hace pensar de inmediato que tienen una probabilidad importante de no llegar a buen término; es decir, intuimos que tienen un riesgo no menor. Basados en que implica incorporar  una disciplina nueva, el BPM; y que involucra un cambio organizacional importante, los Dueños de Procesos de Negocios. Por tanto, en este artículo presentaré este tipo de análisis de riesgo para ayudar a determinar cual es la estrategia adecuada desde el punto de vista de la mitigación de los riesgos para un proyecto BPM y, de este modo se podrá planificar de mejor forma la ejecución del proyecto junto con aumentar la probabilidad de éxito.

 

Definición de Riesgo

Una definición simple de riesgo es: “Un riesgo es la percepción de la ocurrencia de un evento que pueda generar una pérdida” [1].

 

Otra definición más operativa en términos matemáticos es: “Un riesgo es una combinación de restricciones (limitaciones) e incertidumbres (dudas)” [2]. Gráficamente se tiene:

 

Curva Riesgo Aceptable
Curva Riesgo Aceptable

 

 

La curva del gráfico muestra el “Nivel Aceptable de Riesgo”. El riesgo se puede reducir hasta el Nivel Aceptable por medio de la disminución de las restricciones (técnicas, económicas, disponibilidad, etc.) y de la incertidumbre (probabilidad que ocurra el riesgo). En la práctica, las restricciones son muy difíciles de eliminar o flexibilizar, de manera que el foco se coloca en la disminución de la incertidumbre. Del gráfico se desprende que eliminar el riesgo totalmente no es posible o no es económicamente posible.

 En los párrafos siguientes presentaré una metodología para analizar los riesgos basada en cuatro fases:

 

  1. Inventario de Riesgos
  2. Evaluación
  3. Priorización
  4. Control y Mitigación

 

Inventario de Riesgos

Para simplificar la detección de los riesgos se establecen las categorías indicadas en la tabla adjunta. Para cada categoría se deben identificar los riesgos que correspondan a su proyecto, en particular focalizándose en el proceso de negocios en cuestión. Los riesgos se identifican en función de la experiencia y percepción de las personas que hacen el análisis, de ahí la necesidad de conocer el proceso de negocios a cabalidad como también el ambiente operacional (organización, gente, estructuras de poder, etc.)  y, finalmente es importante tener una argumentación plausible para justificar los riesgos identificados.

 

Categoría

Descripción

Humano

Derivados de las personas o la organización, enfermedades, falta disponibilidad, desvinculación, muerte, cambios de ejecutivos, estructuras de poder, oposición al cambio, etc.

Operacional

Generados por interrupciones o fallas en el abastecimiento y en las operaciones, pérdida de acceso a activos esenciales, fallas en la distribución, etc.

Reputación

Pérdida de la confianza de los socios de negocios, de los ejecutivos, de los usuarios, o daño a la reputación del área Informática.

Procedimientos

Son los generados por fallas en la contabilización, en los sistemas, en los controles, en la ejecución de los procedimientos, fraude, etc.

Proyectos

Riesgos de excederse en el presupuesto, en los plazos, o por calidad inadecuada del producto o servicio, etc.

Financiero

Originados por problemas con el negocio, con el mercado accionario, tasa de interés, desempleo, etc.

Técnico

Por el uso de nuevas tecnologías, fallas técnicas, desconocimiento, obsolescencia, etc.

Natural

Impacto por desastres naturales, clima, accidentes, epidemias, etc.

Político

Por cambios de impuestos, opinión publica, políticas de gobierno, influencia extranjera, etc.

 

 

Evaluación

Una vez identificados los riesgos de su proyecto, la etapa siguiente consiste en establecer la mejor estimación de la probabilidad de su ocurrencia y el impacto económico que provocaría.

 

Otra alternativa de estimación es: hacer la mejor estimación de la probabilidad de ocurrencia del riesgo, y multiplicar ésta por el costo que significaría su ocurrencia. Este cálculo da el valor económico del riesgo.

Cada riesgo deberá ser evaluado considerando la probabilidad de ocurrencia y el impacto que provocaría en caso de ocurrir. La perdida de un miembro clave del proyecto tiene una probabilidad de ocurrencia baja, pero el impacto puede ser muy grande.

Muchas personas se complican con esta evaluación porque tanto la probabilidad de ocurrencia como el impacto, son estimaciones. Ellos reconocen que variaciones pequeñas en estos datos pueden cambiar de manera importante el riesgo total del proyecto. Sin embargo, en general, el objetivo no es determinar un número único que represente cada uno de los riesgos. El objetivo es desarrollar un marco de análisis que permitan evaluar los distintos riesgos confrontándolos entre sí. Si bien cierto que la precisión en el proceso de Estimación es útil, no es esencial.

Otro aspecto a considerar es la variable tiempo, el que un evento ocurra al principio del proyecto no es lo mismo que pase durante un fase crítica. Mientras más tempranamente se valida la existencia de un riesgo asociado con una actividad o ítem  del proyecto, más rápidamente el riesgo disminuye o deja de serlo. El focalizarse en los riesgos controlables no elimina los riesgos pero, si los disminuye.

Debe tenerse presente que cada persona puede tener una percepción distinta de un riesgo – lo que para una es un riesgo menor para otra puede ser un riesgo mayor. Y, para calcular el riesgo se usa:

 

Riesgo = Probabilidad del Evento x Costo del Evento 

Una forma sencilla de Evaluar el riesgo es establecer una escala de riesgos del siguiente tenor:

 

Valor

Aplicación

Bajo

Se asigna cuando se estima una probabilidad de ocurrencia baja, por ejemplo menos del 20%. O cuando se observa un cuadro poco probable de acontecer. Se asigna este valor cuando el ítem evaluado tiene todas las condiciones a su favor para ser bien ejecutado.

Medio

Se asigna cuando existe la percepción que el riesgo tiene la misma probabilidad de ocurrir como de no ocurrir, es decir la probabilidad es alrededor del 50%. Se asigna este valuar cuando el ítem evaluado no reúne todas las condiciones para ser bien ejecutado.

Alto

Se asigna cuando existe la convicción que el riesgo ocurrirá si no se actúa para mitigarlo, es decir se tiene certeza que faltan elementos para llegar a la correcta ejecución del ítem evaluado. Luego se puede asignar una probabilidad superior al 80%.

 

Priorización

Una vez que los riesgos están identificados, se les ha asignado una probabilidad de ocurrencia y, se ha evaluado su impacto para el caso que llegaran a suceder,  se está en condiciones de priorizarlos. En general, la priorización se establece usando la valorización económica del impacto del riesgo (este valor se calcula con la fórmula indicado precedentemente).

Otro método para priorizar, que es complementario al anterior, es presentar los riesgos al Comité del Proyecto para que según sus distintas visiones y experiencias establezcan las prioridades. Este método tiene la ventaja de permitir consensuar opiniones distintas, teniendo en cuenta que la base de evaluación de riesgo es la percepción que tengan las personas al respecto.

Control y Mitigación

Una vez identificados y evaluados los riesgos, es necesario buscar la manera de reducirlos o mitigarlos, es decir hacer la Gestión del Riesgo. Es indispensable considerar que un riesgo no se puede eliminar, a lo más se reduce la probabilidad de ocurrencia. El costo del proyecto aumentará en la medida que se necesite reducir el riesgo.

 

Mientras mayor es la reducción del riesgo mayor es el costo involucrado. Por consiguiente, el costo de mitigación tiene que ser un valor adecuado a la realidad del negocio. Muchas veces el costo de mitigación es tan alto, que es preferible aceptar el riesgo. Es fundamental es tener conciencia de los riesgos existentes y de la gestión o mitigación que es factible técnica y económicamente de realizar.

 

Los riesgos se pueden gestionar (o mitigar) de distintas maneras:

 

  • Usando los activos existentes.
  • Con planes de contingencia.
  • Invirtiendo en nuevos recursos.

 

Uso de los activos existentes

Se trata de usar los elementos materiales y los recursos de personal, disponibles en la organización, para mitigar los riesgos.

 

Algunas acciones posibles a considerar son:

 

  • Mejorar los procedimientos y métodos en uso.
  • Cambiar la asignación de responsabilidades.
  • Mejorar el accountability y los controles internos.
  • Capacitar.
  • Usar planes de Gestión de Cambio.

 

Planes de Contingencia

Se puede decidir aceptar el riesgo, pero generando un plan que minimice sus efectos para el caso que suceda. Un buen plan de contingencia permitirá actuar de inmediato, con un adecuado manejo de la situación crítica.

 Los planes de contingencia son parte fundamental de los Business Continuity Planning (BCP) o del Business Continuity Management (BCM).

 

Invirtiendo en nuevos recursos

El análisis de un riesgo puede conducir a la necesidad de contar con recursos adicionales o nuevos para mitigarlo. Entre las múltiples opciones se tiene:

 

  • Contratación de seguros.
  • Disponibilidad temporal de equipamiento adicional.
  • Reemplazo de equipos.
  • Contratación de soporte externo.   

Para cada una de las acciones de mitigación es necesario incorporarlas en la planificación del proyecto (Carta Gantt) a objeto de tener un control formal y periódico de su avance. En particular el control de los riesgos debe ser un punto dentro de la agenda del Comité de Proyectos.

 

Colofón

En mi opinión un proyecto BPM debe ser planificado desde dos ópticas: una la Técnica que incluye el modelamiento de los procesos de negocios, la definición de la gobernabilidad, las herramientas de software, los sistemas de información, los desarrollos a realizar, etc.. Me parece que para las actividades relacionadas con éstos tópicos los riesgos son más fáciles de controlar pues, están en el ámbito de acción y competencia del área de Sistemas o Informática.

 

La otra óptica se refiere al Factor Humano, aquí incluyo los aspectos de política interna, estructuras de poder, aversión al cambio, profesionalismo, nivel de conocimientos, etc. Es decir, comprende las características y formas de relación de las personas que estarán participando en el proyecto y/o se verán afectadas por su implementación. Aquí es dónde vislumbro la fuente principal de riesgos para un proyecto BPM.

 

Referencias

[1] Risk Analysis & Risk Management  http://www.mindtools.com/pages/article/newTMC_07.htm

[2] An Overview of Project Risk Management http://www.netcomuk.co.uk/~rtusler/index.html