Solución Esperada – Definición de Alcance – EAA

La Solución Esperada debe incluir todas las características del producto o servicio que un proyecto pretende crear. Es importante considerar que en la medida que el proyecto avanza en su ciclo de vida la Solución Esperada puede ser modificada.

Todos los detalles de la Solución Esperada no se conocen en las fases iniciales, y éstos se van elaborando progresivamente en las fases siguientes del proyecto. Esta fase de proyecto es clave, ya que es el elemento base para la planificación y ejecución del mismo.

Se deben incluir las descripciones sobre qué es lo que incluye el producto o servicio, y sobre lo que no incluye.

 Alcance

La descripción del Alcance es un relato sobre lo que se necesita implementar, hacer, modificar o capacitar para solucionar el problema definido en la Identificación de la Necesidad, esta descripción puede ser general, sin entrar en detalles. Ya que en caso que se autorice ejecutar el proyecto, el Alcance se precisará más detalladamente durante el Anteproyecto.

En esta Etapa el Alcance se establece a partir de:

  • La Identificación de la Necesidad.
  • Los Objetivos y la Justificación.
  • Las Restricciones.
  • Los Supuestos.
  • El conocimiento del problema que tenga el Equipo de Definición de la Necesidad (Initianting Process Group)
  • Más algunas eventuales entrevistas con las Partes Interesadas.

Es común que el alcance resulte muy extenso y no sea factible implementarlo en un solo proyecto, por eso una vez establecido éste se identifican los elementos que son incluidos y aquellos que no. estos últimos se pueden constituir en el alcance de una fase siguiente del proyecto.

 Descripción Simple del Alcance

Una forma simple para describir el alcance es usar una tabla como la siguiente:

ID Item Incluido No Incluido

1

Estimación de la Demanda

2

Planificación de la Producción

3

Planificación del Abastecimiento

4

Planificación del Transporte Inter Bodegas

5

Sales & Operation Execution

6

Ejecución de la Producción

 …

 Estructura Analítica del Alcance (EAA)

Una manera más sistemática  de definir el Alcance de un Proyecto es la EAA, que es la traducción PBS –Product Breakdown Structure- y que consiste en una estructura jerárquica para describir el producto o servicio que se desea que el Proyecto construya o implemente. No confundir EAP -Estructura Analítica del Proyecto- o WBS –Work Breakdown Structure– que es también una jerarquía, pero con las tareas necesarias para hacer el proyecto.

La tabla siguiente nuestras las características y diferencias entre la EAA y la EAP.

Estructura Analítica del Alcance (EAA) Estructura Analítica del Proyecto (EAP)
Identificado con un Sustantivo. Identificado con un Verbo.
Producto o Servicio (el que será entregado al Cliente). Trabajo necesario para generar el producto o servicio.
Responde al Qué (Producto). Responde al Cómo (Hacer).
Lista de Compra. Lista de Tareas necesarias para hacer las Compras.
No representa procesos. Representa procesos, actividades, hitos, entregables, fechas, etc.
Creado al inicio del proyecto -Identificación de la Necesidad- para visualizar el alcance del producto o servicio. Creado durante la fase Proyecto, etapa Diseño.
El EAA es un antecedente para generar el EAP. El EAP se alimenta del EAA.

Ejemplo EAA:

Definición Alcance EAA

Guía para generar la EAA (Estructura Analítica del Alcance)

¿Qué hacer? ¿Cómo hacer?
1 Definir el nivel más alto o Nivel 0 de la jerarquía
  • Definiendo con, ojalá, un sustantivo el producto o servicio que se necesita crear.
  • El nivel 0 se compone de un solo elemento.
  • Ejemplo de productos o servicio:
    • Motocicleta.
    • Nueva Línea de Producción.
    • Proceso Venta Electrónica.
    • Re-estructuración del área X.
2 Definir los elementos del Nivel 1
  • El Nivel 1 cuelga en la jerarquía del Nivel 0 y puede haber tantos elementos Nivel 1 como sea necesario.
  • El Nivel 1 es la primera descomposición del producto o servicio que generará el proyecto.
  • Una buena práctica es no tener más de 6 elementos por nivel. Si aparecen más quiere decir que se necesita generalizar -sinterizar- más.
  • En la Etapa 1 es indispensable generar el nivel 1 como mínimo.
3 Definirlos elemento del Nivel n+1
  • El nivel n+1 cuelga en la jerarquía del Nivel n, y puede tener tantos elementos como sea necesario.
  • Cada elemento del nivel n+1 es una descomposición del nivel n.

 Restricciones

Son los factores limitantes que afectan la ejecución de un proyecto. Las Restricciones se identifican cuando se define el Alcance del proyecto, describen tanto las limitantes internas como externas.

Las Restricciones del proyecto son limitaciones que enfrenta el proyecto debido a la financiación, programación / horarios, tecnología o recursos o estrategias de la empresa. Las Restricciones pueden ser también físicas (es decir, la falta de espacio o instalaciones).

Las Restricciones deben ser analizadas cuidadosamente y se comunican a todas las Partes Interesadas, ya que pueden requerir un nivel elevado de urgencia o flexibilidad para trabajarlas y completar con éxito el proyecto.

En esta sección se debe describir las limitaciones del proyecto para asegurar que todas las Partes Interesadas compren las limitaciones dentro de las cuales se debe ejecutar y terminar el proyecto.

Categorías de Restricciones:

  • Plazos y Fechas
  • Presupuesto
  • Recursos
  • Conocimientos / Habilidades
  • Dependencias
  • Políticas Internas
  • Tecnología
  • Otras

Ejemplos:

  • El Anteproyecto debe completarse en 30 días.
  • La Capacitación se hará en las dependencias de la empresa, en horario de trabajo.
  • La fecha de Puesta en Marcha debe ser 60 días antes de la Temporada Alta.
  • La WiFi estará habilitada en las bodegas una vez que se complete la construcción de éstas.

 Supuestos

Son factores que se deben considerar durante la planificación como verdaderos, reales, o ciertos, sin que esto sea necesariamente demostrable. También debe anotarse el impacto potencial en caso que sean falsos.

Es importante documentar estas suposiciones porque hay un nivel de incertidumbre asociado con ellas que introduce riesgo al proyecto. En esta sección se deben describir los supuestos para el proyecto, de modo que todas las Partes Interesadas los conozcan y en el futuro, para que puedan ser analizados con el fin de mitigar el riesgo.

Categorías de Supuestos:

  • Alcance.
  • Cronograma.
  • Presupuesto.
  • Expectativas.
  • Patrocinio.
  • Compromiso del Negocio.
  • Tecnología.
  • Proveedores.
  • Otros.

Ejemplos:

  • Los Usuarios Claves estarán disponibles al 100% durante los períodos correspondientes a sus tareas asignadas en la planificación del proyecto.
  • El horario de trabajo es de 9:00 a 18:00 en días hábiles.
  • Se requiere la participación de consultores externos.
  • El nuevo servidor está operativo.
  • Se cuenta con sala para el proyecto.
  • No se permiten cambios de alcance.

 Hitos

Es fundamental tener un Plan con fechas, de otro modo es muy improbable lograr los resultados esperados. Los Hitos se establecen analizando el esfuerzo (recursos) y tiempo necesario para producir cada uno de los elementos Nivel 1 de Estructura Analítica del Alcance, más el conocimiento en la ejecución de proyectos similares. En esta etapa se genera la primera versión de los Hitos, la que será actualizada durante la fase Ante-proyecto.

Los Hitos corresponden a fechas donde se revisa el avance del proyecto y, además cada Hito tiene un conjunto de Entregables que deben estar terminados a la fecha del mismo.

Ejemplo de Hitos:

  1. Fin Anteproyecto 15 de Junio de xx
  2. Capacitación Usuarios Claves 1º de Septiembre xx
  3. Inicio Testing 15 de Octubre xx
  4. Carga Inicial de Datos 20 de Noviembre xx
  5. Puesta en Marcha 15 de Enero xx+1

Conclusión

La Solución Esperada normalmente está definida vagamente, son declaraciones de tipo general, por ejemplo: Actualizar el Sistema X, Implementar el Software para Call Center, Habilitar la Planificación de la Producción, etc. Estos son títulos nada más; para poder establecer un plan de proyecto se necesita tener una idea exacta y detallada de lo que se necesita hacer, de las restricciones y limitaciones que se deberán tener en cuenta y, un cronograma concordante con los tiempos y esfuerzos qué necesitará el proyecto para implementar la Solución Esperada.

El tiempo, esfuerzo y presupuesto que se ocupe para generar la Solución Esperada, que cubra con precisión las necesidades del negocio, es una condición necesaria, pero no suficiente para hacer un proyecto exitoso. No generar formalmente una Solución Esperada significa, al menos, hacer el proyecto en mayor plazo y exceder el presupuesto, por trabajos adicionales de ajustes y correcciones por funciones no consideradas o parcialmente consideradas en la planificación del proyecto.

La Identificación del Problema o Necesidad

La primera acción formal de la ejecución de un proyecto, cual quiera sea su tipo, es identificar el problema o necesidad que se pretende resolver. A objeto de evitar ambigüedades incluyo la definición de problema de acuerdo con los diccionarios.

Problema según el Diccionario de la RAE (Real Academia Española):

Del lat. problēma, y este del gr. πρόβλημα próblēma.

m. Cuestión que se trata de aclarar.

m. Proposición o dificultad de solución dudosa.

m. Conjunto de hechos o circunstancias que dificultan la consecución de algún  ……fin.

m. Disgusto, preocupación. U. m. en pl. Mi hijo solo da problemas.

m. Planteamiento de una situación cuya respuesta desconocida debe obtenerse a través de métodos científicos.

Problem según Concise Oxford Dictionary (1995):

“A doubtful or difficult matter requiring a solution”.

 (Una cuestión dudosa o difícil que requiere solución).

                        and

“Something hard to understand or accomplish or deal with”.

(Algo difícil de entender o lograr o trata).

Para evitar un desajuste en lo que usted entrega, y lo que el cliente desea es indispensable estar de acuerdo con la definición del problema real, entender que un problema en una empresa puede ser percibido de manera distinta según sea la persona que lo observe. A veces se confunden con los síntomas o con los deseos y gustos personales.

Un problema o nueva actividad, o nuevo producto, o nuevo proyecto en el lugar de trabajo se crea en respuesta a una necesidad del negocio. Y, que precisa ser definido de la mejor forma posible a objeto de no malgastar tiempo ni recursos.

A continuación, describiré un método para identificar el Problema o Necesidad, que en estricto rigor corresponde al Análisis de Requerimiento [1], asumiendo que las acciones necesarias para resolver el problema; es decir, la solución del Problema o Necesidad constituyen, primero un Anteproyecto y, después un Proyecto.

Identificar a las Partes Interesadas

¿Por qué son importantes?

Las Partes Interesadas –Stakeholders- son personas, grupos, u organizaciones que pueden afectar a la solución del problema o al proyecto, o pueden ser afectadas por la solución del problema, o perciben que puede ser afectadas por decisiones, actividades, o resultados del proyecto, cuyo objetivo es resolver el problema.

Las Partes Interesadas pueden estar activamente involucradas en la solución del problema o pueden tener intereses que pueden afectar negativa o positivamente el devenir del proyecto que resolverá el problema. Existen diferentes Partes Interesadas que pueden tener expectativas que entran en conflicto con la solución del problema. En definitiva, las Partes Interesadas pueden ejercer influencia sobre la identificación del problema o necesidad, sea por acción u omisión.

 ¿Quiénes son las Partes Interesadas?

Para el caso de la Identificación del Problema es necesario conocer quienes son las Partes Interesadas; es decir identificar a todas las personas relacionadas con el Problema que se pretende resolver, mediante la ejecución de un proyecto. Como también todas la entidades internas o externas que tengan intereses o relación con el problema.

Quién esté designado para ejecutar la tarea de identificación del Problema debe individualizar y calificar a las Partes Interesadas, considerando:

  • Si son internas o externas a la organización.
  • Si tienen una actitud positiva o negativa respeto del proyecto.
  • Si participarán en forma activa o como consejeros.

 Ranking de Interés e Influencia

Cada proyecto tiene “Partes Interesadas”, formando el “elemento humano” del paradigma de la gestión de proyectos. Como su nombre indica, un grupo de interés del proyecto es cualquier persona o entidad con una apuesta en el proyecto —tienen algo que perder y/o algo que ganar. Esta apuesta impulsa el comportamiento, y el comportamiento impulsa los resultados.

Para el éxito del proyecto, con un mínimo de conflictos, es necesario lograr que todos los interesados estén totalmente comprometidos y motivados. El compromiso y la participación infunden orgullo de la propiedad, lo que lleva a mejores resultados, entregados de una manera más productiva. La capacidad de enganchar comienza con una comprensión completa de la identidad de los involucrados y el papel  que tienen asignado, los intereses creados, la responsabilidad y el poder de influir en los resultados finales. En términos de procedimiento, este entendimiento se obtiene a través del análisis de los interesados.

i. Identificar las Partes Interesadas

Consiste en determinar cuáles son las personas que de alguna u otra manera participan y/o influyen en la identificación del Problema o Necesidad, y a la vez establecer cuál será el rol que desempeñaran. La siguiente es una lista con los roles comunes:

  • Los Beneficiarios: Grupo / Persona que recibe un beneficio de la solución del problema.
  • Los Líderes: Grupo / Persona responsable de la gestión de la ejecución de la solución del problema o proyecto.
  • El Equipo del Proyecto: Grupo / Persona responsable de la ejecución del proyecto.
  • El Patrocinador: Grupo / Persona responsable de la supervisión y el patrocinio.
  • Los Asesores: Grupo / Persona responsable de asesorar y supervisar la identificación del Problema.
ii. Establecer Quienes Tienen Interés en la Solución del Problema (Proyecto)

Se utilizan dos dimensiones para establecer el interés en el resultado de la solución

  • Interés determinado por el Impacto. Cada solución de un problema o necesidad tiene consecuencias, que se manifiestan en una variedad de formas y grados (operativos, financieros y personales). La solución de un problema o necesidad puede cambiar la forma en que se realiza el trabajo, disminuir la responsabilidad, añadir más responsabilidad, perder poder y similares. El impacto se puede sentir de muchas maneras, tanto obvias y como sutiles.
  • Interés determinado por la Responsabilidad. Es sabido que la responsabilidad —Accountability- es un gran motivador. La rendición de cuentas se define por el grado en el que un actor se hace responsable por su papel en la solución del problema o proyecto, ya sea para ejecutar tareas asignadas, por las decisiones que toma, por el apoyo que proporciona, por su participación, actitud y contribuciones globales. Cuanto más “responsabilidad” mayor interés.
iii. Determinar Quién Tiene el Poder de Hacer una Diferencia

Se necesita mucho esfuerzo para hacer que un proyecto sea exitoso, pero sólo se necesita un pequeño acto para deshacer ese esfuerzo y tornar las cosas en la dirección equivocada. La gente (y grupos) tienen el poder para conducir los proyectos all éxito o desviar el resultado a situaciones no deseadas. Esta es la moneda de dos caras conocida como la influencia de las Partes Interesadas. En la parte positiva, la participación activa de los interesados; sin duda, tendrá una influencia positiva en el proyecto y / o proceso, y esta posibilidad debe ser cultivada. En el lado negativo, los interesados también tienen la capacidad de influencia negativa, por medio de: falta de cumplimiento, indecisión, falta de apoyo, dilación, retención de información, y similares. Para facilitar el análisis de los interesados, la influencia potencial está determinada en gran parte por la fuerza de las consecuencias probables para cada persona.

Asegúrese de que su lista esté completa: recuerde, las Partes Interesadas afectadas por el Problema o con la Necesidad podrían estar todos en una división o departamento, o podrían estar repartidos entre varios departamentos o niveles de la organización.

iv. Validar la lista de las Partes Interesadas a Entrevistar

Una vez identificadas las Partes Interesadas validar la lista con el Patrocinador —Sponsor- de la Iniciativa y/o con los Ejecutivos que autorizaron ejecutar las acciones para identificar el Problema, así mismo establecer con ellos con quienes se hará la verificación, revisión y generación de la versión final de la Definición del Problema.

Situación Actual

Para que las Partes Interesadas —Stakeholders– comprendan el problema o la necesidad es indispensable que, en primer lugar, que conozcan y entiendan como se están haciendo las cosas ahora en el área afectada de su organización. Esto es lo que en proceso de negocios se denomina as-is.

Es común que las Partes Interesada conozcan sólo una parte del proceso asociado con el problema, en particular cuando el problema afecta a varios departamentos o gerencias.

La primera tarea es precisar la situación actual del entorno donde se está produciendo el problema o la oportunidad de mejoramiento, como ser:

  • Operación as-is. Procedimientos. Reglas de Negocios
  • Procesos de Negocios afectados.
  • Personal involucrado.
  • Estructura organizacional. Gerentes. Supervisores y Operativos.
  • Sistemas o aplicaciones computacionales.
  • Infraestructura, Tecnología.
  • Países donde se opera.
  • Adquisición de otra empresa.
  • Apertura de una nueva locación.
  • Obligaciones Legales.
  • Clientes afectado.s.
  • Sobre gastos, mermas, pérdida de venta, etc.

Para ello debe ejecutar entrevistas a las Partes Interesadas con o sin interés en resolver el problema, esto permite comprobar si el problema es una necesidad del negocio o un requerimiento personal. Tener en cuenta que producto de las entrevistas pueden evidenciarse situaciones conflictivas entre las Partes Interesadas, que es necesario considerar con el debido cuidado.

i. Entrevistas a Las Partes Interesadas para establecer la situación as-is

El objetivo principal de las entrevistas es obtener de las Partes Interesada cual es el Problema o Necesidad de negocio que se precisa solucionar, averigüe que quieren y que esperan de la solución del Problema. [2]

Puede utilizar varios métodos para comprender y capturar la información de las Partes Interesadas, como ser:

  • Uso de entrevista. Converse con cada Parte Interesada individualmente. Esto le permite entender las opiniones y necesidades específicas de cada persona.
  • Realizar talleres. Esto le ayuda a entender cómo fluye la información entre las diferentes divisiones o departamentos o personas y, asegurarse de que las transferencias y coordinaciones se gestionarán sin problemas.

Al usar estos dos métodos, es una buena idea seguir preguntando “¿Por qué?” para cada requisito. Esto puede ayudarle a eliminar los requisitos no deseados o innecesarios. [3]

Recuerde, cada persona considera el Problema o Necesidad desde su perspectiva particular. Usted debe entender estas diferentes perspectivas y reunir los distintos requisitos para construir un cuadro completo del Problema.

ii. Validar la información recopilada en las Entrevistas y/o Talleres

Para cada una de las Entrevista o Talleres generar una minuta con los puntos tratados con las Partes Interesadas y, una descripción del Problema según la visión del entrevistado o de los participantes del Taller.

Enviar el documento formalmente a cada entrevistado o participante del Taller, para la validación de la descripción del Problema o Necesidad. Según las prácticas de su organización podrá enviarse por mail, por escrito, requerir firma, enviar copia al Patrocinador, etc.

Análisis Situación as-is

i. Generar la Lista de Necesidades

Compilar una Lista de Necesidades detectadas en las distintas Entrevistas y Talleres, teniendo en cuenta que esta necesidad pude corresponder al problema completo, a un cuello de botella, a indefiniciones, a puntos de mejoras o carencias, para ello utilizar una tabla como la siguiente:

Identificación Necesidad 1

ii. Validar la Lista de Necesidades

Distribuir a todos los entrevistado y/o participantes de los Talleres la Lista de Necesidades y pedirles que:

  • Validen si las necesidades identificadas corresponden o no con su punto de vista.
  • Ajusten el Ranking de las Necesidades según el criterio de cada uno de los entrevistados.
  • Incluyan comentarios si lo estiman pertinente.
  • Devolver la copia con sus respectivas modificaciones.
iii. Generar la Definición del Problema

A partir de la Listas de Necesidades, devueltas por las Partes Interesadas, generar un ranking de Necesidades general y, considerando las Necesidades que ocupan los primeros lugares establecer una primera formulación del problema. A continuación generar la definición del problema usando un formato como el siguiente:

Identificación Necesidad 2

iv. Validar la Definición del Problema con el Negocio

La Validación de la Definición del Problema y la generación de la versión final se hará con la participación de la gente del Negocio y, utilizando el procedimiento acordado al momento de validar la lista de las Parte Interesadas a entrevistar.

Comentario

En general, el aplicar un método como el propuesto es considerado, en el mejor de los casos, como una actividad que no corresponde al tamaño de la empresa y, en otros casos, que es simplemente una pérdida de tiempo. No obstante, mi experiencia señala que todo tiempo que se ocupa en las definiciones, previas a la ejecución de un proyecto, tales como: Identificación del Problema, Definición del Alcance o Producto, Anteproyecto y Plan de Proyecto son inversiones en tiempo y recursos que redundarán en una mayor probabilidad de lograr un proyecto que cumpla con los objetivos y expectativas del Negocio.

Referencias

[1] https://en.wikipedia.org/wiki/Requirements_analysis

[2] https://www.mindtools.com/pages/article/newPPM_77.htm

[3] https://www.isixsigma.com/tools-templates/cause-effect/determine-root-cause-5-whys/

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

Reglas de Negocio – Business Rules

Desde hace, al menos veinte años, existen artículos referidos a las Reglas de Negocio que las describen desde una perspectiva del “negocio” o con un enfoque de “sistemas”. En este artículo pretendo mostrar como incorporarlas en un proyecto de implementación de procesos de negocios, para ello incluiré algunas definiciones comúnmente aceptadas a objeto de tener un mismo entendimiento, presentaré un método de recopilación y una lista de los usos posibles de éstas.

En primer lugar, tenemos que entender que las Reglas de Negocio siempre han estado presentes, lo que ocurre que se han denominado de distintas maneras y se han tratado de manera parcializada. Es así como las tenemos en:

  • Parámetros, por ejemplo tasas de impuestos, porcentajes de descuentos, listas de valores posibles, etc.
  • Procedimientos, flujos, rangos de autorización, instrucciones, manejo de excepciones, etc.
  • Datos, características del dato, clasificaciones, elementos que indican como tratarlo, p. ej: activo fijo, producto para la venta, materia prima, etc.

Al no estar presente el concepto de Reglas de Negocios en un proyecto de implementación tradicional de un ERP  se genera una dispersión de la información correspondiente a las Reglas de Negocio, y una dilución de la responsabilidad de su mantenimiento y documentación.

La dispersión de la información se genera porque al no considerar el concepto en cuestión, las reglas se tratan en distintos objetos como ser: herramientas para la parametrización de un sistema, programas (codificación en duro – hardcore), estructuras de datos, reglamentos, manuales de procedimientos, conocimiento de los usuarios, entre otros. A su vez la dilución de las responsabilidades se genera por el proceso de generación; que nos es sistemático  en cuanto a la recopilación, identificación de los responsables y a la forma de documentar. En resumen, se mezclan responsabilidades propias del Negocio con las de Informática.

Por tanto, propongo que en un proyecto de implementación de procesos de negocio  se incluya una tarea con un método  sistemático para la recopilación y documentación de las Reglas de Negocio, tal que tanto las áreas del negocio, de auditoría e informática cuenten con una fuente única y válida para estos efectos.

En otras palabras a las dimensiones básicas de un proceso de negocio: Transacciones (Software), Organización (Estructura y Roles) y Procedimientos (Gobernabilidad) estaremos agregando la 4ta D, es decir, las Reglas de Negocio [1].

Definiciones
En general, todo el mundo sabe que es una “Regla de Negocios”, literalmente, es aquello que usamos para operar un negocio. Son las guías que determinan como se lleva el día-a-día de las operaciones. Sin reglas se estaría en una situación en la que cada decisión se resuelve en el momento, eligiendo alternativas caso a cado o ad-hoc, Y, este modo de operar es muy lento, costoso y puede generar resultados inconsistentes [2].

Para el término “Regla de Negocio” se tiene que para un especialista en procesos de negocio puede significar un conjunto de requerimientos asociados con los procesos, que están o no formalizados en una gramática o taxonomía  por algún tipo de mecanismo. Para el especialista en Base de Datos, puede ser un requerimiento específico que se satisface mediante la definición de alguna característica de los datos, que expresará en los valores posibles de un determinado campo [3]. Y, para la gente del negocio no son más que la “manera de hacer las cosas”.

Una Regla de Negocio define o limita un aspecto del negocio con el objeto de establecer una estructura o un grado de influencia que condiciona el comportamiento de los actores del negocio. A menudo las Reglas de Negocio están focalizadas en el control, en la forma de realizar los cálculos, otras permiten establecer las políticas, y así se tienen en cualquier actividad del negocio, que requiera que la gente actúe de una forma pre-establecida [4].

Qué NO son las Reglas de Negocio
Las Reglas de Negocio no son software. Las Reglas de Negocio pueden ser implementadas en el software, pero esto a menudo representa sólo una parcialidad de sus definiciones, ya que partes importantes quedan expresadas en los Procedimientos Manuales. También existe la posibilidad, poco común por ahora, de habilitarlas mediante una Máquina de Reglas o un Sistema Experto. De modo que se debe entender que efectivamente las Reglas del Negocio, como su nombre lo indica, son parte del negocio y, no de alguna plataforma particular de hardware / software que pudiera soportarlas.

Las Reglas de Negocio de no son “Proceso”, de ninguna forma. Roger Burlton indica que: “Se debe separar el flujo del conocimiento”. Dónde las Reglas de Negocio representan la parte conocimiento que guía al flujo, de aquí  su nombre de Regla de Negocio [2].

Recopilación
Dado que las Reglas del Negocio son conocimiento, su formulación –la acción de explicitarlas por escrito- es un proceso de recopilación, entendiendo que están en la cabeza de los empleados, a diferencia del flujo que habitualmente se documenta en un manual de procedimiento o en un workflow.

Podemos, entonces, decir que las Reglas de Negocio corresponden a un conocimiento tácito, por consiguiente el proceso de recopilación consistirá en convertir este conocimiento que tienen las personas en conocimiento explícito [5].

Es necesario tener presente que el poseer el conocimiento de determinadas Reglas de Negocio es poder. Y, que por tanto su recopilación puede tener complicaciones.

Para proceder a la recopilación de las Reglas de negocios me parece un buen punto de partida tener en consideración los principios denominados  “The business rule approach” desarrollados por Ronald Ross [5], estos son:

  • Deben ser explícitas y escritas.
  • Expresadas en términos sencillos.
  • Existen independientemente de los procedimientos y workflows (ej.: modelos).
  • Se construyen a partir de hechos, éstos se definen a partir de conceptos, los que a su vez se representan por medio de términos (ej.: glosarios).
  • Guían o influencian el comportamiento conforme a una forma pre-establecida.
  • Son motivadas por factores de negocios identificables e importantes.
  • Son accesibles a las partes autorizadas (ej.: tienen dueños).
  • Están en una fuente única (ej.: repositorio de reglas).
  • Son especificadas por las personas que tienen directa relación con ellas y que poseen el conocimiento relevante (ej.: los usuarios claves).
  • Son gestionadas –administradas- (ej.: son parte de la Gobernabilidad de los Procesos de Negocios)

Una manera simple para recopilarlas es utilizar alguna herramienta para modelar, p. ej.: modelos EPC, al cual se le define un objeto denominado Regla de Negocio el que se enlaza con:

  •  Una función, esta ligazón permite relacionarla con Roles, secuencias de eventos y facilita su inclusión en la generación de procedimientos a partir de los EPC.
Regla de Negocio conectada a una Función en diagrama EPC
     

  • A un documento –texto, planilla, etc.- donde se incluye la descripción detallada, para este efecto recomiendo utilizar la formulación Rule Speak [6] , que la pueden solicitar en español en el enlace indicado. Si bien, es cierto que algunos expertos encuentran compleja la utilización de Rule Speak a mi parece que simplifican el proceso de documentación, dado que las definiciones se especifican en español, con un expresiones sin ambigüedades.
Ejemplo de especificación de una Regla de Negocios usando Rule Speak.

El proceso de recopilación puede ser apoyado técnicamente por Business Process Expert (BPX) [7] pero, la responsabilidad sobre el contenido y mantenimiento de la Regla de Negocio es del Dueño de Proceso de Negocio, quien puede obtener información detallada de las mismas por medio de los Usuarios Claves –Key Users.

La etapa del proyecto de implementación de procesos de negocios  en la cual me parece adecuado realizar la recopilación de las Reglas de Negocios es la de Diseño o Business Blueprint.

Usos
Entre otros, el disponer de las Reglas de Negocio en un repositorio y formalmente descritas –por ejemplo en ARIS, donde pueden ser un objeto  conectado a una función en un modelo EPC y a documentos -por ejemplo en SAP Solution Manager, con sus respectivas especificaciones– se logran los resultados siguientes:

  • Visibilidad y transparencia de las definiciones de las Reglas de Negocio, tanto para la gente del negocio como para la de informática.
  • Gobernabilidad para las Reglas de Negocio: procedimiento para su creación y mantenimiento sistemático con responsable único y del área de negocios.
  • Mayor agilidad para abordar los cambios en el negocio.
  • Facilitan las auditorías – recorridos- de los procesos de negocios.
  • Lista de Reglas de Negocio por: Proceso, Responsable, Rol, Funciones.
  • Clasificación por uso: Parametrización, Datos o Procedimientos.
  • Documentación disponible centralizadamente.

Referencias
[1] https://msaffirio.wordpress.com/2008/07/26/dimensiones-de-un-proceso-de-negocio-%e2%80%93-business-process-dimension/
[2] http://www.brcommunity.com/b005.php
[3] http://www.dulcian.com/BRIM%20Documents/What%20Are%20Business%20Rules.htm
[4] http://www.agilemodeling.com/artifacts/businessRule.htm
[5] https://msaffirio.wordpress.com/2007/09/23/el-activo-conocimiento-de-informatica-knowledge-asset/
 [6] http://www.rulespeak.com/es/downloads.php