INSTITUTO POLITÉCNICO NACIONAL

Transcripción

1 INSTITUTO POLITÉCNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERIA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS AÑO 2000 Y ADMINISTRACIÓN DE PROYECTOS DE INFORME DE MEMORIA 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

2 INDICE Resumen Introducción i ii Capítulo I. Practica Año Historia IBM Organigrama Antecedentes Necesidad de Conversión Año Qué es el problema del año 2000? Perspectivas acerca del problema El problema del año bisiesto Las PCs y el problema año Concientización Asesoramiento Renovación Validación Implementación Planes de Contingencia Capacidad de respuesta a emergencias Herramientas Clientes Conclusiones año Capítulo II administración del proyecto IBM 2.1 Antecedentes PMI Project Manager La llave del éxito del gerente del proyecto Tipo de organización usada en Proyectos Project Charter Definición del Baseline y sus exclusiones Organización el trabajo WBS Manejo del Riesgo Estableciendo el estimado del proyecto Creando el calendario del proyecto Experiencia en Manejo de Proyectos Conclusiones administración de proyectos 83

3 Conclusiones 86 Bibliografía 87 Anexos 1.- Kickoff Minuta Reporte de Seguimiento Control de Cambios Plan Cierre Carta de Terminación Encuesta de Satisfacción 96

4 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. i

5 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. ii

6 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 iii

7 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. iv

8 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 La equipos involucrados fueron: - PCs - Mainframe - AIX - Storagetek - AS/400 Las áreas involucradas fueron: Diferentes clientes Centros de computo Proveedores v

9 Á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. vi

10 Capítulo I. Practica año 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, 1

11 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. 2

12 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 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

13 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 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. 4

14 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 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 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 5

15 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 6

16 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 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. 7

17 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 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. 8

18 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 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 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. 9

19 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 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 Windows NT 3.51 podría reconocer fechas anteriores a 1980 sin corregir el problema por si mismo. La 10

20 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 Así los problemas que se presentarían en el 2000 sólo se prorrogarán para el 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 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. 11

21 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. 12

22 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 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 o o Pruebas durante el asesoramiento Pruebas durante la renovación 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 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 13

23 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 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 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 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. 14

24 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 Construcción de los planes de contingencia, identificación selección de de los eventos activadores (criterio para utilizar los planes), alternativas prueba de los planes, capacitación del recurso humano 3. Diseño del plan de Es la fase más extensa. En ella se consolida el plan de contingencia 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 Llevar los planes de contingencia más allá del papel, plan de asegurando su efectiva y rápida puesta en funcionamiento. contingencia 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 15

25 contingencia a una solución permanente 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 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 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. 16

26 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. 17

27 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. 18

28 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 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. 19

29 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. 20

30 21

31 NATURAL. 22

32 23

33 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 24

34 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. 25

35 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: 2.2 PMI 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 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. 26

36 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: 27

37 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 Fase 2 Diseño de la solución 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. 28

38 Este enfoque es mas hacia los vendedores que desarrolladores de soluciónes. IPD (Integrated Product Develoment) Fase 1 Fase 2 Fase 3 Fase 4 Fase 5 Fase 6 Concepto Plan Desarrollo Calificar Lanzar 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 Fase 2 Fase 3 Fase 4 Concepto Desarrollo Ejecución 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 29

39 - 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 30

40 - 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 31

41 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. 32

42 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. 33

43 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. 34

44 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: 35

45 - 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 36

46 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 37

47 - 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. 38

48 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 39

49 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 40

50 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 41

51 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 Factor De 12 meses en adelante Factor 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: 42

52 - 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 43

53 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? 44

54 - 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 45

55 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. 46

56 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 BBVANET Instalacion de VTS Línea de soporte y soporte en sitio Manejo de fallas Instalacion de equipo SUN Instalacion de Tivoli DRP Avonne. Banco de Colombia, Goodyer Chile Banca a distancia Bancomer EDS Iusacell, LyFC, Telmex Secretaria de Finanzas IMSS Gedas 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 Julio 04, del Banco Santander Mexicano Manuel Avila Camacho 170 1er. Piso Col. Lomas San Isidro CP Kickoff hrs Participantes Nombre Puesto Siglas 47

57 Emilio Porras Alonso Gerente de Proyecto Santander EP Wuilbert Martinez Soporte WM Jose Luis Quiroz Gerente de Proyecto IBM JLQ Agenda 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 Narrativa 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á 48

58 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 Revisión de requerimientos de los servidores para TIVOLI Acuerdos Compromisos 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. 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. 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 Lugar Tipo Reunión Horario y de Julio 20 de BBVA Madrid, España Reunión de Trabajo. 09:00 18:00 hrs Participantes BBVA Área IBM Latinoamérica Arturo Gil Sistemas Luis Enrique Sanchez 49

59 Operativos Patricia García DB2/UDB Jorge Combes Maria Lucero NES Jorge Benitez García José María Comunicaciones José Luis Luna Rodriguez Emilio Delgado MQSERIES/XCO M Jorge Yaqui Agenda Narrativa Software Base AIX, SOLARIS HACMP Tivoli Websphere Application Server, Netscape Enterprise Server, DB2/UDB: 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) El área del Banco Infraestructura Técnica siguiente: nos informo lo 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: 50

60 Pendientes: - Se les pidío configuración del hacmp incluyendo los Scripts de paro y arranque. 2. TIVOLI. Acuerdos Compromisos Los contactos directos para aclaración de dudas será: - AIX. Se acordó que para México, Colombia y Perú la versión que se instalará será la versión AIX Software Base (AIX, SOLARIS), HACMP, Java Run Time, Tivoli: Aix Reporte de Seguimiento Ing. Juan Carlos Zurita - 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.*). 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 28 horas Revision de configuración actual Reunión de trabajo.. Patricia Reinstalación de Network Dispatcher 10 horas Armendariz.. Jorge Benitez / Revisión de ambiente 28 horas Mikalonis José Luis Quiroz Revisión con BBVA Bancomer del avance que 18 horas se tiene en el proyecto Total de horas 84 horas 51

61 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 Project Manager IBM Ing.Juan Carlos Zurita Líder de proyecto BBVA Bancomer 52

62 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 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 Project Manager IBM Ing.Juan Carlos Zurita Líder de proyecto BBVA Bancomer 53

63 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 Project Manager IBM Ing.Carolina Santana 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 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. 54

64 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 Project Manager IBM Lic. Christian Planeación y Proyectos de sistemas 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 SW 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 ADMST MX1 17 P2SDP9F H C 3 REP CE 7018 SECRETARIA DE F QUIÑONES CALLS 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. 55

65 Quedo a sus ordenes para cualquier comentario al respecto. Atte. Lic. José Luis Quiroz Project Manager Tel IBM Reporte de Avances Transición Versión del plan: 1.0 Fecha de reporte: 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 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 Pendiente de firma de aceptación En espera de observaciones Se revisarán en la siguiente semana En espera de observaciones Tareas Terminadas Terminadas al 05 de Diciembre 2001 contra plan de trabajo ID 3 Start Up ID 46 Transferencia de Recursos Humanos ID 50 Plan de Transición detallado ID 60 Evaluación ambiente operativo del Comentarios Reporte pendiente Plan entregado Documento entregado 56

66 ID 129/149 Implantación Problemas y Cambios ID 6320 Proyectos en Proceso 80 % de avance, procesos definidos y en validación, documentos entregados Documento entregado Adelantadas Comentarios Planeadas pero no terminadas Comentarios Por realizar / En Proceso Comentarios Issues Significativos El cambio de Proveedores sigue siendo el punto más significativo, se está definiendo un plan específico adicional para su manejo Comentarios 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 57

67 Reporte de Estatus de la Transición Technical Transition 04/01/2002 Tabla de Contenido Tabla de Contenido Evaluación del Estatus del Proyecto Notas Planes de Mitigación para las areas en en riesgo (Amarillo & Rojo ) Actividades en BAU Cost Tracking (Help Desk) 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 Factores Críticos de exito Issues Abiertos Cambios aprobados Evaluación del Estatus del Proyecto Ref. Descriptivo Avance Fecha Comentario Riesgo Plan Contractual 47 Transferencia RH 100 % Nov 01,2001 Se transfirieron y cubrieron todos los recursos definidos 48 Cubrir vacantes y 80 % Ene 15,2002 De 5 plazas adicionales definidas adicionales (incluye contractualmente, tenemos Anexo J) pendiente por cerrar una, Cuernavaca 59 Plan de transición de 100 % Nov 15,2001 El plan de trabajo se entrego el 15 detalle aprobado de noviembre como estaba 277 Manual de procedimientos establecido 60 % Ene 31,2002 En Proceso 303 Firma de SLAs con ScotiabankInverlat 325 Firma de nuevos base lines del plan de transición (Proyectos en Proceso) 331 Proveedores Transferidos (Plan Relación con Proveedores) 60 % Ene 31,2002 Se concluyo documento de definición de SLA s se entregó draft el 22 de dic 100 % Nov 30,2001 En casa de bolsa cerrado, en el banco en firma, documento de referencia 60 % Ene 31,2002 Se acepto por parte del banco la transferencia de proveedores, a dar inicio en febrero del

68 Notas Recursos habilitados, Plan creado, Team ejecutando en plan y expectativas cubiertas de acuerdo al plan y a entregables Cubierto lo anterios, pero existen dependencias que deben ser direccionadas y que pueden impactar el plan Entragables identificados o plan requerido, los riesgos ponen a los entregables en plan bajo riesgo Verde Amarillo 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 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 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 Martín Ruiz Joaquin Urias 30/Ene/02 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 Cobro del resultado del item 5 de la tabla de issues Cobro de costos adicionales por concepto de viatico Responsable PE PE Cost Tracking (Help Desk) Cost Tracking (Provedores) 59

69 Estatus General del Proceso de Transición Entregables definidos en el contrato MILESTONES PROYECTADOS Día Efectivos a partir fecha Inicio / Fecha 01/nov/01 1 Plan de Transición documentado 0 2 Inicio de la Transición 0 3 Inicio de BAU (Business as Usual) Inicio de operaciones por IBM 4 Transición de empleados Inverlat 0 5 Procedimiento de Cambios Implantado Revisión y documentación de Proyectos en Proceso Impacto de Proyectos en Proceso a la Transición Plan de transición detallado BASE LINE definido 9 Validación de alcance con Proveedores Inventario de Activos Borrador de Procesos y Procedimientos Definición de Niveles de Servicio con base en Niveles de Servicio Objetivo Implantación de Niveles de Servicio en contratos de Mantenimiento 14 Firma de contratos con proveedores Documento Final de Procesos y Procedimientos Definición de Unidades Equivalentes de Servicio (BASE LINES & Consumos Adicionales) Definición de Tabla de tiempos muertos por Plaza 18 Firma de entregables de la Transición Cierre de la Transición /nov/01 01/nov/01 01/nov/01 30/nov/01 30/nov/01 30/nov/01 15/nov/01 30/nov/01 30/dic/01 30/dic/01 30/ene/02 30/ene/02 30/ene/02 30/ene/02 30/ene/02 30/ene/02 30/ene/02 30/ene/02 Estatus Cerrado Cerrado Cerrado Cerrado 80 % Cerrado Cerrado Cerrado Cerrado 75 % 60 % 60 % 60 % 75 % 60 % 80 % 80 % 0 % 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) 60

70 Issues Abiertos ID Prioridad Issue Fecha Comentario 1 1 Obtención de autos 07/ene/ Transferencia de proveedores y toma de 30/ene/02 servicio por parte de MVS 3 1 Costo de mantenimiento de los proveedores 30/Ago/02 Teledinámica y Getronics 4 2 Definición de cambios operativos 30/ene/ Identificar actividades actuales que no están 23/ene/02 en contrato pero que se ejecutan 6 1 Redefinición de los entregables de la 09/ene/02 Evitar penalizaciones Transición 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 Reunión Horario Participantes Agenda Narrativa de Agosto 22, del 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 61

71 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. 62

72 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 Compromisos 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. 63

73 64

74 65

75 México D.F. a 30 de septiembre del 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. José Luis Quiroz Lechuga Project Manager IBM Acepto Ing.Alberto Martín del Campo 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 66

76 Fecha y Lugar Tipo de Reunión Horario Diciembre 3, del 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 67

77 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: 68

78 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, USD $ X3,x55.00 USD (Trece X cuatro cientos Xa ) mas IVA. Atte. José Luis Quiroz Lechuga Project Manager IBM Proyecto Acepto Ing.Armando Ramos / Juan José Dávila Coordinador de proyecto GEDAS / Lider de 69

79 BUSINESS CONTINUITY & RECOVERY SERVICES BUSINESS RECOVERY CONSULTING DRP Disaster Recovery Plan Infonavit AGENDA 1. Introducción 2. Resumen Ejecutivo 3. Términos y Condiciones 1. Introducción 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. 70

80 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 CONSIDERACIONES El 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. 2. Resumen Ejecutivo 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. 71

81 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 Fase 2 Fase 3 Fase 4 Fase 5 Análisis de Impacto en el Negocio (BIA) Análisis de Ambiente de IT (EA) y de Riesgo de IT (RA) Estudio de Alternativas de Recuperación (RAS) Elaboración del Plan de Recuperación 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. TANGIBLE IM RELATIVE PACTS AND IM PACT EXPOSURES OVER TIM E Lost Sale O ver t im e Fr aud Fines and Penalt ies 1 Week Char ges or Fees 1 Mont h Cr Tot edit al Hours 48 Hours 72 Hours INTANGIBLE Cr Tot edit al IM PACTS M ar ket Shar Pr oduct ivit y Cust om er Ser vice Em ployee M or ale Labor Relat ions Cr Tot edit al 72

82 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. ValorTotal del Negocio AltaDisponibilidad CostoMáximo Tolerable Restauraciónde CintasdeRespaldo Costodela Interupción$DuracióndelaInterupción Recuperación Costode TiempoparaRecuperar Costo Ventana Costo/Tiempo Tiempo 73

83 Teams& TestPlan Responsibilities Backup MaintenancePlan Procedures Recovery Relocationand Procedures Migrationplan Escalation Contact plan Disaster Lists Equipment Recovery Inventory Implementation plan RecoveryStrategies Cost/Benefits Analyses 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. Análisis de Impacto al Negocio BIA Análisis de Ambiente EA Critical proceses FileManagement Voiceasesment MaximumTolerable Asesment ByBusines Network Recovery OutageCostofoutage ISMProceses Asesment Asesment Critical Resources Function Security SkilsAsesment Asesment RecoveryAlternatives Documentation Aplicationpriorities Asesment /Recomendations Asesment FacilityAsesment Vital Records DataVintage 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 74