Icono del sitio Tecnologías de la Información y Procesos de Negocios

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:

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 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:

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:

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:

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] http://msaffirio.com/2009/06/06/mejores-practicas-best-prectices-practicas-propias-own-practices/

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

Salir de la versión móvil