Usar restricciones en P6: Restricción SNET.

September 26, 2017 | Author: HUGO CARDOZO URDANETA | Category: Calculus, Mathematics, Science (General), Science, Science And Technology
Share Embed Donate


Short Description

Descripción: A continuación se explican la restricción SNET - Start Not Early Than, de uso com&...

Description

Restricción SNET. A continuación se explican la restricción SNET de uso común al calcular las fechas de un proyecto. Se utilizará un ejemplo sencillo: Sea la secuencia A1030 → A1040 → A1050. La actividad A1050 representa un trabajo en un sitio confinado y de dificil acceso. Se modela con una restricción del tipo Comenzar en o después. La fecha en cuestión garantiza el acceso al sitio por parte de su dueño. En P6, esta restricción se denomina Start On or After y es equivalente a SNET - Start Not Earlier Than, en términos de cálculo de redes de actividades. Para aplicar la restricción se selecciona de la columna Primary Constraint Type y luego se entra el valor Primavera Constraint Date; o se activa el formulario Activity Details, Status Tab y en la sección Constraints se encuentran los campos señalados. Digamos que se restringe su inicio para el dia 23 del proyecto, esto es 02-May-11. La ilustración siguiente muestra el cálculo en P6 comparando con una red idéntica en lógica y duración:

Illustration 1: Actividad A1050 Restricción SNET aplicada - Formulario Activity Details, Status Tab Al recalcular la red (F9) en P6, se obtiene este impacto:

Illustration 2: A1050 - Sin Restricciones aplicadas. TF = 0d. para todas las actividades.

1

Illustration 3: A1050 - Restricción SNET aplicada (Primary Constraint) Observe que: • TF A1050 = 0d. (se mantiene) • El efecto se origina porque cambia la fecha ES • Dado que SNET > ES, se ha generado TF = 5d propagándose el efecto a las predecesoras. • Un cambio en la duración (EF) de A1050 no tiene impacto en el calculo de TF para dicha actividad ni para las predecesoras. Si SNET < ES se mantiene la lógica de la relación predecesora con A1040 y el valor de TF = 0. (se mantiene la ruta crítica). Supongamos que el acceso al sitio ya estaba garantizado desde el 18-Apr y la actividad comienza el 25-Apr. •

SNET (A1050) = 9 (18-Apr) , ES = 16 (25-Apr)

Illustration 4: A1050 - Restricción SNET aplicada, SNET < ES Restricción secundaria. Digamos que el acceso al sitio está garantizado solo por esos 5 dias, esto es hasta el 06-May-11. En P6, podemos aplicar una restricción secundaria a la fecha de finalización mas tardía (LF) para que finalie el 06-May-11 o antes. En P6, esta restricción se denomina Finish On Or Before y es equivalente a FNLT - Finish not later than, en términos de cálculo de redes de actividades.

2

Illustration 5: A1050 Restricción secundaria aplicada Observe que, en P6, los valores disponibles de restrición secundaria afectan las fechas mas tardias (LF o LS); esto es porque la restricción primaria ya está afectando las fechas mas tempranas. Al recalcular nuevamente, la red (F9) en P6, se mantiene el impacto para la holgura total

Illustration 6: A1050 - FNLT = LF = EF Pero ¿Que impacto tiene un aumento de duración de A1050? En la gráfica de redes:

Illustration 7: A1050 - Restricción FNLT < EF Si OD = 6, aplicando ambas restricciones TF = -1d para A1050. Observe que: •

El efecto se propaga en las predecesoras siendo TF pred = 4d. (Variación de -1 d) 3

• • •

El efecto se origina porque se afecta la fecha LF A1050. y cambia EF siendo EF > FNLT Cualquier cambio en la duración de la actividad on en ES va a generar TF A1050 < 0 Si EF A1040 finalizara el 01-May, y OD A1050 = 5d, causa el mismo impacto: TF = -1d y el efecto se propaga en las predecesoras siendo TF pred = 4d. (Variación de -1 d)

Restricciones inflexibles. Volvamos al caso en que SNET < ES. Vimos que al aplicar una restricción SNET se mantiene la lógica de la relación predecesora con A1040 y el valor de TF = 0. (se mantiene la ruta crítica). Supongamos que el acceso al sitio se garantiza solamente el 18-Apr y la actividad comienza el 25-Apr. SNET (A1050) = 9 (18-Apr) , ES = 16 (25-Apr) Como esta fecha es inflexible, modelamos con la restricción Start On

Observe que al aplicarla, no admite el uso de una restricción secundaria. Esto es porque este tipo afecta tanto fechas tempranas como tardías. Al recalcular la red (F9) en P6, se obtiene este impacto:

Observe que: • En el ejemplo, TF A1050 = -5 d • Dado que SNET < ES, se ha generado TF = - 5d propagándose el efecto a las predecesoras. • El efecto se origina porque cambia LS, ES no cambia porque P6 respeta la relación predecesora. Sin embargo el impacto es suficiente como para generar TF < 0. 4



Un cambio en la duración de A1050 (EF) no tiene impacto en el calculo de TF para dicha actividad ni para las predecesoras.

Obsérvese adicionalmente el reporte SCHEDLOG.TXT al calcular la red: La sección Activities with unsatisfied constraints alerta sobre una restricción no satisfecha (la que hemos aplicado). En este caso pareciera que estuviesemos garantizando el acceso al sitio el 18-Apr, pero eso no se cumple en términos de cálculo de fechas y holgura total.

¿Que ocurre si aplicamos la restricción Mandatory Start?

Observe que al aplicarla, no admite el uso de una restricción secundaria. Esto es porque este tipo afecta tanto fechas tempranas como tardías. Sin embargo, hay una diferencia importantísima. Al recalcular la red (F9) en P6, se obtiene este impacto:

5

Observe que: • En el ejemplo, TF A1050 = -5 d • Dado que SNET < ES, se ha generado TF = - 5d propagándose el efecto a las predecesoras. • El efecto se origina porque cambia LS, ES • No se mantiene la lógica de la predecesora ES A1040 = ES A1050 = 18-Apr . De hecho ambas actividades ahora finalizan el 22-Apr • Un cambio en la duración de A1050 (EF) no tiene impacto en el calculo de TF para dicha actividad ni para las predecesoras. Obsérvese adicionalmente el reporte SCHEDLOG.TXT al calcular la red. La sección Activities with unsatisfied relationships muestra a la actividad A1050 porque no se mantuvo la lógica de la predecesora A1040. La sección Activities with unsatisfied constraints no muestra alerta sobre esta actividad. Esto es porque la restricción se cumple (obligatoriamente).

A manera de conclusión, el uso de restricciones debería servir para ajustar el el secuenciamiento entre actividades, pero si no es manejada correctamente puede distorsionar el cálculo de fechas violando inclusive el secuenciamiento del trabajo planificado. Como recomendación final, se debe anotar usando Activity Notebooks, cualquier información necesaria para justificar el uso de la restricciones, dado que su uso puede cambiar la ruta crítica del proyecto.

6

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF