INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERIA Y CIENCIAS SOCIALES

Y ADMINISTRATIVAS

AÑO 2000 Y ADMINISTRACIÓN DE PROYECTOS

INFORME DE MEMORIA DE EXPERIENCIA PROFESIONAL

QUE PARA OBTENER EL TITULO DE

LICENCIATURA EN CIENCIAS DE LA INFORMATICA

P R E S E N T A

J O S E L U I S Q U I R O Z L E C H U G A

MÉXICO D.F. 2010

INDICE Resumen i Introducción ii Capítulo I. Practica Año 2000 1.1- Historia IBM 1 1.2- Organigrama 1 1.3 Antecedentes 3 1.4 Necesidad de Conversión Año 200 3 1.5 ¿Qué es el problema del año 2000? 3 1.6 Perspectivas acerca del problema 5 1.7 El problema del año bisiesto 8 1.8 Las PCs y el problema año 2000 9 1.9 Concientización 11 1.10 Asesoramiento 11 1.11 Renovación 13 1.12 Validación 13 1.13 Implementación 13 1.14 Planes de Contingencia 14 1.15 Capacidad de respuesta a emergencias 16 1.16 Herramientas 19 1.17 Clientes 24 1.18 Conclusiones año 2000 25 Capítulo II administración del proyecto IBM 2.1 Antecedentes 26 2.2 PMI 26 2.3 Project Manager 27 2.4 La llave del éxito del gerente del proyecto 31 2.5 Tipo de organización usada en Proyectos 32 2.6 Project Charter 35 2.7 Definición del Baseline y sus exclusiones 37 2.8 Organización el trabajo WBS 40 2.9 Manejo del Riesgo 40 2.10 Estableciendo el estimado del proyecto 42 2.11 Creando el calendario del proyecto 43 2.12 Experiencia en Manejo de Proyectos 47 2.13 Conclusiones administración de proyectos 83

Conclusiones 86 Bibliografía 87 Anexos 1.- Kickoff 88 2.- Minuta 90 3.- Reporte de Seguimiento 91 4.- Control de Cambios 92 5.- Plan 93 6.- Cierre 94 7.- Carta de Terminación 95 8.- Encuesta de Satisfacción 96

i

Resumen. En el capítulo I hablare sobre la problemática que se tuvo en el año 2000 con el cambio de siglo. Para todos aquellos que trabajábamos en el área de sistemas en 1997, recordaremos que empezaron a existir fabricas de software que empezaban analizar el impacto de cambio de siglo; los medios de información (Noticias) estaban preocupados al no saber que podría suceder, los centros financieros pensaban que podría haber una gran pérdida monetaria y sobre pagos de intereses en las cuentas; en los sistemas de gobierno se corría el riesgo de que se reportara gente con mayor edad de la que tuviera y que pasaría con los nacimientos. Además de lo anterior nuestra sociedad antes del año 2000 usábamos solo 2 dígitos para identificar el año, con el cambio de cambio de siglo muchos formatos y nosotros mismos cambiamos nuestra cultura empezando a utilizar 4 dígitos En las bases de datos por problemas de espacio se usaba solo dos dígitos y así una infinidad de sistemas y bases de datos se tuvieron que cambiar. Con la ayuda de estas fabricas de software donde tuve la fortuna de trabajar para IBM se inicio desde 1997 y se corrigieron los posibles problemas que se pudieran presentar y se estandarizo en algunos casos el software. Afortunadamente no hubo impacto para las empresas a las que se dio el servicio. En el capitulo II hablare mas sobre la metodología de lo que es ser Project Manager, desde hace mas de 10 años he tenido la suerte de administrar proyectos de tamaño mediano y pequeños, gracias a la confianza prestada por las compañías en la he trabajado. Ser Project Manager es ser el responsable directo que tiene sobre el proyecto que se esta ejecutando, y atendemos a un cliente y trabajamos para una compañía cuyo objetivo principal es hacerlo dentro del tiempo establecido, con el menor costo posible y dejándole una satisfacción al cliente de lo que nos pidió. Para alcanzarlo y estandarizar la forma de administrar los proyectos se creo el instituto de Project Managers asociación civil que dicto y escribió lo que se debe de considerar como metodología (PMBOK) y como debe desenvolverse un Project Manager, antes esta documentación solo era posible conseguirla en ingles, por lo que me hice la tarea de hacer un resumen en español para que todos aquellos que piense hacer una carrera administrando proyectos sepan que deben de considerar. Anteriormente la certificación como PMI era más simple, hoy en dia por el numero de administradores que existen, se ha vuelto más complejo la certificación, pero les recomiendo que la tomen, ya que esta les abrirá nuevas puertas.

ii

Introducción. En esta parte haré un resumen de lo que he realizado en estos 20 años dentro del área de informática, de lo cual solo describiré más detalladamente, mi experiencia de 1997 a 2002 dentro de IBM, en los proyectos conversión año 2000 y administración de proyectos. En el año 1987 entre a trabajar en Banamex como líder de proyecto en el área de Tarjetas de crédito. Mi función aquí fue la de analizar las opciones de terminales punto de venta (TPV) con proveedores nacionales y extranjeros, la implementación de soluciones en centros comerciales con estas terminales considerando las comunicaciones del equipo remoto y el procesador central. La equipos involucrados fueron: Terminales punto de venta (TPV).- Son las maquinas que actualmente se siguen

Utilizando para realizar el cargo de las tarjetas de crédito como tarjetas de debito.

Concentrador.- Cuando en un local existe mas de una TPV es necesario la colocación de un concentrador que en otras palabras en un ruteador que recibe las transacciones y distribuye la carga en más de un TPV. Línea telefónica.- Es el medio con el cual se comunican estas terminales, las cuales tienen la característica de que de cada 10 transacciones una viaja al procesador central, en el caso de las tarjetas de debito, todas las autorizaciones se realizan en línea. Servidor central.- Todas las transacciones realizadas se reciben en un equipo Tandem el cual valida que la tarjetas son validas, la fechas de vigencia del plástico y manda la información al mainframe para cargar y abonar

la compra. Si el baucher de la compra no presenta en los 10 días siguientes en el banco se cancela la compra y se restablece el saldo de la tarjeta.

Las áreas involucradas fueron:

Contratistas de cableado

El proveedor de la TPV

El dueño de local o centro comercial

El área de sistemas Aquí aprendí básicamente a tratar a los clientes, un poco sobre el protocolos de comunicaciones, programación de transacciones y monitoreo de redes.

iii

En el año de 1990 decidí salirme de Banamex y entre a trabajar en Siemens en el área de Telefonía, básicamente mi función aquí fue el de apoyar a adecuar el sistema de control de inventarios como usuario del área de sistemas, posteriormente desarrolle un sistema en Dbase para controlar las llegadas de equipo y refacciones de Alemania. La equipos involucrados fueron:

- PCs - Servidor HP

Las áreas involucradas fueron:

Área Usuaria

Almacén Aquí aprendí más sobre comunicaciones y desarrolle mi primer sistema en Dbase. En el año 1991 decidí entrar a Banco Obrero como programador en Cobol en equipo Mainframe, dándole mantenimiento al sistema de cheques y JCL´s, al poco tiempo la persona encargada del sistema se le dio nuevas asignaciones y tuve la oportunidad de quedarme como responsable del sistema, posteriormente se integraron nuevas personas al proyecto y me dieron nuevas responsabilidades como fue el sistema de inversiones, a lo largo del tiempo y cuando nació el SAR, coordine en conjunto con otro compañero de trabajo el desarrollo del sistema en plataforma cliente servidor con Cobol, así como el desarrollo de módulos de soporte a sucursales bancarias, llego el momento en que sentí que ya no tenia desarrollo y renuncie. La equipos involucrados fueron:

- PCs - Equipo Bull - Servidores AIX

Las áreas involucradas fueron:

Sucursales

Aéreas Operativas

En este trabajo fue donde consolide mis conocimientos como programador En el año de 1994 entre a trabajar en Software AG como líder de proyecto programando en Natural teniendo como base de datos ADABAS. El proyecto al cual

iv

fui asignado fue el sistema Argentaria que se estaba implementando en el Banco Interacciones y en paralelo en Banpais. Este sistema fue un desarrollo de España por el banco Argentaria y que fue comprado por Software AG de América, este sistema fue como un SAP, estaba desarrollado más del 50% en cobol y lo demás en Natural corriendo en plataforma HP-3000 con unix. Este sistema se tuvo que reprogramar sus funciones debido a que tenia los estándares de España, esto complico su implementación, además como muchas de las funciones corrían en cobol eran procesos en Batch y para el banco esto no esta funcional, por lo que fue necesario reprogramar el 25% del código de cobol a natural on-line. Cuando la solución se dejo estable y se salió con la primer sucursal para el público en general se decidió que le diera apoyo al proyecto de Banpais, pero debido a que las soluciones implementadas ahí fueron diferentes a las de Banco Interacciones no fui de gran utilidad. El sistema de solución implementado en Interacciones funciono un poco mas de un año, el mismo sistema en Banpais no pudo funcionar en un ambiente productivo y fue demandado Software AG por esta implementación y ocasiono la separación de Software AG de América de Software AG de Alemania. La equipos involucrados fueron:

- PCs - Servidores AIX

Las áreas involucradas fueron:

Banco Interacciones

Banco Banpais

Aéreas Operativas Después de 2 años decidí salirme para aprender nuevas cosas. Entre lo relevante aprendido fue el adentrarme en el mundo de las bases de datos, conocer un lenguaje de programación amigable, de facilidades para correr en línea procesos sin tener que generar JCL´s. En el año de 1996 gracias al apoyo de ex compañeros de Software a AG tuve la oportunidad de entrar a trabajar en EDS cuando aún era un área de sistemas de General Motors. En el primer proyecto en el que participe fue ISOSA que era la compañía que maquila toda la recaudación de impuestos de la Secretaria de Hacienda y Crédito Público y lo que se intento realizar fue una reingeniería de procesos, aquí aprendí sobre tiempos y movimientos, diagramas de procesos, organigramas, excell, y herramientas de flujo de datos que generaban pseudo código para base de datos. Después de haber realizado parte del análisis nos percatamos que existía demasiado personal y existían trabajos duplicados y algunos de más.

v

En ese entonces EDS llevaba el outsourcing de ISOSA y había conflictos de intereses, así como que la posibilidad de reducir plazas no era factible, por lo que se decidió en la dirección retirarse de este proyecto el cual tomo el Tec. Monterrey. Después me involucre en el proyecto de Tenencia 97 para el Departamento del Distrito Federal, este sistema fue desarrollado en Visual Basic e instalado en todas las oficinas de recaudación con equipo IBM. Al termino de esta asignación me integre al equipo de trabajo de seguros, con el cliente Probursa, ellos habían adquirido un sistema de seguros el cual se estaba adecuando a sus necesidades, aquí trabaje con Cobol en plataforma AS-400. La equipos involucrados fueron:

- PCs Las áreas involucradas fueron:

Áreas usuarias

Oficinas de recaudación Aquí fue donde inicie mi carrera como consultor – Project Manager para manejar proyectos y dejar la parte de programación. En el año de 1997 me invitaron a trabajar en una compañía que se llamaba Tecnología en Soluciones y Sistemas, que había sido comprada por IBM, y su función principal fue la de llevar a cabo la práctica de año 2000, y adentrarse en el mundo de desarrollo de sistemas. Durante 3 años participe en varios proyectos de solución de problemas de años 2000 para diferentes clientes, a partir del 2000, me involucre en proyectos de desarrollo de sistemas en proyectos dentro de IBM hasta mayo del 2002. La equipos involucrados fueron:

- PCs - Mainframe - AIX - Storagetek - AS/400

Las áreas involucradas fueron:

Diferentes clientes

Centros de computo

Proveedores

vi

Áreas internas de IBM Aquí, creo que he consolidado mi experiencia en la administración de proyectos, generación de propuestas, manejo de personal, trabajo en equipo, negociaciones con el cliente, certificación en CMM3, metodologías, pero perdí la practica en la programación. En el año del 2003 me pidió mi antiguo Jefe Gabriel Olguin a continuar trabajando en proyectos de IBM como Project Manager iniciando el area de PMs en IBM y ahí estuve hasta el 2007 La equipos involucrados fueron:

- PCs - Mainframe - AIX - Storagetek - AS/400

Las áreas involucradas fueron:

Diferentes clientes

Centros de computo

Proveedores

Áreas internas de IBM En el año 2007 HSBC, me pidió formar parte de su team de trabajo, primero para concluir el proyecto de migración de Regatta a las Squadrum que había iniciado como IBM. Posteriormente mi Jefe en ese momento me pidió me encargara de la plataforma iSeries y hacer la migración del centro de computo alterno de Reforma a Toluca, siendo esto un gran reto ya que cuando inicie esta tarea solo corría en esta plataforma el sistema de tesorería de México y Brasil y después de 3 años tuve que dejar el cargo Agosto del 2010, dejando operando sobre esta infraestructura 6 core bancarios para 4 países de latinoamerica (Chile, Peru, Colombia, Uruguay), y mas de 20 aplicaciones estándar del grupo HSBC a nivel mundial.

1

Capítulo I. Practica año 2000.

1.1 Historia IBM IBM es una empresa líder en la investigación y desarrollo de las tecnologías de la información mas avanzadas del sector, incluyendo sistemas informáticos, software, redes y sistemas de almacenamientos y microelectrónica.

1.2 Organigrama

De la estructura anterior, no tuve interacción con todas las aéreas, pero puedo hacer un resumen de las que conocí: Tecnology Services.- Es la área encargada de dar el soporte a todos los clientes de IBM, dando el servicio de soporte de centro de computo en caso de contingencia o prueba controlada, servicio de hosting y recursos para asistencia y soporte en sitio. Software Solutions.- Esta área trabaja muy de cerca con Tecnology Services y es la encargada de analizar la problemática de los clientes y dar soluciones integrales o individuales que ayuden en la automatización y control del negocio de sus clientes,

2

entre los software mas reconocidos es el Whebsphere para ambientes WEB, generación de código automático para programación UML, los productos Tivoli para respaldos, monitoreo, etc. Legal: Es el área encargada de revisar las propuestas realizadas por las diferentes aéreas de ventas de IBM, asegurando la redacción en términos legales. Financial Management: Cuando se genera una propuesta en Dólares o en Pesos Mexicanos esta área es la encargada de ver el tipo de cambio en base a la fluctuación que puede tener el peso y en algunos clientes que se realiza un financiamiento se encarga de definir el costo valor presente y futuro del precio del servicio asi como calcular la tasa de interés que se aplicara. Control TS: Al ser una empresa tan grande y para mantener un nivel de calidad en sus servicios y propuestas se creo el área de control de proyectos u oficina de control de proyectos que valida las propuestas, le da seguimiento a los proyectos, verifica su conclusión y realiza las encuestas de satisfacciones a los clientes. Nosotros estábamos debajo de Tecnology Services

Quality Ansurace: Es el area encargada de que se cumplieran las normas de IBM y los procesos Oficina de Control de Proyectos: Era la encargada de llevar el control de todos los proyectos y hacer los informes ejecutivos a la dirección Oficina de PMs: Es donde estaba y éramos los que ejecutábamos los proyectos apoyándonos de las aéreas técnicas.

3

1.3 Antecedentes: Desde 1996 IBM preocupado por el problema que se avecinaba del cambio de siglo se empezó a trabajar y generar alianzas con empresas para poder apoyar a sus clientes en el análisis y solución del problema conocido comúnmente como Y2K. Para este fin IBM compro la empresa Tecnosys que fue la fabrica de software que contribuyo con manos para apoyar a todos los clientes de IBM. Aquí describiré lo siguiente:

Antecedentes

Problemática

Metodologías

Herramientas

Clientes a los cuales apoye para la solución de este problema

Resumen

1.4 Necesidad de conversión año 2000: La sociedad se ha convertido extremadamente dependiente del uso de las computadoras así como de los avances tecnológicos en general. Estos avances han contribuido enormemente al progreso de la humanidad facilitando de manera importante todas sus actividades. Sin embargo estos avances tecnológicos también han causado grandes problemas por no haber sido implementados adecuadamente.

Problemas causados por errores en la programación de computadoras han sido responsables de serias interferencias e inclusive deterioro total de diversas actividades tales como problemas de logística, salud, financieros, de telecomunicaciones, de tráfico aéreo, etcétera. Un claro ejemplo es el llamado “problema del año 2000”.

Este problema consiste básicamente en la práctica de almacenar los años en las fechas en tan solo dos dígitos. El problema fue originado básicamente debido a que en las décadas de los sesenta y setenta, cuando el uso de las computadoras se difundió ampliamente, el costo de almacenamiento de datos era bastante caro pues además de su costo económico, implicaba perder eficiencia en cuanto a tiempo de procesamiento. Por esta razón el almacenar los años en dos dígitos era una buena solución a este problema.

1.5 ¿Qué es el "problema del año 2000"? Conforme se acerca la fecha surgen distintos comentarios acerca del llamado problema del año 2000, aparecen distintos escenarios que describen a su muy particular forma de ver las cosas lo que sucederá el primero de enero del 2000.

4

El también llamado Y2K problem (por sus siglas en inglés Y de year, 2 por dos mil y K de kilo) es considerado por muchos como un fenómeno tanto técnico como social.

Este problema consiste en que la mayoría de los programas de cómputo se escribieron considerando que los dos primeros dígitos en la identificación del año serían 1 y 9, mismos que sirven para identificar el siglo. Esto significa que, al llegar el año 2000, éste se registrará solamente con el doble cero. Los sistemas que no hayan sido actualizados asumirán que dicho número se refiere a 1900 o tal vez otro año, lo cual causará errores en operaciones lógicas y aritméticas, produciendo resultados incorrectos, y también provocará que algunos sistemas dejen de operar.

El problema del año 2000 no sólo afectará a las computadoras. En realidad puede afectar a cualquier dispositivo que contenga componentes electrónicos (chips) que registren fechas para controlar la operación de instrumentos y maquinaria. Tal es el caso de equipo médico, sistemas de seguridad, equipo para control de tráfico aéreo, elevadores, bóvedas, etc.

El problema pareciera conceptualmente sencillo y exclusivamente de carácter técnico. Sin embargo conforme se analiza con mayor detenimiento, resulta evidente que, por sus características y magnitud, su solución se torna extremadamente laboriosa además de tener fuertes repercusiones tanto administrativas como económicas. Esto quiere decir, que es necesario movilizar una cantidad considerable de recursos físicos y humanos así como también se necesita una alta capacidad organizacional para que los equipos puedan estar listos para manejar en forma adecuada el cambio de año con la transición del milenio. Orígenes:

Los orígenes del problema se remontan a las décadas de los sesenta y setenta, cuando se extendió el uso de computadoras. En ese entonces la memoria así como el almacenamiento de datos eran muy costosos. Los programas parecían mejores mientras menos recursos consumieran, es así como los programadores, quienes habitualmente trabajaban en COBOL (Common Oriented Business Language), presentan la idea de utilizar sólo dos dígitos para registrar los años en las fechas; así el 63 representaba el año 1963.

Gran parte de las operaciones que realizaban las computadoras dependían del cálculo de fechas por lo que reducir a la mitad el espacio que ocupaba el año en las fechas resultaba bastante útil.

Cuando en la década de los ochenta los costos de la memoria y de almacenamiento comenzaron a bajar debido a la llegada de nuevas generaciones de computadoras, software, programadores y usuarios de PC, se continuó con esta costumbre sin prestarle demasiada atención debido a que la abreviatura no causaba grandes problemas, la fecha aún parecía lejana.

5

No fue hasta principios de la década de los noventa cuando los problemas comenzaron a surgir. Para 1995, la conciencia de lo que pronto se conoció como el Problema del Año 2000 se habría extendido en gran medida; sin embargo, pocas compañías tomaron cartas en el asunto. El sentir general reflejaba una confianza en que todo se resolvería sin mayor problema, las compañías confiaban en que esto no representaba un riesgo y que sus programadores podrían resolverlo fácilmente.

No obstante para mediados de 1997, la perspectiva cambió en forma radical. Muchas de aquellas compañías que en un principio prestaron poca atención al problema, comenzaron una revisión formal del año 2000 así como algunos programas de ajuste. El problema era tema de foros de computación y fue difundiéndose a través de la prensa popular. Fue hasta entonces que se descubrió que la solución no sería tan sencilla además de que resultaría muy costosa.

Desafortunadamente el problema del año 2000 resulta ser sólo la punta del iceberg, pues los campos de fechas no son los únicos campos que fueron almacenados arbitrariamente para ahorrar espacio de almacenamiento. Muchas aplicaciones presentan problemas con cálculos financieros y demás tipo de información debido a que no les fue asignado suficiente espacio al momento de construir la aplicación. Este tipo de problemas que tienen que ver directamente con el ahorro de espacio en memoria ha repercutido en la creación de arquitecturas imperfectas para bases de datos y demás tipo de software.

1.6 Perspectivas acerca del problema

Con el paso del tiempo y conforme la fecha se acerca, surgen distintas perspectivas acerca de lo que pasará o de lo que dejará de pasar el 1o de enero del 2000. A continuación se presenta una tabla publicada en el periódico Reforma el 5 de octubre de 1998, que compara algunos escenarios vistos desde distintos puntos de vista:

Escenario pesimista

El mundo entero sufrirá un desabasto total porque la producción de las fábricas se detendrá totalmente.

Las aerolíneas suspenderán sus operaciones y nadie podrá volar al menos en la primer semana del año 2000.

Si una persona realiza una llamada poco antes de la medianoche del 31 de diciembre de 1999 y se prolonga hasta las primeras horas del siguiente año, entonces la llamada su cobrará con una duración de un año.

Escenario optimista

Las fábricas continuarán con su proceso de producción normalmente ya que no existe ningún indicio de que puedan tener problemas

6

Si usted desea puede regresar de celebrar las fiestas decembrinas del 99 de cualquier lugar del mundo sin ningún contratiempo viajando por avión.

Si una persona hace una llamada en estas circunstancias no hay problema de cobro, porque el año en que comenzó a hacerla aún no llega y por lo tanto no habrá registro de ella.

Escenario realista

Hay riesgo de que algún punto de la producción una empresa se vea afectada, no por fallas internas sino por problemas en algunos elementos o proveedores de la cadena de suministros.

Algunas aerolíneas anunciaron que se suspenderán sus vuelos durante un día para probar que el sistema de tráfico aéreo esté funcionando correctamente, pero no por problemas internos, sino por los sistemas de telecomunicaciones.

Existe la posibilidad de que se presenten situaciones confusas sólo si las compañías de servicio de telefonía no hicieron nada por revisar y solucionar sus sistemas.

Estos escenarios nos ejemplifican como se verán afectadas ciertas industrias desde tres puntos de vista distinto. Sin embargo, éstas no son las únicas industrias afectadas, consideremos los riesgos que representa este problema para algunas otras industrias si no se solucionaran antes de tiempo.

Finanzas En el área financiera de cualquier entidad el riesgo se refleja en problemas como son el cálculo de intereses, errores en los estados financieros, cargos y abonos a tarjetas de crédito y en general en todas las transacciones financieras que impliquen la interacción con fechas. Gobierno Los gobiernos de las naciones podrían incurrir en errores en los registros que se llevan de los impuestos recaudados, pensiones mal calculadas, retiros anticipados, errores en los juicios en trámite, registros de nacimientos, muertes, matrimonios, etc. Seguridad nacional La seguridad nacional se vería afectada en grande manera debido a que en algunos países altamente desarrollados los sistemas de defensa son controlados mediante sistemas computarizados, lo cual repercutiría probablemente en el mal funcionamiento de armas estratégicas, registros de mantenimiento erróneos, confusión en transmisiones vía satélite, etc. Los anteriores son sólo algunos ejemplos de cómo se verían afectadas nuestras actividades diarias. El mundo se ha vuelto extremadamente dependiente de las computadoras, lo cual ha beneficiado en gran manera a la sociedad, pero esta

7

dependencia no está libre de riesgos. Los errores producidos a causa de las computadoras han sido responsables de grandes problemas en distintos ámbitos de nuestra vida diaria. Equipos Biomédicos.

Los hospitales, clínicas y centros de salud utilizan diversas aplicaciones que son susceptibles a presentar fallas relacionadas con el año 2000. Esta tecnología está presente no solo en equipos biomédicos utilizados para diagnóstico y tratamiento de pacientes, sino también en los equipos de infraestructura que soportan a estos equipos. Los sistemas y los dispositivos de atención de salud que quizá sean sensibles al problema se clasifican en tres categorías generales:

1. Sistemas de información. incluye todos aquellos sistemas utilizados en laboratorios clínicos, farmacias, departamentos de radiología o bancos de sangre; sistemas de facturación y financieros; sistemas de ingeniería clínica o de control de equipo; sistemas de gestión de enfermos (programación, admisión, gestión de camas, consultas externas); archivos; almacenamiento. Los problemas pueden variar desde los errores de fecha de facturación hasta el cálculo incorrecto de la edad de un paciente.

2. Equipos Biomédicos. Un número significativo de equipos Biomédicos trabajan con base en microprocesadores y usan datos con la fecha impresa o graban datos con la fecha en el sistema.

3. Sistemas generales del hospital. Estos incluyen los sistemas usados para control ambiental, detección de incendios, alumbrado, seguridad, telecomunicaciones, calderas y transporte de pacientes.

Estos equipos deben ser evaluados según la función del mismo, el riesgo para el paciente y la importancia para el centro de salud. Las características para identificar un equipo sensible al Y2K son las siguientes:

Si el equipo esta conectado con aparatos y/o sistemas adicionales.

Si posee sistema de alarma.

Si usa la fecha para programar el mantenimiento.

Si muestra o imprime la fecha.

Si calcula edades, hora, etc.

Si hace seguimiento de datos de pacientes en múltiples usos.

Si se puede introducir el año en 2 dígitos

Si tiene un "display" digital.

8

Estos equipos biomédicos deben agruparse según su función (laboratorios clínicos, radioterapia, cuidados intensivos, quirófano, imageneología), y su probabilidad de falla.

Facturación. La facturación es un proceso complejo en empresas comercializadoras de servicios de energía eléctrica, gas, teléfonos, acueducto y alcantarillado y en aquellas que por su gran número de suscriptores involucra una gran cantidad de información. El software en el cual se encuentra implementada la facturación no es amigable y está generalmente instalado en equipos obsoletos. Las modificaciones que se requieren para garantizar su correcto funcionamiento antes, durante y después del año 2000 exigen inversiones importantes en tiempo, personal y recursos financieros. Además de las fallas propias, la facturación puede verse afectada por situaciones ajenas a las diferentes empresas, lo cual hace necesario diseñar, preparar y probar planes de contingencia.

1.7 El problema del año bisiesto

La rotación de la tierra alrededor del sol ocurre cada 365 ¼ días aproximadamente lo cual redunda en que es imposible hacer un calendario con una duración exacta en cuanto al número de días. Por tanto es necesario que cada 4 años se agregue un día más al año para compensar esa inexactitud. Evidentemente esta situación resulta más compleja de lo que pareciera, pues la diferencia de rotación no es exactamente de un cuarto de día por lo que el hecho de añadir un día cada cuatro años sólo funcionará por uno o dos siglos.

Existen tres reglas generales para determinar un año bisiesto pero una de estas reglas es tan rara que casi no ocurre. Debido a esta tercera regla, el año 2000 es un año bisiesto y este aspecto causará problemas relacionados con el problema del año 2000 el 29 de febrero del 2000.

Regla 1: Los años exactamente divisibles entre 4 son años bisiestos. Regla 2: Los años exactamente divisibles entre 100 no son años bisiestos. Regla 3: Los años exactamente divisibles entre 400 son años bisiestos.

De acuerdo con las reglas 1 y 3 el año 2000 será un año bisiesto, no obstante basados en la regla 2 no será año bisiesto. El año 2000 es uno de esos años raros donde es necesario tomar en cuenta el hecho de que el año solar no dura exactamente 365 ¼ días.

9

Las implicaciones de este problema podrían trastornar las aplicaciones del software. El año 1988 fue accidentalmente omitido como año bisiesto por algunos fabricantes de software lo que hace suponer que este incidente podría repetirse en el 2000.

El hecho de que no se registre un año como año bisiesto puede causar errores en cálculos de fecha. El origen de este tipo de problemas también se remonta a las décadas de los sesenta y setenta cuando las aplicaciones de software fueron desarrolladas sin tomar en cuenta que los años 1988 y 2000 serían años bisiestos por tanto estas aplicaciones presentan complicaciones.

1.8 Las PCs y el problema del año 2000

Uno de los mitos más difundidos gira en torno de que todos los problemas del cambio de milenio están relacionados con las minicomputadoras y los mainframes, se señala que ni el hardware ni el software para PC existían en la época del COBOL y por lo tanto son inmunes. Esto en efecto resulta erróneo pues si bien es cierto que los problemas en las PC son ínfimos comparados con los grandes problemas de hardware y software más antiguos, estos equipos no están exentos del problema, existen las situaciones críticas en ellos además de que son difíciles de resolver.

Los problemas en las PC repercuten en tres áreas básicamente:

Los chips BIOS (Basic Input/Output System) El código de los dígitos en el software comercial para PC El hábito de almacenar fechas de dos dígitos en el año en hojas de cálculo y

bases de datos.

En cuanto a los chips BIOS, es impresionante saber que algunas PC fabricadas en 1997 tiene BIOS que no satisfacen los requisitos del año 2000 . En algunos casos en posible "quemar" los BIOS (sobreescribirlos con un código actualizado) para así resolver el problema. En otros casos están disponibles chips actualizados que satisfacen los requerimientos al respecto y que los usuarios pueden solicitar al proveedor.

Sin embargo no se debe suponer que una PC determinada o alguna otra computadora funciona de manera adecuada sin realizar las pruebas de validación correspondientes.

Es posible también que existan ciertos vicios ocultos dentro de algunos programas que supuestamente satisfacen o no presentan este problema. Tal es el caso de Office, Microsoft asegura que tanto la versión estándar de Office 4 así como Office 97 satisfacen los requerimientos del año 2000, no obstante es posible que se presenten ciertos problemas con Access y Excel. Existe algo peor aún, los problemas y soluciones pueden variar de una versión a otra.

10

Podríamos decir entonces que la causa raíz del problema en las computadoras de escritorio es el BIOS pues es en esencia un intermediario entre el hardware y el software de la máquina. Entre otras de sus funciones el sistema operativo lo utiliza par enviar información a la tarjeta madre y a diversos periféricos físicos, así como recibirla de estos. El BIOS es el responsable de recuperar la fecha y hora de un chip de respaldo por una batería que es conocida como el Reloj de Tiempo Real (RTC; Real-Time Clock). El OS entonces actualiza su propio reloj con esta información. Cuando se apaga una máquina el reloj del OS deja de trabajar sin embargo el RTC sigue funcionando.

El RTC tiene siete registros que almacenan la hora y la fecha. Los primeros seis se actualizan de manera automática sin importar el estado de la computadora, cada uno de estos registros almacena un valor diferente. El problema es que el registro de los años está limitado a sólo dos dígitos abreviando 1998 como 98. El séptimo registro almacena los dos primeros dígitos del año, pero no los actualiza en forma automática. Cuando el siglo finalice los primeros seis registros se cambiarán de forma correcta pero el de l siglo seguirá siendo 19, entonces el RTC supondrá que el año es 1900.

No obstante el problema no es del todo del RTC pues correspondería al BIOS programarlo para resolver esta contingencia. Un BIOS inteligente será capaz de sobreescribir el registro de los siglos para que el 19 se convierta en 20 cuando sea necesario. Un BIOS no inteligente recuperará un 19 del registro de los siglos del RTC cuando en verdad corresponda a 20.

Este problema, de no ser resuelto, reflejará diversas reacciones en el sistema operativo. En Windows NT 4.0 así como en Windows 98 recocerá que la fecha es incorrecta por lo que la cambiará de manera automática, sin embargo un sistema operativo más antiguo, como es el caso de MS-DOS, Windows 3.x y Windows 95, supondrá que la fecha es 1 o 4 de enero de 1980. Windows NT 3.51 podría reconocer fechas anteriores a 1980 sin corregir el problema por si mismo. La

11

solución en Windows 98 no fue ampliar a cuatro dígitos el campo para el año dentro del sistema operativo, sino que en vez de 1900 el reloj interno empezará en 1930. Así los problemas que se presentarían en el 2000 sólo se prorrogarán para el 2029. El problema del año 2000 es real, está presente y es inminente que debe ser resuelto pues el tiempo es impostergable. Las organizaciones deben estar conscientes del riesgo que esta situación implica, es necesario desarrollar soluciones que mitiguen los posibles efectos que pueda causar el problema. Existen diferentes metodologías que se han desarrollado para atacar el problema, sin embargo Bryce Ragland en su libro: The Year 2000 Problem Solver, indica que todas podrían ser representadas por estos seis pasos.

Concienciación

Asesoramiento

Renovación

Validación

Implementación

Planes de contingencia

1.9 Concientización. Esta fase es en donde muchas organizaciones se encontraban en 1997 o han superado, tratando de crear conciencia a la administración acerca del problema del año 2000, es decir, hacer del conocimiento de la alta gerencia la magnitud y repercusiones de la situación.

Esta es probablemente la etapa más difícil para el equipo técnico pues no es una etapa técnica. Requiere habilidades sociales que regularmente no poseen este tipo de personas. La mayoría de los técnicos preferirían que se les asignara actividades que tuvieran que ver con su área de competencia y que se les dejara solos resolviéndolas.

Para poder llevar a cabo satisfactoriamente esta etapa, es necesario encontrar algunas situaciones que ejemplifiquen los impactos que podría tener el problema del año 2000 dentro de la organización.

1.10 Asesoramiento. Es la etapa más larga fase de todo el proceso. Es aquí donde no sólo se asesora la organización para determinar si se tendrán o no impactos ocasionados por el problema del año 2000, sino que también es en esta etapa donde se determina cuan grandes serían estos impactos en caso de existir.

12

Lo siguiente dentro del proceso es desarrollar algunas estrategias en como atacar el problema. En esta etapa es necesario que el equipo técnico se ponga de acuerdo con la administración y se determinen las prioridades que existen así como los mejores métodos a seguir en la solución del problema.

Lo primero que se debe determinar es que sistemas necesitan ser arreglados; cuales pueden o deben ser retirados o remplazados y cuales pueden continuar operando sin una intervención inmediata.

El siguiente paso es establecer un proceso de mantenimiento, documentarlo así como seguirlo rigurosamente. De esta manera se pretende tener asegurar la calidad de cualquier esfuerzo encaminado al mantenimiento. Se ha demostrado que aquellas organizaciones que documentan sus procesos tienen una mejor oportunidad de repetir ese proceso exitosamente.

Otro punto importante dentro de este proceso es el de desarrollar estrategias. Esto se logra determinando como se desarrollará el análisis de los sistemas de la empresa. Con este punto cubierto, será más fácil determinar que métodos se deben seguir para la conversión de los sistemas.

En este paso se implementarán las estrategias que se hayan desarrollado durante el proceso de asesoramiento. Es aquí donde se debe conformar completa y formalmente lo que será el equipo técnico para el año 2000 que básicamente estaría conformado por:

Líder de proyecto: quien será una persona con amplios conocimientos en el área de sistemas, pero sin lugar a dudas será una persona que haya demostrado aptitudes de liderazgo. En muchos casos la mejor manera de escoger a aquel que será el líder es permitiendo al propio equipo de trabajo elegir a quien los dirigirá pues de esta manera trabajarán de manera más confortable.

Programadores: estas personas deberán entender la estructura de los sistemas, su funcionamiento así como que tipo de información manejan. Su función será la de hacer las modificaciones necesarias al software para que cumplan con los requisitos del cambio de milenio.

Ingeniero de pruebas: es extremadamente importante contar con alguien que cuente con experiencia en cuanto a pruebas de software y sistemas. Esta persona será encargada de determinar la eficacia de las reparaciones hechas a los sistemas, regularmente este tipo de profesionales percibe errores y situaciones que para el desarrollador pasarían inadvertidas.

Consultor externo: un consultor externo es necesario para ver de manera más objetiva los avances del proyecto así como también será responsable de verificar que ningún punto del sistema se ha dejado fuera de las reparaciones.

13

1.11 Renovación. El proceso de renovación es el siguiente paso una vez que se ha conformado el equipo ideal. Existen básicamente tres maneras de corregir el problema: 1.- Reemplazar el sistema

2.- Renovar el sistema

3.- Retirar el sistema

Corresponderá al equipo de trabajo determinar de que manera se pretende atacar al problema. Con las estrategias desarrolladas se procederá a llevar a cabo las correcciones por la que se haya optado y de esta manera solucionar la situación.

1.12 Validación. La validación es evidentemente una etapa crítica. El problema del año 2000 fue provocado en gran medida porque no se le tomó mucha importancia a esta etapa cuando se desarrollaron los sistemas. En esta etapa se incurre en el error de sobrestimar la capacidad de los desarrolladores y se intuye que el producto que se está utilizando es de máxima calidad. Muchas veces esta etapa no es llevada a cabo debido al tiempo con el que se cuenta; aun cuando no se esté seguro del optimo funcionamiento del producto.

Las pruebas de software y la validación son etapas que van ligadas íntimamente. Es necesario hacer tantas pruebas como sea necesario para asegurarse de que el software es en verdad confiable. Las pruebas podrían dividirse en las siguientes fases:

o Pruebas durante el asesoramiento o Pruebas durante la renovación o Pruebas operacionales durante la implementación

La planeación y ejecución de todas estas pruebas es crucial en el proceso. La planeación de pruebas se debe llevar a cabo durante el asesoramiento. Por último es importante recalcar que hay que dar a las pruebas la importancia que se merecen.

1.13 Implementación. La etapa de implementación tiene que ver con las interfaces externas. Durante el proceso de validación, se debieron probar estas interfaces. Lo que hay que verificar en esta etapa es que los datos que proporcionan los sistemas sean en verdad correctos. Existen diversos tipos de problemas que deben ser previstos antes de llegar a la etapa de implementación. Se deben desarrollar planes de contingencia

14

para atacar los contratiempos que se llegaran a presentar después de la liberación de los sistemas corregidos. Se debiera llegar a esta etapa cuando menos seis meses antes del cambio de milenio para tener plena confianza de que los sistemas cumplen satisfactoriamente las soluciones implementadas.

Este proceso puede ser implementado en casi cualquier organización. Se tendrán que hacer los ajustes necesarios para que funcione adecuadamente en cada organización.

Los usuarios de computadoras no deben quedar fuera del proceso de conversión al año 2000. Se ha estimado que si se solucionarán todos los problemas al respecto con las grandes empresas, aún se tendría la mitad del problema por solucionar pues los usuarios de computadoras personales también tienen el problema en algunos casos y es necesario resolverlo.

1.14 Planes de contingencia.

El problema del Año 2000 está presente en todos los sectores y actividades económicas, implicando riesgos de falla en operaciones y procesos críticos fundamentales para cada entidad. En ningún caso existe garantía total de estar exento de fallas con la llegada del Año 2000, principalmente por tres razones:

Es altamente probable que el tiempo disponible y los recursos económicos, humanos y tecnológicos no sean suficientes para corregir todos los problemas y probar completamente las soluciones desarrolladas. Es utópico pensar que todo podrá repararse.

No existen garantías sobre el éxito de los esfuerzos para corregir el problema. El año 2000 no tiene precedente y no es posible asegurar plenamente el correcto y continuo funcionamiento de cada sistema, aislado o en su relación con otros sistemas.

No se puede garantizar que cada sistema, interfaz, y socio comercial cumpla con los requerimientos del año 2000. A pesar de los esfuerzos que haga su entidad para ser diligente, no podrá controlar las posibles fallas en su sistema, a causa de las interrupciones en las empresas de servicios públicos, en las de comunicaciones y en los vínculos con socios y clientes comerciales.

En caso de presentarse alguna falla, se debe tratar de minimizar el impacto tanto dentro como fuera de la organización. Los planes de contingencia permitirán mantener la continuidad en las operaciones críticas de su entidad y minimizar el impacto negativo sobre la misma, su entorno, sus empleados y sus clientes. Deben ser parte integral de su proyecto Año 2000 y servir para evitar interrupciones, estar preparado para fallas potenciales y llevar hacia una solución permanente lo más rápido posible.

15

Un plan de contingencia tiene las siguientes características esenciales:

Garantiza la continuidad de un proceso crítico por medio de su ejecución

Constituye un mecanismo alterno de operación (diferente al mecanismo usual)

Cumple requisitos mínimos de calidad, alcance, seguridad, operaciones, etc.

No replica la operación normal del negocio

Está diseñado para aplicación temporal únicamente

Contempla los mecanismos para el regreso a condiciones normales de operación Postergación u omisión del proceso Es necesaria la planificación de contingencias del año 2000 en todos y cada uno de los procesos vitales en la operación de su organización. Además, debe hacerse para todo aquello cuyo control escapa de sus manos. La elaboración de planes de contingencia requiere un cuidadoso análisis para determinar si está disponible cualquiera de las alternativas usuales. A continuación, en la Tabla 1, se listan los seis pasos para elaborar y poner en práctica los planes de contingencia.

Pasos para hacer planes de contingencia

PASO DESCRIPCIÓN

1. Evaluación Conformación del equipo de trabajo, definición del alcance, identificación de escenarios de falla y priorización de los riesgos

2. Identificación y selección de alternativas

Construcción de los planes de contingencia, identificación de los eventos activadores (criterio para utilizar los planes), prueba de los planes, capacitación del recurso humano

3. Diseño del plan de contingencia

Es la fase más extensa. En ella se consolida el plan de contingencia y sus objetivos, se determinan los recursos requeridos, se definen los criterios de activación, las responsabilidades y la duración de la implementación y se estructura la operación y administración del plan. También se definen los criterios para el regreso a la condición normal y los requisitos de capacitación y pruebas

4.Implementación del plan de contingencia

Llevar los planes de contingencia más allá del papel, asegurando su efectiva y rápida puesta en funcionamiento. Incluye adquirir o preparar equipos y procedimientos requeridos, capacitar al personal involucrado, realizar pruebas y, en general, asegurar que todo pueda funcionar oportuna y correctamente si los eventos activadores así lo exigen.

5. Ejecución del plan A partir de un evento activador se implementa el plan de contingencia

6. Recuperación Corresponde al tiempo destinado para desactivar las operaciones de contingencia y reiniciar los procesos primarios de las operaciones normales . En esta fase, tan pronto como sea posible, se pasará de las operaciones de

16

contingencia a una solución permanente.

1.15 Capacidad de respuesta a emergencias

Introducción. Como se había planteado anteriormente, no existe seguridad de que el 100% de los sistemas, interfases y relaciones con terceros, pasarán sin problemas la llegada del Año 2000. Esto implica la preparación para escenarios probables de falla . Ya se ha explicado cómo los planes de contingencia son vitales en la disminución del impacto de posibles problemas que se puedan presentar. No obstante, el año 2000 no tiene precedente, y es en general imposible contemplar de antemano todos los sucesos posibles. Por ello, toda entidad debe preparar una capacidad de respuesta a emergencias (CRE) que pueda: (1) coordinar, de ser necesario, el desarrollo de los planes de contingencia que sea necesario durante el cambio de año y (2) reaccionar ante eventualidades imprevistas diferentes a las contempladas en planes de contingencia. Se puede comparar la CRE con una sala de emergencias de un hospital, que recibe diferentes tipos de problemas, los prioriza, los clasifica, los asigna a los diferentes especialistas, y les brinda respuesta con la mayor rapidez posible. La CRE es un recurso necesario para enfrentar situaciones inesperadas, previstas o no, con la llegada del Año 2000. El principal objetivo de la CRE es garantizar los niveles mínimos de funcionamiento en una situación de crisis.

Habilidades. La CRE debe tener, entre otras, las siguientes habilidades: • Condiciones suficientes para coordinar la ejecución de planes de contingencia,

según el diseño y la implantación explicados anteriormente en este documento. Se debe contar con toda la información y recursos necesarios para la ejecución de los planes que estén bajo su responsabilidad. Debe tenerse en cuenta que la CRE no se limita a la ejecución de planes de contingencia, ya que existe la posibilidad de que se presenten emergencias que no han sido previstas.

• Monitoreo y evaluación del impacto de las posibles fallas internas que se puedan

presentar. Pueden ser fallas ya analizadas o problemas que no han sido considerados. El CRE, entre otros, debe evaluar el impacto de la ejecución simultánea de varios planes de contingencia, que puede generar en sí una situación de crisis. Por ejemplo, si se activan los planes de contingencia para cierre de varias sucursales en un mismo banco, la situación generará una crisis para la entidad como un todo, que seguramente no fue contemplada en los planes a nivel de sucursal.

17

• Identificación, comunicación y seguimiento a entidades afines relevantes, para la detección de posibles fallas. Esta comunicación permitirá anticipar posibles impactos sobre procesos de la entidad que dependan de terceros. Por ejemplo, si los proveedores de la entidad han presentado fallas importantes, la entidad probablemente enfrentará una escasez de suministro durante los primeros meses del año.

• Planeación y diseño de procedimientos para la solución rápida y efectiva de

problemas. Los procesos para toma de decisiones deben estar previamente acordados, entendidos y probados; de lo contrario, el pánico que genera la crisis potencial evitará la toma de decisiones y acción efectiva de respuesta.

• Coordinación de empresas, personas y recursos para responder a la situación.

Incluye todos los equipos requeridos, y la capacitación del recurso humano involucrado.

• Comunicación interna y externa sobre el impacto de la situación y las acciones

que se deben tomar. Se deben incluir empleados, clientes, proveedores y público general afectado, así como autoridades sectoriales o nacionales de ser necesario.

Componentes. La capacidad de respuesta a emergencias debe contar antes, durante y después del día cero los siguientes componentes, coordinados local o virtualmente: • Personal disponible. Es el recurso más importante de una buena CRE.

Usualmente, se tiene un director que coordina las actividades, y dos grupos funcionales:

Logística y Comunicaciones: Debe preparar el equipo de trabajo y los recursos necesarios, capacitar al personal, planear y suministrar información, emitir comunicados si es necesario, y en general, mantener toda la infraestructura requerida para el funcionamiento de la CRE.

Respuesta a Emergencias: Debe establecer contactos con las unidades del negocio y con otras empresas, desarrollar guiones de posibles fallas, monitorear la situación para detectar problemas, crear, asignar y coordinar los equipos de respuesta, y dar soporte a las unidades del negocio en caso de ser necesario. Por lo general, los equipos de respuesta tienen un representante de la unidad del negocio afectada, y un pequeño grupo de especialistas en la situación particular.

• Líneas de comunicación internas y externas: para identificar cualquier

eventualidad con la mayor rapidez posible, y del mismo modo comunicar a los equipos de respuesta. Se sugiere tener varios medios de comunicación, en caso de que fallen los sistemas de telecomunicaciones.

18

• Ubicación: no es necesario que la CRE sea una oficina, puede tener una

ubicación virtual. Lo importante es que se tenga la posibilidad de localizar a todo el personal rápidamente, y se cuente con el espacio físico que sea necesario.

• Recursos tecnológicos y físicos: tales como plantas eléctricas, teléfonos, radios,

equipos de primeros auxilios, suministros de primera necesidad, etc. • Sistemas de seguimiento y monitoreo: tanto para detectar fallas, como para

efectuar un seguimiento permanente a la evolución de las situaciones de falla, las emergencias, los planes de contingencia, etc.

• Documentación: planes de contingencia, contactos, eventos, inventario de

aplicaciones, etc.

Factores Críticos de Éxito. Es importante tener en cuenta los siguientes factores para que la CRE sea rápida, efectiva, y logre cumplir su propósito, es decir, garantizar el funcionamiento mínimo requerido en la organización: • Autoridad suficiente para lograr la colaboración de las diferentes áreas de la

empresa en la planeación y ejecución de la estrategia de emergencias. • Entendimiento profundo del problema del Año 2000 y sus posibles

consecuencias. • Priorización de problemas y situaciones de emergencia. • Relación estrecha con todas las unidades del negocio, operaciones relacionadas,

y proveedores críticos. • Canales de comunicación múltiples, conocidos por el personal y probados. • Procedimientos eficientes y ágiles para la respuesta a problemas. • Capacitación de todo el personal involucrado. • Coordinación de un gran número de recursos. Finalmente, se recomienda integrar este esfuerzo a capacidades existentes, y no tratar los problemas de Año 2000 aisladamente. Las entidades enfrentan situaciones de crisis con cierta frecuencia, por lo cual existen ya en alguna medida procesos para respuesta y toma de decisiones.

19

Esta metodología para generar y ejecutar un plan de contingencia fue enfocado inicialmente para dar solución a problemas Y2K, pero su base puede ser utilizada para generar cualquier plan de contingencia en el desarrollo e implantación de sistemas mayores donde se requieran. Esto también lo veremos en la parte de formación de PM´s.

1.16 Herramientas Muchos de los proveedores de software y compañías de consultoría desarrollaron sus propias herramientas de trabajo para evaluar y corregir el problema del año 2000, en el caso de IBM desarrollo sus propias herramientas para cada plataforma y fueron: Mainframe. Debido a que el proceso de análisis en Mainframe era lento y consumía demasiados recursos, la opción fue el pasar este código a una PC donde seria analizada con la herramienta Revolve. Esta herramienta analiza código cobol, JCL´s y las relaciones entre los programas y tiene un modulo que realiza la solución de ventaneo. También analiza las FD´s y su longitud en caso de que se cambie alguna redefinición. Cuando el sistema estaba desarrollado en Natural se transfería el código a un equipo AIX, donde se corría una herramienta que se llama Natural 2000, esta herramienta generaba listados con las líneas impactadas por programa y posteriormente la corrección era manual. El análisis y solución de programas desarrollados en Ensamblador era de forma manual. Unix/Aix Las aplicaciones desarrolladas en cobol también eran transferidas a una PC para sus análisis y corrección con la herramienta Revolve, pero los Shells no podían ser analizados por esta herramienta, por lo que el análisis se realizaba en unix con sus propias utilerías. Para definir el inventario de los objetos era necesario realizarlo manualmente, buscando los “Call” internos de los programas y los llamados dentro de los shells. Si el código ya estaba en Natural, se transfería a equipos del laboratorio donde era analizado la aplicación.

20

AS/400 Las aplicaciones desarrolladas en RPG que corren es estos equipos eran analizados por una herramienta que se llama ADAMS/4000; esta herramienta nos permite analizar el impacto de los programas, pero la solución se hace manual. Todas las herramientas antes mencionadas tienen el mismo principio que es la de analizar en base a patrones y constante de números y después de un análisis manual se identifican cuales son los programas impactados. También las herramientas nos permiten entrar y salir con gran facilidad de un programa a otro.

21

22

NATURAL.

23

24

1.17 Clientes. Inicialmente cuando empezamos a analizar el problema de año 2000, se dividío en dos partes una conocido como Fase 0 donde le decíamos al cliente que tan infectado esta y otro donde ya le hacíamos la remediación al problema.

- Avon Análisis y Remediación - Bancomex Análisis - Serfin Análisis y remediación - Xerox Análisis y remediación - Banco de Venezuela Análisis y remediación - Banco de Colombia Análisis y remediación - Goodyear Chile Análisis

25

1.18 Conclusiones año 2000: Durante esta etapa de mi vida tuve la oportunidad de conocer muchos clientes, permitiéndome tener un mejor desenvolvimiento con los clientes, a aprender a manejar equipos de trabajo grandes (40 personas en el proyecto de Xerox y un promedio de 18 en los demás proyectos) En la mayoría de los clientes la solución fue ventaneo debido a que la expansión de campos involucraba el modificar no solo a aplicación, si también todas las interfases que se tenían, muchas de estas externas al cliente. Solo en los casos donde la fecha formaba parte de la llave de sorteo de los datos, fue necesario la expansión, en los demás casos se seguía la política de ventaneo. En el caso de cobol, la función de sorteo de fechas se soluciono con un fix en el lenguaje o compilador.

26

Capítulo II.- Administración del proyecto IBM

2.1 Antecedentes Gracias al apoyo brindado por la compañía tuve la oportunidad de llevar la administración de proyectos como Gerente del proyecto, en otros como Project Manager y por ultimo coordinar la administración, ejecución de los proyecto de un área especifica de IBM ITS encargada de la línea de soporte y soporte en sitio de la infraestructura de productos IBM. Aquí describiré lo siguiente:

Resumen de los puntos más relevantes a considerar en la administración de proyectos, considerando lo que es el PMI.

Proyectos en los que participe

Tips

Resumen

2.2 PMI

Project Management Institute (PMI), es la institución de profesionales no lucrativa más grande del mundo. El PMI representa a los profesionales en dirección de proyectos a nivel mundial. A través de la membresía en PMI y el grado como profesionales en dirección de proyectos (PMP) la gente ha podido demostrar su valor ante cualquier organización que compita en el creciente y cambiante mercado hoy en día.

PMI Internacional fue fundado en 1969 con socios voluntarios. Durante los años setenta PMI se desarrolló principalmente en el campo de la ingeniería, mientras tanto el mundo de los negocios desarrollaba sus proyectos a través de especialistas de la misma empresa y formaban grupos de trabajo llamados "Task Force". Para los años ochenta, el mundo de los negocios comenzó gradualmente a dirigir sus negocios por proyectos.

Durante este tiempo el PMI, a través del comité de estándares y colaboradores (entre ellos empresas, universidades, asociaciones de profesionales, especialistas y consultores en proyectos) realizó el estudio, evaluación y revisión acerca de los estándares aceptados a nivel internacional, dando como resultado los estándares que representan el cuerpo de conocimientos generalmente aceptados de la Dirección en Proyectos, cuyo título original es "Project Management Body of Knowledge" (PMBOK). En 1987 se publicó su primera edición y en 2000 se ha generado una nueva versión más actualizada.

PMI tiene como objetivo establecer los estándares de la dirección de proyectos, mediante la certificación profesional y agrupar a profesionales de diversas áreas e industrias. Así mismo, se ha dedicado a estudiar proyectos que han seguido o siguieron los estándares establecidos por el instituto.

27

Por lo anterior, desde su fundación en 1969, PMI se ha convertido en una de las primeras organizaciones especializadas para industrias como ingeniería, aeroespacial, servicios financieros, servicios domésticos, automotriz, construcción, farmacéutica, manufactura, telecomunicaciones y tecnología de información, entre otras.

Actualmente, el PMI cuenta con más de 50,000 socios activos a través del desarrollo de actividades profesionales de la dirección de proyectos. Así mismo, representa a más de 40 países y 106 ciudades del mundo, entre ellos México

Los objetivos estratégicos del PMI México son los siguientes:

Difundir y consolidar la imagen del PMI en México.

Promover los conceptos del PMBOK a través de los profesionales de México.

Promover la Dirección de Proyectos como una profesión reconocida mundialmente.

Compartir la experiencia internacional, a través del desarrollo de profesionales nacionales e internacionales.

Desarrollar calidad en los recursos humanos para la Dirección de Proyectos.

Compartir los conocimientos generalmente aceptados que dan reconocimiento a la profesión en nuestro entorno.

Consolidar estándares internacionales para el entorno nacional.

Certificación de profesionales en proyectos reconocidos mundialmente.

2.3 Project Manager IBM de México preocupado por la correcta administración de proyectos implemento una serie de cursos que permita a sus Project Manager´s una correcta y misma forma de administrar proyectos. A continuación mencionare alguno puntos relevantes y generales de este proceso de capacitación; definiendo algunos conceptos y metodologías. Que es un proyecto? Un finito esfuerzo de:

28

Tiene un definido Inicio y un Definido Fin Es único Consume recursos

Que es un subproyecto? Parte del manejo de un proyecto con un nivel de independencia. Que es un administrador de proyecto? Es la aplicación del conocimiento, skill, y herramientas para las actividades del proyecto, subproyecto y programas para reunir o exceder los objetivos (stakeholder). La administración de un proyecto requiere de un Gerente: Comunique Coordine Construya un equipo de trabajo Resuelva posibles problemas Integre Ejecute Planee Presupueste Controle Cubra las expectativas del cliente Fases del proyecto: Los proyectos son normalmente divididos en Fases Colectivamente estas fases son llamadas Life cycle Los ciclos de vida del proyecto son similares pero dificilmente identicos Existen 3 formas de observar un proyecto: CRM (Customer RelationShip) Fase 1 Diseño de la solución Fase 2 Entregable de la solución En las buenas relaciones se debe de considerar el manejo de la oportunidad, identificar la oportunidad, validar la oportunidad, calificar la oportunidad y seleccionar la oportunidad. Durante el diseño de la solución debemos de definir la solución, crear la propuesta y obtener la aprobación. Y durante el entregable de la solución debemos de realizar la entrega, el kickoff de inicio y al final la encuesta de satisfacción del cliente.

29

Este enfoque es mas hacia los vendedores que desarrolladores de soluciónes. IPD (Integrated Product Develoment) Fase 1 Concepto Fase 2 Plan Fase 3 Desarrollo Fase 4 Calificar Fase 5 Lanzar Fase 6 Ciclo de vida Durante el proceso de selección de un producto, debemos de considerar el desarrollo de los requerimientos del producto y su concepto, definición del producto y su plan del proyecto, desarrollo y verificación del producto, calificar y certificar el producto, entregar el producto y administrar el ciclo de vida. PMBOOK Fase 1 Concepto Fase 2 Desarrollo Fase 3 Ejecución Fase 4 Terminación Este es el ciclo de vida de todos los proyectos, independientemente del enfoque con el que se maneje. Por lo antes mencionado se considera que: Proyecto = Negocio mas pequeño Ya que ambos: Consumen recursos - Staff - Equipo - Facilidades Tienen un medio a su alrededor (Stakeholder) quienes: - Invierten - Definen objetivos - Demandan un beneficio de capital Tienen factores críticos del éxito: (DESICION) - Costo - Plan - Calidad Tienen blanco financiero: - Trabajar dentro del presupuesto - Control de costos

30

- Deben de generar un ingreso y una ganancia - Tener un flujo de efectivo positivo. Así como de las cualidades de las que requiere un gerente antes mencionadas, el gerente es responsable de: - Responsable del proyecto - El único punto de contacto para el proyecto - Responsable de identificar los stakeholders Los stakeholders del proyecto son: - Son las personas quienes tienen un interes o rol en el proyecto. (Procurement, Legal, Finance, Project team, Quality assurance,suppliers,client) Analisis de Stakeholder Identifique todos los Stakeholder (Identificar a todos los participantes involucrados

en el proyecto) Identifique si es amigo o enemigo Utilice a los amigos para llevar a los enemigos en línea Del restante enemigos determine:

Como medirlo Como recompensar

Desarrolle e implemente una estrategia de Ganar/Ganar para llevar a los enemigos en línea

Recuerde: Siempre existirá alguna forma de enganchar a los enemigos, para el éxito del

proyecto Usted no tiene que gustarle a todos para el éxito del proyecto Guarde su ego donde este se necesite para estar seguro del éxito del proyecto Papel de un project manager: Plan del proyecto - Actividades técnicas - Administración de las actividades del proyecto Manejo de la triple restricción Cliente/Proyecto/Gasto(Debe de existir un balance) - Calendario - Costo

31

- Especificaciones Organice el proyecto incluyendo: - Formación del equipo del proyecto - Seleccione el sistema para documentar el proyecto - Seleccione el plan del proyecto por el cual el proyecto puede ser controlado Usted puede manejar el proyecto con: - Seguimiento técnico por la triple restricción - Seguimiento financiero del proyecto - Evaluación y manejo del proyecto por los factores de riesgo - Trato a los posibles problemas, problemas que ocurran durante el proyecto - Seguimiento a los proveedores y sus contratos - Asegurar la satisfacción del cliente - Construir y mantener la moral del equipo de trabajo - Comunicación con los involucrados del proyecto - Manejar al equipo de trabajo incluyendo terceros - Seguimiento en la utilización de los recursos - Usar el procedimiento de control de cambios - Cierre del proyecto

2. 4 La llave del éxito del gerente del proyecto: Rango prolongado de expectativas Hable sobre el riesgo y sea emprendedor Clarifique objetivos Innovador y creativo Participe resolviendo problemas Sistematice el pensamiento y la planeación Estrategia de encuesta Conciencia política Facilitador entre los miembros del equipo Desarrollo del equipo Asertividad Retroalimentación a los miembros del equipo Relación con el gerente funcional Optimizar los estándares Manejar Presión de objetivos Delegación Reconocimiento a lo mejor

32

Conducta para el éxito del gerente del proyecto:

Ser proactivo Pruebe nuevas ideas Preserverar Orientarse a los objetivos Comunicación Motivación Ser organizado Priorizar Ser sensitivo a la gente y a la situación Facilitador Apoyar Innovador Honesto Realista Dar criticas cuando se requieran Listo Planear Pensar sistemáticamente Asertivo Decisivo Confidente Constructor del equipo Perseguir la excelencia Entusiasta Enérgico Delegar A favor Mantener contacto Sensitivo cuando se requiere y se necesite Elogiar cuando sea apropiado

2.5 Tipos de organización usada en proyectos. - Funcional - Proyectizada - Matricial Proyectos en una organización Funcional. En la organización funcional cada trabajador pasa a responder ante varios supervisores o jefes. Cada supervisor o jefe solo supervisa a los obreros en los asuntos de su competencia. Los trabajadores deben recurrir ante una situación problemática al supervisor más adecuado para resolver su problema, evitando pasos intermedios con jefes de grupo, cuya atribución seria limitada solo a su especialidad.

33

Por ejemplo, un jefe de producción se especializaría solo en ese campo y no tendría competencia en problemas como la rotura de una maquinaria.

Proyectos en una organización Proyectizada. Es donde la mayor parte de los recursos de la organización está involucrada en los proyectos, y los gerentes de cada proyecto tienen gran independencia y autoridad. Las organizaciones proyectizadas muchas veces tienen unidades organizacionales llamadas departamentos, pero estos grupos regularmente proveen servicios de soporte a varios proyectos, por ejemplo, sueldos y beneficios, limpieza, seguridad, etcétera.

34

Proyectos en una organización Matricial. Las organizaciones matriciales involucran, la estructura tradicional Los miembros del equipo son dibujados para varias líneas o unidades funcionales

de la organización Las organizaciones matriciales son complejas y presentan retos para la

administración de proyectos. Los retos involucrados:

Autoridad/Responsabilidad de el gerente del proyecto y el gerente funcional Flujos de comunicación

Manejo en la matriz. - El éxito de la operación depende de las actitudes, acciones y actividades de la gente involucrada - Un estatuto de proyecto asigna autoridades y responsabilidades para el manejo del proyecto, es extremadamente útil. - El gerente del proyecto y el gerente funcional tienen que trabajar en una buena relación. - El gerente del proyecto se esfuerza por que se realicen los trabajos principales a través de la negociación o su líder. - Los miembros del equipo tienen que adaptarse a reportar a 2 jefes.

35

2.6 Project Charter El estatuto del proyecto es un documento formalmente reconocido de la existencia del proyecto. Este incluye: - Las necesidades de negocio del proyecto por el cual fue concebido por la dirección - Una descripción del producto, este documento este documento generalmente tiene las características del producto o servicio y dibuja la relación entre el servicio y las necesidades de negocio. Principio del estatuto del proyecto. Establecer el alcance Sea tan conciso como sea posible Nombre del gerente del proyecto como del responsable y de quien autoriza en la

organización Identificación de entregables, calendarios y presupuesto Identificación de papales (Roles) Construcción básica del equipo: Un equipo:

36

- Es un número de individuos asociados para una acción conjunta - Incluye gente de la organización, proveedores y cliente, responsables - Conjunta talentos para alcanzar un objetivo Desarrollo del equipo: - Esforzar las habilidades del entorno - Esforzar las habilidades del equipo y sus funciones Cuando un grupo de individuos vienen a un equipo, estos individuos: - Vienen obligados a alcanzar un objetivo - Aprendan a trabajar bien juntos y a disfrutarlo - Producir resultados de alta calidad Como construir un equipo? - Seleccione a los miembros del equipo correctos + Identifique las necesidades del skill del proyecto + Valide los requerimientos del skill y recursos - Organice el equipo + Identifique a todos los gerentes del subproyecto + Prepare el estatuto de la organización + Establezca niveles de delegación - Asegure una comunicación abierta - Inspire a los integrantes del equipo a ser los mejores - Incorpore a nuevos miembros como ellos disfruten durante este ciclo de vida Consideraciones multiculturales del equipo - Costumbres sociales - Diferencia de horarios - Ingles como segundo lenguaje - Practicas de protocolo - Practicas de documentación

37

Team Charter. - Escriban los objetivos del alcance de objetivos del equipo - Que el equipo lo acepte - Describir las expectativas del éxito del proyecto - Defina responsabilidades del los miembros del equipo - Defina las reglas base para la operación del equipo del proyecto, incluyendo + Guías de administración + Manejo de conflictos + Escalamiento - Comunicación - Reporte de estatus - Retroalimentación en las juntas

2.7 Definición del Baseline y sus exclusiones Needs: El responsable del proyecto tiene requerimientos, ideas y requerimientos de negocio Requirements: Declaración de deseos para el futuro sistema Exclusions: Declaraciones de no incluir para el futuro sistema Baseline: Declaración de compromiso para el futuro sistema Identifique y valide requerimientos cuando: - Desarrolle una propuesta - Inicie un proyecto - Tome un proyecto en ejecución - Revalue requerimientos de un proyecto Por que establecer un baseline? El baseline: - Incorpora los requerimientos originales para un proyecto mas o menos aprobado los cambios

38

- Sirve como la base del manejo de los requerimientos - Puede ser firmado y aprobado - Sirve como base para acuerdo de terminación del proyecto - Define el alcance del proyecto Preguntas fundamentales para identificar los requerimientos: IPD y CRM usa: - Que es lo que se desea? - Quienes son los involucrados? - Cual podría ser su costo? - Cual es el plan de gasto? - Cuanto tiempo es el proceso de desarrollo? - Como puede ser el servicio y mantenimiento y cuales son las garantías implicadas? - Puede existir una infraestructura de esto? - Que soporte externo se requiere? - Como se define el éxito? - Que sistema de apoyo se pude brindar en sitio? IPD usa además: - Como se comercializara? - Cual es la estrategia del canal? - Como puede ser pedido? - Cuanto tiempo durará? - Cuales productos están listos, en desarrollo y en operación? Como establezco un baseline. - Necesidades - Requerimientos - Reviso - Acepto - Genero un baseline y depuro con exclusiones y excepciones. - Vuelvo a revisar - Apruebo - Baseline final. Usando el Project Definition Report (PDR) para identificar y validar los requerimientos del proyecto. - Cree el baseline para medir y manejar los cambios - Defina criterios de medición, apoyase en el control de proyectos - Prevenga al equipo para brincos y esfuerzo de gastos. - Asegure claridad en el alcance del proyecto antes de detallar el plan.

39

Que es un Project Definition Report? - Es una revisión al documento - Define los limites del proyecto - Establece que puede y que no puede hacer el proyecto - Inicio a organizar el proyecto dentro de una forma manejable - Esto no es un estatuto de proyecto - Esto no es un estatuto del equipo - Esto no es un contrato del cliente Componentes del PDR Project Definition Report? - Aspectos y sumario del proyecto. + De donde vino este proyecto? + Por que esta haciéndose? + Que recibe y que no recibe el cliente con el proyecto? - Objetivos del proyecto: + Cual el blanco del proyecto? + Cual es el problema original? + Cuales son los mejores componentes para trabajar en el proyecto? - Entregables del proyecto: + Cuales con los mejores productos requeridos para cumplir con los objetivos? + Entregables para el cliente + Entregables para el proyecto + Entregables del proceso Trampas en la definición del Baseline. Proceder con requerimientos no claros. - Requerimientos de naturaleza dinámica - Incertidumbre con respecta a quien usara el producto (Importante para el CRM y critico para el IPD) Identificar soluciones prematuras Direccionar los requerimientos de múltiples clientes Los análisis de los desarrolladores con diferente matiz o distorsionar el requerimiento

40

2.8 Organizando el trabajo WBS WBS: Work Breakdown Structure PBS: Producto Breakdown Structure OBS: Organization Breakdown Structure El WBS es una actividad orientada a estructurar el trabajo a realizar. Sistemáticamente presenta todo el trabajo sobre el proyecto con efectos de Costos, Calendario o especificaciones. El tamaño y el número de los niveles WBS varia para cada proyecto. Por que el WBS es necesario? - Son los prerrequisitos principales para la integración del éxito y controlar el total del proyecto asistido en: + Desarrollando el plan de manejo de riesgos + Completar el calendario + Desarrollando el estimado del costo - Son los focos de atención sobre los objetivos del proyecto - Representa un frente para identificar el desarrollo del proyecto - Clarifica responsabilidades - Identifica paquetes de especificaciones de trabajo para estimar y asignar trabajos - Ayuda a construir el equipo del proyecto

2.9 Manejo de riesgo. El riesgo se divide en tres componentes: 1.- Un evento (Posible) 2.- Probabilidad de que sucede este evento 3.- Impacto del evento (Monto del riesgo) Tipos de riesgos. A.- Business risk: Riesgo por la de ganar o perder B.- Pure risk: Este riesgo representa una oportunidad de perder únicamente C.- Known: Se conoce el riesgo anticipadamente D.- Unknown: El riesgo no es planeado y no es reconocido

41

Manejo del riesgo. Proceso de identificar y evaluar el riesgo Una parte integral del manejo del proyecto * Identificación del riesgo * Evaluación del riesgo * Mitigación del riesgo * Monitoreo del riesgo Por que manejar el riesgo: - Proteger el riesgo, calendario y especificaciones - Prevenir sorpresas - Foco para construir una correcta oferta la primera vez. - Prevención de manejo de crisis - Prevenir problemas que pudieran ocurrir o si ocurre para escalarlo Preguntas a considerar en la evaluación de riesgos: Precedencia: Este riesgo a ocurrido antes? Esta familiarizado en la operación? El staff tiene la habilidad para el trabajo? Los recursos son los adecuados para completar el trabajo? El tiempo es el adecuado para terminar el trabajo? Se tiene la calidad adecuada para el trabajo? El manejo del costo esta fondeado para a completar el trabajo? Cuantifica el posible riesgo individualmente. Use conceptos de probabilidad de riesgo. (Alto, Medio y Bajo) Prioritice los riesgos por su severidad (Alto, Medio Bajo) Analice el rango de que suceda el evento de riesgo Revise los posibles riesgos y revíselo con el equipo de trabajo No haga un plan de estrategia de mitigación como parte de este proceso Mitigación del riesgo. Avoid: Estoy conciente de este riesgo y no cambio esta opción Ignore/Accept: Estoy conciente del riesgo y espero aceptar las consecuencias y el evento ocurre

42

Contain: Estoy conciente del riesgo y realizo una acción especifica para minimizar lo ocurrido y el efecto. Establish Contingency: Tengo alternativas en caso de que suceda Transfer: Estoy conciente del riesgo y transfiero parte de este a otra facción. El plan de manejo de riesgo de mitigación es por cada uno. Monitoreo del riesgo: Implemente un plan de seguimiento y manejo del riesgo Comunique el estatus de este plan a los miembros del equipo y los involucrados Cree un lección aprendida en la base de datos

2.10 Estableciendo el estimado del proyecto Considerar el Baseline, los recursos a utilizar, el riesgo, contingencia las horas invertidas en el proyecto multiplicado por el factor de utilización, ya que como sabemos los recursos, se llegan a enfermar, tienen vacaciones, tiempo para ellos y muchas veces no se utilizan al 100% las horas. Una guía de utilización es: 3 a 6 meses 176 hrs Factor 80% 6 a 12 meses 130-140 Factor 75-80 De 12 meses en adelante 120-130 Factor 70-75 Considerando 22 días de trabajo al mes por 8 hrs = 176 por el factor serian 220 hrs (27.5 días) al mes. Duration = Estimated effort / utilization factor 220 = 176 / .80 Estimación: Level of effort (LOE). Que es un estimado? Es una evaluación cuantitativa de los resultados Usualmente aplicado a proyectos el factor del costo y el calendario Usualmente es usado con modificaciones, para ejemplo, preliminar, conceptual , viabilidad Un estimado no es:

43

- Una estrategia de cuenta - Precio - Inversión de mercadeo - Satisfacción del responsable del proyecto - Software o herramienta - Encontrar un camino seguro Razón para estimar: - Para evaluar el estimado del costo proyecto antes de la autorización de implementación - Proveer las bases para el seguimiento y manejo del proyecto - Proveer al gerente del proyecto con una herramienta para evaluar la rutina de decisiones del proyecto - Establecer los recursos requeridos y el resultado del calendario Cuando debe de estimar: - Después del WBS es desarrollado - Cuando determine si es una oportunidad - Antes de mirar el proyecto - Siempre que el WBS cambie Proceso de estimación: - Establezca el objetivo del estimado - Determine el detalle del proyecto - Seleccione el modelo apropiado - Desarrolle la estrategia del estimado y plan - Prepare el estimado - Incluya el riesgo - Valide y finalice el estimado - Estimado del Baseline - Use el estimado en el plan del proyecto

2.11 Creando el calendario del proyecto. Un calendario es un plan de fechas para realizar actividades y juntas de hitos Para usar el plan: - Determine si los objetivos de su junta o recorrido. - De seguimiento y comunique el progreso del proyecto - Vea como un posible cambio puede afectar el proyecto - Asigne tarea a su staff

44

En el WBS determine sus dependencias de tÁreas Guías para realizar el diagrama de red (Plan con precedencias) - El diagrama de red inicia con una tarea o trabajo, paquete o actividades o un acontecimiento (Milestone) - El diagrama de red termina con una tarea o trabajo, paquete o actividades o un acontecimiento (Milestone) - Estas son predecesoras para todas las actividades - Estas son sucesoras de otras actividades - Las tÁreas lógicas pueden ser actualizadas y concurrentes - No existen loop Terminología básica del plan: - Actividad - Milestone - Relationship * Finish-start * Finish- finish * Start- start - Lag time Late start (LS) Late finish (LF) - Lead time Early start (ES) Early finish (EF) Estableciendo el plan de manejo de cambios En los capítulos anteriores quedamos que se tiene que reestimar el baseline cada vez que haya un cambio y debemos de considerar los tres factores críticos del un proyecto: - Requerimientos - Calendario - Costo Todo Baseline y alcance es finito Que es un manejo de cambio?

45

- Es el procedo de manejar y controlar el baseline - Un sistema de control de cambios * Incluye el procedimiento de documento formal y define como se manejara el cambio * Establece los papeles de trabajo, sistema de seguimiento y niveles de aprobación necesarios para autorizar el cambio Proceso de manejar cambios - Identificar el cambio - Claridad en el alcance - Complejidad del estimado / precio de la inversión - decisión si se evalúa - Si se decide no continuar se documenta - Si se decide continuar se evalúa el impacto - Se evalúa el costo - Selecciona alternativas - Precio - Decisión de aceptación - Si es un no se documenta - Si es un si Se actualiza la documentación necesaria - Se implementa - Se documenta - Se archiva Manejo y control del proyecto El gerente del proyecto deberá de integrar todos los aspectos del proyecto, asegurándose de contar con el conocimiento apropiado y que los recursos estén disponibles cuando se necesiten, y encima de todo, asegurar las expectativas de los resultados sean producidos en tiempo y costo efectivo. Meredith and Mantel 1995 p.4. Controlar es el proceso de monitorear, evaluar y comparar los resultados de los planes con los resultados reales, para determinar el estatus del costo del proyecto, calendario y técnicas de mejoras. David I.Cleland 1994, p.285. Por que es importante controlar el proyecto?

El proyecto se puede volver infinito

El costo se puede elevar excesivamente

Se puede incrementar el riesgo

Pueden faltar planes

46

Durante el proceso de control debemos de: Establecer estándares Observar mejoras Comparar el plan actual contra el planeado Hacer acciones correctivas Para un buen control del proyecto es necesario levar una carpeta de control de proyectos, el cual deberá de contener los documentos generados utilizada para:

- Como base para revisiones y auditorias - Como un repositorio de información para los miembros del equipo - Como una herramienta para el manejo de otros proyectos

Definición de una buena carpeta de control de proyecto. Seguimiento y evaluación del proyecto Administración financiera Reportes Manejo de riesgo Manejo de proveedores Control de calidad Control de cambios Manejo de problemas e issues Manejo de contrato Administración de los recursos Entregables Cierre de proyecto. Es necesario asegurarse de cerrar el proyecto para:

Cerrar formalmente los gastos del proyecto Controlar los registros del proyecto que son terminados Los criterios de terminación se reúnen para la ultima revisión y generación de

documentación. Preparar documentación de lecciones aprendidas Garantizar la transferencia cuando aplique

Cuando debe de cerrarse el proyecto? Un día antes del término en una junta con el cliente. Revisión del proyecto final.

Asegurarse que se cumplieron con todas las obligaciones contractuales, debiéndose revisar en una junta.

47

Antes de cerrar el proyecto asegurarse de que ninguna actividad pendiente

Preparar el reporte basado en la revisión

2.12 Experiencia en Manejo de Proyectos Algunos de los proyectos en los que participe como responsable son: Proyectos Año 2000 Avonne. Banco de Colombia, Goodyer Chile BBVANET Banca a distancia Bancomer Instalacion de VTS EDS Línea de soporte y soporte en sitio Iusacell, LyFC, Telmex Manejo de fallas Secretaria de Finanzas Instalacion de equipo SUN IMSS Instalacion de Tivoli Gedas DRP Infonavit A continuación adjunto de los documentos importantes de estos proyectos: PROYECTO BBVA A BANCOMER Kickoff

Fecha y Lugar Tipo de Reunión Horario Participantes

_________________________________________________ Julio 04, del 2000. Banco Santander Mexicano Manuel Avila Camacho 170 1er. Piso Col. Lomas San Isidro CP 11620 _________________________________________________ Kickoff. _________________________________________________ 11.30 - 13.00 hrs _________________________________________________

Nombre Puesto Siglas

48

Agenda Narrativa

Emilio Porras Alonso

Gerente de Proyecto Santander

EP

Wuilbert Martinez

Soporte

WM

Jose Luis Quiroz

Gerente de Proyecto IBM

JLQ

1. Presentación del equipo de trabajo 2. Solicitud de requerimientos por parte de IBM 3. Revisión del plan de trabajo 4. Revisión de requerimientos de los servidores para TIVOLI 1.- Presentación del equipo de trabajo LAC presento a los nuevos integrantes del quipo de trabajo quedando conformado de la siguiente forma: Gerente de proyecto por parte de Santander Emilio Porras Alonso Por medio del cual se canalizará la comunicación hacia IBM como hacia Santander. Gerente de proyecto por parte de IBM José Luis Quiroz Lechuga Quien administrará el proyecto por parte de IBM, y dará informes de avance al Banco Santander y será también el único canal de comunicación y de acuerdos entre IBM y el Banco Santander. Arquitecto Antonio Cristan Quien se encargará de diseñar la arquitectura que se requiera para la instalación de los productos de TIVOLI adquiridos por el Banco….. 2. Solicitud de requerimientos por parte de IBM LAC solicito a EP Lugares de estacionamiento para personal que estará

49

laborando el en proyecto, gafetes provisionales para el acceso al edificio del banco para evitar el registro diario del personal, así como memorandums para poder entrar con las Think Pads sin tener que estar registrando diario, en el entendido de que será necesario mostrarlas tanto al entrar como al salir del Banco.EP quedo de revisarlo y nos informaría….. 3. Revisión del plan de trabajo WM explico de forma general y resaltando algunos puntos el Plan de trabajo, del cual estuvo de acuerdo EP, y quedo WM de enviar el plan de trabajo actualizado con fecha de arranque del lunes 10 de julio del 2000. … 4. Revisión de requerimientos de los servidores para TIVOLI Al revisar la solicitud del nuevo equipo para los servidores de Netview y Framework, AC comento que faltaban algunos datos los cuales revisaría y le enviaría una nota indicándole los valores correctos en base a “Mejores Practicas”.

Acuerdos 1.- EP estuvo de acuerdo con los integrantes del equipo de trabajo y la forma de comunicación en ambas partes. 2.- EP quedo de revisar los requerimiento de IBM 3.- EP estuvo de acuerdo con el plan de trabajo y que la metodología y procedimientos que se apliquen sean los que recomiende IBM en base a sus mejores practicas. 4.- EP quedo de enviar el documento que generó para que AC complemente.

Compromisos 1.- EP quedo de enviar la lista de la gente que participará por parte del Banco. 2.- EP quedo de investigar y solicitar, Gafetes de acceso, lugares de estacionamiento, Acceso a equipo de computo y líneas analógicas. …..

Minuta

Fecha y Lugar

Julio 20 de 2000. BBVA Madrid, España

Tipo de Reunión

Reunión de Trabajo.

Horario 09:00 – 18:00 hrs Participantes BBVA Área IBM Latinoamérica Arturo Gil Sistemas Luis Enrique Sanchez

50

Operativos Patricia García DB2/UDB Jorge Combes Maria Lucero

García NES Jorge Benitez

José María Rodriguez

Comunicaciones José Luis Luna

Emilio Delgado MQSERIES/XCOM

Jorge Yaqui

Agenda Software Base – AIX, SOLARIS HACMP

Tivoli Websphere Application Server, Netscape Enterprise Server,

DB2/UDB: Narrativa TEMA: Reunión. Software Base (AIX, SOLARIS), HACMP, Java

Run Time, Tivoli: 1.- AIX. Y S.O. Los contactos directos para aclaración de dudas será: Fernando Roca (34)91-807-30-… El área del Banco Infraestructura Técnica nos informo lo siguiente: SUN. 1.4.La instalación de sistema operativo se realiza con los parámetros por default, sin embargo, se cambian algunos parámetros generales y son: Pendientes: - Programar reunión de trabajo con la gente de almacenamiento - Se solicitó los estandares de nomenclatura - Lista de parametros instalados por servidor - Favor de indicarnos cual es la versión anterior del Stone Beat

(Deberia ser la que esta corriendo actualmente). Y el tipo de licencia.

HACMP.

1.5 En los servidores de WebSeal en BBVA se tiene instalado HACMP y network Despatcher. Acuerdos:

51

Pendientes: - Se les pidío configuración del hacmp incluyendo los Scripts de paro y arranque. 2. TIVOLI. Los contactos directos para aclaración de dudas será: -

Acuerdos AIX. Se acordó que para México, Colombia y Perú la versión que se instalará será la versión AIX 4.3.3.

Compromisos Software Base (AIX, SOLARIS), HACMP, Java Run Time, Tivoli: Aix

- El BBVA proporcionara la lista de los procesos mínimos de arranque del S.O. para la solución Banca a Distancia.(initab y archivos /ect/rc.*).

Reporte de Seguimiento Ing. Juan Carlos Zurita Por medio de la presente le hago llegar el reporte semanal de las horas trabajadas del periodo 4 de Enero al 6 de Enero del 2001 para el Proyecto “Banca a Distancia”.

Nombre Actividades Horas

Jorge Combes Soporte aplicatvo Revision de configuración actual Reunión de trabajo …..

28 horas

Patricia Armendariz

Reinstalación de Network Dispatcher …..

10 horas

Jorge Benitez / Mikalonis

Revisión de ambiente …

28 horas

José Luis Quiroz Revisión con BBVA Bancomer del avance que se tiene en el proyecto

…

18 horas

Total de horas 84 horas

52

Informe de avance. Seguridad

Se revisó el ambiente y esta funcionando correctamente. Se integro al equipo de trabajo Mikalonis por cinco días para dar soporte a Jorge ……

Mqseries Se intento configurar Mqseries en ambiente de producción por la parte de host, pero se tuvieron algunos problemas y se decidio regresar al ambiente de testing para continuar probando. Aplicación….

Conclusiones: …….

Pendientes: Seguridad

- Probar el Network Dispatcher con la alta disponibilidad y dar solución a los problemas presentados.

- ……. Aplicación.

- Pruebas de Volumen en ambiente productivo con cuentas validas …… Atte. Autorizo ______________________ ________________________ José Luis Quiroz Lechuga Ing.Juan Carlos Zurita Project Manager IBM Líder de proyecto BBVA Bancomer

53

Cierre de Proyecto Ing. Juan Carlos Zurita Le informo que de acuerdo al anexo “Banca a Distancia” Number Contract MXAAAYP Work Number MXABAP del contrato firmado entre IBM de México y Bancomer S.A. No 3098000172. Se da por terminado satisfactoriamente la instalación y configuración de la infraestructura con la aplicación BBVNET: Entre las tareas relevantes realizadas en esta Fase II fueron: 1- Se instalo la versión del aplicativo 1.0 enviado por España y se hicieron pruebas de a travez de la infraestructura validando cada uno de los componentes instalados los cuales se pusieron a punto y se dejaron funcionando. 2.- Se instalo la nueva imagen del aplicativo y se hicieron pruebas de volumen en el ambiente productivo con una transacción y que esta funcionamiento, pero al mandar 10 usuarios concurrentes con 10 transacciones no se recibió respuesta de host y se continua revisando para identificar cual es el problema. 3.- Se integro el equipo de operadores que darán el servicio de 7 x 24 a partir del 12 de enero y se les dio una inducción de los productos instalados. Ellos solo son responsables de la operación, en caso de algún problema seguirán la matriz de escalamiento. 4.- Se entregó un draft de la documentación de la operación de los productos instalados en los equipos IBM. Se esta trabajando en la ultima versión. 5.- Se continua haciendo pruebas para identificar donde están las demoras en los tiempos de respuestas. 6.- Se entregó el ambiente estable aunque falta por terminar hacer pruebas Pido de favor firme al calce dando por finalizada la fase II del proyecto, así como satisfactoria los entregables marcados en el anexo del contrato firmado entre IBM y Bancomer. Atte. Acepto ______________________ ________________________ José Luis Quiroz Lechuga Ing.Juan Carlos Zurita Project Manager IBM Líder de proyecto BBVA Bancomer

54

Carta de Terminación Ing. Carolina Santana Me es grato informarle que el proyecto “Instalación del VTS” OMSYS ha concluido satisfactoriamente, terminándose las actividades marcadas en el plan de trabajo. Se dio la capacitación información transfiriendo los conocimientos del proceso satisfactoriamente. Solo me queda agradecerle las facilidades brindadas para el éxito de este proyecto y quedo a sus ordenes para cualquier otro requerimiento que necesiten. Por favor firme al calce de aceptación servicios y cumplimiento con todos los entregables marcados en el contrato. Atte. Acepto ______________________ ________________________ José Luis Quiroz Lechuga Ing.Carolina Santana Project Manager IBM Líder de Proyectos EDS

Cierre de proyecto IUSACELL

Lic. Christian

Planeación y Proyectos de Sistemas

Iusacell

Me es grato informarle que de acuerdo con el contrato número 1804823 firmado entre IBM y

Iusacell donde se les otorgo 120 horas de nuestros especialistas de soporte en sitio en sus

instalaciones en la plataforma red distribuida se da por terminado cumpliendo los siguientes

servicios:

1.- Se completaron las horas ofrecidas dentro del contrato

2.- Se hizo el análisis y diseño de los siguientes programas:

A) Extracción y envío de datos de la base de NPDV. B) Inserción en la base de datos Oracle de BSCS y envío de respuestas a NPDV.

55

C) Inserción de respuesta en la base de datos de NPDV. 3.- Pruebas de los programas en ambiente de desarrollo.

Por lo antes mencionado pido de favor firme alcalce finalizando las actividades antes descritas

liberando de cualquier responsabilidad a IBM de México por los servicios antes mencionados.

Atte. Acepto

______________________ ________________________

Lic. José Luis Quiroz L Lic. Christian

Project Manager Planeación y Proyectos de sistemas

IBM Iusacell

Informe de reporte de Fallas Lic. Modesto Garcia Hernandez

Coordinador de desarrollo técnologico

Secretaria de Finanzas

Por medio de la presente le informo que durante el periodo de la vigencia del contrato

SW010532 de septiembre a diciembre del 2001, no hubo ningun reporte atendido por el

soporte IBM de México o de sus laboratorios en EEUU, existieron 2 llamas de su parte:

16 P2SDKLX H C 2 REP RC 8688 SECRETARIA DE F RODRIGUE ADMST3 1115 1739 MX1 17 P2SDP9F H C 3 REP CE 7018 SECRETARIA DE F QUIÑONES CALLS1 1114 1422 MX1

El primero fue manejado por la gente de hardware, razón por la cual no tenemos documentado

del estado que guarda el reporte.

En el segundo se reporta el 14 de noviembre del 2001 a las 14:22, un problema de reseteo con

la tarjeta de red, el especialista de IBM el Ing. José Luis Luna se reporto con ustedes para

atenderlos, pero de acuerdo a sus comentarios, el problema ya estaba controlado y casi

resuelto por ustedes, por lo que ya no se requirio del soporte.

56

Quedo a sus ordenes para cualquier comentario al respecto.

Atte.

______________________

Lic. José Luis Quiroz

Project Manager

Tel. 5270-2854

IBM

Reporte de Avances Transición Versión del plan: 1.0

Fecha de reporte: 05-12-2001 Reporte elaborado por: AT/JV

Status resumido

GENERAL

El avance del proyecto esta en un 40%, contra plan de trabajo. El problema principal sigue siendo el área de proveedores.

TRANSICIÓN

Documento criterios de conclusión de Transición definido Plan de detalle definido Entrega de documento de Evaluación de ambiente Operatívo Entrega de documentos de Proceso de Cambios y Proceso de Problemas Entrega de Documento de proyectos en procesos

Pendiente de firma de aceptación En espera de observaciones Se revisarán en la siguiente semana En espera de observaciones

BAU Quedaron cubiertas todas las vacantes por renuncia en la transferencia y las definidas en el anexo G En proceso de cubrir las 5 nuevas plazas

Tareas Terminadas

Terminadas al 05 de Diciembre del 2001 contra plan de trabajo

Comentarios

ID 3 Start Up

ID 46 Transferencia de Recursos Humanos Reporte pendiente

ID 50 Plan de Transición detallado Plan entregado

ID 60 Evaluación ambiente operativo Documento entregado

57

ID 129/149 Implantación Problemas y Cambios 80 % de avance, procesos definidos y en validación, documentos entregados

ID 6320 Proyectos en Proceso Documento entregado

Adelantadas Comentarios

Planeadas pero no terminadas Comentarios

Por realizar / En Proceso Comentarios

Issues Significativos Comentarios

El cambio de Proveedores sigue siendo el punto más significativo, se está definiendo un plan específico adicional para su manejo Se definió una matriz que incluye los elementos que el Banco considera se deben cubrir a fin de proceder al reemplazo de los proveedores

Cambios Significativos Comentarios

58

Reporte de Estatus de la Transición

Technical Transition

04/01/2002

Tabla de Contenido

Tabla de Contenido ........................................................................................................................ 58

Evaluación del Estatus del Proyecto .............................................................................................. 58

Notas .......................................................................................................................................... 59

Planes de Mitigación para las areas en en riesgo (Amarillo & Rojo ) ........................................ 59

Actividades en BAU ................................................................................................................... 59

Cost Tracking (Help Desk) ........................................................................................................ 59

Cost Tracking (Labor) ................................................................. ¡Error! Marcador no definido. Adolfo Tapia ............................................................................. ¡Error! Marcador no definido. Objectivo/Alcance .................................................................... ¡Error! Marcador no definido. Consideraciones ...................................................................... ¡Error! Marcador no definido. Entregables definidos en el contrato ..................................................................................... 60

Factores Críticos de exito ...................................................................................................... 60

Issues Abiertos ...................................................................................................................... 61

Cambios aprobados ............................................................................................................... 61

Evaluación del Estatus del Proyecto

Ref. Plan

Descriptivo Avance Fecha Contractual

Comentario Riesgo

47 Transferencia RH 100 % Nov 01,2001 Se transfirieron y cubrieron todos los recursos definidos

48 Cubrir vacantes y adicionales (incluye Anexo J)

80 % Ene 15,2002 De 5 plazas adicionales definidas contractualmente, tenemos pendiente por cerrar una, Cuernavaca

59 Plan de transición de detalle aprobado

100 % Nov 15,2001 El plan de trabajo se entrego el 15 de noviembre como estaba establecido

277 Manual de procedimientos

60 % Ene 31,2002 En Proceso

303 Firma de SLAs con ScotiabankInverlat

60 % Ene 31,2002 Se concluyo documento de definición de SLA’s se entregó draft el 22 de dic

325 Firma de nuevos base lines del plan de transición (Proyectos en Proceso)

100 % Nov 30,2001 En casa de bolsa cerrado, en el banco en firma, documento de referencia

331 Proveedores Transferidos (Plan Relación con Proveedores)

60 % Ene 31,2002 Se acepto por parte del banco la transferencia de proveedores, a dar inicio en febrero del 2001

59

Notas

Recursos habilitados, Plan creado, Team ejecutando en

plan y expectativas cubiertas de acuerdo al plan y a

entregables

Verde

Cubierto lo anterios, pero existen dependencias que

deben ser direccionadas y que pueden impactar el plan Amarillo

Entragables identificados o plan requerido, los riesgos

ponen a los entregables en plan bajo riesgo Rojo

Planes de Mitigación para las areas en en riesgo (Amarillo & Rojo )

Plan de Acción Asignado a Fecha

El Primer draft del manual de procedimientos será liberado y revisado esta semana con el Banco, se revisará el martes 08, el contenido del manual y se definirá el contenido final del mismo, se redefinirán recursos para la conclusión del mismo para el 30 de enero de 2002.

Rogelio Ibarra 30/Ene/02

El martes 08, se revisarán los 4 elementos principales que debe contener el documento de SLA’s El documento final esta en proceso de “adelgazamiento”

Martín Ruiz 30/Ene/02

El proceso de cambio de proveedores ya fue aceptado, el inicio de operaciones por parte de los proveedores propios de IBM y los subcontratados por IBM, inicia el 1ro de Febrero de 2002.

Joaquin Urias 30/Ene/02

Actividades en BAU

Los puntos siguientes, necesitan ser direccionados por el equipos de trabajo de Delivery o por el engagement

manager para su renegociación e implementación.

Item Responsable

Cobro del resultado del item 5 de la tabla de issues PE

Cobro de costos adicionales por concepto de viatico PE

Cost Tracking (Help Desk)

Cost Tracking (Provedores)

60

Estatus General del Proceso de Transición

Entregables definidos en el contrato

MILESTONES PROYECTADOS Día Efectivos a

partir fecha Inicio /

Fecha

Estatus

1 Plan de Transición documentado 0 01/nov/01

Cerrado

2 Inicio de la Transición 0 01/nov/01

Cerrado

3 Inicio de BAU (Business as Usual) –

Inicio de operaciones por IBM 0

01/nov/01 Cerrado

4 Transición de empleados Inverlat 0 01/nov/01

Cerrado

5 Procedimiento de Cambios Implantado 30 30/nov/01

80 %

6 Revisión y documentación de Proyectos

en Proceso 30

30/nov/01 Cerrado

7 Impacto de Proyectos en Proceso a la

Transición 30

30/nov/01 Cerrado

8 Plan de transición detallado BASE LINE

definido 15

15/nov/01 Cerrado

9 Validación de alcance con Proveedores 30 30/nov/01

Cerrado

10 Inventario de Activos 60 30/dic/01

75 %

11 Borrador de Procesos y Procedimientos 60 30/dic/01

60 %

12 Definición de Niveles de Servicio con

base en Niveles de Servicio Objetivo 90

30/ene/02 60 %

13 Implantación de Niveles de Servicio en

contratos de Mantenimiento 90

30/ene/02 60 %

14 Firma de contratos con proveedores 90 30/ene/02

75 %

15 Documento Final de Procesos y

Procedimientos 90

30/ene/02 60 %

16

Definición de Unidades Equivalentes de

Servicio (BASE LINES & Consumos

Adicionales)

90

30/ene/02

80 %

17 Definición de Tabla de tiempos muertos

por Plaza 90

30/ene/02 80 %

18 Firma de entregables de la Transición 90 30/ene/02

0 %

19 Cierre de la Transición 90 30/ene/02

0 %

Factores Críticos de exito

Disponibilidad de Sponsor por parte del cliente

Mantener plantilla de recursos actuales

Uso de infraestructura y funcionamiento del help desk actual (CAI)

61

Issues Abiertos

ID Prioridad Issue Fecha Comentario

1 1 Obtención de autos 07/ene/02

2 1 Transferencia de proveedores y toma de

servicio por parte de MVS

30/ene/02

3 1 Costo de mantenimiento de los proveedores

Teledinámica y Getronics

30/Ago/02

4 2 Definición de cambios operativos 30/ene/02

5 2 Identificar actividades actuales que no están

en contrato pero que se ejecutan

23/ene/02

6 1 Redefinición de los entregables de la

Transición

09/ene/02 Evitar penalizaciones

7 1 Costo de recursos adicionales de Serfin 30/ene/02 El costo es adicional al over

budget

Cambios aprobados

Ninguno

Fecha y Lugar

Tipo de

Reunión

Horario

Participantes

Agenda

Narrativa

_________________________________________________

Agosto 22, del 2003.

IMSS

Tokio 80 Mezanine

Col. Juarez

_________________________________________________

Kickoff.

_________________________________________________

16:00 - 17:40 hrs

_________________________________________________

Nombre Puesto Representante

Alberto Martín del Campo Jefe de División IMSS

Agustín Trueba Rivas Soporte servidores IMSS

José C. Bolaños Cruz Soporte Mainframe IMSS

Adrián Díaz de León Soporte Técnico IMSS

Guillermo Labastida Sales IBM

Moisés Acevedo Project Manager IBM

Antonio Cristan Especialista Tivoli IBM

Adrian Corona Lider Técnico IBM

José Luis Quiroz Project Manager IBM

1. Objetivo

2. Presentación del equipo de trabajo

3. Revisión del Alcance del Proyecto

1.- Objetivo

IBM de México apoyara al IMSS en la instalación y configuración básica de los productos

IBM para la plataforma de servidores Sun (System Open) y equipos Mainframe.

Los tiempos dedicados por parte de los especialistas como la administración será pagada por

62

el área de software group de IBM, previa autorización de ellos y no mayor a las horas

ofrecidas por esta área.

2.- Presentación del equipo de trabajo

Guillermo Labastida presento a los integrantes del quipo de trabajo que realizaran las

actividades dentro de la Institución. Moisés Acevedo quien había llevado la coordinación del

proyecto hasta este momento presento a Jose Luis Quiroz como el nuevo Project Manager

para dar continuidad al proyecto.

Jose Luis Quiroz / IBM

Será el encargado de administrar y mantener la comunicación y de acuerdos hacia IBM y el

IMSS, reportando oportunamente el avance del proyecto e informando cualquier desviación

que se encuentre durante el mismo.

Alberto Martín del Campo / IMSS

Será el encargado de mantener la comunicación y de acuerdos hacia el IMSS e IBM,

validará el avance del proyecto y autorizará los reportes de horas semanales, dando el visto

bueno de entrega de las instalaciones, configuraciones de los productos ofrecidos y

finalización del proyecto cuando este termine.

Adrián Corona

Será el especialista Tivoli quien además fungirá como líder técnico.

Jose C. Bolaños

Será el líder técnico por parte del IMSS en equipos Mainframe

Agustín Trueba

Será el líder Técnico por parte del IMSS en equipos servidores Sun (System Open)

3. Solicitud de requerimientos por parte de IBM

TIVOLI.

Jose Luis Quiroz entrego a los participantes un breve resumen del alcance general de proyecto

System Open. Una vez revisado este documento se observo que algunos de los productos ya

habían sido instalados como es el caso del WAS y algunos productos de Tivoli por lo que se

definió que Adrián Corona a partir del jueves se presentaría en la institución para revisar que

se tenia instalado por parte de Tivoli y el Lunes próximo iría alguien de Websphere para

revisarlo.

En el caso de Websphere se acordó que en caso de ya no requerirse alguna instalación se

utilizarían las horas estimadas para revisar dicha instalación y dar una capacitación informal al

personal del IMSS tanto en México como en Monterrey.

También se les solicito nos indicaran en que equipo se realizaría la instalación y configuración

básica de los productos Tivoli y si este ambiente seria el definitivo o habría que migrarlo a

Producción. Nos indico Agustín que el ambiente sería de pruebas y que seguramente algunos

productos se instalarían en producción tanto en México como en Monterrey.

Informo que una vez que Adrián Corona tuviera un bosquejo de sus necesidades se realizaría

el plan de trabajo, pero que a partir del lunes irían los especialistas de Tivoli para empezar a

realizar la instalación de los productos.

63

Acordaron Alberto Martín del Campo como Jose Luis Quiroz que existe una presión por

ambas partes de poder dar por instalado todos los productos durante el mes de septiembre y en

caso de que quede alguna tarea pendiente de capacitación y documentación se realice durante

el mes de octubre.

MAINFRAME

Jose Luis Quiroz entrego a los participantes un breve resumen del alcance general de proyecto

para la plataforma Mainframe. En donde las tareas a realizar resaltan la instalación del CTG y

el WORKLOAD. Por la parte del Workload Arturo Juárez especialista en Mainframe, ya se

presento con el cliente para revisar el Plan de trabajo y ajustarlo de acuerdo a sus necesidades

y disponibilidad del especialista.

Una vez que tenga Jose Luis Quiroz la información y disponibilidad de los recursos se

realizara el plan de trabajo que será entregado lo antes posible.

Acuerdos 1.- Agustín Trueba junto con Adrian Corona definiran los equipos donde se trabajara.

2.- Alberto Martín del campo y Jose Luis Quiroz se apoyaran para terminar la instalación de

los productos durante el mes de septiembre.

Compromisos

64

65

66

México D.F. a 30 de septiembre del 2003.

Ing. Alberto Martín del Campo

Me es grato informarle que de acuerdo al Contrato firmado el 9 de julio del 2003 entre el

IMSS e IBM ”Licencia de uso de Software, Contract Number MXAABMK Work Number

MXACS5. Se ha terminado satisfactoriamente la instalación y configuración básica de los

productos Tivoli y Websphere señalados en el anexo 2 del contrato consistente en:

Se hizo la transferencia del conocimiento de instalación y configuración básica al personal del

IMSS.

Se cumplió con la cláusula Décima del contrato “Servicio Técnico Especializado”.

Por lo anterior pido de favor se firme el presente documento dando su visto bueno de

terminación.

Atte. Acepto

______________________ ________________________

José Luis Quiroz Lechuga Ing.Alberto Martín del Campo

Project Manager IBM Jefe de División de Producción de Operacion

_______________________________ _________________________________

Mario Alberto Ramos Rentería Gabriel Daniel Flores Saucedo

Jefe de división de Soporte Técnico Jefe de División de Administración de

Infraestructura Arquitectura Tecnológica

Mexico D.F. A 21 de noviembre del 2003

Por medio de la presente hago entrega de la documentación

complemento del proyecto IMSS TIVOLI/MAINFRAME

No. Descripción del documento No.Pestaña

1 Programación de inicio del Decision Support 20

2 Carta de terminación Tivoli Configuration Manager con plan de prueba 4

3 Carta de terminación Websphere Business Integrator 13

4 Carta de terminación Websiteanalyzer con el plan de prueba 12

5 Carta de terminación Access Manager for O.S. Con plan de prueba 15

6 Carta de terminación CTG Sun con informe técnico 8

7 Carta de terminación CTG Mainframe 9

8 Carta de terminación Websphere Studio 22

9 Carta de terminación Websphere Aplication Server con informe 18

67

Fecha y Lugar

Tipo de Reunión

Horario

_________________________________________________

Diciembre 3, del 2003.

Gedas Puebla

_________________________________________________

Kickoff

_________________________________________________

10:30 - 11:00 hrs

_________________________________________________

Participantes Nombre Puesto Representante Juan José Dávila Líder de proyecto Gedas

José Luis Quiroz Project Manager IBM

Agenda Revisión del alcance del proyecto

Narrativa Se identifico como líder de proyecto a Juan José Dávila por parte de

Gedas, pero la firma de los reportes de avance y cartas de terminación

seria Armando Ramos con el visto bueno de Juan José Dávila.

Por parte de IBM el Project Manager será José Luis Quiroz. Y la

comunicación y negociación será a través del líder del proyecto, en caso

de generarse un control de cambio este será revisado y aprobado por Juan

José Dávila y Armando Ramos. Se considera como comunicación valida

el envió de mensajes.

Juan José Dávila externo su necesidad de tener el ambiente DEVdbb

configurado y listo para probar en este mes y programar dentro del plan

las tareas faltantes de configuración y prueba del ambiente FI/CO

completo.

José Luis Quiroz comento que esto es muy alcanzable, lo que nosotros

estábamos esperando era terminar la fase 1 del contrato completo y no

solo un piloto. Juan José Dávila comento que esto era poco probable ya

que existen dependencias externas, El ve poco factible concluir en este

año como es la configuración del HBA en PRD. José Luis Quiroz le

comento que de todas formas se avanzara en las tareas en la fase 1, para

concluirla lo antes posible.

Se hablo por teléfono con Alejandro Martín del Campo y Francisco

Mendoza y se quedo de que mañana José Luis Quiroz pasa a IBM a

recoger el software de Gresham y Francisco Mendoza quedo de dar un

estatus real de cuando recibiría Gedas los equipos Pseries el día de

68

mañana.

José Luis Quiroz quedo de modificar el plan de trabajo de acuerdo al

objetivo de Gedas.

Acuerdos Tener listo y probado el submodulo de DEVDBB (Piloto) para

probar la funcionalidad del producto, independientemente de la

terminación de toda la fase 1 del contrato.

Compromisos

Puebla Puebla a 24 de Febrero del 2004 Ing. Armando Ramos

Me es grato informarle que de acuerdo al Contrato-Propuesta “Implementation of Enterprise

Backup Solution Project” Number OMNotes/Omsys 4NLW9GBN firmado entre IBM de

México y Gedas. Se cuenta con un avance integral del 48% de la Fase 1:

69

Diseño de arquitectura al 92%

TSM1 al 74% nos falta la documentación

DEV 49%, nos falta pruebas con la libreria L700 y la documentación

QAS 55%, nos falta pruebas con la libreria L700 y la documentación

ACSLS FINSA 11% nos falta la documentación

ACSLS CUBO6 12% nos falta pruebas con libreria L700 y la documentación

APL1,APL2, APL3 y APL5 8% nos falta probar y la documentación

Documentación entregada.

- Diseño de Arquitectura v15

- Diagramas por servidor de SAP/FiCo

- Plan de trabajo v14

- Mejores Practicas S.O. En AIX, en Solaris, TSM en AIX y Solaris

- Matriz de mejores practicas Velocidad de transmisión de datos por segundo

- Sheduler de programación de respaldos

Pendientes.

- Entrega de memoria tecnica de TSM1, DEV

Facturación.

El 23 de diciembre se reporto un avance del 25%. El avance al dia de hoy es del 48%

Porcentaje de Avance Monto de la Fase 1 Importe a reconocer

23% $ X8,500.00 USD $ X3,x55.00 USD

(Trece X cuatro cientos Xa ) mas IVA.

Atte. Acepto

______________________ ________________________

José Luis Quiroz Lechuga Ing.Armando Ramos / Juan José Dávila

Project Manager IBM Coordinador de proyecto GEDAS / Lider de

Proyecto

70

BUSINESS CONTINUITY &

RECOVERY SERVICES

BUSINESS RECOVERY CONSULTING

DRP – Disaster Recovery Plan

Infonavit

AGENDA

1. Introducción

2. Resumen Ejecutivo

3. Términos y Condiciones

OBJETIVO:

Apoyar al Infonavit en el desarrollo de su estrategia y

Plan de Recuperación en caso de Desastre; para el

procesamiento de datos soportado por su

infraestructura de Hw y Sw, y basándose en la

metodología e infraestructura de IBM para tal efecto.

1. Introducción

71

ANTECEDENTES:

La consultoría en recuperación, ha evolucionado y en la

actualidad se conoce como un proceso interactivo y

estructurado, que comienza con la recopilación de

información, donde intervienen especialistas de IBM,

trabajando en forma coordinada con los dueños y

usuarios de los procesos de negocio del Infonavit y

culmina con la entrega de varios productos:

1. Análisis del Impacto en el Negocio (BIA)

2. Análisis de Ambiente(EA) de IT y Ambiente de Riesgo

(RA) de IT

3. Estudio de Alternativas de Recuperación (RAS)

4. Elaboración del Plan de Recuperación

5. Soporte a la primera prueba del Plan de Recuperación

CONSIDERACIONESEl plan de Recuperación incluye las actividades a realizar

antes, durante y después de la contingencia, así como el

conjunto de tareas y responsabilidades de cada grupo de

recuperación . El plan debe tomar el flujo completo en

cada caso.

SOLUCION

Apoyar al Infonavit en la identificación de los elementos

necesarios para minimizar el impacto de una

contingencia, permitiendo la continuidad de los procesos

críticos del negocio ante interrupciones prolongadas y el

restablecimiento de las operaciones del negocio.

Esto se logra desarrollando un Plan de Recuperación de

Desastres, efectivo.

2. Resumen Ejecutivo

72

Aplicando la metodología de IBM es posible un enfoque

integral que considere todos los aspectos relacionados a la

recuperación del Infonavit dentro de la ventana de tiempo

definida como "tolerable".

Para lograr nuestro objetivo, el proyecto se divide en 5

fases donde se recopila, analiza y genera la información

que nos permita mantener la continuidad operativa del

Infonavit

Fase 1 Análisis de Impacto en el Negocio (BIA)

Fase 2 Análisis de Ambiente de IT (EA) y de Riesgo de IT (RA)

Fase 3 Estudio de Alternativas de Recuperación (RAS)

Fase 4 Elaboración del Plan de Recuperación

Fase 5 Soporte a la primera prueba del Plan de Recuperación

1.- El Análisis del Impacto en el Negocio (BIA) nos permite

cuantificar las pérdidas tangibles e intangibles de una

interrupción en el procesamiento normal de datos, así se

proyecta el impacto por alcance y duración de la

suspensión.

Lost SaleO ver t im e

Fr audFines and Penalt ies

Char ges or Fees

0

2

4

6

8

10

CreditTot al

TANGIBLE IM PACTS AND EXPOSURES

8 Hours48 Hours

72 Hours1 Week

1 Mont h

0

1

2

3

4

5

6

7

8

CreditTot al

RELATIVE IM PACT OVER TIM E

Mar ket Shar

Pr oduct ivit y

Cust omer Ser vice

Employee Mor ale

Labor Relat ions

0

2

4

6

8

10

CreditTot al

INTANGIBLE IM PACTS

73

El Análisis de Impacto en el Negocio (BIA) para el

Infonavit comprende las areas de negocio

relacionadas al servicio de Informática, con datos del

Infonavit y considera las funciones críticas:

2.- El Análisis de Ambiente (EA) de IT identifica los

requerimientos tecnológicos y la interacción de los

diversos elementos a fin de facilitar la identificación de

una configuración mínima de recuperación.

Se revisa la situación actual y la capacidad de recuperación a

través del análisis de la infraestructura de informática:

instalaciones, hardware, software y comunicaciones, así como

la validación de los procesos de respaldo y restauraciónlos

requerimientos de recuperación y el costo de la contingencia

identificados en el BIA, junto con los requerimientos de IT

obtenidos en el EA, son las variables claves para determinar

las Estrategias de Recuperación.

Costo de Recuperación Tiempo para RecuperarCosto de la Interrupción $$ Duración de la Interrupción

Restauración de

Cintas de Respaldo

Costo Máximo

Tolerable

Costo

Tiempo

Ventana

Costo/Tiempo

Valor Total del NegocioAlta Disponibilidad

74

3.- Durante el Estudio de Alternativas de Recuperación

(RAS) se evaluán las estrategias, seleccionando la más

conveniente para el centro alterno de respaldo, resaltando

las ventajas y desventajas de cada una de las alternativas

de recuperación analizadas y aplicables.

La información recopilada en cada etapa se consolida para

conformar el Plan de Recuperación que satisface la ventana

de recuperación y los niveles de operación aceptables.

Recovery Strategies

Cost/Benefits Analyses

Skills Assessment

File Management AssessmentNetwork AssessmentSecurity AssessmentFacility Assessment

ISM Processes AssessmentDocumentation Assessment

Voice assessment

Recovery Alternatives

/Recommendations

Recovery Assessment

By Business

Function

Maximum Tolerable Outage Cost of outage

Critical Resources

Application priorities

Vital Records

Critical processes

Data Vintage

Análisis de Impacto al Negocio BIA Análisis de Ambiente EA Estudio de Alternativas

de Recuperación RAS

El resultado de las tres fases anteriores es un Plan de

Recuperación en caso de desastres. Se desarrolla el plan de

Recuperación con todas sus fase, retornando a la localidad

original, después de presentarse alguna contingencia que

afecte el soporte de IT.

Se obtendrán los elementos que en su conjunto

representarán la estrategia de protección y

recuperación del Infonavit

Análisis de Impacto en el Negocio (BIA)

Análisis de Ambiente de IT (EA)

Estudio de Alternativas de Recuperación (RAS)

Plan de Recuperación en caso de Desastres

Back up ProceduresRecovery Procedures

Teams &

Responsibilities

Escalation plan

Maintenance Plan

Relocation and Migration plan

Test Plan

Contact ListsEquipment

Inventory

Disaster Recovery

Implementation plan

75

IMPLEMENTACION

La duración estimada de todo proyecto es en semanas, en

donde de manera continua el equipo de trabajo del

Infonavit e IBM realizarán las actividades correspondientes

a cada fase.

1413121110987654321

321TIEMPO/

ACTIVIDAD

PRUEBA

IMPLANTACION

BRP

RAS

EA

BIA

ALCANCEEl alcance resulta y es afinado a lo largo de la definición de los

requerimientos, por los equipos de trabajo IBM y el Infonavit a

través de entrevistas, sesiones de trabajo y cuestionarios.

Entrevistas y sesiones de trabajo

Revisión de la documentación existente

Revisión Técnica de la Infraestructura de IT de Infonavit

Juntas de revisión

Entrega de Recomendaciones

FINDINGS

RECOMMENDATIONS

ACTION PLANS

Presentaciónfinal y entrega de

documentos generados

Cuestionarios

Revisión de Documentación

3. Términos y Condiciones

ENTREGABLESPara el Análisis (BIA) los entregables corresponden a un

documento de análisis del impacto en el negocio, que

incluye la evaluación del impacto durante una contingencia,

priorización de funciones y aplicaciones críticas, ventanas

de recuperación y recursos de usuario mínimos necesarios.

Con la siguiente guía:

INTRODUCCIÓN

PREMISAS

RESUMEN EJECUTIVO

METODOLOGÍA IBM

ANÁLISIS DE LAS ÁREAS DE NEGOCIO

ANALISIS DE IMPACTO

SECUENCIA DE RECUPERACIÓN DE APLICACIONES

HALLAZGOS, CONCLUSIONES Y RECOMENDACIONES

CALIFICACION DEL PROCESO DE CONTINUIDAD

76

Los Entregables en el Análisis de Ambiente de IT (EA) en

base a la revisión de la situación actual son:

Documento de análisis de ambiente incluyendo los

hallazgos, conclusiones y recomendaciones necesarias.

Con la siguiente guía:

INTRODUCCIÓN

PREMISAS

RESUMEN EJECUTIVO

AMBIENTE ACTUAL DE INFORMÁTICA

EVALUACIÓN DEL AMBIENTE INFORMATICO

HALLAZGOS

CONCLUSIONES

RECOMENDACIONES

Los entregables del Estudio de Alternativas de Recuperación

(RAS) son:

Documento de análisis de ambiente incluyendo los hallazgos,

conclusiones y recomendaciones necesarias, con la

siguiente guía:

INTRODUCCIÓN

PREMISAS

RESUMEN EJECUTIVO

AMBIENTE ACTUAL DE INFORMÁTICA

EVALUACIÓN DEL AMBIENTE INFORMATICO

HALLAZGOS

CONCLUSIONES

RECOMENDACIONES:

Los entregables del Plan de Recuperación son:

Documento conteniendo el plan de recuperación de

operaciones, orientado a a superar toda interrupción en los

servicios de informática; incluye la definición de los equipos de

trabajo, la descripción de actividades para la implementación

del plan, políticas de pruebas y mantenimiento. Con la siguiente

guía:

INFORMACIÓN GENERAL DEL PLAN DE RECUPERACIÓN

PARA EL CLIENTE

EQUIPOS DE TRABAJO Y RESPONSABILIDADES

IMPLEMENTACIÓN (EJECUCIÓN) DEL PLAN DE

RECUPERACIÓN

ACTIVIDADES DEL PLAN DE RECUPERACIÓN

ACTIVIDADES POR EQUIPO DE TRABAJO

PRUEBAS DEL PLAN DE RECUPERACIÓN

MANTENIMIENTO DEL PLAN DE RECUPERACIÓN

77

EQUIPO DE TRABAJOEl personal involucrado en la realización de este proyecto

intervendrá de acuerdo a su rol, en los diferentes momentos

en los que por su especialidad y responsabilidades sea

requerido.

Estructura Gerencial del proyecto

Ejecutivo de Proyecto

IBM

Ejecutivo de Proyecto

Cliente

Consultores

de recuperación

Especialistas

Técnicos

Gerente de Proyecto

IBM

Dueños de

Procesos de negocio

Personal

Técnico

Gerente de Proyecto

Cliente

IBM Global Services

© Copyright IBM Corporation 2003

INFONAVIT México - IBM Confidencial

Revisión del Plan de Recuperación

Revisión al 7 de Octubre del 2004

IBM Global Services

© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México

Agenda

Revisión del alcance del servicio general

Revisión de avance

Actividades Pendientes

Siguiente reunión de avance

78

IBM Global Services

© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México

2.Alcance General

Actividad Responsable

1.- Procedimientos de recolección y traslado de respaldos INFONAVIT/IBM

2.- Recolección de respaldos INFONAVIT/IBM

3.- Recuperación de respaldos INFONAVIT/IBM

4.- Procedimiento de mantenimiento al plan INFONAVIT/IBM

5.- Generación de respaldos (Procedimiento) INFONAVIT/IBM

6.- Procedimiento de operación de sistemas INFONAVIT/IBM

7.- Estudio de Aplicaciones Criticas INFONAVIT/IBM

8.- Planificación de pruebas INFONAVIT/IBM

Capacitación de uso de software LDRPS (Living Disarter Recovery Plan System) INFONAVIT/IBM

IBM Global Services

© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México

1. Avance

Actividad % Responsable

Procedimientos de recolección y traslado de cintas 90% INFONAVIT/IBM

Recoleccion de respaldos 100% INFONAVIT/IBM

Procedimiento de recuperación de respaldos 90% INFONAVIT/IBM

Procedimiento para el mantenimiento al plan 90% INFONAVIT/IBM

Aplicaciónes Criticas

-Revisión del estudio anterior

-Identificación de aplicaciones criticas (4)

20% INFONAVIT/IBM

Procedimientos de Generación de respaldos:

-Documentación de estrategia

-Solicitud de información a Raúl Cortes

20% INFONAVIT/IBM

IBM Global Services

© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México

3.Pendientes....

ActividadFecha

compromisoResponsable

1.- Procedimientos de recolección y traslado de respaldos

Entrega del documento

Firma de aceptación de Infonavit

15 OCT

20 OCT

IBM

INFONAVIT

2.- Recolección de respaldos

Revisión de alcance del contrato 14 OCT INFONAVIT/IBM

3.- Recuperación de respaldos

Matriz de escalamiento

Entrega del documento

Firma de aceptación de Infonavit

15 OCT

15 OCT

20 OCT

IBM

IBM

INFONAVIT

4.- Procedimiento de mantenimiento al plan

Entrega del documento

Firma de aceptación de Infonavit

15 OCT

20 OCT

IBM

INFONAVIT

5.- Generación de respaldos (Procedimiento)

Entrega de procedimientos 14 OCT INFONAVIT

79

IBM Global Services

© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México

Pendientes.

ActividadFecha

compromisoResponsable

6.- Procedimiento de operación de sistemas

Se solicitará lo requerido (Proveedores Criticos, Directorio

de personal de usuarios de aplicaciones, Definición de sitios

de reunión, etc)

Entrega de información solicitada

7 OCTIBM

INFONAVIT

7.- Estudio de Aplicaciones Criticas

Lista de aplicaciones actualizada (7 jun / 16 ago)

Solicitud de información a responsables (7 jun / 16 ago)

INFONAVIT

INFONAVIT

8.- Planificación de pruebas Pendiente de cerrar actividades

anteriores

9.-

Fecha Capacitación de uso de software LDRPS (Living Disarter

Recovery Plan System) (Agosto)

Especificar el equipo donde va ha recidir el sofware

Fecha Demo del producto con proveedor

INFONAVIT

INFONAVIT

IBM

10.- Plan de seguimiento de actividades anteriores 14 OCT IBM

IBM Global Services

© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México

Junta de seguimiento

Siguiente reunión:

- Lunes 14 de Octubre, 12:00 AM

80

FLUJOGRAMA: RECOLECCIÓN Y TRASLADO DE DE RESPALDOS A IBM

INICIOSe presenta ENOperación de

sistemas de INFONAVIT en días y

horarios convenidos contractualmente

Recibe del personal del

INFONAVIT el oficio en el cual se

relacionan los respaldos

Conjuntamente con personal del

INFONAVIT abren el contenedor y

revisan que lo relacionado en el

oficio corresponda al contenido.

El mismo día de la recolección se

debe entregar el contenedor con

los respaldos en la bóveda de

almacenamiento externo de IBM

Recibe la dos copias del oficio y el

contenedor con los resplados

Revisa que los marbetes, sellos o

candados de seguridad no hayan

sido violados o rotos.

Una vez revisado y verif icado el

oficio V.S. los cartuchos en el

contenedor, f irma de recibido en el

oficio (original y 2 copias)

Mensajería IBM Bóv eda de almacenamiento

Proced.

Recuperación de

respaldos en

caso de

contingencia

Empaca Cartuchos en el

contenedor, y lo cierran

utilizando marbetes,

sellos o candados de

seguridad

Traslada el contenedor con los

respaldos hacia la bóveda de

almacenamiento de IBM

(Nota: respetar y cumpir con los

procedimientos de seguridad de

accesos del Instituto)

Recibe, del personal de

INFONAVIT 2 copias del oficio

firmado por ambas partes

Los sellos, marbetes o

candados del contenedor

han sido violados?

No

Sí

Conjuntamente con personal de

Mensajería abren el contenedor y

revisan que lo relacionado en el

oficio corresponda al contenido.

Firma de recibido en las dos

copias. Se queda con una copia y

el personal de mensajería se

queda con la otra copia

Rcibe. resguarda y administra los

respaldos recibidos con base a sus

procedimientos internos

81

Diagrama del Plan de Acción ( FASE DE PREVENCION)

EQUIPO COORDINADOR

DE RECUPERACION

EQUIPO DE

OPERACIÓN

EQUIPO PLAN.

FISICA

EQUIPOS

TÉCNICOS

PLANEACION A LA

PRODUCCION

Mantener actualizados

los directorios

10

Definir políticas para

situaciones legales

55

Elaborar presupuesto anual

para DRP

65

Resguardar los

respaldos en Bóveda

Externa

25

Identificar manuales de

operación que deban

estar en bóveda externa

35

Mantener actualizados los

directorios

10

Actualizar los Directorios

necesarios para comunicar

la contingencia

15

Contar con planos

estructurales

32

Identificar al Responsable

del Centro de Cómputo

Alterno

40

Mantener actualizados los directorios

necesarios (proveedores, clientes, personal)

Actualizar al personal de cada equipo de

recuperación

Actualizar los requerimientos mínimos y

Registros Vitales

Contar con la documentación de la

configuración de los equipos de su

responsabilidad

Contactar a los proveedores de software

para el uso de licencias de software en el

centro de cómputo alterno

Actualizar el uso de Licencias de Software en

el Centro de Cómputo Alterno

Evaluar el portafolio de aplicaciones críticas

cada seis meses

Documentar los procedimientos de

recuperación de acuerdo a su área de resp.

Obtener passwords para los productos no

IBM en el Centro de cómputo alterno

Validar la actualización de los procedimientos

de recuperación.

Realizar pruebas a los respaldos de

información

Mantener actualizados los

directorios necesarios

(proveedores, clientes,

personal)

10

Verificar la actualización

de los requerimientos

mínimos y registros

vitales

15

Actualizar al personal de

su equipo de

recuperación

25

Contar con copia de los

planes de ejecución en

bóveda externa

30

Asegurar que los respaldos de información

crítica son enviados a la bóveda externa.

Asegurar el Mantenimiento

al plan de Recuperación

10

De acuerdo a los riesgos

Contratar Seguros

45

Asegurar la capacitación de

los Equipos de Recuperación

75

Actualizar al personal de su

equipo de recuperación

15

Actualizar la configuración

del equipo cada 6 meses

20

Contar con la relación

de cartuchos de

respaldos en bóveda

externa

45

Actualizar al personal de su

equipo

15

Revisar los servicios que

mantienen la seguridad

física

20

Revisar los servicios de

emergencia

25

Revisar cada 6 meses las

instalaciones del edificio

30

Revisar las localidades de

recuperación cada 6 meses

35

Actualizar los planes de

ejecución

35

Participar en los

simulacros del DRP

Diagrama del Plan de Acción ( FASE DE PREVENCION)

EQUIPO COORDINADOR

DE RECUPERACION

EQUIPO DE

OPERACIÓN

EQUIPO DE PLAN.

FISICA

EQUIPOS

TÉCNICOS

PLANEACION A LA

PRODUCCION

Contratar servicio de red para DRP con

proveedores

Contar con Manuales de Operación en

Centro de Cómputo alterno

Desarrollar los checklist de evaluación de

desastre

Planear y coordinar la realización de

simulacros en forma periódica

Desarrollar checklist de evaluación del

desastre de acuerdo a su área de resp.

Realizar una consolidación de información

en servidores de recuperación y

documentar

Definir requerimientos de la red para el

DRP

SINIESTRO

Desarrollar el Checklist

para evaluar el

Desastre

40

Planear la ejecución de

simulacros de seguridad

45

Participar en la ejecución

de las pruebas del DRP

50

Revisar la actualización

checklist para evaluación

de desastre

95

Planear y coordinar la

realización de pruebas del

plan

120

Definir políticas de

activación del DRP

125

Preparar y notificar fecha

de simulacros a los equipos

de recuperación

135

Participar en la ejecución

de las pruebas del DRP

140

Elaborar checklist

para evaluar el

desastre

50

Documentar y

actualizar

procedimiento de

IPL

55

Documentar y

actualizar

procedimiento de

IPL

55

Participar de manera

activa en los

simulacros de DRP

65

Diagrama del Plan de Acción ( FASE DE RESPUESTA)

EQUIPO COORDINADOR

DE RECUPERACION

EQUIPO DE

OPERACIÓN

EQUIPO DE PLAN.

FISICA

EQUIPOS

TÉCNICOS

PLANEACION A LA

PRODUCCION

Declarar el Desastre

Notificar el Desastre

SINIESTRO

Establecer

Comunicación con los

Equipos

Contactar Servicios de

Emergencia

y Asistencia Médica

Solicitar la Evaluación del

Impacto del Desastre

Es un Desastre

Obvio ?

Evaluar la disponibilidad

del personal

asignado al Centro de

Cómputo alterno

Establecer

Comunicación con los

Equipos

Notificar el Desastre

Si

Solicitar la Evaluación del

Impacto del Desastre

Es técnico

y/o problema físico

severo ?

Evaluar la disponibilidad

del personal

asignado al Centro de

Cómputo Alterno

Establecer Comunicación

con los Equipos

Continuar Proceso Resolución

de Problemas (Matriz de

Escalamiento)

Solución < 72 hrs.

Corrige falla

Regreso a

Operación

Normal

Si

No

No

No

No

Si

Evaluar la disponibilidad

del personal

asignado al Centro de

Cómputo alterno

Si

82

Diagrama del Plan de Acción ( FASE DE

RECUPERACIÓN)

EQUIPO COORDINADOR

DE RECUPERACIÓN

EQUIPO DE

OPERACIÓN

EQUIPO DE PLAN.

FISICA

EQUIPOS

TÉCNICOS

PLANEACION A LA

PRODUCCION

Realiza actividades de

atención a la emergencia

10

Asegurar que todos los

integrantes han sido

notificados sobre el

desastre

Apoyar al personal que

haya resultado herido

40

Desarrollar plan de trabajo

para renovar el equipo o

instalaciones

60

Trabajar con los proveedores

de equipo para su

reconstrucción

80

Registrar en bitácora las

desviaciones

62

Asegurar que todos los

integrantes han sido notificados

sobre el desastre

10

Hacer la evaluación del desastre

y determinar daños

Tomar las acciones apropiadas para

restablecer el Centro de Cómputo

Primario

Solicitar requerimientos de equipo

necesarios para reestablecer

comunicaciones, u otros equipos

Trasladarse al centro de cómputo

alterno

Ir por los respaldos y registros vitales

de la bóveda externa

Recuperar e sistema en el Centro de

Cómputo (producción y WEB)

Recuperar los servidores en el centro

de cómputo alterno

Solicitar los registros

vitales a la bóveda

externa

25

Prepara noticias que serán

liberadas a medios de

información

40

Asegurar que todos los

integrantes han sido

notificados sobre el

desastre

10

Establecer acuerdos con los

líderes de equipos de

recuperación

130

Registrar en bitácora las

desviaciones así como las

acciones tomadas

132

Mantener contacto con las

unidades de negocio para

notificar la situación

135

Coordinar solución de

problemas legales

140

Contactar empresas de

seguros

78

Contactar proveedores

de servicio para

restaurar Centro de

Cómputo

25

Obtener de la bóveda

los respaldos y

manuales de operación

90

Restaurar el ambiente

de producción

100

Restaurar el ambiente

WEB

120

Coordinar los

suministros con

proveedores

150

Realizar los respaldos

de información

y enviar a bóveda

170

Validar el daño a la

localidad y a sistemas de

soporte

35

Operar con los procedimientos

diseñados en la etapa anterior

Asegurar que todos los

integrantes han sido

notificados sobre el

desastre

10

Informar a los proveedores,

usuarios la situación de

desastre

17

Definir acciones a

seguir para los

procesos batch

40

Diagrama del Plan de Acción(FASE DE REANUDACIÓN Y

RECUPERACIÓN)

EQUIPO COORDINADOR

DE RECUPERACIÓN

EQUIPO DE

OPERACIÓN

EQUIPO DE PLAN.

FISICA

EQUIPOS

TÉCNICOS

PLANEACION A LA

PRODUCCION

Verificar que los accesos a los

equipos y BD trabajan

adecuadamente

Dar seguimiento a los acuerdos

establecidos por los líderes de los

equipos de recuperación

Reconstrucción del Centro de

Cómputo primario

Registrar en bitácora los problemas

presentados y las acciones tomadas

Registrar en bitácora

actividades así como

problemas detectados

47

Ejecutar las alternativas

para actualizar la

información de respaldos

40

Iniciar la operación de las

aplicaciones críticas

60

Entrega del producto

final al usuario y

esperar el VoBo

70

Obtener aprobaciones de

autoridades civiles

95

Registrar en bitácora las

desviaciones presentadas

187

Dar seguimiento a las

actividades de

Reparación al Centro de

Cómputo

190

Trabajar con los equipos

técnicos para la

reocupación del Centro

de Cómputo

85

Establecer fechas

compromiso para

restaurar el Centro de

Cómputo

150

Diagrama del Plan de Acción ( FASE DE RESTAURACIÓN)

EQUIPO COORDINADOR

DE RECUPERACIÓN

EQUIPO DE

OPERACIÓN

EQUIPO DE PLAN.

FISICA

EQUIPOS

TÉCNICOS

PLANEACION A LA

PRODUCCION

Declarar la terminación del

desastre

15

Evaluar el plan de acción y

desempeño de los equipos en el

proceso de continuidad y

reanudación

60

Evaluar el plan de

acción y desempeño de

los equipos en el

proceso de continuidad

y reanudación

120

Informar la estabilidad de la

infr. De equipos estratégicos

para garantizar la operación

10

Evaluar el plan de acción y

desempeño de los Equipos

en el proceso de

continuidad y reanudación

12

Contactar autoridades

civiles para implantar

procedimientos

15

Realizar plan de trabajo para

regreso de operación

Entregar los registros vitales

Supervisar la toma de

respaldos

Borrar información del Centro

de Cómputo alterno

Restaurar los ambientes de

producción y WEB

Aplicar checklist de validación

de ambientes

Evaluar el plan de acción y

desempeño de los Equipos

en el proceso de continuidad

y reanudación

Entregar los registros

vitales

5

Validar ambiente

productivo

20

Evaluar el plan de acción

y desempeño de los

Equipos en el proceso de

continuidad yreanudación

40

FIN

Terminar operaciones en el centro

de cómputo alterno

20

Controlar y enviar los registros

vitales a la bóveda externa

35

Solicitar a la aseguradora la

remuneración de daños

55

Implantar cambios a

procedimientos

65

Verificar el plan de pruebas y los

alcances

75

Entregar los requerimientos

mínimos y registros vitales

15

Respaldar información del

ambiente de producción y

WEB

40

Enviar respaldos y

documentación al centro

cómputo primario

50

Restaurar los ambientes de

producción y WEB

90

Actualizar los

procedimientos

125

Actualizar procedimientos

20

Actualizar procedimientos

Revisión de procesos y

decidir acciones a tomar

30

Actualizar procedimientos

45

83

2.13 Conclusiones Administración de Proyectos Sinceramente la metodología de administración de proyectos antes mencionada es de gran utilidad para llevar adecuadamente un proyecto.

84

Me gustaría solo comentar algunas cosas que creo relevantes: a.- Cuando se nos asigne un proyecto es importante saber que es exactamente lo que se esta esperando de nosotros, y el nivel de autoridad que tendremos en el mismo, posiblemente en algunas organizaciones los recursos que estén bajo nuestro cargo tienen su jefe administrativo, es importante dialogar con el y el equipo de trabajo para que todos tengan claro la forma de trabajar. b.- Revisar con el cliente el contrato antes de empezar su ejecución, para asegurarnos que los dos estamos esperando lo mismo c.- Realizar la reunión de Kickoff, en donde se generará la minuta de arranque donde se plasmara de forma general cuales son los canales de comunicación, quienes son los responsables por ambas compañías y listar los primeros compromisos c.- Una vez empezado el proyecto e identificado a los participantes y definido el alcance revisar o generar el plan de trabajo el cual deberá de ser autorizado por el cliente y mostrado a los participantes para que todos estén esterados de las fechas y quienes son los responsables de las actividades También es importante hacer la carpeta de control de proyectos con la documentación mas importante del proyecto, con una pestaña de control financiero. Si hay gastos de viáticos, sugiero llevar un a carpeta complementaria, el manejo de los proveedores deberá de quedar en la carpeta principal junto con los contrato o acuerdo tomados con ellos. d.- Documentar semanalmente o quincenalmente el avance del proyecto, en caso de desviaciones también deberán de quedar asentadas aquí, en caso de que los contratiempos ocasionen un incumplimiento del plan de trabajo, es necesario generar un control de cambios el cual se debe de documentar y ser aprobado por el cliente (En caso de que el cliente no lo apruebe también se debe de documentar y la razón) e.- Asegurarse de cumplir con los entregables del contrato, si el cliente desea cambiar alguna actividad ya definida previamente, se deberé de documentar con un control de cambios, de igual forma si el cliente nos pide algo adicional sin importar si afecta o no el plan se deberá de evaluar y definir si se realiza dentro de este proyecto o mejor se genera un proyecto en paralelo para realizar esta actividad, les sugiero que por ningún motivo se retrase las fechas de un proyecto a no ser que sea por causa mayor y que este correctamente documentado. f.- Es importante que se revise periódicamente los gastos, la facturación con el cliente para que sepa cuanto se ha gastado y según lo planeado cuanto más se ira gastando, en caso de que se gaste más de lo planeado se deberá de generar un control de cambios documentándolo y deberá de ser aprobado por el cliente.

85

g.- En los reportes de avance que se tenga con el cliente se deben de ir marcando las tÁreas terminadas y si se ha cumplido con el contrato. h.- Antes de cerrar el proyecto revisar con el cliente que efectivamente se cubrieron los puntos acordados tanto en el contrato como durante el proyecto, y si algún punto no se quedará cubierto presentarle al cliente la razón y la documentación del por que no. i.-Generar carta de terminación y realizar la encuesta de satisfacción, para saber que tan satisfecho esta el cliente con nuestro trabajo. En caso de que el proyecto duré más de 6 meses, se recomienda hacer una encuesta de satisfacción a la mitad del proyecto o al término de cada fase. Anexo algunos formatos que considero importantes para manejar un proyecto y algunos de evaluación. Dentro de IBM tuve la fortuna de administrar varios proyectos.

86

Conclusiones. Con todo lo antes expuesto, creo que he comprobado mi experiencia dentro del área de informática por los últimos 15 años, he aprendido muchas cosas y siento que aun me falta muchas más por aprender y certificarme. Considero que en la vida de todo Licenciado en Informática debe de entender que hay tres cosas que siempre deberá de considerar.

- Siempre hay un cliente que tiene algún problema y que requiere de nuestra ayuda, la destreza y conocimientos de cada uno será la diferencia de satisfacción del cliente

- Siempre necesitaremos de un equipo de trabajo el cual será nuestro apoyo para el éxito de un proyecto

- Nosotros somos parte del equipo de trabajo y necesariamente debemos de aprender a comunicarnos claramente.

87

Bibliografía

- Documentación proyectos IBM DE 1997 – 2002 v1.5 - Metodología Conversión año 2000 IBM - Management Empresarial El diario Financial Times (Chile) - Project Management Body of Knowledge (PMBOK Guide) - Project Management Fundamentals v2.4 IBM

- Project Management

http://img.redusers.com/imagenes/libros/lpcue024/capitulogratis.pdf

88

ANEXOS Formato de Kickoff

Fecha y Lugar Tipo de Reunión Horario Participantes Agenda Narrativa

_________________________________________________ Julio 04, del 2000. Banco Santander Mexicano Manuel Avila Camacho 170 1er. Piso Col. Lomas San Isidro CP 11620 _________________________________________________ Kickoff. _________________________________________________ 11.30 - 13.00 hrs _________________________________________________

Nombre

Puesto

Siglas

Emilio Porras Alonso

Gerente de Proyecto Santander

EP

Wuilbert Martinez

Soporte

WM

Jose Luis Quiroz

Gerente de Proyecto IBM

JLQ

1. Presentación del equipo de trabajo 2. Solicitud de requerimientos por parte de IBM LAC presento a los nuevos integrantes del quipo de trabajo quedando conformado de la siguiente forma: Gerente de proyecto por parte de Santander Emilio Porras Alonso

89

Gerente de proyecto por parte de IBM 2. Solicitud de requerimientos por parte del proveedor 3. Revisión del plan de trabajo 4. Revisión de requerimientos

Acuerdos 1.- EP estuvo de acuerdo con los integrantes del equipo de trabajo y la forma de comunicación en ambas partes.

Compromisos 1.- EP quedo de enviar la lista de la gente que participará por parte del Banco. …..

90

Formato de Minuta

Fecha y Lugar

Julio 20 de 2000. BBVA Madrid, España

Tipo de Reunión

Reunión de Trabajo.

Horario 09:00 – 18:00 hrs Participantes BBVA Área IBM Latinoamérica Arturo Gil Sistemas

Operativos

Luis Enrique Sanchez

Patricia García DB2/UDB Jorge Combes Maria Lucero

García NES Jorge Benitez

José María Rodriguez

Comunicaciones José Luis Luna

Emilio Delgado MQSERIES/XCOM

Jorge Yaqui

Agenda Software Base – AIX, SOLARIS HACMP

Tivoli Websphere Application Server, Netscape Enterprise Server,

DB2/UDB: Narrativa TEMA: Reunión. Software Base (AIX, SOLARIS), HACMP, Java

Run Time, Tivoli: 1.- AIX. Y S.O. SUN. HACMP. 2. TIVOLI. Los contactos directos para aclaración de dudas será: -

Acuerdos AIX.

Compromisos Software Base (AIX, SOLARIS), HACMP, Java Run Time, Tivoli:

91

Formato de Reporte de Seguimiento Ing. Juan Carlos Zurita Por medio de la presente le hago llegar el reporte semanal de las horas trabajadas del periodo 4 de Enero al 6 de Enero del 2001 para el Proyecto “Banca a Distancia”.

Nombre Actividades Horas

Jorge Combes Soporte aplicatvo Revision de configuración actual Reunión de trabajo …..

28 horas

Patricia Armendariz

Reinstalación de Network Dispatcher …..

10 horas

Jorge Benitez / Mikalonis

Revisión de ambiente …

28 horas

José Luis Quiroz Revisión con BBVA Bancomer del avance que se tiene en el proyecto

…

18 horas

Total de horas 84 horas

Informe de avance. Seguridad Mqseries Aplicación….

Conclusiones:…….

Pendientes: Seguridad……. Aplicación.…… Atte. Autorizo ______________________ ________________________ José Luis Quiroz Lechuga Ing.Juan Carlos Zurita Project Manager IBM Líder de proyecto BBVA Bancomer

92

Control de Cambios

FORMATO DE SOLICITUD DE CAMBIO No ___2

CLIENTE BBVA Bancomer S.A.

PROYECTO Banca a Distancia

SECCIÓN 1: DESCRIPCIÓN DEL CAMBIO Requerimiento que afecta: Cambio en cronograma

Descripción del Cambio: De acuerdo a la solicitud de BBVA Bancomer

Se detiene el proyecto a partir del 29 de septiembre del 2000, estimando reiniciarlo el 10 de

Octubre del 2000. Debido a que el desarrollo del aplicativo no esta terminada por BBVA España,

Y la infraestructura esta casi terminada, se detendrá hasta que el aplicativo este listo.

José Luis Quiroz Lechuga IBM 2-Oct-00 Nombre Firma Compañía Fecha

SECCIÓN 2 : ANÁLISIS DEL CAMBIO Costos Estimados $ 0 Evaluado Por Juan Carlos Zurita Tiempo Estimado 0 hrs Fecha 2 de octubre del 2000 Solución Propuesta: Esperar que el aplicativo este listo para continuar con la

puesta a

Punto de la infraestructura y probar con el aplicativo. Se acordó continuar con la configura-

……….

Parte del Contrato que Modifica: Cronograma

SECCIÓN 3 : DEFINICIÓN DEL CAMBIO Aprobado Si. Rechazado Diferido Juan Carlos Zurita BBVA Bancomer 2-oct-00 Nombre Firma Compañía Fecha

Sergio Mendoza BBVA Bancomer 2-Oct-00 Nombre Firma Compañía Fecha

93

Plan de trabajo Formato de un proyecto

94

Formato de Cierre Ing. Juan Carlos Zurita Le informo que de acuerdo al anexo “Banca a Distancia” Number Contract MXAAAYY Work Number MXABAY del contrato firmado entre IBM de México y Bancomer S.A. No 3098000171. Se da por terminado satisfactoriamente la instalación y configuración de la infraestructura con la aplicación BBVNET: Entre las Áreas relevantes realizadas en esta Fase II fueron: 1- Se instalo la versión del aplicativo 1.0 enviado por España y se hicieron pruebas de a travez de la infraestructura validando cada uno de los componentes instalados los cuales se pusieron a punto y se dejaron funcionando. 2.- Se instalo la nueva imagen del aplicativo y se hicieron pruebas de volumen en el ambiente productivo con una transacción y que esta funcionamiento, pero al mandar 10 usuarios concurrentes con 10 transacciones no se recibió respuesta de host y se continua revisando para identificar cual es el problema. 3.- Se integro el equipo de operadores que darán el servicio de 7 x 24 a partir del 12 de enero y se les dio una inducción de los productos instalados. Ellos solo son responsables de la operación, en caso de algún problema seguirán la matriz de escalamiento. 4.- Se entregó un draft de la documentación de la operación de los productos instalados en los equipos IBM. Se esta trabajando en la ultima versión. 5.- Se continua haciendo pruebas para identificar donde están las demoras en los tiempos de respuestas. 6.- Se entregó el ambiente estable aunque falta por terminar hacer pruebas Pido de favor firme al calce dando por finalizada la fase II del proyecto, así como satisfactoria los entregables marcados en el anexo del contrato firmado entre IBM y Bancomer. Atte. Acepto ______________________ ________________________ José Luis Quiroz Lechuga Ing.Juan Carlos Zurita Project Manager IBM Líder de proyecto BBVA Bancomer

95

Formato de Carta de Terminación Ing. Carolina Santana Me es grato informarle que el proyecto “Instalación del VTS” OMSYS ha concluido satisfactoriamente, terminándose las actividades marcadas en el plan de trabajo. Se dio la capacitación información transfiriendo los conocimientos del proceso satisfactoriamente. Solo me queda agradecerle las facilidades brindadas para el éxito de este proyecto y quedo a sus ordenes para cualquier otro requerimiento que necesiten. Por favor firme al calce de aceptación servicios y cumplimiento con todos los entregables marcados en el contrato. Atte. Acepto ______________________ ________________________ José Luis Quiroz Lechuga Ing.Carolina Santana Project Manager IBM Líder de Proyectos EDS

96

Formato de Encuesta de satisfacción del cliente Le agradeceremos se tome algunos minutos para describir su nivel de satisfacción con el desempeño de nuestro equipo de trabajo en el proyecto: “ “ Su retroalimentación nos ayudara a mejorar nuestro servicio. ¿ Que tan satisfecho esta? :

1. De que IBM cubrió sus expectativas en todo lo relacionado al contrato o proyecto.

Comentario.______________________________________________________________________________________________________________________________________________________________________________________________________________________________________

( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión

2. De que IBM entendió las necesidades de su negocio en el diseño de este contrato o proyecto?

Comentario.________________________________________________________________________________________________________________________________________________________________________________________________________________________________

( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión

3. De que IBM mantuvimos comunicaciones claras durante todas las fases del contrato o proyecto?

Comentario.______________________________________________________________________________________________________________________________________________________________________________________________________________________________________

( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión

4. Con las habilidades de la gente que trabajó en este contrato o proyecto?

Comentario.____________________________________________________________________________________________________________________________________________________________________________________________________________________________

( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión

5. Con el valor recibido por ustedes en relación con la inversión que hicieron en este contrato o proyecto?

Comentario.______________________________________________________________________________________________________________________________________

( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy

97

_______________________________________________________________________________________________

Insatisfecho ( ) 0 Sin Opinión

6. De que este contrato o proyecto fue administrado eficazmente?

Comentario.______________________________________________________________________________________________________________________________________________________________________________________________________________________________________

( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión

7. De que cumplimos los compromisos que hicimos respeto a la ejecución de los servicios o entrega e instalación de los productos?

Comentario._____________________________________________________________________________________________________________________________________________________________________________________

( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión

8. Si requiriera servicios adicionales en el futuro, escogeria a IBM como su proveedor?

Comentario.______________________________________________________________________________________________________________________________________________________________________________________________________________________________________

( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión

9. Considerando todos los aspectos del contrato o proyecto, la solución, la gente y la entrega de la solución, por favor díganos su nivel general de satisfacción.

Comentario._____________________________________________________________________________________________________________________________________

( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión

10. Basado en su experiencia en este contrato o proyecto. ¿Recomendaría a IBM a otros? Comentario.______________________________________________________________________________________________________________________________________________________________________________________

( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión

11. Le gustaría que IBM lo contactará acerca de los resultados de esta encuesta?

( ) Si ( ) No

98

Nombre :_______________________________________ Puesto: ______________________ Número Tel.: _______________ Firma: ______________________ Fecha: ________________ A ser completado por el entrevistador: Razón Social del Cliente: _______________________________________________________________ Proyecto: _______________________________________________________________ Línea de Servicios: ______________________ Fecha del proyecto __/__/__ - __/__/__ Número de contrato (De aplicar): _______________ Número de Cliente ___________ GB __________ Nombre del Entrevistador : _________________________________________