El Anteproyecto de una Implementación BPM

29/08/09 § 12 comentarios

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

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

About these ads

Etiquetado:, , ,

§ 12 respuestas a El Anteproyecto de una Implementación BPM

  • hector dice:

    Excelente artículo, la verdad siempre me he preguntado lo mismo.
    Cualquier proyecto de ingeniería requiere de planos, estimaciones mas o menos precisas, planificación, presupuestos, maquetas, etc…¿por qué entonces cuando hacemos proyectos informáicos, esto pareciera no importar?.
    ¿¿Hacemos ingeniería o chasquillamos??

    Hace unos meses me postulé a un cargo de Jefatura de Proyectos para Servipag, y durante el proceso se hizo una dinámica grupal en la cual había que planificar un proyecto.
    De los postulantes, sólo yo hablé de anteproyecto en los términos que plantea este artículo, y de la necesidad de calcular indicadores como VAN o TIR para conocer cuantitativamente la conveniencia de llevarlo a cabo, etc..etc…

    Lo pintotresco del hecho, es que mis otros 5 competidores (colegas, tambien ingenieros supongo), se tiraron en picada, para atacar mi propuesta: “que eso no se usa”, “que es de los estructurales”,” que es una pérdida de tiempo”, “que la organización necesita respuestas inmediatas y no da para burocracia”…etc…..si hubiese preguntado que significaba VAN …posiblemente habrían dicho “un auto familiar”.

    Obviamente después de ese 5 a 1, la sicóloga que cachaba menos, debió pensar que efectivamente yo estaba loco….

    Por eso me gustó el artículo, es bueno que esta información se divulgue de manera simple, pues hay demasiada ignorancia dando vueltas, y cuando esta llega a los mandos superiores nos transformamos en amenazas, y nuestras oportunidades laborales se esfuman por saber mucho :-)…….y no es mas que la punta del iceberg….

    Atte., Héctor

  • msaffirio dice:

    Héctor:

    Muchas gracias por tu comentario, en relación a la opinión de colegas respecto a la inutitilidad del Anteproyecto he tenido con mucha frecuencia respuestas similares. Sin embargo, cuando trato el tema con Usuarios y lo explico con la analogía de la construcción o el montaje industrial es acaeptado y entendido.

    Por otra parte hoy día puedes generar “planos” en el Anteproyecto al modelar ocupando diagramas EPC, que son muy bien entendidos por los usarios.

    Saludos cordiales,

    M. Saffirio

  • hector dice:

    Hola Mario:

    Ahora se que no intervengo en el proceso :-)

    Mira, hay un aspecto de tu artículo, que es por si sólo un tema (entre varios otros en realidad), pero me refiero específicamente al dimensionamiento del software, o evaluación de tamaño.
    Los puntos de función, son una alternativa pero tiene la desventaja que aplica dentro de un marco muy restringido, en cuánto a tamaño y a tipo de proyecto….o sea, un proyecto de implantación no lo puedo medir con PF….un proyecto muy tecnológico tampoco.

    Entonces sería interesante debatir en cuanto a qué otros mecanismos de estimación de tamaño, aparte de los Puntos de Función, de los Puntos de Característica, del Cocomo, etc….aplican sobre otro o todo tipo de proyectos.

    Esta fue una discusión que tuve con mis pares cuando implementabamos los PF en el contexto de la metodología de Proyectos en LAN (CMM).
    Y era que no podíamos aplicar PF para todo, por poner un caso, un componente de comunicaciones posiblemente tenga PF=0, no obstante su esfuerzo no es menor, una mantención de software de negocio, eventualmente puede resultar con PF=0, y demandar un gran esfuerzo.
    El tema es entonces, ¿cómo hacemos una estimación temprana (hablamos en fase de anteproyecto) del tamaño del software, con un método científico, y no con el de los “dedos oscilantes”, (o sea, el mas o menos)…un proyecto que no clasifica para los PF….¿historia?, ¿experiencia?, o hay algo mas elaborado?.

    • msaffirio dice:

      Hctor:

      La estimacin de tiempos de un proyecto informtico sigue siendo una ciencia arcana. Claramente los PF sirve para el tema de evaluar cuanto demorar el desarrollo de cierta funcionalidad de software. Por mi parte el mtodo que mejor resultado me ha dado es la simple Carta Gantt pero, hacindola como una simulacin de la ejecuin del proyecto. Esto es incluyendo cada una de las tareas que es necesario realizar, por mnimas y triviales que sean. No te preocupes si salen ms de 300 actividades. Ahora lo que pasa que para cada tarea puedes definir precisamente su alcance y quienes son sus responsables, a partir de esto puedes estimar con una mejor aproximacin la duracin.

      Saludos,

      M. Saffirio.

  • hector dice:

    Mario:

    Concuerdo contigo, en que al parecer no habría un método científico relativamente certero para estimar el esfuerzo de un proyecto.

    No olvidemos que los PF no es una fórmula mágica que resulta en un plazo, el resultado es un número, que en base a la historia de la organización (en cuanto a desarrollo de proyectos), el desempeño o capacidad de los desarrolladores, complejidad o facilidades de las herramientas y/o del lenguaje…..etc…..se pueden traducir en tiempo con un pequeño margen de error, que en Obras Civiles sería inaceptable…a esto se agregan otros factores como los SLA de otras unidades o proveedores, negociaciones, analisis de riesgos etc…que al ponerlos en la juguera recién permiten visualizar un plazo.

    Por lo que me dices entonces, concluyo que el mejor método sería la experiencia y obviamente la historia, apoyándose con técnicas como los PF …pero no utilizando estos como métodos únicos, ¿correcto?.

    Otro aspecto importante al momento de establecer plazos y compromisos, es el desempeño del equipo.
    Al respecto, ¿cuánto es el % de productividad real (se entiende un promedio) que según tu experiencia posee un desarrollador, llámese Programador, Analista, Jefe de Proyecto??..
    He discutido este tema con colegas, y me cuesta un poco aceptar que los porcentajes sean tan bajos, y me gustaría conocer tu percepción al respecto.
    Ahora esto es un problema de nuestra cultura o es general?, en paises como Japón o Alemania por ejemplo, que se caracterizan por ser poco sacadores de vuelta, ¿ocurre algo similar?, sabes algo de eso?.

    • msaffirio dice:

      Hctor:

      La planificacin no es una ciencia, es una metodologa. Por tanto podramos decir que no existe un algoritmo para planificar que nos garantice cierta exactitud. Entonces podemos asimilar la programacin a una heurstica; es decir, un conjunto de reglas que por lo general producen un resultado conocido y, en el “por lo general”, est la clave ya que una heurstica no garantiza, a diferencia del algoritmo, que siempre dar un resultado conocido, pertinente y exacto.

      Por otra parte podemos decir que la planificacin trata sobre el futuro. Un proyecto, como sabemos, incluye un conjunto de tareas, plazos, recursos finacieros, recursos humanos, etc. que organizadamente conducirn a un determinado logro. Pero, nada garantiza el comportamiento de las personas, de la sociedad y de la factibilidad del objetivo propuesto, tal que se conjuguen para el logro de la meta. En resumen, todo proyecto tiene una probabilidad de fracaso mayor que 0.

      Y, en cuanto al rendimiento de los profesionales, slo me remito reproducir un comentario generalizado. “los chilenos trabajamos una gran cantidad de horas con una productividad bajsima”. Con esto se nos abre una perspectiva de trabajo muy interesante: cmo efectivamente medimos la productividad de nuestros profesionales. Y, por tanto medir las Horas Hombre es el primer paso para mejorar el rendimiento y la exactitud de nuestra planificacin.

      Atentamente,

      M. Saffirio.

  • hector dice:

    Completisima tu explicación, no obstante echo de menos una referencia a la historia…
    Tal como dices, la planificación habla de hechos futuros… pero ¿cómo hacemos que esa planificación tenga algún grado de efectividad, si no tenemos un punto de referencia?, de lo contrario cada proyecto se transforma en ruleta rusa….

    El segundo nivel del CMM se llama repetible, justamente porque en base a hechos consumados, debidamente registrados, “es posible” repetir esa experiencia…entendiéndose que haya sido buena :-).

    Ahora claro, es cierto lo que mencionas..que no se puede garantizar el comportamiento de las entidades involucradas, y eso puede incorporar variaciones, pero no es menos cierto que si un proyecto demoró/costó una cantidad X, es muy probable que un proyecto similar esté dentro de un X+/-deltaX.

    Ahora del rendimiento de los desarrolladores, creo que hay una componente no menor que tiene que ver con la planificación.
    En algún punto anterior, mencionas que se deben considerar hasta los mas mínimos detalles, y creo que en gran medida esa baja productividad de nuestros desarrolladores, tiene que ver, al menos en parte, con una mala planificación. No quiero decir con esto que no sacamos la vuelta, eso es cultural, pero dudo que sea la única causa.

    He visto “cartas gantt” de empresas supuestamente “certificadas en CMM”, en el cuerpo de un mail, o en un txt….que no son mas que una lista de deseos y buenas acciones….entonces, obviamente es imposible medir la productividad de un equipo de desarrollo con una planificación de ese tipo.

    Atte., Héctor

  • Jose Antonio dice:

    Hola, buenas tardes, no soy del sector y no entiendo muy bien la terminologia, pero si creo que es un gran articulo…, solo me gustaria saber una cosa: cuales serían las necesidades para saber si una empresa debiera implementar este tipo de aplicaciones, y que información previa necesita una compañía que lo implemente (a nivel tecnologico, de filosofia o de procesos) para ofrecerlo?

    • msaffirio dice:

      Jos Antonio:

      La disciplina BPM se puede ocupar en todas las empresas, independientemente de su tamao. Dado que cada empresa representa un situacin particular de negocio, la aplicacin del BPM se debe hacer cargo de esta realidad y para ello el primer paso es que sus ejecutivos entiendan los conceptos y principios del BPM, ya que cualquier proyecto de introduccin de este necesita el patrocinio de los ejecutivos superiores, en particular del Gerente General.

      Atentamente,

      M. Saffirio

  • impecable artículo, saque un par de cosas para un trabajo q estoy haciendo, gracias!

  • Adriana dice:

    Esta muy interesante tu articulo, y estoy muy interesada en establecer como medir el esfuerzo en duración y recursos de un proyecto bpm, agradezco mucho si me puedes direccionar hacia algunas técnicas en las cuales me pueda apoyar para esa estimación.

    Gracias.

    • msaffirio dice:

      Adriana:

      Para estimar tiempos de un proyecto, cualquiera que sea su naturaleza, es necesario realizar un ante-proyecto para precisar el alcance, determinar las reas a intervenir, establecer los recursos necesarios, etc. Un un sitio donde puedes encontrar muy buena informacin es en el Project Management Institute cuyo sitio es www,pmi.org.

      Atentamente,

      M. Saffirio

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

¿Qué es esto?

Actualmente estás leyendo El Anteproyecto de una Implementación BPM en Mario Saffirio.

Meta

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 121 seguidores

A %d blogueros les gusta esto: