Está en la página 1de 14

Labores Soporte Factora

LABORES SOPORTE FACTORA FINAL (2) Pgina 1 de 14








Diseo y Desarrollo
Direccin de Factoras y Calidad











Labores Soporte Factora
Gua

Agosto 2010
















[Versin 2.0]



Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 2 de 14

INDICE


LANZAMIENTO DE PROYECTO ....................................................................................................... 3
GESTIN DE ENTREGAS ................................................................................................................. 4
MODIFICACIONES ............................................................................................................................. 5
GESTIN DE RECEPCIONES ........................................................................................................... 6
GESTIN DE LAS DUDAS ................................................................................................................ 7
GESTIN DE FECHAS Y RECEPCIONES ........................................................................................ 8
GESTIN DE ERRORES ................................................................................................................... 9
TIPIFICACIONES .............................................................................................................................. 10
FACTURACION ................................................................................................................................ 11
GESTIN DE USUARIOS GEF@ .................................................................................................... 12
GESTIN DE USUARIOS GEF@ .................................................................................................... 12
PLANTILLAS .................................................................................................................................... 13
1.1 CORREOS TIPO PARA UNA BUENA COMUNICACIN ................................................................ 13


Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 3 de 14

LANZAMIENTO DE PROYECTO

Factora recibir un correo e incluso puede que se realice una reunin para dar salida al
comienzo de un proyecto, donde se establecern los mtodos de trabajo y el modo de intercambio
de documentacin y donde se conocern cada una de las partes.

En dicho correo se detallar el recurso compartido, en el cual, el proyecto va a dejar la
informacin de cada una de las entregas (versionado completo, nuevos, modificaciones,
estndares de trabajo, etc.) y la factora dejar la informacin que le corresponda para cada una de
las recepciones de componentes realizadas. Este correo debe informar de las personas de
contacto de proyecto, ya que esta informacin es muy importante para el Soporte de Factora para
poder ponerse en contacto con proyecto para poder trasmitir cualquier notificacin (recepciones,
dudas, errores).

A cada factora se le comunicar el porcentaje en el cual participa en cada una de las
entregas que se van a realizar por parte del proyecto, para ello, se les enviar el calendario de
entregas que va a realizar el proyecto. Este reparto puede fijarse al principio del lanzamiento del
proyecto y variar a lo largo de la vida del proyecto por sobrecarga de factora u otros parmetros
que pueda considerar el coordinador del Centro Gestor de Factoras.



Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 4 de 14

GESTIN DE ENTREGAS

Si la factora se encuentra participando en un proyecto en el cual colabora con otras
factoras en el desarrollo de los componentes, el correo de la entrega con su correspondiente hoja
de tipificacin (F010, F011 o Fxxx) les ser remitida por el CGF, as como la informacin o
particularidades de cada una de ellas (prioridades, fechas, etc.), a cada uno de los Soportes de
Factora participantes. Es decir, el CGF ser el encargado de repartir los componentes entre
factoras segn el porcentaje acordado con cada una y les enviar un correo a cada factora
adjuntando el F0XX_Factora_X con los componentes que le corresponda.

Si la colaboracin es directa, es decir una factora asignada a ese proyecto, el Soporte de
Factora ser el que remita la entrega de componentes para realizar la formalizacin en la Web. Ya
que la colaboracin entre Factora y Proyecto es directa y Proyecto suele poner en copia a factora,
pero si fuera necesario algn cambio en la planificacin o en la priorizacin de alguno de los
componentes ser el CGF quien indique estas condiciones previamente negociadas con ambos.

Si el CGF no queda avisado de una entrega est no ser oficial y por lo tanto no quedar
documentada en la herramienta Web GEF@.

Es labor de los Soportes de Factora hacer llegar a la factora la entrega correspondiente
con la informacin necesaria para el desarrollo de los componentes asignados (F0XX con la
dificultad de los componentes, los diseos de los componentes, fechas y prioridades etc.).

Dentro de la gestin de las entregas se debe destacar los siguientes casos, por sus
particularidades:

- Rechazos de DT:
o Lo normal que se haga, aproximadamente, los dos das siguientes a la entrega
de componentes, previa checklist de verificacin por medio adjuntndola en el
correo. Es decir si los diseos no cumplen con la normativa BBVA, estn
compuestos en su mayora por cdigo y/o pseudo cdigo, etc., factora deber
rechazarlos, avisando tanto al CGF como a proyecto y cambiando el estado de
los componentes a Rechazado por factora en Gef@.

- Cancelacin DT por cambio en ms del 60% (modificacin en Web):
o Cuando un DT tiene un cambio de alcance que modifica la estructura o
funcionalidad del programa en ms del 60%, se debe indicar al proyecto que
se cancelar y se enviar como nuevo en un nuevo lote (el lote debe coincidir
con la fecha en la que se dio de alta la modificacin que es superior al 60%), a
partir del cual contarn las fechas de recepcin acordadas (que pueden ser las
mismas que las originales u otras).
o La modificacin abierta en la Web asociada a esta cancelacin se cerrar sin
coste, para evitar duplicidad de trabajo (el componente se habr dado de alta
en la pestaa de seguimiento y control).
o Este caso se debe tener en cuenta tanto para las modificaciones de programas
de produccin, evolutivos y dems, como para las modificaciones en vuelo y
modificaciones de programas ya enviados a factora.

Es importante puntualizar qu tanto para los rechazos como para las cancelaciones de DT,
factora debe consensuarlo previamente con el CGF, exponindole lo motivos que han llevado al
rechazo o a la cancelacin.

Para el tratamiento de los diferentes temas existen correos que se pueden denominar
plantillas. Estas plantillas han sido adaptadas para que reflejen cada situacin. Cada CGF deber
crear estas plantillas segn sus necesidades y para facilitar la comunicacin tanto con proyecto
como con el propio CGF.



Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 5 de 14

MODIFICACIONES

Hay que distinguir entre modificaciones de programas de produccin (evolutivos, en hoja
de control) y modificaciones de programas que ya han pasado por factora (cambios de alcance, en
pestaa de modificaciones en la Web).
Las primeras van en una entrega normal junto a los programas nuevos (aunque aparezcan
como modificaciones en el F0XX y en la pestaa de seguimiento y control). Estas s que se deben
comunicar al CGF para que actualice las fechas de entrega ya que el calado de las modificaciones
no es el mismo que el de los componentes nuevos. Se deber acordar la fecha con proyecto y
factora.

La comunicacin de modificaciones (las de la pestaa de modificaciones en la Web) al
CGF, no debe realizarse, ya que las debe de cerrar el Soporte de Factora. En algunas
excepciones (proyectos o equipos problemticos) s se puede dejar constancia al CGF, pero
siempre las deber cerrar el Soporte de Factora.

El texto de la modificacin debe ser explicativo (como lo mencionado en la Gestin de
dudas). No vale ver DT, mejora de componente, etc. Con lo que es obligacin del Soporte de
Factora denunciar al CGF estos casos para solicitar a proyecto que modifique la descripcin de la
modificacin.
Se debe perseguir al proyecto para mejorar esto, del mismo modo, cualquier modificacin
debe quedar reflejada en el diseo tcnico, y este se debe incluir en la carpeta correspondiente
(Solicitud de Cambios) del recurso compartido.



Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 6 de 14

GESTIN DE RECEPCIONES


El Soporte de Factora ser quien remita un correo tanto a proyecto como al CGF,
indicando cada uno de los componentes que han sido finalizados lote al que pertenecen.

Es importante que en el asunto de los correos venga especificado el Proyecto Lote y la
factora que realiza la recepcin y siempre comenzando con la palabra recepcin.

Es importante que el asunto de los correos estn bien informados ya que esto hace ms
fcil la tarea a los coordinadores CGF y se puede evitar si no se actualizan los datos,
modificaciones en vuelo, retrasos de factora, etc.

Los Soportes de Factora deben evitar que los componentes que se notifiquen tengan
dudas o modificaciones abiertas cuando se enva el correo a los Coordinadores del CGF, ya que
esto puede llevar a que finalmente el componente quede como no recepcionado.

Cuando factora realiza la recepcin de componentes debe proporcionar la siguiente
documentacin:

- F201 Albarn de Entrega: Listado productos entregados por Factora.

Nota: Este punto puede no aplicar a ciertos pases

- F301 Informe de Calidad: Es necesario por parte de la Factora, cargar los resultados
de este documento en la Web de Factoras (para ello se usa el botn Generar Hoja
Resumen del F301) para aquellos componentes del lote con Dificultad > 0. Tampoco
se generan mtricas de calidad para los componentes de tipologa Copy o JetForm.

Nota: Este punto puede no aplicar a ciertos pases

- C204 Casos de Prueba: Un C204 por cada componente de Dificultad > 0.

Todos estos documentos se pueden descargar del Espacio Personal BBVA dentro de
Metodologa TyO > Catlogo de Productos del CVP. Adems, cada documento tiene una pestaa
de Ayuda que explica cmo se debe rellenar.

Las Evidencias de Prueba, generalmente, se agrupan en un .zip por componente.





Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 7 de 14

GESTIN DE LAS DUDAS

Al no existir el envo de correo automtico al proyecto con la notificacin de la duda, debe
ser el Soporte de Factora quien remita al proyecto la duda o dudas informadas en la aplicacin.
Del mismo modo el Soporte de Factora debera ver si la duda que ha sido puesta desde factora
es realmente una duda vlida o procedente.

Desde proyecto podrn rechazar cualquier duda que consideren dada de alta sin motivo
alguno, ya sea porqu queda claramente explicado en el diseo o que sean cuestiones de
programacin que ya deba saber la factora.

El Soporte de Factora deber ser consciente de los problemas que pueden causar los
siguientes casos:
- Dudas de ltima hora: generan mucho ruido al proyecto. A final del desarrollo del
componente factora debera tener claro el DT de forma que si les ha surgido alguna
duda, debe de surgir al principio del desarrollo o a mitad del desarrollo, si no se puede
interpretar que factora ha comenzado demasiado tarde el desarrollo. De todos modos
se deber estudiar el caso.

- Dudas que bloquean programas sine die: se debe gestionar con el proyecto si el
programa se cancela o no y se reenva ms tarde en nueva entrega. Otra alternativa
puede ser bloquear el componente hasta que proyecto aclare la duda, siempre y
cuando este bloqueo no se alargue demasiado.

- Dudas que hacen referencia a problemas que ya estn resueltos en el DT y no ha sido
comprobado.

- Canalizacin de las dudas que llegan: existen dudas realmente reiterativas.
Terminarn no siendo razn de retraso si no se utilizan convenientemente.

- Las dudas con resolucin incorrecta impiden entregar un componente hasta que (en
buena lgica) se resuelva correctamente. Si se entrega el componente, se deduce que
la duda finalmente fue correctamente resuelta.

Las dudas deben ser explicativas. Puede que no se tenga suficiente espacio para aclarar,
pero no valen las del tipo Enviada por E-mail o comentada por telfono. La informacin debe ser
accesible y explicativa (en la medida de lo posible) en la Web y puede completarse con el envo de
un correo ms detallado si es que fuera realmente necesario. Esto no quita, qu si la duda genera
un cambio en el diseo, esto quede reflejado en el diseo y si genera una modificacin que esta
sea dada de alta a travs de la pestaa de modificaciones.

El Soporte de Factora debe garantizar la estabilidad de los diseos tcnicos, ya que la
factora es conocedora de la informacin que tiene el DT y de la informacin que se est dando en
la resolucin de cada una de las dudas y debe, el Soporte de Factora, informar al proyecto que es
necesaria la actualizacin de la informacin del DT con el contenido de la resolucin de cada una
de las dudas.

Se debe garantizar la estabilidad de los diseos por ello es vital que el punto anterior sea
llevado a cabo y comprobado por factora, si el proyecto no realiza esta labor se deber notificar al
CGF para que se ponga en contacto con el proyecto y as indicarle cuales son sus obligaciones.

No hace falta decir qu la resolucin de las dudas por parte de proyecto debe ser gil y
clara. No s ha establecido un tiempo lmite en el que proyecto debe resolver las dudas, pero es
importante que lo hagan en el menor tiempo posible, ya que una duda puede estar bloqueando el
desarrollo del componente. Esto puede ser motivo de replanificacin, pero siempre debe
consultarse al CGF y a proyecto.



Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 8 de 14

GESTIN DE FECHAS Y RECEPCIONES

Es labor del Soporte de Factora revisar los programas retrasados (fecha real superior a la
fecha negociada la negociada es la que vale a efectos de mtricas) y especificar las causas. Si
procede, se actualizarn las fechas para que no cuente como retraso (es decir se igualar la fecha
negociada, con la prevista y con la fecha real).

Ser labor del Soporte de Factora mantener al da su correo electrnico de forma que no
quede nada pendiente, y si fuera as, avisar al Proyecto o al CGF, qu queda pendiente. Tambin
debe encargarse de que los datos que hay en la Web son coherentes y en el caso en el que
encuentre una incoherencia deber avisar al CGF para que lo solucione.

Es necesario que se persiga a la factora para evitar retrasos, sin necesidad de que el CGF
persiga al Soporte de Factora para llevar a cabo esta funcin.

La anticipacin en retrasos debe ser justificada:

- No vale de nada argumentar con razones vagas, poco precisas o poco justificables
(p.e. duda de ltimo momento). La justificacin la dar el Soporte de Factora una vez
sea hablado con el Coordinador del CGF y se haya determinado correctamente.

- Programas que se entregan con retraso, especificar, cuando se entreguen. las causas
que motivaron el retraso. Actualmente slo se especifican las causas para los
programas no entregados en el plazo, pero no se aclaran cuando se entregan
finalmente. Para ello se debe usar las plantillas y formato de correos que facilite el
CGF.

- Es prioritario que sean justificaciones razonables, no vale el mtodo, por si cuela o por
si no es revisada la informacin y dems artes pueden ser usadas. Todos los casos
que se detecten puede ser que lleven a penalizaciones a las factoras que lo usen.

Es responsabilidad del Soporte de Factora cerrar las modificaciones en la fecha correcta.
En el caso de sufrir un retraso, como ya se ha explicado, se deber justificar el porqu de dicho
retraso.



Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 9 de 14

GESTIN DE ERRORES


Como es lgico la resolucin de errores debe ser prioritaria y por lo tanto su seguimiento
tambin. A parte de la resolucin de los mismos en los plazos correspondientes se debe vigilar que
no aumente el nmero de errores. Si los errores aumentasen, el Soporte de Factora de transmitir a
Factora los suficientes mensajes y notificaciones para que se esfuerce por ofrecer ms calidad en
sus desarrollos.

El tiempo mximo qu indica la web para resolver los errores es de dos das. Pero esto es
un dato orientativo, y factora debe resolverlo en el menor tiempo posible.

Se debe vigilar la excesiva libertad de las factoras a la hora de rechazar errores. Esto se
debe filtrar por los Soportes de Factora, ya que genera mucho ruido en el proyecto y eso la
factora no lo ve y lo sufre el Soporte de Factora y el CGF.

Por otro lado se debe vigilar que los errores que se abren no encumbren modificaciones, si
esto sucediera, se debera hablar con el proyecto para que abran las pertinentes modificaciones y
a la vez se subsana los errores que correspondan.

Para facilitar el trabajo al CGF y evitar posibles disputas entre Proyecto y Factora en la
que ninguna de las dos partes tiene razn, Gef@ proporciona el estado de error Rechazado-
Resuelto, lo que significa qu factora rechaza el error debido a que no ha sido error suyo, pero en
cambio lo resuelve porque no esta claro que haya sido error por parte de factora.


Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 10 de 14

TIPIFICACIONES


Los componentes de una entrega deben ser tipificados en la Web al cuarto da de haber
recibido una entrega, si no se encuentran tipificadas el quinto da pasarn a ser bloqueadas y se
tomarn como valor del componente la tipificacin inicial.

o Hoja de Seguimiento y Control:

Introducirlas siempre en la Web, independientemente de que coincidan con las
del proyecto. Factora comunicar por correo en cualquier caso y cambiar el
estado de tipificacin de los componentes a Revisado por Factora, si el CGF
est de acuerdo, las pasar a Bloqueado.

Para programas fuera de catlogo y variaciones respecto a la tipificacin
inicial. Comunicacin por correo en cualquier caso con justificacin y desglose
de la modificacin, qu tambin deber quedar reflejado en la Web,
justificando este coste. La notificacin de estos casos deber ser en los
primeros das de la construccin de los mismos. Un tipo F puede ser revisado
por proyecto y comprobar que puede realizarse de otra forma.

Para programas cancelados con incurridos, tipificar como F (para permitir
introducir coste menor), en el caso en el que no se haya incurrido nada el coste
deber ser cero.

Si se imput algo adicional a lo tipificado por cambio en vuelo, eso debe ir en la
pestaa de modificaciones, al igual que lo anterior siempre debe ir justificado.

El formato de facturacin ser resultado de la descarga de la Web una vez
introducidas y revisadas las tipificaciones. Se enviar al Soporte de Factora el
total a facturar para confirmacin o discusin.

o Hoja de modificaciones

En el caso en el que haya disminuido las horas de alguna modificacin, el
coordinador CGF lo indicar en el correo de facturacin dando sus motivos, el
Soporte de Factora deber dar su aprobacin o desaprobacin.

Revisin de costes de modificaciones. No se aceptarn modificaciones segn
catlogo que resulten improcedentes desde el punto de vista de coste (p.e.
cambiar el nombre a una variable, como es nivel 1, son. 5 horas!!!).


Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 11 de 14

FACTURACION

El proceso de Facturacin se realizar, aproximadamente, durante el 15-20 de cada mes.

El Soporte de Factora recibir un cuadro donde se les informar de los componentes
nuevos (mediante los lotes) y los componentes modificados (mediante el nmero de la
modificacin) que se van a facturar para este periodo de tiempo.

El cuadro sera similar al que se muestra a continuacin

Mes
Lote Horas Coste Tarifa Comentarios
Nuevos (De lote vAAAAMMDD a lote vAAAAMMDD)
Modif. (De nro modif a nro modif)
Total Coste

IVA o
Impuesto
Local

Total+IVA o
Impuesto
Local

Como se puede ver, a parte de la notificacin de los componentes, se incluir el total del
cmputo de la facturacin ms el IVA o Impuesto Local.

Del mismo modo recibirn notificaciones de los cambios que el CGF observase durante el
proceso de la facturacin en las tipificaciones de las modificaciones, tanto hacia abajo como hacia
arriba en el valor de la facturacin.

Una vez que la notificacin ha sido aceptada por el Soporte de Factora, el Coordinador
CGF proceder a realizar la Periodificacin, para que posteriormente el Soporte de Factora pase a
generar el Prov-10 y finalmente sea visado por parte del Coordinador CGF.

Antes y durante este proceso el Coordinador CGF puede ser que solicite al Soporte de
Factora una propuesta econmica para poder pasar a facturar.




Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 12 de 14

GESTIN DE USUARIOS GEF@

Se deben gestionar de forma ptima, se har seguimiento de la optimizacin y utilizacin
por parte de las factoras, en la Web.

El mejor momento para solicitar los permisos es cuando se lanza el proyecto, a pesar de
que este proceso es automtico es importante solicitarlos desde el principio.

Se necesita saber, para el alta de usuarios y/o permisos: los cdigos de usuarios (cuando
existan) y los que son altas nuevas. Para ello se dispone de plantillas para la solicitud de acceso
en Gef@ (Usuarios BBVA - Aplicacin Web CGF).



Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 13 de 14


PLANTILLAS

1.1 CORREOS TIPO PARA UNA BUENA COMUNICACIN

Destinatario: CGF
Descripcin: Resumen donde se indica, como a travs del campo asunto de los correos, la
comunicacin resulta ms eficiente. Estos correos tipo deben ser usados para cada una de las
acciones que llevan por ttulo.

Correos de Entrega (nuevos)

Asunto -> Entrega Factora XXXX Proyecto YYYY vAAAAMMDD, donde XXXX es la
Factora, YYYY es el nombre del proyecto tal y como aparece en GEF@, y vAAAAMMDD es el lote
al cual pertenece el elemento.
Este es el correo que llegar a factora por parte de CGF, cuando se realice una entrega o en la
comunicacin con la factora (para aquellos proyectos en los cuales no existe accin de reparto por
parte del CGF),

Importante: Se tienen que asegurar que se refleje en la hoja de Tipificacin la aplicacin a la que
pertenece cada uno de los componentes, ya que en muchas ocasiones en la misma hoja de
tipificacin se encuentran con componentes de varias aplicaciones bajo el mismo proyecto.
Algunos de los proyectos funcionan como lneas de trabajo independientes, acumulando distintos
evolutivos. El campo aplicacin se est explotando en este sentido, siendo de vital importancia a la
hora de distinguir el presupuesto/s del cual se tendr que extraer los fondos para facturacin.
En algunos aplicativos, el campo aplicacin no tiene mucha utilidad, pero ya se ha ido insistiendo
en aquellos en las que si la tienen.

Correos de Entrega (modificaciones)

En los correos de entregas de modificaciones a Factora no hace falta que se avise a CGF, ya que
al ser dados de alta en la GEF@ por el proyecto, no se requiere accin alguna por parte del CGF.
Excepcin: cuando se tengan que escalonar las modificaciones segn acuerdo con CGF (por
ejemplo, si se reciben modificaciones masivas).

Correos para Tipificar Componentes tanto para nuevos como modificaciones

Asunto -> Tipificacin Factora XXXX Proyecto Vxxxxxx
Asunto -> Tipificacin Fechas Factora XXXX Proyecto Vxxxxxx modif.

En cualquier caso, la forma de facturar ahora debe ser mucho ms gil, cumplimentando la
tipificacin de factora en GEF@ (Control y Seguimiento, o Modificaciones, segn proceda), por lo
que no ser necesario que la remitis salvo:
- para programas de tipo F, en los cuales se debe desglosar el coste ad hoc y su
justificacin. (Recordatorio: en la GEF@ slo se deben resear la justificacin, y nunca
indicando nada relativo al coste u horas en el campo Comentarios Tipificacin).
- Para discrepancias entre lo tipificado por Proyecto y lo tipificado por Factora. (Tambin en
estos casos se debe incluir la justificacin en la GEF@)

Correos de Recepcin de Componentes (nuevos)

Nuevos - Asunto -> Recepcin Factora XXXX Proyecto Vxxxxx, en el cuerpo del correo se
detallarn los componentes que se entregan, ms la informacin que est aadiendo hasta ahora.

Correos de Recepcin de Componentes (modificaciones)


Labores Soporte Factora



LABORES SOPORTE FACTORA FINAL (2) Pgina 14 de 14


Modificaciones - Asunto -> Recepcin Factora XXXX Proyecto Vxxxxx Modificaciones, en
el cuerpo del correo se detallarn los componentes que se entregan, ms la informacin que est
aadiendo hasta ahora

En los correos de recepciones de modificaciones no hace falta que copiis, ya que al ser cerrados
en la GEF@ por el Experto o la Factora, no se requiere accin alguna por parte del CGF.

Correos para Replanificar Fechas de Componentes tanto para nuevos como modificaciones

Asunto -> Replanificacin Fechas Factora XXXX Proyecto Vxxxxxx
Asunto -> Replanificacin Fechas Factora XXXX Proyecto Vxxxxxx Modif

En el cuerpo del mensaje irn entre otras cosas los componentes a replanificar y las razones y
justificaciones de la misma (qu dudas, modificaciones en vuelo, bloqueos, etc. han provocado la
replanificacin). Recordatorio: siempre hay que avisar y consensuar esto con el proyecto.

Correos para Cancelacin de Componentes tanto para nuevos como modificaciones

Asunto -> Cancelacin Factora XXXX Proyecto Vxxxxxx
Asunto -> Cancelacin Factora XXXX Proyecto Vxxxxxx modif.

En el cuerpo del mensaje irn entre otras cosas los componentes a cancelar y las razones de la
cancelacin (qu dudas, modificaciones en vuelo, bloqueos, etc. han provocado la replanificacin).
Hay que recordar que si una modificacin provoca un cambio en ms del 60% del DT, pasar a
considerarse el elemento como nuevo (previa discusin con el proyecto), y dicha modificacin
tendr que marcarse como rechazada.

Correos para Rechazos de Componentes tanto para nuevos como modificaciones

Asunto -> Rechazo Factora XXXX Proyecto Vxxxxxx
Asunto -> Rechazo Factora XXXX Proyecto Vxxxxxx modif.

En el cuerpo del mensaje irn entre otras cosas los componentes a rechazar y las razones para
ello. Ser necesario adjuntar el DT, los comentarios al mismo y el F110 (Checklist). Recordatorio:
siempre hay que avisar y consensuar esto con el proyecto.

Correos para Bloqueos de Componentes tanto para nuevos como modificaciones

Asunto -> Bloqueo Factora XXXX Proyecto Vxxxxxx
Asunto -> Bloqueo Factora XXXX Proyecto Vxxxxxx modif.

En el cuerpo del mensaje irn entre otras cosas los componentes que tienen algn tipo de bloqueo,
entendiendo por bloqueo, dudas que no se contestan, diseos que no terminan de cerrarse, falta
de componentes asociados (Copys, tablas, rutinas, etc.) y las razones para ello.

Correos para la peticin de Usuarios

Asunto -> Usuarios Factora XXXX Tipo de Peticin Proyecto, donde el tipo de peticin ser
usuarios nuevos, solicitud de acceso a Nmesis/host o Nacar y solicitud de acceso a la WEB
GEF@