El Anteproyecto de una Implementación BPM 29/08/09
Posted by msaffirio in Administración, BPM, Informática, Proyectos.Tags: BPM, Gestión, Proceso, Proyectos
7 comments
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
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 Proyecto –Project 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
[5] http://msaffirio.wordpress.com/2009/01/28/analisis-de-gestion-de-riesgos-en-proyectos-bpm/
As-is; To-Be; Gap 4/07/09
Posted by msaffirio in BPM, Gestión, Informática, Proceso, SAP.Tags: BPM, Business Process, Modelo, Proceso
4 comments
Este artículo corresponde en parte a discusiones técnicas con mis colegas de Embotelladora Andina y refleja mi opinión respecto a los modelos As-Is y To-Be más el análisis de GAP.
Primero es necesario tener en consideración que estas discusiones se originan por causa del transcurso del tiempo, al igual que uno los sistemas envejecen y requieren ser actualizados funcionalmente. Luego la pregunta es ¿Cómo actualizo funcionalmente mis sistemas? Asunto que intentaré responder a continuación[1].
La necesidad de la actualización funcional se presenta cuando se está trabajando varios años con un mismo sistema, que se ha actualizado técnicamente, se han instalado las nuevas versiones del software. Pero, no se usan extensivamente las nuevas funciones que incluye este nuevo software y, por otra parte el portafolio de proyectos se comienza a llenar de muchas iniciativas de “mejoramientos”. La conclusión es: los sistemas requieren un mejoramiento de mayor alcance o profundidad.
El plantearse este mejoramiento o puesta al día tiene varias implicancias:
- Los sistemas en uso se implementaron con una tecnología distinta a la hoy en boga, entiéndase BPM. Es decir se diseñaron a partir del concepto funcional: Área Organizativa / Módulo de Software.
- No existe mucha seguridad que la documentación del sistema refleje la realidad actual.
- La actualización, con toda seguridad, ocupará la disciplina BPM y el concepto Proceso de Negocios.
- Lo más probable es que la organización no esté dispuesta a ejecutar un proyecto con una estrategia Big Band, básicamente por una cuestión de costos. Esto obliga a una estrategia de implementación que denomino “Cambiar la Rueda en Marcha”[2], es decir implementar los nuevos procesos de negocios mientras los sistema originales –antiguos- siguen funcionando y, todo esto en un mismo landscape.
- Dado que los sistemas antiguos tienen un diseño funcional, se mapean directamente uno es a uno con las área organizacionales. Cuestión que no ocurre con los procesos de negocios, que generan una estructura organizacional matricial, y esto provoca, sin lugar a dudas, un conflicto de poderes –político- no menor.
- Si la empresa tiene filiales, plantas u operaciones en distintos lugares o países lo más típico es que teniendo el mismo software, se tienen implementaciones distintas de acuerdo con los criterios de los gerentes.
Estrategia Cambio de Rueda en Marcha
Esta estrategia es válida para una empresa que opera un ERP con sistemas adicionales como CRM, SCM y sistemas legados, todos estos sistemas con algún grado importante de interconexiones. Es decir es para una empresa de tamaño grande con una infraestructura informática compleja que justifica una estrategia como la que describiré a continuación.
Características
Esta estrategia corresponde a las de tipo Evolutivo por Proceso[1], cuyas características principales son:
Fortalezas
- Permite un enfoque en profundidad y sistemático.
- Cambio Organizacional suave.
Debilidades
- Realización lenta de los beneficios.
- Se generan cambios en los procesos debido al paso del tiempo.
Básicamente esta estrategia se aplica a un proceso de negocios End-To-End, por ejemplo: Order-to-Cash, Procure-to-Pay, etc.
Pre-Requisitos
Para que esta estrategia efectivamente pueda aplicarse exitosamente es necesario contar con:
- Una directriz del Directorio y la Gerencia General que señale que la empresa re-implementará sus sistemas informáticos utilizando la disciplina BPM.
- Un Mapa de los Procesos de Negocios oficial.
- Un área Informática con personal capacitado en BPM y que conozca los procesos de negocios de su empresa en profundidad (detalles operativos).
- Una estructura metodológica que incluya: la Enterprise Architecture, La estrategia BPM (la que presento en este artículo), Gestión de Portafolio y Metodología para la Implementación de Procesos de Negocios.
- Un plan de Gestión de Cambio.
A mi juicio, lo que importa es contar con estos elementos independientemente del área organizativa que los provee.
Modelo
Este modelo se aplica a un proceso de negocios End-To-End y su estructura general es:
Estrategia Cambio Rueda en Marcha
Etapa AS-IS
Este es uno de los aspectos que siempre está en discusión[2], ya que existen opiniones a favor y en contra respecto a si es necesario generar los modelos As-is, mi opinión es que es indispensable generar estos modelos debido a que:
- Ayuda a generar un alineamiento y entendimiento entre las distintas áreas y locaciones de la empresa en cuanto a cómo efectivamente se ejecuta el proceso de negocios. A menudo en las organizaciones grandes muchos ejecutivos y usuarios claves no tienen la visión completa de cada uno de los pasos y detalles de la operación del proceso de negocios. La documentación del As-Is ayuda a generar claridad respecto a cómo se ejecutan las cosas y cuáles son los desalineamientos.
- Ayuda a introducir los conceptos de BPM a los ejecutivos y a los usuarios claves, en particular en el uso de los diagramas de procesos de negocios (VAC, EPC, etc.)
- Permite establecer los puntos críticos y de mejoramiento del proceso.
- Afiata el equipo de trabajo del proyecto: Consultores, Usuarios Claves y Ejecutivos Claves.
Para el levantamiento del proceso As-Is es importante considerar:
- Que a fin de generar la documentación del As-Is en un tiempo razonable es necesario tener un método preestablecido de trabajo y un estándar para modelar.
- Se necesita de herramienta de software para modelar, ojalá una que maneje objetos como ARIS.
- Es indispensable, una vez generado el modelo As-Is, los gerentes involucrados en el proceso validen formalmente el modelo. Esta acción tiene más de una complicación debido a que a menudo el modelo levantado no corresponde a la imagen que tienen del mismo los ejecutivos.
- Por último, si su empresa necesita cumplir con alguna regulación (SoX, Basilea II) o alguna certificación el disponer de la documentación de los procesos de negocios actualizados es una obligación.
- La responsabilidad de generar y mantener actualizados los modelos As-Is de los procesos de negocios debe estar formalmente asignada a alguna unidad de la organización.
To-Be
La generación de los modelos To-Be es indispensable para establecer que se quiere de la nueva implementación, y ayuda a:
- Definir el nuevo modelo del proceso de negocios independientemente del software a utilizar. Esto permite pensar sin restricciones dadas por el software, por la costumbre, por el personal, etc. cuestión que posibilita descubrir oportunidades de mejoramiento.
- Al tener los modelos To-Be y los As-Is es factible realizar un análisis de GAP, que es fundamental para esta estrategia.
- El desarrollo del modelo To-Be permite establecer Indicadores de Performance –KPI que apoyaran el mejoramiento del negocio y el accountability.
- Posibilita realizar un efectivo alineamiento de los procesos de negocios con la estrategia corporativa.
Para la generación del modelo To-Be se pueden trabajar con los siguientes enfoques:
- Utilizar Mejores Prácticas, que son modelos provistos, en general, por los fabricantes del software o por alguna otra organización. La ventaja de su uso es tiempo, costo y que son modelos probados en la práctica[3]
- Variantes LLL (Legal, Language, Localization), modificaciones a una Mejor Práctica originadas por un imperativo legal, una necesidad impuesta por el idioma o por elementos físicos –no de idiosincrasia- de una locación, por ejemplo la disponibilidad de un determinado elemento.
- Prácticas Propias, son modelos generados por la propia organización y que se justifican, dado su alto costo de generación, cuando el proceso o parte de el –subproceso- no está presente en una Mejor Práctica y/o cuando su implementación genera una ventaja competitiva muy significativa.
Análisis de GAP
En simple es establecer cuáles son los cambios necesarios de realizar al proceso actual para actualizarlo al Nuevo modelo.
En esta estrategia es necesario volver a tener en cuenta que el “Cambio de Rueda es en Mrcha”, esto significa que los ajustes, modificaciones y adiciones se hacen en el landscape que está operando. Hecho que significa establecer con mucha precisión cuales serán los cambios a realizar, cómo y dónde se harán y, muy principalmente, cuál será el impacto que tendrán
Resumiendo el Análisis de GAP, debe establecer las brechas en:
- Procesos y Subprocesos
- Parametrizaciones
- Desarrollos propios (existente y nuevos)
- Datos
- Roles
- Responsabilidades
- Documentación
- Performance
- Gobernabilidad
Cada uno de los tópicos anteriores debe ser documentado y en conjunto constituirán en Business Blue Print que define el GAP a implementar.
Referencias
[1] SAP Roadmap for BPM
[2] http://it.toolbox.com/blogs/erp-roi/erp-business-process-improvement-asis-or-tobe-13208
[1] Todo este artículo tiene un trasfondo de tecnología SAP, pues es la que ocupa mi empleador: Embotelladora Andina.
[2] Expresión que la escuché a menudo de mi ex jefe Ricardo Majluf.
Mejores Prácticas – Best Prectices / Prácticas Propias Own Practices 6/06/09
Posted by msaffirio in Gestión, Proceso, SAP.Tags: Best Practice, BPM, Proceso
1 comment so far
Durante el Sapphire 09 (Orlando, Mayo 2009) asistí a la presentación Clear Business Value realizada por los ejecutivos Bill McDermott y Jim Hagemann Snabe [1], ellos responden a la pregunta: ¿Cómo se genera ventaja competitiva con los procesos de negocios? Plantearon que para generar Valor para el Cliente es necesario tener: Visión del Negocio, Mejores Prácticas y Prácticas Propias. La aplicación de estos tres elementos lleva a la Excelencia Operativa, y ésta es la que genera Valor para el Cliente y permite obtener ventaja sobre la competencia. En los párrafos siguientes expondré estos conceptos con algunas explicaciones mías.
Visión del Negocio
Con cualquier ejecutivo que uno converse le dirá que tiene una visión y un conocimiento profundo de su negocio, sin embargo McDermott y Hagemann definen que la visión se da cuando se dispone de:
- Información Unificada, toda la información de los procesos de negocios está estandarizada para toda la compañía, es decir un parámetro, un campo, una clasificación, un KPI, etc. significan lo mismo para cualquier empleado, independiente del cargo, de la gerencia o filial a la que pertenezca.
- Acceso Instantáneo, los empleados tienen acceso a la información que precisan en cualquier momento, no están sujetos a la necesidad de pedir a un tercero la información deseada.
- Ciclo cerrado entre estrategia y ejecución. Los procesos de negocios, que soportan la ejecución y el control, están alineados con la estrategia corporativa; es decir, en cada proceso se tienen mecanismos que permiten medir cuantitativamente la estrategia (presupuestos, planes, KPI, etc.)
El diagrama siguiente muestra como se insertan estos conceptos en un modelo de operación más general.
Modelo presentando por Bill McDermott y Jim Hagemann Snabe en Sapphire 09
Mejores Prácticas – Best Practices
Originalmente el término o concepto Mejores Prácticas -Best Practices- fue acuñado en 1993 por Hammer and Champy [2] para identificar siete reglas o indicaciones para modelar procesos de negocios.
Hoy la Mejor Práctica corresponde a un modelo completamente definido, cuyos buenos resultados operacionales están comprobados y que está disponible para ser utilizada. Por ejemplo: SAP por medio de su aplicación Solution Manager[3] permite “bajar” Mejores Prácticas prácticamente para cualquier proceso.
El usar Mejores Prácticas significa un gran ahorro de dinero, debido a que los modelos ya están establecidos y han sido refinados por el uso en muchas empresas. Las ventajas de utilizarlas son básicamente el menor costo y el menor plazo de implementación. Sin embargo, utilizar las Mejores Prácticas, a pesar que su habilitación no es un mero copiar / pegar, es simplemente una replicación de un modelo de proceso de negocios que muchas empresas ya tienen en uso, con la salvedad que quien la está implementando no será ni el primero ni el último. De modo que podemos decir que al usar una compañía Mejores Prácticas sólo está “empatando” con las otras compañías que también ocupan la referida Mejor Práctica.
Prácticas Propias – Own Practices
Son modelos de procesos de negocios propios que corresponden a aspectos específicos de la operación de una compañía, que se refieren a aspecto particulares de su operación y que al llevarlos a nivel de excelencia permiten generar más Valor para los Clientes. Por ejemplo en una empresa distribuidora puede ser algún aspecto de la logística, en otra será un forma diferencial en la generación de demanda, en el tratamiento de las órdenes de producción.
Las localizaciones del tipo LLL (Legal, Localization & Language) no corresponden a una Práctica Propia, pues dan satisfacción a una necesidad que es común para varias empresas en un país determinado.
Las Prácticas Propias se construyen por medio de:
- Identificación de las áreas de diferenciación.
- Expandiendo las Mejores Prácticas en uso.
- Construyendo Mejores Prácticas.
- Apalancándose en SOA para aumentar la velocidad de implementación.
Conclusión
La vía propuesta por McDermott y Hagemann consiste en desarrollar en paralelo la implementación de las Mejores Prácticas y la habilitación de una plataforma de Business Intelligence para proveer a los usuarios el acceso instantáneo a la información que necesitan. Una vez resueltos estos dos aspectos se procede con la generación de las Prácticas Propias, se estima que éstas debieran corresponder al 20% de las Prácticas de una empresa.
Luego, las Prácticas Propias serán las implementaciones de los modelos de procesos de negocios que en definitiva permitan generar Valor para Cliente y, establecer una diferencia competitiva por la vía de la Excelencia Operativa, que como se sabe es mucho más difícil de copiar que los productos y los servicios.
Referencias:
[1] McDermott y Hagemann, http://www.sap.com/community/events/sapphire_online_2009/index.epx
[2]Hammer, M (1990) “Reengineering work: don’t automate, obliterate”, Harvard
Business Review, Vol. 68, No. 4, pp 104-112.
El Factor Clave para un Proyecto BPM 3/05/09
Posted by msaffirio in BPM, Informática, Opinión, Proceso, Proyectos.Tags: BPM, Business Process, Proyectos
2 comments
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
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
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] http://msaffirio.wordpress.com/2008/11/08/algunas-dudas-respecto-a-un-proyecto-bpm/
[3] http://msaffirio.wordpress.com/2008/09/30/business-process-expert-%E2%80%93-bpx/
[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 28/01/09
Posted by msaffirio in BPM, Informática, Opinión, Proceso, Proyectos.Tags: BPM, Proyectos, Riesgo
2 comments
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
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:
- Inventario de Riesgos
- Evaluación
- Priorización
- 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
