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:
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
[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/
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
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
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?.
Héctor:
La estimación de tiempos de un proyecto informático 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 método que mejor resultado me ha dado es la simple Carta Gantt pero, haciéndola como una simulación de la ejecuión del proyecto. Esto es incluyendo cada una de las tareas que es necesario realizar, por mínimas y triviales que sean. No te preocupes si salen más 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 aproximación la duración.
Saludos,
M. Saffirio.
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?.
Héctor:
La planificación no es una ciencia, es una metodología. Por tanto podríamos decir que no existe un algoritmo para planificar que nos garantice cierta exactitud. Entonces podemos asimilar la programación a una heurística; 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 heurística no garantiza, a diferencia del algoritmo, que siempre dará un resultado conocido, pertinente y exacto.
Por otra parte podemos decir que la planificación trata sobre el futuro. Un proyecto, como sabemos, incluye un conjunto de tareas, plazos, recursos finacieros, recursos humanos, etc. que organizadamente conducirán 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, sólo me remito reproducir un comentario generalizado. «los chilenos trabajamos una gran cantidad de horas con una productividad bajísima». Con esto se nos abre una perspectiva de trabajo muy interesante: cómo 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 planificación.
Atentamente,
M. Saffirio.
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
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?
José Antonio:
La disciplina BPM se puede ocupar en todas las empresas, independientemente de su tamaño. Dado que cada empresa representa un situación particular de negocio, la aplicación 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 introducción 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!
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.
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 información es en el Project Management Institute cuyo sitio es www,pmi.org.
Atentamente,
M. Saffirio