INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERIA Y CIENCIAS SOCIALES
Y ADMINISTRATIVAS
AÑO 2000 Y ADMINISTRACIÓN DE PROYECTOS
INFORME DE MEMORIA DE EXPERIENCIA PROFESIONAL
QUE PARA OBTENER EL TITULO DE
LICENCIATURA EN CIENCIAS DE LA INFORMATICA
P R E S E N T A
J O S E L U I S Q U I R O Z L E C H U G A
MÉXICO D.F. 2010
INDICE Resumen i Introducción ii Capítulo I. Practica Año 2000 1.1- Historia IBM 1 1.2- Organigrama 1 1.3 Antecedentes 3 1.4 Necesidad de Conversión Año 200 3 1.5 ¿Qué es el problema del año 2000? 3 1.6 Perspectivas acerca del problema 5 1.7 El problema del año bisiesto 8 1.8 Las PCs y el problema año 2000 9 1.9 Concientización 11 1.10 Asesoramiento 11 1.11 Renovación 13 1.12 Validación 13 1.13 Implementación 13 1.14 Planes de Contingencia 14 1.15 Capacidad de respuesta a emergencias 16 1.16 Herramientas 19 1.17 Clientes 24 1.18 Conclusiones año 2000 25 Capítulo II administración del proyecto IBM 2.1 Antecedentes 26 2.2 PMI 26 2.3 Project Manager 27 2.4 La llave del éxito del gerente del proyecto 31 2.5 Tipo de organización usada en Proyectos 32 2.6 Project Charter 35 2.7 Definición del Baseline y sus exclusiones 37 2.8 Organización el trabajo WBS 40 2.9 Manejo del Riesgo 40 2.10 Estableciendo el estimado del proyecto 42 2.11 Creando el calendario del proyecto 43 2.12 Experiencia en Manejo de Proyectos 47 2.13 Conclusiones administración de proyectos 83
Conclusiones 86 Bibliografía 87 Anexos 1.- Kickoff 88 2.- Minuta 90 3.- Reporte de Seguimiento 91 4.- Control de Cambios 92 5.- Plan 93 6.- Cierre 94 7.- Carta de Terminación 95 8.- Encuesta de Satisfacción 96
i
Resumen. En el capítulo I hablare sobre la problemática que se tuvo en el año 2000 con el cambio de siglo. Para todos aquellos que trabajábamos en el área de sistemas en 1997, recordaremos que empezaron a existir fabricas de software que empezaban analizar el impacto de cambio de siglo; los medios de información (Noticias) estaban preocupados al no saber que podría suceder, los centros financieros pensaban que podría haber una gran pérdida monetaria y sobre pagos de intereses en las cuentas; en los sistemas de gobierno se corría el riesgo de que se reportara gente con mayor edad de la que tuviera y que pasaría con los nacimientos. Además de lo anterior nuestra sociedad antes del año 2000 usábamos solo 2 dígitos para identificar el año, con el cambio de cambio de siglo muchos formatos y nosotros mismos cambiamos nuestra cultura empezando a utilizar 4 dígitos En las bases de datos por problemas de espacio se usaba solo dos dígitos y así una infinidad de sistemas y bases de datos se tuvieron que cambiar. Con la ayuda de estas fabricas de software donde tuve la fortuna de trabajar para IBM se inicio desde 1997 y se corrigieron los posibles problemas que se pudieran presentar y se estandarizo en algunos casos el software. Afortunadamente no hubo impacto para las empresas a las que se dio el servicio. En el capitulo II hablare mas sobre la metodología de lo que es ser Project Manager, desde hace mas de 10 años he tenido la suerte de administrar proyectos de tamaño mediano y pequeños, gracias a la confianza prestada por las compañías en la he trabajado. Ser Project Manager es ser el responsable directo que tiene sobre el proyecto que se esta ejecutando, y atendemos a un cliente y trabajamos para una compañía cuyo objetivo principal es hacerlo dentro del tiempo establecido, con el menor costo posible y dejándole una satisfacción al cliente de lo que nos pidió. Para alcanzarlo y estandarizar la forma de administrar los proyectos se creo el instituto de Project Managers asociación civil que dicto y escribió lo que se debe de considerar como metodología (PMBOK) y como debe desenvolverse un Project Manager, antes esta documentación solo era posible conseguirla en ingles, por lo que me hice la tarea de hacer un resumen en español para que todos aquellos que piense hacer una carrera administrando proyectos sepan que deben de considerar. Anteriormente la certificación como PMI era más simple, hoy en dia por el numero de administradores que existen, se ha vuelto más complejo la certificación, pero les recomiendo que la tomen, ya que esta les abrirá nuevas puertas.
ii
Introducción. En esta parte haré un resumen de lo que he realizado en estos 20 años dentro del área de informática, de lo cual solo describiré más detalladamente, mi experiencia de 1997 a 2002 dentro de IBM, en los proyectos conversión año 2000 y administración de proyectos. En el año 1987 entre a trabajar en Banamex como líder de proyecto en el área de Tarjetas de crédito. Mi función aquí fue la de analizar las opciones de terminales punto de venta (TPV) con proveedores nacionales y extranjeros, la implementación de soluciones en centros comerciales con estas terminales considerando las comunicaciones del equipo remoto y el procesador central. La equipos involucrados fueron: Terminales punto de venta (TPV).- Son las maquinas que actualmente se siguen
Utilizando para realizar el cargo de las tarjetas de crédito como tarjetas de debito.
Concentrador.- Cuando en un local existe mas de una TPV es necesario la colocación de un concentrador que en otras palabras en un ruteador que recibe las transacciones y distribuye la carga en más de un TPV. Línea telefónica.- Es el medio con el cual se comunican estas terminales, las cuales tienen la característica de que de cada 10 transacciones una viaja al procesador central, en el caso de las tarjetas de debito, todas las autorizaciones se realizan en línea. Servidor central.- Todas las transacciones realizadas se reciben en un equipo Tandem el cual valida que la tarjetas son validas, la fechas de vigencia del plástico y manda la información al mainframe para cargar y abonar
la compra. Si el baucher de la compra no presenta en los 10 días siguientes en el banco se cancela la compra y se restablece el saldo de la tarjeta.
Las áreas involucradas fueron:
Contratistas de cableado
El proveedor de la TPV
El dueño de local o centro comercial
El área de sistemas Aquí aprendí básicamente a tratar a los clientes, un poco sobre el protocolos de comunicaciones, programación de transacciones y monitoreo de redes.
iii
En el año de 1990 decidí salirme de Banamex y entre a trabajar en Siemens en el área de Telefonía, básicamente mi función aquí fue el de apoyar a adecuar el sistema de control de inventarios como usuario del área de sistemas, posteriormente desarrolle un sistema en Dbase para controlar las llegadas de equipo y refacciones de Alemania. La equipos involucrados fueron:
- PCs - Servidor HP
Las áreas involucradas fueron:
Área Usuaria
Almacén Aquí aprendí más sobre comunicaciones y desarrolle mi primer sistema en Dbase. En el año 1991 decidí entrar a Banco Obrero como programador en Cobol en equipo Mainframe, dándole mantenimiento al sistema de cheques y JCL´s, al poco tiempo la persona encargada del sistema se le dio nuevas asignaciones y tuve la oportunidad de quedarme como responsable del sistema, posteriormente se integraron nuevas personas al proyecto y me dieron nuevas responsabilidades como fue el sistema de inversiones, a lo largo del tiempo y cuando nació el SAR, coordine en conjunto con otro compañero de trabajo el desarrollo del sistema en plataforma cliente servidor con Cobol, así como el desarrollo de módulos de soporte a sucursales bancarias, llego el momento en que sentí que ya no tenia desarrollo y renuncie. La equipos involucrados fueron:
- PCs - Equipo Bull - Servidores AIX
Las áreas involucradas fueron:
Sucursales
Aéreas Operativas
En este trabajo fue donde consolide mis conocimientos como programador En el año de 1994 entre a trabajar en Software AG como líder de proyecto programando en Natural teniendo como base de datos ADABAS. El proyecto al cual
iv
fui asignado fue el sistema Argentaria que se estaba implementando en el Banco Interacciones y en paralelo en Banpais. Este sistema fue un desarrollo de España por el banco Argentaria y que fue comprado por Software AG de América, este sistema fue como un SAP, estaba desarrollado más del 50% en cobol y lo demás en Natural corriendo en plataforma HP-3000 con unix. Este sistema se tuvo que reprogramar sus funciones debido a que tenia los estándares de España, esto complico su implementación, además como muchas de las funciones corrían en cobol eran procesos en Batch y para el banco esto no esta funcional, por lo que fue necesario reprogramar el 25% del código de cobol a natural on-line. Cuando la solución se dejo estable y se salió con la primer sucursal para el público en general se decidió que le diera apoyo al proyecto de Banpais, pero debido a que las soluciones implementadas ahí fueron diferentes a las de Banco Interacciones no fui de gran utilidad. El sistema de solución implementado en Interacciones funciono un poco mas de un año, el mismo sistema en Banpais no pudo funcionar en un ambiente productivo y fue demandado Software AG por esta implementación y ocasiono la separación de Software AG de América de Software AG de Alemania. La equipos involucrados fueron:
- PCs - Servidores AIX
Las áreas involucradas fueron:
Banco Interacciones
Banco Banpais
Aéreas Operativas Después de 2 años decidí salirme para aprender nuevas cosas. Entre lo relevante aprendido fue el adentrarme en el mundo de las bases de datos, conocer un lenguaje de programación amigable, de facilidades para correr en línea procesos sin tener que generar JCL´s. En el año de 1996 gracias al apoyo de ex compañeros de Software a AG tuve la oportunidad de entrar a trabajar en EDS cuando aún era un área de sistemas de General Motors. En el primer proyecto en el que participe fue ISOSA que era la compañía que maquila toda la recaudación de impuestos de la Secretaria de Hacienda y Crédito Público y lo que se intento realizar fue una reingeniería de procesos, aquí aprendí sobre tiempos y movimientos, diagramas de procesos, organigramas, excell, y herramientas de flujo de datos que generaban pseudo código para base de datos. Después de haber realizado parte del análisis nos percatamos que existía demasiado personal y existían trabajos duplicados y algunos de más.
v
En ese entonces EDS llevaba el outsourcing de ISOSA y había conflictos de intereses, así como que la posibilidad de reducir plazas no era factible, por lo que se decidió en la dirección retirarse de este proyecto el cual tomo el Tec. Monterrey. Después me involucre en el proyecto de Tenencia 97 para el Departamento del Distrito Federal, este sistema fue desarrollado en Visual Basic e instalado en todas las oficinas de recaudación con equipo IBM. Al termino de esta asignación me integre al equipo de trabajo de seguros, con el cliente Probursa, ellos habían adquirido un sistema de seguros el cual se estaba adecuando a sus necesidades, aquí trabaje con Cobol en plataforma AS-400. La equipos involucrados fueron:
- PCs Las áreas involucradas fueron:
Áreas usuarias
Oficinas de recaudación Aquí fue donde inicie mi carrera como consultor – Project Manager para manejar proyectos y dejar la parte de programación. En el año de 1997 me invitaron a trabajar en una compañía que se llamaba Tecnología en Soluciones y Sistemas, que había sido comprada por IBM, y su función principal fue la de llevar a cabo la práctica de año 2000, y adentrarse en el mundo de desarrollo de sistemas. Durante 3 años participe en varios proyectos de solución de problemas de años 2000 para diferentes clientes, a partir del 2000, me involucre en proyectos de desarrollo de sistemas en proyectos dentro de IBM hasta mayo del 2002. La equipos involucrados fueron:
- PCs - Mainframe - AIX - Storagetek - AS/400
Las áreas involucradas fueron:
Diferentes clientes
Centros de computo
Proveedores
vi
Áreas internas de IBM Aquí, creo que he consolidado mi experiencia en la administración de proyectos, generación de propuestas, manejo de personal, trabajo en equipo, negociaciones con el cliente, certificación en CMM3, metodologías, pero perdí la practica en la programación. En el año del 2003 me pidió mi antiguo Jefe Gabriel Olguin a continuar trabajando en proyectos de IBM como Project Manager iniciando el area de PMs en IBM y ahí estuve hasta el 2007 La equipos involucrados fueron:
- PCs - Mainframe - AIX - Storagetek - AS/400
Las áreas involucradas fueron:
Diferentes clientes
Centros de computo
Proveedores
Áreas internas de IBM En el año 2007 HSBC, me pidió formar parte de su team de trabajo, primero para concluir el proyecto de migración de Regatta a las Squadrum que había iniciado como IBM. Posteriormente mi Jefe en ese momento me pidió me encargara de la plataforma iSeries y hacer la migración del centro de computo alterno de Reforma a Toluca, siendo esto un gran reto ya que cuando inicie esta tarea solo corría en esta plataforma el sistema de tesorería de México y Brasil y después de 3 años tuve que dejar el cargo Agosto del 2010, dejando operando sobre esta infraestructura 6 core bancarios para 4 países de latinoamerica (Chile, Peru, Colombia, Uruguay), y mas de 20 aplicaciones estándar del grupo HSBC a nivel mundial.
1
Capítulo I. Practica año 2000.
1.1 Historia IBM IBM es una empresa líder en la investigación y desarrollo de las tecnologías de la información mas avanzadas del sector, incluyendo sistemas informáticos, software, redes y sistemas de almacenamientos y microelectrónica.
1.2 Organigrama
De la estructura anterior, no tuve interacción con todas las aéreas, pero puedo hacer un resumen de las que conocí: Tecnology Services.- Es la área encargada de dar el soporte a todos los clientes de IBM, dando el servicio de soporte de centro de computo en caso de contingencia o prueba controlada, servicio de hosting y recursos para asistencia y soporte en sitio. Software Solutions.- Esta área trabaja muy de cerca con Tecnology Services y es la encargada de analizar la problemática de los clientes y dar soluciones integrales o individuales que ayuden en la automatización y control del negocio de sus clientes,
2
entre los software mas reconocidos es el Whebsphere para ambientes WEB, generación de código automático para programación UML, los productos Tivoli para respaldos, monitoreo, etc. Legal: Es el área encargada de revisar las propuestas realizadas por las diferentes aéreas de ventas de IBM, asegurando la redacción en términos legales. Financial Management: Cuando se genera una propuesta en Dólares o en Pesos Mexicanos esta área es la encargada de ver el tipo de cambio en base a la fluctuación que puede tener el peso y en algunos clientes que se realiza un financiamiento se encarga de definir el costo valor presente y futuro del precio del servicio asi como calcular la tasa de interés que se aplicara. Control TS: Al ser una empresa tan grande y para mantener un nivel de calidad en sus servicios y propuestas se creo el área de control de proyectos u oficina de control de proyectos que valida las propuestas, le da seguimiento a los proyectos, verifica su conclusión y realiza las encuestas de satisfacciones a los clientes. Nosotros estábamos debajo de Tecnology Services
Quality Ansurace: Es el area encargada de que se cumplieran las normas de IBM y los procesos Oficina de Control de Proyectos: Era la encargada de llevar el control de todos los proyectos y hacer los informes ejecutivos a la dirección Oficina de PMs: Es donde estaba y éramos los que ejecutábamos los proyectos apoyándonos de las aéreas técnicas.
3
1.3 Antecedentes: Desde 1996 IBM preocupado por el problema que se avecinaba del cambio de siglo se empezó a trabajar y generar alianzas con empresas para poder apoyar a sus clientes en el análisis y solución del problema conocido comúnmente como Y2K. Para este fin IBM compro la empresa Tecnosys que fue la fabrica de software que contribuyo con manos para apoyar a todos los clientes de IBM. Aquí describiré lo siguiente:
Antecedentes
Problemática
Metodologías
Herramientas
Clientes a los cuales apoye para la solución de este problema
Resumen
1.4 Necesidad de conversión año 2000: La sociedad se ha convertido extremadamente dependiente del uso de las computadoras así como de los avances tecnológicos en general. Estos avances han contribuido enormemente al progreso de la humanidad facilitando de manera importante todas sus actividades. Sin embargo estos avances tecnológicos también han causado grandes problemas por no haber sido implementados adecuadamente.
Problemas causados por errores en la programación de computadoras han sido responsables de serias interferencias e inclusive deterioro total de diversas actividades tales como problemas de logística, salud, financieros, de telecomunicaciones, de tráfico aéreo, etcétera. Un claro ejemplo es el llamado “problema del año 2000”.
Este problema consiste básicamente en la práctica de almacenar los años en las fechas en tan solo dos dígitos. El problema fue originado básicamente debido a que en las décadas de los sesenta y setenta, cuando el uso de las computadoras se difundió ampliamente, el costo de almacenamiento de datos era bastante caro pues además de su costo económico, implicaba perder eficiencia en cuanto a tiempo de procesamiento. Por esta razón el almacenar los años en dos dígitos era una buena solución a este problema.
1.5 ¿Qué es el "problema del año 2000"? Conforme se acerca la fecha surgen distintos comentarios acerca del llamado problema del año 2000, aparecen distintos escenarios que describen a su muy particular forma de ver las cosas lo que sucederá el primero de enero del 2000.
4
El también llamado Y2K problem (por sus siglas en inglés Y de year, 2 por dos mil y K de kilo) es considerado por muchos como un fenómeno tanto técnico como social.
Este problema consiste en que la mayoría de los programas de cómputo se escribieron considerando que los dos primeros dígitos en la identificación del año serían 1 y 9, mismos que sirven para identificar el siglo. Esto significa que, al llegar el año 2000, éste se registrará solamente con el doble cero. Los sistemas que no hayan sido actualizados asumirán que dicho número se refiere a 1900 o tal vez otro año, lo cual causará errores en operaciones lógicas y aritméticas, produciendo resultados incorrectos, y también provocará que algunos sistemas dejen de operar.
El problema del año 2000 no sólo afectará a las computadoras. En realidad puede afectar a cualquier dispositivo que contenga componentes electrónicos (chips) que registren fechas para controlar la operación de instrumentos y maquinaria. Tal es el caso de equipo médico, sistemas de seguridad, equipo para control de tráfico aéreo, elevadores, bóvedas, etc.
El problema pareciera conceptualmente sencillo y exclusivamente de carácter técnico. Sin embargo conforme se analiza con mayor detenimiento, resulta evidente que, por sus características y magnitud, su solución se torna extremadamente laboriosa además de tener fuertes repercusiones tanto administrativas como económicas. Esto quiere decir, que es necesario movilizar una cantidad considerable de recursos físicos y humanos así como también se necesita una alta capacidad organizacional para que los equipos puedan estar listos para manejar en forma adecuada el cambio de año con la transición del milenio. Orígenes:
Los orígenes del problema se remontan a las décadas de los sesenta y setenta, cuando se extendió el uso de computadoras. En ese entonces la memoria así como el almacenamiento de datos eran muy costosos. Los programas parecían mejores mientras menos recursos consumieran, es así como los programadores, quienes habitualmente trabajaban en COBOL (Common Oriented Business Language), presentan la idea de utilizar sólo dos dígitos para registrar los años en las fechas; así el 63 representaba el año 1963.
Gran parte de las operaciones que realizaban las computadoras dependían del cálculo de fechas por lo que reducir a la mitad el espacio que ocupaba el año en las fechas resultaba bastante útil.
Cuando en la década de los ochenta los costos de la memoria y de almacenamiento comenzaron a bajar debido a la llegada de nuevas generaciones de computadoras, software, programadores y usuarios de PC, se continuó con esta costumbre sin prestarle demasiada atención debido a que la abreviatura no causaba grandes problemas, la fecha aún parecía lejana.
5
No fue hasta principios de la década de los noventa cuando los problemas comenzaron a surgir. Para 1995, la conciencia de lo que pronto se conoció como el Problema del Año 2000 se habría extendido en gran medida; sin embargo, pocas compañías tomaron cartas en el asunto. El sentir general reflejaba una confianza en que todo se resolvería sin mayor problema, las compañías confiaban en que esto no representaba un riesgo y que sus programadores podrían resolverlo fácilmente.
No obstante para mediados de 1997, la perspectiva cambió en forma radical. Muchas de aquellas compañías que en un principio prestaron poca atención al problema, comenzaron una revisión formal del año 2000 así como algunos programas de ajuste. El problema era tema de foros de computación y fue difundiéndose a través de la prensa popular. Fue hasta entonces que se descubrió que la solución no sería tan sencilla además de que resultaría muy costosa.
Desafortunadamente el problema del año 2000 resulta ser sólo la punta del iceberg, pues los campos de fechas no son los únicos campos que fueron almacenados arbitrariamente para ahorrar espacio de almacenamiento. Muchas aplicaciones presentan problemas con cálculos financieros y demás tipo de información debido a que no les fue asignado suficiente espacio al momento de construir la aplicación. Este tipo de problemas que tienen que ver directamente con el ahorro de espacio en memoria ha repercutido en la creación de arquitecturas imperfectas para bases de datos y demás tipo de software.
1.6 Perspectivas acerca del problema
Con el paso del tiempo y conforme la fecha se acerca, surgen distintas perspectivas acerca de lo que pasará o de lo que dejará de pasar el 1o de enero del 2000. A continuación se presenta una tabla publicada en el periódico Reforma el 5 de octubre de 1998, que compara algunos escenarios vistos desde distintos puntos de vista:
Escenario pesimista
El mundo entero sufrirá un desabasto total porque la producción de las fábricas se detendrá totalmente.
Las aerolíneas suspenderán sus operaciones y nadie podrá volar al menos en la primer semana del año 2000.
Si una persona realiza una llamada poco antes de la medianoche del 31 de diciembre de 1999 y se prolonga hasta las primeras horas del siguiente año, entonces la llamada su cobrará con una duración de un año.
Escenario optimista
Las fábricas continuarán con su proceso de producción normalmente ya que no existe ningún indicio de que puedan tener problemas
6
Si usted desea puede regresar de celebrar las fiestas decembrinas del 99 de cualquier lugar del mundo sin ningún contratiempo viajando por avión.
Si una persona hace una llamada en estas circunstancias no hay problema de cobro, porque el año en que comenzó a hacerla aún no llega y por lo tanto no habrá registro de ella.
Escenario realista
Hay riesgo de que algún punto de la producción una empresa se vea afectada, no por fallas internas sino por problemas en algunos elementos o proveedores de la cadena de suministros.
Algunas aerolíneas anunciaron que se suspenderán sus vuelos durante un día para probar que el sistema de tráfico aéreo esté funcionando correctamente, pero no por problemas internos, sino por los sistemas de telecomunicaciones.
Existe la posibilidad de que se presenten situaciones confusas sólo si las compañías de servicio de telefonía no hicieron nada por revisar y solucionar sus sistemas.
Estos escenarios nos ejemplifican como se verán afectadas ciertas industrias desde tres puntos de vista distinto. Sin embargo, éstas no son las únicas industrias afectadas, consideremos los riesgos que representa este problema para algunas otras industrias si no se solucionaran antes de tiempo.
Finanzas En el área financiera de cualquier entidad el riesgo se refleja en problemas como son el cálculo de intereses, errores en los estados financieros, cargos y abonos a tarjetas de crédito y en general en todas las transacciones financieras que impliquen la interacción con fechas. Gobierno Los gobiernos de las naciones podrían incurrir en errores en los registros que se llevan de los impuestos recaudados, pensiones mal calculadas, retiros anticipados, errores en los juicios en trámite, registros de nacimientos, muertes, matrimonios, etc. Seguridad nacional La seguridad nacional se vería afectada en grande manera debido a que en algunos países altamente desarrollados los sistemas de defensa son controlados mediante sistemas computarizados, lo cual repercutiría probablemente en el mal funcionamiento de armas estratégicas, registros de mantenimiento erróneos, confusión en transmisiones vía satélite, etc. Los anteriores son sólo algunos ejemplos de cómo se verían afectadas nuestras actividades diarias. El mundo se ha vuelto extremadamente dependiente de las computadoras, lo cual ha beneficiado en gran manera a la sociedad, pero esta
7
dependencia no está libre de riesgos. Los errores producidos a causa de las computadoras han sido responsables de grandes problemas en distintos ámbitos de nuestra vida diaria. Equipos Biomédicos.
Los hospitales, clínicas y centros de salud utilizan diversas aplicaciones que son susceptibles a presentar fallas relacionadas con el año 2000. Esta tecnología está presente no solo en equipos biomédicos utilizados para diagnóstico y tratamiento de pacientes, sino también en los equipos de infraestructura que soportan a estos equipos. Los sistemas y los dispositivos de atención de salud que quizá sean sensibles al problema se clasifican en tres categorías generales:
1. Sistemas de información. incluye todos aquellos sistemas utilizados en laboratorios clínicos, farmacias, departamentos de radiología o bancos de sangre; sistemas de facturación y financieros; sistemas de ingeniería clínica o de control de equipo; sistemas de gestión de enfermos (programación, admisión, gestión de camas, consultas externas); archivos; almacenamiento. Los problemas pueden variar desde los errores de fecha de facturación hasta el cálculo incorrecto de la edad de un paciente.
2. Equipos Biomédicos. Un número significativo de equipos Biomédicos trabajan con base en microprocesadores y usan datos con la fecha impresa o graban datos con la fecha en el sistema.
3. Sistemas generales del hospital. Estos incluyen los sistemas usados para control ambiental, detección de incendios, alumbrado, seguridad, telecomunicaciones, calderas y transporte de pacientes.
Estos equipos deben ser evaluados según la función del mismo, el riesgo para el paciente y la importancia para el centro de salud. Las características para identificar un equipo sensible al Y2K son las siguientes:
Si el equipo esta conectado con aparatos y/o sistemas adicionales.
Si posee sistema de alarma.
Si usa la fecha para programar el mantenimiento.
Si muestra o imprime la fecha.
Si calcula edades, hora, etc.
Si hace seguimiento de datos de pacientes en múltiples usos.
Si se puede introducir el año en 2 dígitos
Si tiene un "display" digital.
8
Estos equipos biomédicos deben agruparse según su función (laboratorios clínicos, radioterapia, cuidados intensivos, quirófano, imageneología), y su probabilidad de falla.
Facturación. La facturación es un proceso complejo en empresas comercializadoras de servicios de energía eléctrica, gas, teléfonos, acueducto y alcantarillado y en aquellas que por su gran número de suscriptores involucra una gran cantidad de información. El software en el cual se encuentra implementada la facturación no es amigable y está generalmente instalado en equipos obsoletos. Las modificaciones que se requieren para garantizar su correcto funcionamiento antes, durante y después del año 2000 exigen inversiones importantes en tiempo, personal y recursos financieros. Además de las fallas propias, la facturación puede verse afectada por situaciones ajenas a las diferentes empresas, lo cual hace necesario diseñar, preparar y probar planes de contingencia.
1.7 El problema del año bisiesto
La rotación de la tierra alrededor del sol ocurre cada 365 ¼ días aproximadamente lo cual redunda en que es imposible hacer un calendario con una duración exacta en cuanto al número de días. Por tanto es necesario que cada 4 años se agregue un día más al año para compensar esa inexactitud. Evidentemente esta situación resulta más compleja de lo que pareciera, pues la diferencia de rotación no es exactamente de un cuarto de día por lo que el hecho de añadir un día cada cuatro años sólo funcionará por uno o dos siglos.
Existen tres reglas generales para determinar un año bisiesto pero una de estas reglas es tan rara que casi no ocurre. Debido a esta tercera regla, el año 2000 es un año bisiesto y este aspecto causará problemas relacionados con el problema del año 2000 el 29 de febrero del 2000.
Regla 1: Los años exactamente divisibles entre 4 son años bisiestos. Regla 2: Los años exactamente divisibles entre 100 no son años bisiestos. Regla 3: Los años exactamente divisibles entre 400 son años bisiestos.
De acuerdo con las reglas 1 y 3 el año 2000 será un año bisiesto, no obstante basados en la regla 2 no será año bisiesto. El año 2000 es uno de esos años raros donde es necesario tomar en cuenta el hecho de que el año solar no dura exactamente 365 ¼ días.
9
Las implicaciones de este problema podrían trastornar las aplicaciones del software. El año 1988 fue accidentalmente omitido como año bisiesto por algunos fabricantes de software lo que hace suponer que este incidente podría repetirse en el 2000.
El hecho de que no se registre un año como año bisiesto puede causar errores en cálculos de fecha. El origen de este tipo de problemas también se remonta a las décadas de los sesenta y setenta cuando las aplicaciones de software fueron desarrolladas sin tomar en cuenta que los años 1988 y 2000 serían años bisiestos por tanto estas aplicaciones presentan complicaciones.
1.8 Las PCs y el problema del año 2000
Uno de los mitos más difundidos gira en torno de que todos los problemas del cambio de milenio están relacionados con las minicomputadoras y los mainframes, se señala que ni el hardware ni el software para PC existían en la época del COBOL y por lo tanto son inmunes. Esto en efecto resulta erróneo pues si bien es cierto que los problemas en las PC son ínfimos comparados con los grandes problemas de hardware y software más antiguos, estos equipos no están exentos del problema, existen las situaciones críticas en ellos además de que son difíciles de resolver.
Los problemas en las PC repercuten en tres áreas básicamente:
Los chips BIOS (Basic Input/Output System) El código de los dígitos en el software comercial para PC El hábito de almacenar fechas de dos dígitos en el año en hojas de cálculo y
bases de datos.
En cuanto a los chips BIOS, es impresionante saber que algunas PC fabricadas en 1997 tiene BIOS que no satisfacen los requisitos del año 2000 . En algunos casos en posible "quemar" los BIOS (sobreescribirlos con un código actualizado) para así resolver el problema. En otros casos están disponibles chips actualizados que satisfacen los requerimientos al respecto y que los usuarios pueden solicitar al proveedor.
Sin embargo no se debe suponer que una PC determinada o alguna otra computadora funciona de manera adecuada sin realizar las pruebas de validación correspondientes.
Es posible también que existan ciertos vicios ocultos dentro de algunos programas que supuestamente satisfacen o no presentan este problema. Tal es el caso de Office, Microsoft asegura que tanto la versión estándar de Office 4 así como Office 97 satisfacen los requerimientos del año 2000, no obstante es posible que se presenten ciertos problemas con Access y Excel. Existe algo peor aún, los problemas y soluciones pueden variar de una versión a otra.
10
Podríamos decir entonces que la causa raíz del problema en las computadoras de escritorio es el BIOS pues es en esencia un intermediario entre el hardware y el software de la máquina. Entre otras de sus funciones el sistema operativo lo utiliza par enviar información a la tarjeta madre y a diversos periféricos físicos, así como recibirla de estos. El BIOS es el responsable de recuperar la fecha y hora de un chip de respaldo por una batería que es conocida como el Reloj de Tiempo Real (RTC; Real-Time Clock). El OS entonces actualiza su propio reloj con esta información. Cuando se apaga una máquina el reloj del OS deja de trabajar sin embargo el RTC sigue funcionando.
El RTC tiene siete registros que almacenan la hora y la fecha. Los primeros seis se actualizan de manera automática sin importar el estado de la computadora, cada uno de estos registros almacena un valor diferente. El problema es que el registro de los años está limitado a sólo dos dígitos abreviando 1998 como 98. El séptimo registro almacena los dos primeros dígitos del año, pero no los actualiza en forma automática. Cuando el siglo finalice los primeros seis registros se cambiarán de forma correcta pero el de l siglo seguirá siendo 19, entonces el RTC supondrá que el año es 1900.
No obstante el problema no es del todo del RTC pues correspondería al BIOS programarlo para resolver esta contingencia. Un BIOS inteligente será capaz de sobreescribir el registro de los siglos para que el 19 se convierta en 20 cuando sea necesario. Un BIOS no inteligente recuperará un 19 del registro de los siglos del RTC cuando en verdad corresponda a 20.
Este problema, de no ser resuelto, reflejará diversas reacciones en el sistema operativo. En Windows NT 4.0 así como en Windows 98 recocerá que la fecha es incorrecta por lo que la cambiará de manera automática, sin embargo un sistema operativo más antiguo, como es el caso de MS-DOS, Windows 3.x y Windows 95, supondrá que la fecha es 1 o 4 de enero de 1980. Windows NT 3.51 podría reconocer fechas anteriores a 1980 sin corregir el problema por si mismo. La
11
solución en Windows 98 no fue ampliar a cuatro dígitos el campo para el año dentro del sistema operativo, sino que en vez de 1900 el reloj interno empezará en 1930. Así los problemas que se presentarían en el 2000 sólo se prorrogarán para el 2029. El problema del año 2000 es real, está presente y es inminente que debe ser resuelto pues el tiempo es impostergable. Las organizaciones deben estar conscientes del riesgo que esta situación implica, es necesario desarrollar soluciones que mitiguen los posibles efectos que pueda causar el problema. Existen diferentes metodologías que se han desarrollado para atacar el problema, sin embargo Bryce Ragland en su libro: The Year 2000 Problem Solver, indica que todas podrían ser representadas por estos seis pasos.
Concienciación
Asesoramiento
Renovación
Validación
Implementación
Planes de contingencia
1.9 Concientización. Esta fase es en donde muchas organizaciones se encontraban en 1997 o han superado, tratando de crear conciencia a la administración acerca del problema del año 2000, es decir, hacer del conocimiento de la alta gerencia la magnitud y repercusiones de la situación.
Esta es probablemente la etapa más difícil para el equipo técnico pues no es una etapa técnica. Requiere habilidades sociales que regularmente no poseen este tipo de personas. La mayoría de los técnicos preferirían que se les asignara actividades que tuvieran que ver con su área de competencia y que se les dejara solos resolviéndolas.
Para poder llevar a cabo satisfactoriamente esta etapa, es necesario encontrar algunas situaciones que ejemplifiquen los impactos que podría tener el problema del año 2000 dentro de la organización.
1.10 Asesoramiento. Es la etapa más larga fase de todo el proceso. Es aquí donde no sólo se asesora la organización para determinar si se tendrán o no impactos ocasionados por el problema del año 2000, sino que también es en esta etapa donde se determina cuan grandes serían estos impactos en caso de existir.
12
Lo siguiente dentro del proceso es desarrollar algunas estrategias en como atacar el problema. En esta etapa es necesario que el equipo técnico se ponga de acuerdo con la administración y se determinen las prioridades que existen así como los mejores métodos a seguir en la solución del problema.
Lo primero que se debe determinar es que sistemas necesitan ser arreglados; cuales pueden o deben ser retirados o remplazados y cuales pueden continuar operando sin una intervención inmediata.
El siguiente paso es establecer un proceso de mantenimiento, documentarlo así como seguirlo rigurosamente. De esta manera se pretende tener asegurar la calidad de cualquier esfuerzo encaminado al mantenimiento. Se ha demostrado que aquellas organizaciones que documentan sus procesos tienen una mejor oportunidad de repetir ese proceso exitosamente.
Otro punto importante dentro de este proceso es el de desarrollar estrategias. Esto se logra determinando como se desarrollará el análisis de los sistemas de la empresa. Con este punto cubierto, será más fácil determinar que métodos se deben seguir para la conversión de los sistemas.
En este paso se implementarán las estrategias que se hayan desarrollado durante el proceso de asesoramiento. Es aquí donde se debe conformar completa y formalmente lo que será el equipo técnico para el año 2000 que básicamente estaría conformado por:
Líder de proyecto: quien será una persona con amplios conocimientos en el área de sistemas, pero sin lugar a dudas será una persona que haya demostrado aptitudes de liderazgo. En muchos casos la mejor manera de escoger a aquel que será el líder es permitiendo al propio equipo de trabajo elegir a quien los dirigirá pues de esta manera trabajarán de manera más confortable.
Programadores: estas personas deberán entender la estructura de los sistemas, su funcionamiento así como que tipo de información manejan. Su función será la de hacer las modificaciones necesarias al software para que cumplan con los requisitos del cambio de milenio.
Ingeniero de pruebas: es extremadamente importante contar con alguien que cuente con experiencia en cuanto a pruebas de software y sistemas. Esta persona será encargada de determinar la eficacia de las reparaciones hechas a los sistemas, regularmente este tipo de profesionales percibe errores y situaciones que para el desarrollador pasarían inadvertidas.
Consultor externo: un consultor externo es necesario para ver de manera más objetiva los avances del proyecto así como también será responsable de verificar que ningún punto del sistema se ha dejado fuera de las reparaciones.
13
1.11 Renovación. El proceso de renovación es el siguiente paso una vez que se ha conformado el equipo ideal. Existen básicamente tres maneras de corregir el problema: 1.- Reemplazar el sistema
2.- Renovar el sistema
3.- Retirar el sistema
Corresponderá al equipo de trabajo determinar de que manera se pretende atacar al problema. Con las estrategias desarrolladas se procederá a llevar a cabo las correcciones por la que se haya optado y de esta manera solucionar la situación.
1.12 Validación. La validación es evidentemente una etapa crítica. El problema del año 2000 fue provocado en gran medida porque no se le tomó mucha importancia a esta etapa cuando se desarrollaron los sistemas. En esta etapa se incurre en el error de sobrestimar la capacidad de los desarrolladores y se intuye que el producto que se está utilizando es de máxima calidad. Muchas veces esta etapa no es llevada a cabo debido al tiempo con el que se cuenta; aun cuando no se esté seguro del optimo funcionamiento del producto.
Las pruebas de software y la validación son etapas que van ligadas íntimamente. Es necesario hacer tantas pruebas como sea necesario para asegurarse de que el software es en verdad confiable. Las pruebas podrían dividirse en las siguientes fases:
o Pruebas durante el asesoramiento o Pruebas durante la renovación o Pruebas operacionales durante la implementación
La planeación y ejecución de todas estas pruebas es crucial en el proceso. La planeación de pruebas se debe llevar a cabo durante el asesoramiento. Por último es importante recalcar que hay que dar a las pruebas la importancia que se merecen.
1.13 Implementación. La etapa de implementación tiene que ver con las interfaces externas. Durante el proceso de validación, se debieron probar estas interfaces. Lo que hay que verificar en esta etapa es que los datos que proporcionan los sistemas sean en verdad correctos. Existen diversos tipos de problemas que deben ser previstos antes de llegar a la etapa de implementación. Se deben desarrollar planes de contingencia
14
para atacar los contratiempos que se llegaran a presentar después de la liberación de los sistemas corregidos. Se debiera llegar a esta etapa cuando menos seis meses antes del cambio de milenio para tener plena confianza de que los sistemas cumplen satisfactoriamente las soluciones implementadas.
Este proceso puede ser implementado en casi cualquier organización. Se tendrán que hacer los ajustes necesarios para que funcione adecuadamente en cada organización.
Los usuarios de computadoras no deben quedar fuera del proceso de conversión al año 2000. Se ha estimado que si se solucionarán todos los problemas al respecto con las grandes empresas, aún se tendría la mitad del problema por solucionar pues los usuarios de computadoras personales también tienen el problema en algunos casos y es necesario resolverlo.
1.14 Planes de contingencia.
El problema del Año 2000 está presente en todos los sectores y actividades económicas, implicando riesgos de falla en operaciones y procesos críticos fundamentales para cada entidad. En ningún caso existe garantía total de estar exento de fallas con la llegada del Año 2000, principalmente por tres razones:
Es altamente probable que el tiempo disponible y los recursos económicos, humanos y tecnológicos no sean suficientes para corregir todos los problemas y probar completamente las soluciones desarrolladas. Es utópico pensar que todo podrá repararse.
No existen garantías sobre el éxito de los esfuerzos para corregir el problema. El año 2000 no tiene precedente y no es posible asegurar plenamente el correcto y continuo funcionamiento de cada sistema, aislado o en su relación con otros sistemas.
No se puede garantizar que cada sistema, interfaz, y socio comercial cumpla con los requerimientos del año 2000. A pesar de los esfuerzos que haga su entidad para ser diligente, no podrá controlar las posibles fallas en su sistema, a causa de las interrupciones en las empresas de servicios públicos, en las de comunicaciones y en los vínculos con socios y clientes comerciales.
En caso de presentarse alguna falla, se debe tratar de minimizar el impacto tanto dentro como fuera de la organización. Los planes de contingencia permitirán mantener la continuidad en las operaciones críticas de su entidad y minimizar el impacto negativo sobre la misma, su entorno, sus empleados y sus clientes. Deben ser parte integral de su proyecto Año 2000 y servir para evitar interrupciones, estar preparado para fallas potenciales y llevar hacia una solución permanente lo más rápido posible.
15
Un plan de contingencia tiene las siguientes características esenciales:
Garantiza la continuidad de un proceso crítico por medio de su ejecución
Constituye un mecanismo alterno de operación (diferente al mecanismo usual)
Cumple requisitos mínimos de calidad, alcance, seguridad, operaciones, etc.
No replica la operación normal del negocio
Está diseñado para aplicación temporal únicamente
Contempla los mecanismos para el regreso a condiciones normales de operación Postergación u omisión del proceso Es necesaria la planificación de contingencias del año 2000 en todos y cada uno de los procesos vitales en la operación de su organización. Además, debe hacerse para todo aquello cuyo control escapa de sus manos. La elaboración de planes de contingencia requiere un cuidadoso análisis para determinar si está disponible cualquiera de las alternativas usuales. A continuación, en la Tabla 1, se listan los seis pasos para elaborar y poner en práctica los planes de contingencia.
Pasos para hacer planes de contingencia
PASO DESCRIPCIÓN
1. Evaluación Conformación del equipo de trabajo, definición del alcance, identificación de escenarios de falla y priorización de los riesgos
2. Identificación y selección de alternativas
Construcción de los planes de contingencia, identificación de los eventos activadores (criterio para utilizar los planes), prueba de los planes, capacitación del recurso humano
3. Diseño del plan de contingencia
Es la fase más extensa. En ella se consolida el plan de contingencia y sus objetivos, se determinan los recursos requeridos, se definen los criterios de activación, las responsabilidades y la duración de la implementación y se estructura la operación y administración del plan. También se definen los criterios para el regreso a la condición normal y los requisitos de capacitación y pruebas
4.Implementación del plan de contingencia
Llevar los planes de contingencia más allá del papel, asegurando su efectiva y rápida puesta en funcionamiento. Incluye adquirir o preparar equipos y procedimientos requeridos, capacitar al personal involucrado, realizar pruebas y, en general, asegurar que todo pueda funcionar oportuna y correctamente si los eventos activadores así lo exigen.
5. Ejecución del plan A partir de un evento activador se implementa el plan de contingencia
6. Recuperación Corresponde al tiempo destinado para desactivar las operaciones de contingencia y reiniciar los procesos primarios de las operaciones normales . En esta fase, tan pronto como sea posible, se pasará de las operaciones de
16
contingencia a una solución permanente.
1.15 Capacidad de respuesta a emergencias
Introducción. Como se había planteado anteriormente, no existe seguridad de que el 100% de los sistemas, interfases y relaciones con terceros, pasarán sin problemas la llegada del Año 2000. Esto implica la preparación para escenarios probables de falla . Ya se ha explicado cómo los planes de contingencia son vitales en la disminución del impacto de posibles problemas que se puedan presentar. No obstante, el año 2000 no tiene precedente, y es en general imposible contemplar de antemano todos los sucesos posibles. Por ello, toda entidad debe preparar una capacidad de respuesta a emergencias (CRE) que pueda: (1) coordinar, de ser necesario, el desarrollo de los planes de contingencia que sea necesario durante el cambio de año y (2) reaccionar ante eventualidades imprevistas diferentes a las contempladas en planes de contingencia. Se puede comparar la CRE con una sala de emergencias de un hospital, que recibe diferentes tipos de problemas, los prioriza, los clasifica, los asigna a los diferentes especialistas, y les brinda respuesta con la mayor rapidez posible. La CRE es un recurso necesario para enfrentar situaciones inesperadas, previstas o no, con la llegada del Año 2000. El principal objetivo de la CRE es garantizar los niveles mínimos de funcionamiento en una situación de crisis.
Habilidades. La CRE debe tener, entre otras, las siguientes habilidades: • Condiciones suficientes para coordinar la ejecución de planes de contingencia,
según el diseño y la implantación explicados anteriormente en este documento. Se debe contar con toda la información y recursos necesarios para la ejecución de los planes que estén bajo su responsabilidad. Debe tenerse en cuenta que la CRE no se limita a la ejecución de planes de contingencia, ya que existe la posibilidad de que se presenten emergencias que no han sido previstas.
• Monitoreo y evaluación del impacto de las posibles fallas internas que se puedan
presentar. Pueden ser fallas ya analizadas o problemas que no han sido considerados. El CRE, entre otros, debe evaluar el impacto de la ejecución simultánea de varios planes de contingencia, que puede generar en sí una situación de crisis. Por ejemplo, si se activan los planes de contingencia para cierre de varias sucursales en un mismo banco, la situación generará una crisis para la entidad como un todo, que seguramente no fue contemplada en los planes a nivel de sucursal.
17
• Identificación, comunicación y seguimiento a entidades afines relevantes, para la detección de posibles fallas. Esta comunicación permitirá anticipar posibles impactos sobre procesos de la entidad que dependan de terceros. Por ejemplo, si los proveedores de la entidad han presentado fallas importantes, la entidad probablemente enfrentará una escasez de suministro durante los primeros meses del año.
• Planeación y diseño de procedimientos para la solución rápida y efectiva de
problemas. Los procesos para toma de decisiones deben estar previamente acordados, entendidos y probados; de lo contrario, el pánico que genera la crisis potencial evitará la toma de decisiones y acción efectiva de respuesta.
• Coordinación de empresas, personas y recursos para responder a la situación.
Incluye todos los equipos requeridos, y la capacitación del recurso humano involucrado.
• Comunicación interna y externa sobre el impacto de la situación y las acciones
que se deben tomar. Se deben incluir empleados, clientes, proveedores y público general afectado, así como autoridades sectoriales o nacionales de ser necesario.
Componentes. La capacidad de respuesta a emergencias debe contar antes, durante y después del día cero los siguientes componentes, coordinados local o virtualmente: • Personal disponible. Es el recurso más importante de una buena CRE.
Usualmente, se tiene un director que coordina las actividades, y dos grupos funcionales:
Logística y Comunicaciones: Debe preparar el equipo de trabajo y los recursos necesarios, capacitar al personal, planear y suministrar información, emitir comunicados si es necesario, y en general, mantener toda la infraestructura requerida para el funcionamiento de la CRE.
Respuesta a Emergencias: Debe establecer contactos con las unidades del negocio y con otras empresas, desarrollar guiones de posibles fallas, monitorear la situación para detectar problemas, crear, asignar y coordinar los equipos de respuesta, y dar soporte a las unidades del negocio en caso de ser necesario. Por lo general, los equipos de respuesta tienen un representante de la unidad del negocio afectada, y un pequeño grupo de especialistas en la situación particular.
• Líneas de comunicación internas y externas: para identificar cualquier
eventualidad con la mayor rapidez posible, y del mismo modo comunicar a los equipos de respuesta. Se sugiere tener varios medios de comunicación, en caso de que fallen los sistemas de telecomunicaciones.
18
• Ubicación: no es necesario que la CRE sea una oficina, puede tener una
ubicación virtual. Lo importante es que se tenga la posibilidad de localizar a todo el personal rápidamente, y se cuente con el espacio físico que sea necesario.
• Recursos tecnológicos y físicos: tales como plantas eléctricas, teléfonos, radios,
equipos de primeros auxilios, suministros de primera necesidad, etc. • Sistemas de seguimiento y monitoreo: tanto para detectar fallas, como para
efectuar un seguimiento permanente a la evolución de las situaciones de falla, las emergencias, los planes de contingencia, etc.
• Documentación: planes de contingencia, contactos, eventos, inventario de
aplicaciones, etc.
Factores Críticos de Éxito. Es importante tener en cuenta los siguientes factores para que la CRE sea rápida, efectiva, y logre cumplir su propósito, es decir, garantizar el funcionamiento mínimo requerido en la organización: • Autoridad suficiente para lograr la colaboración de las diferentes áreas de la
empresa en la planeación y ejecución de la estrategia de emergencias. • Entendimiento profundo del problema del Año 2000 y sus posibles
consecuencias. • Priorización de problemas y situaciones de emergencia. • Relación estrecha con todas las unidades del negocio, operaciones relacionadas,
y proveedores críticos. • Canales de comunicación múltiples, conocidos por el personal y probados. • Procedimientos eficientes y ágiles para la respuesta a problemas. • Capacitación de todo el personal involucrado. • Coordinación de un gran número de recursos. Finalmente, se recomienda integrar este esfuerzo a capacidades existentes, y no tratar los problemas de Año 2000 aisladamente. Las entidades enfrentan situaciones de crisis con cierta frecuencia, por lo cual existen ya en alguna medida procesos para respuesta y toma de decisiones.
19
Esta metodología para generar y ejecutar un plan de contingencia fue enfocado inicialmente para dar solución a problemas Y2K, pero su base puede ser utilizada para generar cualquier plan de contingencia en el desarrollo e implantación de sistemas mayores donde se requieran. Esto también lo veremos en la parte de formación de PM´s.
1.16 Herramientas Muchos de los proveedores de software y compañías de consultoría desarrollaron sus propias herramientas de trabajo para evaluar y corregir el problema del año 2000, en el caso de IBM desarrollo sus propias herramientas para cada plataforma y fueron: Mainframe. Debido a que el proceso de análisis en Mainframe era lento y consumía demasiados recursos, la opción fue el pasar este código a una PC donde seria analizada con la herramienta Revolve. Esta herramienta analiza código cobol, JCL´s y las relaciones entre los programas y tiene un modulo que realiza la solución de ventaneo. También analiza las FD´s y su longitud en caso de que se cambie alguna redefinición. Cuando el sistema estaba desarrollado en Natural se transfería el código a un equipo AIX, donde se corría una herramienta que se llama Natural 2000, esta herramienta generaba listados con las líneas impactadas por programa y posteriormente la corrección era manual. El análisis y solución de programas desarrollados en Ensamblador era de forma manual. Unix/Aix Las aplicaciones desarrolladas en cobol también eran transferidas a una PC para sus análisis y corrección con la herramienta Revolve, pero los Shells no podían ser analizados por esta herramienta, por lo que el análisis se realizaba en unix con sus propias utilerías. Para definir el inventario de los objetos era necesario realizarlo manualmente, buscando los “Call” internos de los programas y los llamados dentro de los shells. Si el código ya estaba en Natural, se transfería a equipos del laboratorio donde era analizado la aplicación.
20
AS/400 Las aplicaciones desarrolladas en RPG que corren es estos equipos eran analizados por una herramienta que se llama ADAMS/4000; esta herramienta nos permite analizar el impacto de los programas, pero la solución se hace manual. Todas las herramientas antes mencionadas tienen el mismo principio que es la de analizar en base a patrones y constante de números y después de un análisis manual se identifican cuales son los programas impactados. También las herramientas nos permiten entrar y salir con gran facilidad de un programa a otro.
21
22
NATURAL.
23
24
1.17 Clientes. Inicialmente cuando empezamos a analizar el problema de año 2000, se dividío en dos partes una conocido como Fase 0 donde le decíamos al cliente que tan infectado esta y otro donde ya le hacíamos la remediación al problema.
- Avon Análisis y Remediación - Bancomex Análisis - Serfin Análisis y remediación - Xerox Análisis y remediación - Banco de Venezuela Análisis y remediación - Banco de Colombia Análisis y remediación - Goodyear Chile Análisis
25
1.18 Conclusiones año 2000: Durante esta etapa de mi vida tuve la oportunidad de conocer muchos clientes, permitiéndome tener un mejor desenvolvimiento con los clientes, a aprender a manejar equipos de trabajo grandes (40 personas en el proyecto de Xerox y un promedio de 18 en los demás proyectos) En la mayoría de los clientes la solución fue ventaneo debido a que la expansión de campos involucraba el modificar no solo a aplicación, si también todas las interfases que se tenían, muchas de estas externas al cliente. Solo en los casos donde la fecha formaba parte de la llave de sorteo de los datos, fue necesario la expansión, en los demás casos se seguía la política de ventaneo. En el caso de cobol, la función de sorteo de fechas se soluciono con un fix en el lenguaje o compilador.
26
Capítulo II.- Administración del proyecto IBM
2.1 Antecedentes Gracias al apoyo brindado por la compañía tuve la oportunidad de llevar la administración de proyectos como Gerente del proyecto, en otros como Project Manager y por ultimo coordinar la administración, ejecución de los proyecto de un área especifica de IBM ITS encargada de la línea de soporte y soporte en sitio de la infraestructura de productos IBM. Aquí describiré lo siguiente:
Resumen de los puntos más relevantes a considerar en la administración de proyectos, considerando lo que es el PMI.
Proyectos en los que participe
Tips
Resumen
2.2 PMI
Project Management Institute (PMI), es la institución de profesionales no lucrativa más grande del mundo. El PMI representa a los profesionales en dirección de proyectos a nivel mundial. A través de la membresía en PMI y el grado como profesionales en dirección de proyectos (PMP) la gente ha podido demostrar su valor ante cualquier organización que compita en el creciente y cambiante mercado hoy en día.
PMI Internacional fue fundado en 1969 con socios voluntarios. Durante los años setenta PMI se desarrolló principalmente en el campo de la ingeniería, mientras tanto el mundo de los negocios desarrollaba sus proyectos a través de especialistas de la misma empresa y formaban grupos de trabajo llamados "Task Force". Para los años ochenta, el mundo de los negocios comenzó gradualmente a dirigir sus negocios por proyectos.
Durante este tiempo el PMI, a través del comité de estándares y colaboradores (entre ellos empresas, universidades, asociaciones de profesionales, especialistas y consultores en proyectos) realizó el estudio, evaluación y revisión acerca de los estándares aceptados a nivel internacional, dando como resultado los estándares que representan el cuerpo de conocimientos generalmente aceptados de la Dirección en Proyectos, cuyo título original es "Project Management Body of Knowledge" (PMBOK). En 1987 se publicó su primera edición y en 2000 se ha generado una nueva versión más actualizada.
PMI tiene como objetivo establecer los estándares de la dirección de proyectos, mediante la certificación profesional y agrupar a profesionales de diversas áreas e industrias. Así mismo, se ha dedicado a estudiar proyectos que han seguido o siguieron los estándares establecidos por el instituto.
27
Por lo anterior, desde su fundación en 1969, PMI se ha convertido en una de las primeras organizaciones especializadas para industrias como ingeniería, aeroespacial, servicios financieros, servicios domésticos, automotriz, construcción, farmacéutica, manufactura, telecomunicaciones y tecnología de información, entre otras.
Actualmente, el PMI cuenta con más de 50,000 socios activos a través del desarrollo de actividades profesionales de la dirección de proyectos. Así mismo, representa a más de 40 países y 106 ciudades del mundo, entre ellos México
Los objetivos estratégicos del PMI México son los siguientes:
Difundir y consolidar la imagen del PMI en México.
Promover los conceptos del PMBOK a través de los profesionales de México.
Promover la Dirección de Proyectos como una profesión reconocida mundialmente.
Compartir la experiencia internacional, a través del desarrollo de profesionales nacionales e internacionales.
Desarrollar calidad en los recursos humanos para la Dirección de Proyectos.
Compartir los conocimientos generalmente aceptados que dan reconocimiento a la profesión en nuestro entorno.
Consolidar estándares internacionales para el entorno nacional.
Certificación de profesionales en proyectos reconocidos mundialmente.
2.3 Project Manager IBM de México preocupado por la correcta administración de proyectos implemento una serie de cursos que permita a sus Project Manager´s una correcta y misma forma de administrar proyectos. A continuación mencionare alguno puntos relevantes y generales de este proceso de capacitación; definiendo algunos conceptos y metodologías. Que es un proyecto? Un finito esfuerzo de:
28
Tiene un definido Inicio y un Definido Fin Es único Consume recursos
Que es un subproyecto? Parte del manejo de un proyecto con un nivel de independencia. Que es un administrador de proyecto? Es la aplicación del conocimiento, skill, y herramientas para las actividades del proyecto, subproyecto y programas para reunir o exceder los objetivos (stakeholder). La administración de un proyecto requiere de un Gerente: Comunique Coordine Construya un equipo de trabajo Resuelva posibles problemas Integre Ejecute Planee Presupueste Controle Cubra las expectativas del cliente Fases del proyecto: Los proyectos son normalmente divididos en Fases Colectivamente estas fases son llamadas Life cycle Los ciclos de vida del proyecto son similares pero dificilmente identicos Existen 3 formas de observar un proyecto: CRM (Customer RelationShip) Fase 1 Diseño de la solución Fase 2 Entregable de la solución En las buenas relaciones se debe de considerar el manejo de la oportunidad, identificar la oportunidad, validar la oportunidad, calificar la oportunidad y seleccionar la oportunidad. Durante el diseño de la solución debemos de definir la solución, crear la propuesta y obtener la aprobación. Y durante el entregable de la solución debemos de realizar la entrega, el kickoff de inicio y al final la encuesta de satisfacción del cliente.
29
Este enfoque es mas hacia los vendedores que desarrolladores de soluciónes. IPD (Integrated Product Develoment) Fase 1 Concepto Fase 2 Plan Fase 3 Desarrollo Fase 4 Calificar Fase 5 Lanzar Fase 6 Ciclo de vida Durante el proceso de selección de un producto, debemos de considerar el desarrollo de los requerimientos del producto y su concepto, definición del producto y su plan del proyecto, desarrollo y verificación del producto, calificar y certificar el producto, entregar el producto y administrar el ciclo de vida. PMBOOK Fase 1 Concepto Fase 2 Desarrollo Fase 3 Ejecución Fase 4 Terminación Este es el ciclo de vida de todos los proyectos, independientemente del enfoque con el que se maneje. Por lo antes mencionado se considera que: Proyecto = Negocio mas pequeño Ya que ambos: Consumen recursos - Staff - Equipo - Facilidades Tienen un medio a su alrededor (Stakeholder) quienes: - Invierten - Definen objetivos - Demandan un beneficio de capital Tienen factores críticos del éxito: (DESICION) - Costo - Plan - Calidad Tienen blanco financiero: - Trabajar dentro del presupuesto - Control de costos
30
- Deben de generar un ingreso y una ganancia - Tener un flujo de efectivo positivo. Así como de las cualidades de las que requiere un gerente antes mencionadas, el gerente es responsable de: - Responsable del proyecto - El único punto de contacto para el proyecto - Responsable de identificar los stakeholders Los stakeholders del proyecto son: - Son las personas quienes tienen un interes o rol en el proyecto. (Procurement, Legal, Finance, Project team, Quality assurance,suppliers,client) Analisis de Stakeholder Identifique todos los Stakeholder (Identificar a todos los participantes involucrados
en el proyecto) Identifique si es amigo o enemigo Utilice a los amigos para llevar a los enemigos en línea Del restante enemigos determine:
Como medirlo Como recompensar
Desarrolle e implemente una estrategia de Ganar/Ganar para llevar a los enemigos en línea
Recuerde: Siempre existirá alguna forma de enganchar a los enemigos, para el éxito del
proyecto Usted no tiene que gustarle a todos para el éxito del proyecto Guarde su ego donde este se necesite para estar seguro del éxito del proyecto Papel de un project manager: Plan del proyecto - Actividades técnicas - Administración de las actividades del proyecto Manejo de la triple restricción Cliente/Proyecto/Gasto(Debe de existir un balance) - Calendario - Costo
31
- Especificaciones Organice el proyecto incluyendo: - Formación del equipo del proyecto - Seleccione el sistema para documentar el proyecto - Seleccione el plan del proyecto por el cual el proyecto puede ser controlado Usted puede manejar el proyecto con: - Seguimiento técnico por la triple restricción - Seguimiento financiero del proyecto - Evaluación y manejo del proyecto por los factores de riesgo - Trato a los posibles problemas, problemas que ocurran durante el proyecto - Seguimiento a los proveedores y sus contratos - Asegurar la satisfacción del cliente - Construir y mantener la moral del equipo de trabajo - Comunicación con los involucrados del proyecto - Manejar al equipo de trabajo incluyendo terceros - Seguimiento en la utilización de los recursos - Usar el procedimiento de control de cambios - Cierre del proyecto
2. 4 La llave del éxito del gerente del proyecto: Rango prolongado de expectativas Hable sobre el riesgo y sea emprendedor Clarifique objetivos Innovador y creativo Participe resolviendo problemas Sistematice el pensamiento y la planeación Estrategia de encuesta Conciencia política Facilitador entre los miembros del equipo Desarrollo del equipo Asertividad Retroalimentación a los miembros del equipo Relación con el gerente funcional Optimizar los estándares Manejar Presión de objetivos Delegación Reconocimiento a lo mejor
32
Conducta para el éxito del gerente del proyecto:
Ser proactivo Pruebe nuevas ideas Preserverar Orientarse a los objetivos Comunicación Motivación Ser organizado Priorizar Ser sensitivo a la gente y a la situación Facilitador Apoyar Innovador Honesto Realista Dar criticas cuando se requieran Listo Planear Pensar sistemáticamente Asertivo Decisivo Confidente Constructor del equipo Perseguir la excelencia Entusiasta Enérgico Delegar A favor Mantener contacto Sensitivo cuando se requiere y se necesite Elogiar cuando sea apropiado
2.5 Tipos de organización usada en proyectos. - Funcional - Proyectizada - Matricial Proyectos en una organización Funcional. En la organización funcional cada trabajador pasa a responder ante varios supervisores o jefes. Cada supervisor o jefe solo supervisa a los obreros en los asuntos de su competencia. Los trabajadores deben recurrir ante una situación problemática al supervisor más adecuado para resolver su problema, evitando pasos intermedios con jefes de grupo, cuya atribución seria limitada solo a su especialidad.
33
Por ejemplo, un jefe de producción se especializaría solo en ese campo y no tendría competencia en problemas como la rotura de una maquinaria.
Proyectos en una organización Proyectizada. Es donde la mayor parte de los recursos de la organización está involucrada en los proyectos, y los gerentes de cada proyecto tienen gran independencia y autoridad. Las organizaciones proyectizadas muchas veces tienen unidades organizacionales llamadas departamentos, pero estos grupos regularmente proveen servicios de soporte a varios proyectos, por ejemplo, sueldos y beneficios, limpieza, seguridad, etcétera.
34
Proyectos en una organización Matricial. Las organizaciones matriciales involucran, la estructura tradicional Los miembros del equipo son dibujados para varias líneas o unidades funcionales
de la organización Las organizaciones matriciales son complejas y presentan retos para la
administración de proyectos. Los retos involucrados:
Autoridad/Responsabilidad de el gerente del proyecto y el gerente funcional Flujos de comunicación
Manejo en la matriz. - El éxito de la operación depende de las actitudes, acciones y actividades de la gente involucrada - Un estatuto de proyecto asigna autoridades y responsabilidades para el manejo del proyecto, es extremadamente útil. - El gerente del proyecto y el gerente funcional tienen que trabajar en una buena relación. - El gerente del proyecto se esfuerza por que se realicen los trabajos principales a través de la negociación o su líder. - Los miembros del equipo tienen que adaptarse a reportar a 2 jefes.
35
2.6 Project Charter El estatuto del proyecto es un documento formalmente reconocido de la existencia del proyecto. Este incluye: - Las necesidades de negocio del proyecto por el cual fue concebido por la dirección - Una descripción del producto, este documento este documento generalmente tiene las características del producto o servicio y dibuja la relación entre el servicio y las necesidades de negocio. Principio del estatuto del proyecto. Establecer el alcance Sea tan conciso como sea posible Nombre del gerente del proyecto como del responsable y de quien autoriza en la
organización Identificación de entregables, calendarios y presupuesto Identificación de papales (Roles) Construcción básica del equipo: Un equipo:
36
- Es un número de individuos asociados para una acción conjunta - Incluye gente de la organización, proveedores y cliente, responsables - Conjunta talentos para alcanzar un objetivo Desarrollo del equipo: - Esforzar las habilidades del entorno - Esforzar las habilidades del equipo y sus funciones Cuando un grupo de individuos vienen a un equipo, estos individuos: - Vienen obligados a alcanzar un objetivo - Aprendan a trabajar bien juntos y a disfrutarlo - Producir resultados de alta calidad Como construir un equipo? - Seleccione a los miembros del equipo correctos + Identifique las necesidades del skill del proyecto + Valide los requerimientos del skill y recursos - Organice el equipo + Identifique a todos los gerentes del subproyecto + Prepare el estatuto de la organización + Establezca niveles de delegación - Asegure una comunicación abierta - Inspire a los integrantes del equipo a ser los mejores - Incorpore a nuevos miembros como ellos disfruten durante este ciclo de vida Consideraciones multiculturales del equipo - Costumbres sociales - Diferencia de horarios - Ingles como segundo lenguaje - Practicas de protocolo - Practicas de documentación
37
Team Charter. - Escriban los objetivos del alcance de objetivos del equipo - Que el equipo lo acepte - Describir las expectativas del éxito del proyecto - Defina responsabilidades del los miembros del equipo - Defina las reglas base para la operación del equipo del proyecto, incluyendo + Guías de administración + Manejo de conflictos + Escalamiento - Comunicación - Reporte de estatus - Retroalimentación en las juntas
2.7 Definición del Baseline y sus exclusiones Needs: El responsable del proyecto tiene requerimientos, ideas y requerimientos de negocio Requirements: Declaración de deseos para el futuro sistema Exclusions: Declaraciones de no incluir para el futuro sistema Baseline: Declaración de compromiso para el futuro sistema Identifique y valide requerimientos cuando: - Desarrolle una propuesta - Inicie un proyecto - Tome un proyecto en ejecución - Revalue requerimientos de un proyecto Por que establecer un baseline? El baseline: - Incorpora los requerimientos originales para un proyecto mas o menos aprobado los cambios
38
- Sirve como la base del manejo de los requerimientos - Puede ser firmado y aprobado - Sirve como base para acuerdo de terminación del proyecto - Define el alcance del proyecto Preguntas fundamentales para identificar los requerimientos: IPD y CRM usa: - Que es lo que se desea? - Quienes son los involucrados? - Cual podría ser su costo? - Cual es el plan de gasto? - Cuanto tiempo es el proceso de desarrollo? - Como puede ser el servicio y mantenimiento y cuales son las garantías implicadas? - Puede existir una infraestructura de esto? - Que soporte externo se requiere? - Como se define el éxito? - Que sistema de apoyo se pude brindar en sitio? IPD usa además: - Como se comercializara? - Cual es la estrategia del canal? - Como puede ser pedido? - Cuanto tiempo durará? - Cuales productos están listos, en desarrollo y en operación? Como establezco un baseline. - Necesidades - Requerimientos - Reviso - Acepto - Genero un baseline y depuro con exclusiones y excepciones. - Vuelvo a revisar - Apruebo - Baseline final. Usando el Project Definition Report (PDR) para identificar y validar los requerimientos del proyecto. - Cree el baseline para medir y manejar los cambios - Defina criterios de medición, apoyase en el control de proyectos - Prevenga al equipo para brincos y esfuerzo de gastos. - Asegure claridad en el alcance del proyecto antes de detallar el plan.
39
Que es un Project Definition Report? - Es una revisión al documento - Define los limites del proyecto - Establece que puede y que no puede hacer el proyecto - Inicio a organizar el proyecto dentro de una forma manejable - Esto no es un estatuto de proyecto - Esto no es un estatuto del equipo - Esto no es un contrato del cliente Componentes del PDR Project Definition Report? - Aspectos y sumario del proyecto. + De donde vino este proyecto? + Por que esta haciéndose? + Que recibe y que no recibe el cliente con el proyecto? - Objetivos del proyecto: + Cual el blanco del proyecto? + Cual es el problema original? + Cuales son los mejores componentes para trabajar en el proyecto? - Entregables del proyecto: + Cuales con los mejores productos requeridos para cumplir con los objetivos? + Entregables para el cliente + Entregables para el proyecto + Entregables del proceso Trampas en la definición del Baseline. Proceder con requerimientos no claros. - Requerimientos de naturaleza dinámica - Incertidumbre con respecta a quien usara el producto (Importante para el CRM y critico para el IPD) Identificar soluciones prematuras Direccionar los requerimientos de múltiples clientes Los análisis de los desarrolladores con diferente matiz o distorsionar el requerimiento
40
2.8 Organizando el trabajo WBS WBS: Work Breakdown Structure PBS: Producto Breakdown Structure OBS: Organization Breakdown Structure El WBS es una actividad orientada a estructurar el trabajo a realizar. Sistemáticamente presenta todo el trabajo sobre el proyecto con efectos de Costos, Calendario o especificaciones. El tamaño y el número de los niveles WBS varia para cada proyecto. Por que el WBS es necesario? - Son los prerrequisitos principales para la integración del éxito y controlar el total del proyecto asistido en: + Desarrollando el plan de manejo de riesgos + Completar el calendario + Desarrollando el estimado del costo - Son los focos de atención sobre los objetivos del proyecto - Representa un frente para identificar el desarrollo del proyecto - Clarifica responsabilidades - Identifica paquetes de especificaciones de trabajo para estimar y asignar trabajos - Ayuda a construir el equipo del proyecto
2.9 Manejo de riesgo. El riesgo se divide en tres componentes: 1.- Un evento (Posible) 2.- Probabilidad de que sucede este evento 3.- Impacto del evento (Monto del riesgo) Tipos de riesgos. A.- Business risk: Riesgo por la de ganar o perder B.- Pure risk: Este riesgo representa una oportunidad de perder únicamente C.- Known: Se conoce el riesgo anticipadamente D.- Unknown: El riesgo no es planeado y no es reconocido
41
Manejo del riesgo. Proceso de identificar y evaluar el riesgo Una parte integral del manejo del proyecto * Identificación del riesgo * Evaluación del riesgo * Mitigación del riesgo * Monitoreo del riesgo Por que manejar el riesgo: - Proteger el riesgo, calendario y especificaciones - Prevenir sorpresas - Foco para construir una correcta oferta la primera vez. - Prevención de manejo de crisis - Prevenir problemas que pudieran ocurrir o si ocurre para escalarlo Preguntas a considerar en la evaluación de riesgos: Precedencia: Este riesgo a ocurrido antes? Esta familiarizado en la operación? El staff tiene la habilidad para el trabajo? Los recursos son los adecuados para completar el trabajo? El tiempo es el adecuado para terminar el trabajo? Se tiene la calidad adecuada para el trabajo? El manejo del costo esta fondeado para a completar el trabajo? Cuantifica el posible riesgo individualmente. Use conceptos de probabilidad de riesgo. (Alto, Medio y Bajo) Prioritice los riesgos por su severidad (Alto, Medio Bajo) Analice el rango de que suceda el evento de riesgo Revise los posibles riesgos y revíselo con el equipo de trabajo No haga un plan de estrategia de mitigación como parte de este proceso Mitigación del riesgo. Avoid: Estoy conciente de este riesgo y no cambio esta opción Ignore/Accept: Estoy conciente del riesgo y espero aceptar las consecuencias y el evento ocurre
42
Contain: Estoy conciente del riesgo y realizo una acción especifica para minimizar lo ocurrido y el efecto. Establish Contingency: Tengo alternativas en caso de que suceda Transfer: Estoy conciente del riesgo y transfiero parte de este a otra facción. El plan de manejo de riesgo de mitigación es por cada uno. Monitoreo del riesgo: Implemente un plan de seguimiento y manejo del riesgo Comunique el estatus de este plan a los miembros del equipo y los involucrados Cree un lección aprendida en la base de datos
2.10 Estableciendo el estimado del proyecto Considerar el Baseline, los recursos a utilizar, el riesgo, contingencia las horas invertidas en el proyecto multiplicado por el factor de utilización, ya que como sabemos los recursos, se llegan a enfermar, tienen vacaciones, tiempo para ellos y muchas veces no se utilizan al 100% las horas. Una guía de utilización es: 3 a 6 meses 176 hrs Factor 80% 6 a 12 meses 130-140 Factor 75-80 De 12 meses en adelante 120-130 Factor 70-75 Considerando 22 días de trabajo al mes por 8 hrs = 176 por el factor serian 220 hrs (27.5 días) al mes. Duration = Estimated effort / utilization factor 220 = 176 / .80 Estimación: Level of effort (LOE). Que es un estimado? Es una evaluación cuantitativa de los resultados Usualmente aplicado a proyectos el factor del costo y el calendario Usualmente es usado con modificaciones, para ejemplo, preliminar, conceptual , viabilidad Un estimado no es:
43
- Una estrategia de cuenta - Precio - Inversión de mercadeo - Satisfacción del responsable del proyecto - Software o herramienta - Encontrar un camino seguro Razón para estimar: - Para evaluar el estimado del costo proyecto antes de la autorización de implementación - Proveer las bases para el seguimiento y manejo del proyecto - Proveer al gerente del proyecto con una herramienta para evaluar la rutina de decisiones del proyecto - Establecer los recursos requeridos y el resultado del calendario Cuando debe de estimar: - Después del WBS es desarrollado - Cuando determine si es una oportunidad - Antes de mirar el proyecto - Siempre que el WBS cambie Proceso de estimación: - Establezca el objetivo del estimado - Determine el detalle del proyecto - Seleccione el modelo apropiado - Desarrolle la estrategia del estimado y plan - Prepare el estimado - Incluya el riesgo - Valide y finalice el estimado - Estimado del Baseline - Use el estimado en el plan del proyecto
2.11 Creando el calendario del proyecto. Un calendario es un plan de fechas para realizar actividades y juntas de hitos Para usar el plan: - Determine si los objetivos de su junta o recorrido. - De seguimiento y comunique el progreso del proyecto - Vea como un posible cambio puede afectar el proyecto - Asigne tarea a su staff
44
En el WBS determine sus dependencias de tÁreas Guías para realizar el diagrama de red (Plan con precedencias) - El diagrama de red inicia con una tarea o trabajo, paquete o actividades o un acontecimiento (Milestone) - El diagrama de red termina con una tarea o trabajo, paquete o actividades o un acontecimiento (Milestone) - Estas son predecesoras para todas las actividades - Estas son sucesoras de otras actividades - Las tÁreas lógicas pueden ser actualizadas y concurrentes - No existen loop Terminología básica del plan: - Actividad - Milestone - Relationship * Finish-start * Finish- finish * Start- start - Lag time Late start (LS) Late finish (LF) - Lead time Early start (ES) Early finish (EF) Estableciendo el plan de manejo de cambios En los capítulos anteriores quedamos que se tiene que reestimar el baseline cada vez que haya un cambio y debemos de considerar los tres factores críticos del un proyecto: - Requerimientos - Calendario - Costo Todo Baseline y alcance es finito Que es un manejo de cambio?
45
- Es el procedo de manejar y controlar el baseline - Un sistema de control de cambios * Incluye el procedimiento de documento formal y define como se manejara el cambio * Establece los papeles de trabajo, sistema de seguimiento y niveles de aprobación necesarios para autorizar el cambio Proceso de manejar cambios - Identificar el cambio - Claridad en el alcance - Complejidad del estimado / precio de la inversión - decisión si se evalúa - Si se decide no continuar se documenta - Si se decide continuar se evalúa el impacto - Se evalúa el costo - Selecciona alternativas - Precio - Decisión de aceptación - Si es un no se documenta - Si es un si Se actualiza la documentación necesaria - Se implementa - Se documenta - Se archiva Manejo y control del proyecto El gerente del proyecto deberá de integrar todos los aspectos del proyecto, asegurándose de contar con el conocimiento apropiado y que los recursos estén disponibles cuando se necesiten, y encima de todo, asegurar las expectativas de los resultados sean producidos en tiempo y costo efectivo. Meredith and Mantel 1995 p.4. Controlar es el proceso de monitorear, evaluar y comparar los resultados de los planes con los resultados reales, para determinar el estatus del costo del proyecto, calendario y técnicas de mejoras. David I.Cleland 1994, p.285. Por que es importante controlar el proyecto?
El proyecto se puede volver infinito
El costo se puede elevar excesivamente
Se puede incrementar el riesgo
Pueden faltar planes
46
Durante el proceso de control debemos de: Establecer estándares Observar mejoras Comparar el plan actual contra el planeado Hacer acciones correctivas Para un buen control del proyecto es necesario levar una carpeta de control de proyectos, el cual deberá de contener los documentos generados utilizada para:
- Como base para revisiones y auditorias - Como un repositorio de información para los miembros del equipo - Como una herramienta para el manejo de otros proyectos
Definición de una buena carpeta de control de proyecto. Seguimiento y evaluación del proyecto Administración financiera Reportes Manejo de riesgo Manejo de proveedores Control de calidad Control de cambios Manejo de problemas e issues Manejo de contrato Administración de los recursos Entregables Cierre de proyecto. Es necesario asegurarse de cerrar el proyecto para:
Cerrar formalmente los gastos del proyecto Controlar los registros del proyecto que son terminados Los criterios de terminación se reúnen para la ultima revisión y generación de
documentación. Preparar documentación de lecciones aprendidas Garantizar la transferencia cuando aplique
Cuando debe de cerrarse el proyecto? Un día antes del término en una junta con el cliente. Revisión del proyecto final.
Asegurarse que se cumplieron con todas las obligaciones contractuales, debiéndose revisar en una junta.
47
Antes de cerrar el proyecto asegurarse de que ninguna actividad pendiente
Preparar el reporte basado en la revisión
2.12 Experiencia en Manejo de Proyectos Algunos de los proyectos en los que participe como responsable son: Proyectos Año 2000 Avonne. Banco de Colombia, Goodyer Chile BBVANET Banca a distancia Bancomer Instalacion de VTS EDS Línea de soporte y soporte en sitio Iusacell, LyFC, Telmex Manejo de fallas Secretaria de Finanzas Instalacion de equipo SUN IMSS Instalacion de Tivoli Gedas DRP Infonavit A continuación adjunto de los documentos importantes de estos proyectos: PROYECTO BBVA A BANCOMER Kickoff
Fecha y Lugar Tipo de Reunión Horario Participantes
_________________________________________________ Julio 04, del 2000. Banco Santander Mexicano Manuel Avila Camacho 170 1er. Piso Col. Lomas San Isidro CP 11620 _________________________________________________ Kickoff. _________________________________________________ 11.30 - 13.00 hrs _________________________________________________
Nombre Puesto Siglas
48
Agenda Narrativa
Emilio Porras Alonso
Gerente de Proyecto Santander
EP
Wuilbert Martinez
Soporte
WM
Jose Luis Quiroz
Gerente de Proyecto IBM
JLQ
1. Presentación del equipo de trabajo 2. Solicitud de requerimientos por parte de IBM 3. Revisión del plan de trabajo 4. Revisión de requerimientos de los servidores para TIVOLI 1.- Presentación del equipo de trabajo LAC presento a los nuevos integrantes del quipo de trabajo quedando conformado de la siguiente forma: Gerente de proyecto por parte de Santander Emilio Porras Alonso Por medio del cual se canalizará la comunicación hacia IBM como hacia Santander. Gerente de proyecto por parte de IBM José Luis Quiroz Lechuga Quien administrará el proyecto por parte de IBM, y dará informes de avance al Banco Santander y será también el único canal de comunicación y de acuerdos entre IBM y el Banco Santander. Arquitecto Antonio Cristan Quien se encargará de diseñar la arquitectura que se requiera para la instalación de los productos de TIVOLI adquiridos por el Banco….. 2. Solicitud de requerimientos por parte de IBM LAC solicito a EP Lugares de estacionamiento para personal que estará
49
laborando el en proyecto, gafetes provisionales para el acceso al edificio del banco para evitar el registro diario del personal, así como memorandums para poder entrar con las Think Pads sin tener que estar registrando diario, en el entendido de que será necesario mostrarlas tanto al entrar como al salir del Banco.EP quedo de revisarlo y nos informaría….. 3. Revisión del plan de trabajo WM explico de forma general y resaltando algunos puntos el Plan de trabajo, del cual estuvo de acuerdo EP, y quedo WM de enviar el plan de trabajo actualizado con fecha de arranque del lunes 10 de julio del 2000. … 4. Revisión de requerimientos de los servidores para TIVOLI Al revisar la solicitud del nuevo equipo para los servidores de Netview y Framework, AC comento que faltaban algunos datos los cuales revisaría y le enviaría una nota indicándole los valores correctos en base a “Mejores Practicas”.
Acuerdos 1.- EP estuvo de acuerdo con los integrantes del equipo de trabajo y la forma de comunicación en ambas partes. 2.- EP quedo de revisar los requerimiento de IBM 3.- EP estuvo de acuerdo con el plan de trabajo y que la metodología y procedimientos que se apliquen sean los que recomiende IBM en base a sus mejores practicas. 4.- EP quedo de enviar el documento que generó para que AC complemente.
Compromisos 1.- EP quedo de enviar la lista de la gente que participará por parte del Banco. 2.- EP quedo de investigar y solicitar, Gafetes de acceso, lugares de estacionamiento, Acceso a equipo de computo y líneas analógicas. …..
Minuta
Fecha y Lugar
Julio 20 de 2000. BBVA Madrid, España
Tipo de Reunión
Reunión de Trabajo.
Horario 09:00 – 18:00 hrs Participantes BBVA Área IBM Latinoamérica Arturo Gil Sistemas Luis Enrique Sanchez
50
Operativos Patricia García DB2/UDB Jorge Combes Maria Lucero
García NES Jorge Benitez
José María Rodriguez
Comunicaciones José Luis Luna
Emilio Delgado MQSERIES/XCOM
Jorge Yaqui
Agenda Software Base – AIX, SOLARIS HACMP
Tivoli Websphere Application Server, Netscape Enterprise Server,
DB2/UDB: Narrativa TEMA: Reunión. Software Base (AIX, SOLARIS), HACMP, Java
Run Time, Tivoli: 1.- AIX. Y S.O. Los contactos directos para aclaración de dudas será: Fernando Roca (34)91-807-30-… El área del Banco Infraestructura Técnica nos informo lo siguiente: SUN. 1.4.La instalación de sistema operativo se realiza con los parámetros por default, sin embargo, se cambian algunos parámetros generales y son: Pendientes: - Programar reunión de trabajo con la gente de almacenamiento - Se solicitó los estandares de nomenclatura - Lista de parametros instalados por servidor - Favor de indicarnos cual es la versión anterior del Stone Beat
(Deberia ser la que esta corriendo actualmente). Y el tipo de licencia.
HACMP.
1.5 En los servidores de WebSeal en BBVA se tiene instalado HACMP y network Despatcher. Acuerdos:
51
Pendientes: - Se les pidío configuración del hacmp incluyendo los Scripts de paro y arranque. 2. TIVOLI. Los contactos directos para aclaración de dudas será: -
Acuerdos AIX. Se acordó que para México, Colombia y Perú la versión que se instalará será la versión AIX 4.3.3.
Compromisos Software Base (AIX, SOLARIS), HACMP, Java Run Time, Tivoli: Aix
- El BBVA proporcionara la lista de los procesos mínimos de arranque del S.O. para la solución Banca a Distancia.(initab y archivos /ect/rc.*).
Reporte de Seguimiento Ing. Juan Carlos Zurita Por medio de la presente le hago llegar el reporte semanal de las horas trabajadas del periodo 4 de Enero al 6 de Enero del 2001 para el Proyecto “Banca a Distancia”.
Nombre Actividades Horas
Jorge Combes Soporte aplicatvo Revision de configuración actual Reunión de trabajo …..
28 horas
Patricia Armendariz
Reinstalación de Network Dispatcher …..
10 horas
Jorge Benitez / Mikalonis
Revisión de ambiente …
28 horas
José Luis Quiroz Revisión con BBVA Bancomer del avance que se tiene en el proyecto
…
18 horas
Total de horas 84 horas
52
Informe de avance. Seguridad
Se revisó el ambiente y esta funcionando correctamente. Se integro al equipo de trabajo Mikalonis por cinco días para dar soporte a Jorge ……
Mqseries Se intento configurar Mqseries en ambiente de producción por la parte de host, pero se tuvieron algunos problemas y se decidio regresar al ambiente de testing para continuar probando. Aplicación….
Conclusiones: …….
Pendientes: Seguridad
- Probar el Network Dispatcher con la alta disponibilidad y dar solución a los problemas presentados.
- ……. Aplicación.
- Pruebas de Volumen en ambiente productivo con cuentas validas …… Atte. Autorizo ______________________ ________________________ José Luis Quiroz Lechuga Ing.Juan Carlos Zurita Project Manager IBM Líder de proyecto BBVA Bancomer
53
Cierre de Proyecto Ing. Juan Carlos Zurita Le informo que de acuerdo al anexo “Banca a Distancia” Number Contract MXAAAYP Work Number MXABAP del contrato firmado entre IBM de México y Bancomer S.A. No 3098000172. Se da por terminado satisfactoriamente la instalación y configuración de la infraestructura con la aplicación BBVNET: Entre las tareas relevantes realizadas en esta Fase II fueron: 1- Se instalo la versión del aplicativo 1.0 enviado por España y se hicieron pruebas de a travez de la infraestructura validando cada uno de los componentes instalados los cuales se pusieron a punto y se dejaron funcionando. 2.- Se instalo la nueva imagen del aplicativo y se hicieron pruebas de volumen en el ambiente productivo con una transacción y que esta funcionamiento, pero al mandar 10 usuarios concurrentes con 10 transacciones no se recibió respuesta de host y se continua revisando para identificar cual es el problema. 3.- Se integro el equipo de operadores que darán el servicio de 7 x 24 a partir del 12 de enero y se les dio una inducción de los productos instalados. Ellos solo son responsables de la operación, en caso de algún problema seguirán la matriz de escalamiento. 4.- Se entregó un draft de la documentación de la operación de los productos instalados en los equipos IBM. Se esta trabajando en la ultima versión. 5.- Se continua haciendo pruebas para identificar donde están las demoras en los tiempos de respuestas. 6.- Se entregó el ambiente estable aunque falta por terminar hacer pruebas Pido de favor firme al calce dando por finalizada la fase II del proyecto, así como satisfactoria los entregables marcados en el anexo del contrato firmado entre IBM y Bancomer. Atte. Acepto ______________________ ________________________ José Luis Quiroz Lechuga Ing.Juan Carlos Zurita Project Manager IBM Líder de proyecto BBVA Bancomer
54
Carta de Terminación Ing. Carolina Santana Me es grato informarle que el proyecto “Instalación del VTS” OMSYS ha concluido satisfactoriamente, terminándose las actividades marcadas en el plan de trabajo. Se dio la capacitación información transfiriendo los conocimientos del proceso satisfactoriamente. Solo me queda agradecerle las facilidades brindadas para el éxito de este proyecto y quedo a sus ordenes para cualquier otro requerimiento que necesiten. Por favor firme al calce de aceptación servicios y cumplimiento con todos los entregables marcados en el contrato. Atte. Acepto ______________________ ________________________ José Luis Quiroz Lechuga Ing.Carolina Santana Project Manager IBM Líder de Proyectos EDS
Cierre de proyecto IUSACELL
Lic. Christian
Planeación y Proyectos de Sistemas
Iusacell
Me es grato informarle que de acuerdo con el contrato número 1804823 firmado entre IBM y
Iusacell donde se les otorgo 120 horas de nuestros especialistas de soporte en sitio en sus
instalaciones en la plataforma red distribuida se da por terminado cumpliendo los siguientes
servicios:
1.- Se completaron las horas ofrecidas dentro del contrato
2.- Se hizo el análisis y diseño de los siguientes programas:
A) Extracción y envío de datos de la base de NPDV. B) Inserción en la base de datos Oracle de BSCS y envío de respuestas a NPDV.
55
C) Inserción de respuesta en la base de datos de NPDV. 3.- Pruebas de los programas en ambiente de desarrollo.
Por lo antes mencionado pido de favor firme alcalce finalizando las actividades antes descritas
liberando de cualquier responsabilidad a IBM de México por los servicios antes mencionados.
Atte. Acepto
______________________ ________________________
Lic. José Luis Quiroz L Lic. Christian
Project Manager Planeación y Proyectos de sistemas
IBM Iusacell
Informe de reporte de Fallas Lic. Modesto Garcia Hernandez
Coordinador de desarrollo técnologico
Secretaria de Finanzas
Por medio de la presente le informo que durante el periodo de la vigencia del contrato
SW010532 de septiembre a diciembre del 2001, no hubo ningun reporte atendido por el
soporte IBM de México o de sus laboratorios en EEUU, existieron 2 llamas de su parte:
16 P2SDKLX H C 2 REP RC 8688 SECRETARIA DE F RODRIGUE ADMST3 1115 1739 MX1 17 P2SDP9F H C 3 REP CE 7018 SECRETARIA DE F QUIÑONES CALLS1 1114 1422 MX1
El primero fue manejado por la gente de hardware, razón por la cual no tenemos documentado
del estado que guarda el reporte.
En el segundo se reporta el 14 de noviembre del 2001 a las 14:22, un problema de reseteo con
la tarjeta de red, el especialista de IBM el Ing. José Luis Luna se reporto con ustedes para
atenderlos, pero de acuerdo a sus comentarios, el problema ya estaba controlado y casi
resuelto por ustedes, por lo que ya no se requirio del soporte.
56
Quedo a sus ordenes para cualquier comentario al respecto.
Atte.
______________________
Lic. José Luis Quiroz
Project Manager
Tel. 5270-2854
IBM
Reporte de Avances Transición Versión del plan: 1.0
Fecha de reporte: 05-12-2001 Reporte elaborado por: AT/JV
Status resumido
GENERAL
El avance del proyecto esta en un 40%, contra plan de trabajo. El problema principal sigue siendo el área de proveedores.
TRANSICIÓN
Documento criterios de conclusión de Transición definido Plan de detalle definido Entrega de documento de Evaluación de ambiente Operatívo Entrega de documentos de Proceso de Cambios y Proceso de Problemas Entrega de Documento de proyectos en procesos
Pendiente de firma de aceptación En espera de observaciones Se revisarán en la siguiente semana En espera de observaciones
BAU Quedaron cubiertas todas las vacantes por renuncia en la transferencia y las definidas en el anexo G En proceso de cubrir las 5 nuevas plazas
Tareas Terminadas
Terminadas al 05 de Diciembre del 2001 contra plan de trabajo
Comentarios
ID 3 Start Up
ID 46 Transferencia de Recursos Humanos Reporte pendiente
ID 50 Plan de Transición detallado Plan entregado
ID 60 Evaluación ambiente operativo Documento entregado
57
ID 129/149 Implantación Problemas y Cambios 80 % de avance, procesos definidos y en validación, documentos entregados
ID 6320 Proyectos en Proceso Documento entregado
Adelantadas Comentarios
Planeadas pero no terminadas Comentarios
Por realizar / En Proceso Comentarios
Issues Significativos Comentarios
El cambio de Proveedores sigue siendo el punto más significativo, se está definiendo un plan específico adicional para su manejo Se definió una matriz que incluye los elementos que el Banco considera se deben cubrir a fin de proceder al reemplazo de los proveedores
Cambios Significativos Comentarios
58
Reporte de Estatus de la Transición
Technical Transition
04/01/2002
Tabla de Contenido
Tabla de Contenido ........................................................................................................................ 58
Evaluación del Estatus del Proyecto .............................................................................................. 58
Notas .......................................................................................................................................... 59
Planes de Mitigación para las areas en en riesgo (Amarillo & Rojo ) ........................................ 59
Actividades en BAU ................................................................................................................... 59
Cost Tracking (Help Desk) ........................................................................................................ 59
Cost Tracking (Labor) ................................................................. ¡Error! Marcador no definido. Adolfo Tapia ............................................................................. ¡Error! Marcador no definido. Objectivo/Alcance .................................................................... ¡Error! Marcador no definido. Consideraciones ...................................................................... ¡Error! Marcador no definido. Entregables definidos en el contrato ..................................................................................... 60
Factores Críticos de exito ...................................................................................................... 60
Issues Abiertos ...................................................................................................................... 61
Cambios aprobados ............................................................................................................... 61
Evaluación del Estatus del Proyecto
Ref. Plan
Descriptivo Avance Fecha Contractual
Comentario Riesgo
47 Transferencia RH 100 % Nov 01,2001 Se transfirieron y cubrieron todos los recursos definidos
48 Cubrir vacantes y adicionales (incluye Anexo J)
80 % Ene 15,2002 De 5 plazas adicionales definidas contractualmente, tenemos pendiente por cerrar una, Cuernavaca
59 Plan de transición de detalle aprobado
100 % Nov 15,2001 El plan de trabajo se entrego el 15 de noviembre como estaba establecido
277 Manual de procedimientos
60 % Ene 31,2002 En Proceso
303 Firma de SLAs con ScotiabankInverlat
60 % Ene 31,2002 Se concluyo documento de definición de SLA’s se entregó draft el 22 de dic
325 Firma de nuevos base lines del plan de transición (Proyectos en Proceso)
100 % Nov 30,2001 En casa de bolsa cerrado, en el banco en firma, documento de referencia
331 Proveedores Transferidos (Plan Relación con Proveedores)
60 % Ene 31,2002 Se acepto por parte del banco la transferencia de proveedores, a dar inicio en febrero del 2001
59
Notas
Recursos habilitados, Plan creado, Team ejecutando en
plan y expectativas cubiertas de acuerdo al plan y a
entregables
Verde
Cubierto lo anterios, pero existen dependencias que
deben ser direccionadas y que pueden impactar el plan Amarillo
Entragables identificados o plan requerido, los riesgos
ponen a los entregables en plan bajo riesgo Rojo
Planes de Mitigación para las areas en en riesgo (Amarillo & Rojo )
Plan de Acción Asignado a Fecha
El Primer draft del manual de procedimientos será liberado y revisado esta semana con el Banco, se revisará el martes 08, el contenido del manual y se definirá el contenido final del mismo, se redefinirán recursos para la conclusión del mismo para el 30 de enero de 2002.
Rogelio Ibarra 30/Ene/02
El martes 08, se revisarán los 4 elementos principales que debe contener el documento de SLA’s El documento final esta en proceso de “adelgazamiento”
Martín Ruiz 30/Ene/02
El proceso de cambio de proveedores ya fue aceptado, el inicio de operaciones por parte de los proveedores propios de IBM y los subcontratados por IBM, inicia el 1ro de Febrero de 2002.
Joaquin Urias 30/Ene/02
Actividades en BAU
Los puntos siguientes, necesitan ser direccionados por el equipos de trabajo de Delivery o por el engagement
manager para su renegociación e implementación.
Item Responsable
Cobro del resultado del item 5 de la tabla de issues PE
Cobro de costos adicionales por concepto de viatico PE
Cost Tracking (Help Desk)
Cost Tracking (Provedores)
60
Estatus General del Proceso de Transición
Entregables definidos en el contrato
MILESTONES PROYECTADOS Día Efectivos a
partir fecha Inicio /
Fecha
Estatus
1 Plan de Transición documentado 0 01/nov/01
Cerrado
2 Inicio de la Transición 0 01/nov/01
Cerrado
3 Inicio de BAU (Business as Usual) –
Inicio de operaciones por IBM 0
01/nov/01 Cerrado
4 Transición de empleados Inverlat 0 01/nov/01
Cerrado
5 Procedimiento de Cambios Implantado 30 30/nov/01
80 %
6 Revisión y documentación de Proyectos
en Proceso 30
30/nov/01 Cerrado
7 Impacto de Proyectos en Proceso a la
Transición 30
30/nov/01 Cerrado
8 Plan de transición detallado BASE LINE
definido 15
15/nov/01 Cerrado
9 Validación de alcance con Proveedores 30 30/nov/01
Cerrado
10 Inventario de Activos 60 30/dic/01
75 %
11 Borrador de Procesos y Procedimientos 60 30/dic/01
60 %
12 Definición de Niveles de Servicio con
base en Niveles de Servicio Objetivo 90
30/ene/02 60 %
13 Implantación de Niveles de Servicio en
contratos de Mantenimiento 90
30/ene/02 60 %
14 Firma de contratos con proveedores 90 30/ene/02
75 %
15 Documento Final de Procesos y
Procedimientos 90
30/ene/02 60 %
16
Definición de Unidades Equivalentes de
Servicio (BASE LINES & Consumos
Adicionales)
90
30/ene/02
80 %
17 Definición de Tabla de tiempos muertos
por Plaza 90
30/ene/02 80 %
18 Firma de entregables de la Transición 90 30/ene/02
0 %
19 Cierre de la Transición 90 30/ene/02
0 %
Factores Críticos de exito
Disponibilidad de Sponsor por parte del cliente
Mantener plantilla de recursos actuales
Uso de infraestructura y funcionamiento del help desk actual (CAI)
61
Issues Abiertos
ID Prioridad Issue Fecha Comentario
1 1 Obtención de autos 07/ene/02
2 1 Transferencia de proveedores y toma de
servicio por parte de MVS
30/ene/02
3 1 Costo de mantenimiento de los proveedores
Teledinámica y Getronics
30/Ago/02
4 2 Definición de cambios operativos 30/ene/02
5 2 Identificar actividades actuales que no están
en contrato pero que se ejecutan
23/ene/02
6 1 Redefinición de los entregables de la
Transición
09/ene/02 Evitar penalizaciones
7 1 Costo de recursos adicionales de Serfin 30/ene/02 El costo es adicional al over
budget
Cambios aprobados
Ninguno
Fecha y Lugar
Tipo de
Reunión
Horario
Participantes
Agenda
Narrativa
_________________________________________________
Agosto 22, del 2003.
IMSS
Tokio 80 Mezanine
Col. Juarez
_________________________________________________
Kickoff.
_________________________________________________
16:00 - 17:40 hrs
_________________________________________________
Nombre Puesto Representante
Alberto Martín del Campo Jefe de División IMSS
Agustín Trueba Rivas Soporte servidores IMSS
José C. Bolaños Cruz Soporte Mainframe IMSS
Adrián Díaz de León Soporte Técnico IMSS
Guillermo Labastida Sales IBM
Moisés Acevedo Project Manager IBM
Antonio Cristan Especialista Tivoli IBM
Adrian Corona Lider Técnico IBM
José Luis Quiroz Project Manager IBM
1. Objetivo
2. Presentación del equipo de trabajo
3. Revisión del Alcance del Proyecto
1.- Objetivo
IBM de México apoyara al IMSS en la instalación y configuración básica de los productos
IBM para la plataforma de servidores Sun (System Open) y equipos Mainframe.
Los tiempos dedicados por parte de los especialistas como la administración será pagada por
62
el área de software group de IBM, previa autorización de ellos y no mayor a las horas
ofrecidas por esta área.
2.- Presentación del equipo de trabajo
Guillermo Labastida presento a los integrantes del quipo de trabajo que realizaran las
actividades dentro de la Institución. Moisés Acevedo quien había llevado la coordinación del
proyecto hasta este momento presento a Jose Luis Quiroz como el nuevo Project Manager
para dar continuidad al proyecto.
Jose Luis Quiroz / IBM
Será el encargado de administrar y mantener la comunicación y de acuerdos hacia IBM y el
IMSS, reportando oportunamente el avance del proyecto e informando cualquier desviación
que se encuentre durante el mismo.
Alberto Martín del Campo / IMSS
Será el encargado de mantener la comunicación y de acuerdos hacia el IMSS e IBM,
validará el avance del proyecto y autorizará los reportes de horas semanales, dando el visto
bueno de entrega de las instalaciones, configuraciones de los productos ofrecidos y
finalización del proyecto cuando este termine.
Adrián Corona
Será el especialista Tivoli quien además fungirá como líder técnico.
Jose C. Bolaños
Será el líder técnico por parte del IMSS en equipos Mainframe
Agustín Trueba
Será el líder Técnico por parte del IMSS en equipos servidores Sun (System Open)
3. Solicitud de requerimientos por parte de IBM
TIVOLI.
Jose Luis Quiroz entrego a los participantes un breve resumen del alcance general de proyecto
System Open. Una vez revisado este documento se observo que algunos de los productos ya
habían sido instalados como es el caso del WAS y algunos productos de Tivoli por lo que se
definió que Adrián Corona a partir del jueves se presentaría en la institución para revisar que
se tenia instalado por parte de Tivoli y el Lunes próximo iría alguien de Websphere para
revisarlo.
En el caso de Websphere se acordó que en caso de ya no requerirse alguna instalación se
utilizarían las horas estimadas para revisar dicha instalación y dar una capacitación informal al
personal del IMSS tanto en México como en Monterrey.
También se les solicito nos indicaran en que equipo se realizaría la instalación y configuración
básica de los productos Tivoli y si este ambiente seria el definitivo o habría que migrarlo a
Producción. Nos indico Agustín que el ambiente sería de pruebas y que seguramente algunos
productos se instalarían en producción tanto en México como en Monterrey.
Informo que una vez que Adrián Corona tuviera un bosquejo de sus necesidades se realizaría
el plan de trabajo, pero que a partir del lunes irían los especialistas de Tivoli para empezar a
realizar la instalación de los productos.
63
Acordaron Alberto Martín del Campo como Jose Luis Quiroz que existe una presión por
ambas partes de poder dar por instalado todos los productos durante el mes de septiembre y en
caso de que quede alguna tarea pendiente de capacitación y documentación se realice durante
el mes de octubre.
MAINFRAME
Jose Luis Quiroz entrego a los participantes un breve resumen del alcance general de proyecto
para la plataforma Mainframe. En donde las tareas a realizar resaltan la instalación del CTG y
el WORKLOAD. Por la parte del Workload Arturo Juárez especialista en Mainframe, ya se
presento con el cliente para revisar el Plan de trabajo y ajustarlo de acuerdo a sus necesidades
y disponibilidad del especialista.
Una vez que tenga Jose Luis Quiroz la información y disponibilidad de los recursos se
realizara el plan de trabajo que será entregado lo antes posible.
Acuerdos 1.- Agustín Trueba junto con Adrian Corona definiran los equipos donde se trabajara.
2.- Alberto Martín del campo y Jose Luis Quiroz se apoyaran para terminar la instalación de
los productos durante el mes de septiembre.
Compromisos
64
65
66
México D.F. a 30 de septiembre del 2003.
Ing. Alberto Martín del Campo
Me es grato informarle que de acuerdo al Contrato firmado el 9 de julio del 2003 entre el
IMSS e IBM ”Licencia de uso de Software, Contract Number MXAABMK Work Number
MXACS5. Se ha terminado satisfactoriamente la instalación y configuración básica de los
productos Tivoli y Websphere señalados en el anexo 2 del contrato consistente en:
Se hizo la transferencia del conocimiento de instalación y configuración básica al personal del
IMSS.
Se cumplió con la cláusula Décima del contrato “Servicio Técnico Especializado”.
Por lo anterior pido de favor se firme el presente documento dando su visto bueno de
terminación.
Atte. Acepto
______________________ ________________________
José Luis Quiroz Lechuga Ing.Alberto Martín del Campo
Project Manager IBM Jefe de División de Producción de Operacion
_______________________________ _________________________________
Mario Alberto Ramos Rentería Gabriel Daniel Flores Saucedo
Jefe de división de Soporte Técnico Jefe de División de Administración de
Infraestructura Arquitectura Tecnológica
Mexico D.F. A 21 de noviembre del 2003
Por medio de la presente hago entrega de la documentación
complemento del proyecto IMSS TIVOLI/MAINFRAME
No. Descripción del documento No.Pestaña
1 Programación de inicio del Decision Support 20
2 Carta de terminación Tivoli Configuration Manager con plan de prueba 4
3 Carta de terminación Websphere Business Integrator 13
4 Carta de terminación Websiteanalyzer con el plan de prueba 12
5 Carta de terminación Access Manager for O.S. Con plan de prueba 15
6 Carta de terminación CTG Sun con informe técnico 8
7 Carta de terminación CTG Mainframe 9
8 Carta de terminación Websphere Studio 22
9 Carta de terminación Websphere Aplication Server con informe 18
67
Fecha y Lugar
Tipo de Reunión
Horario
_________________________________________________
Diciembre 3, del 2003.
Gedas Puebla
_________________________________________________
Kickoff
_________________________________________________
10:30 - 11:00 hrs
_________________________________________________
Participantes Nombre Puesto Representante Juan José Dávila Líder de proyecto Gedas
José Luis Quiroz Project Manager IBM
Agenda Revisión del alcance del proyecto
Narrativa Se identifico como líder de proyecto a Juan José Dávila por parte de
Gedas, pero la firma de los reportes de avance y cartas de terminación
seria Armando Ramos con el visto bueno de Juan José Dávila.
Por parte de IBM el Project Manager será José Luis Quiroz. Y la
comunicación y negociación será a través del líder del proyecto, en caso
de generarse un control de cambio este será revisado y aprobado por Juan
José Dávila y Armando Ramos. Se considera como comunicación valida
el envió de mensajes.
Juan José Dávila externo su necesidad de tener el ambiente DEVdbb
configurado y listo para probar en este mes y programar dentro del plan
las tareas faltantes de configuración y prueba del ambiente FI/CO
completo.
José Luis Quiroz comento que esto es muy alcanzable, lo que nosotros
estábamos esperando era terminar la fase 1 del contrato completo y no
solo un piloto. Juan José Dávila comento que esto era poco probable ya
que existen dependencias externas, El ve poco factible concluir en este
año como es la configuración del HBA en PRD. José Luis Quiroz le
comento que de todas formas se avanzara en las tareas en la fase 1, para
concluirla lo antes posible.
Se hablo por teléfono con Alejandro Martín del Campo y Francisco
Mendoza y se quedo de que mañana José Luis Quiroz pasa a IBM a
recoger el software de Gresham y Francisco Mendoza quedo de dar un
estatus real de cuando recibiría Gedas los equipos Pseries el día de
68
mañana.
José Luis Quiroz quedo de modificar el plan de trabajo de acuerdo al
objetivo de Gedas.
Acuerdos Tener listo y probado el submodulo de DEVDBB (Piloto) para
probar la funcionalidad del producto, independientemente de la
terminación de toda la fase 1 del contrato.
Compromisos
Puebla Puebla a 24 de Febrero del 2004 Ing. Armando Ramos
Me es grato informarle que de acuerdo al Contrato-Propuesta “Implementation of Enterprise
Backup Solution Project” Number OMNotes/Omsys 4NLW9GBN firmado entre IBM de
México y Gedas. Se cuenta con un avance integral del 48% de la Fase 1:
69
Diseño de arquitectura al 92%
TSM1 al 74% nos falta la documentación
DEV 49%, nos falta pruebas con la libreria L700 y la documentación
QAS 55%, nos falta pruebas con la libreria L700 y la documentación
ACSLS FINSA 11% nos falta la documentación
ACSLS CUBO6 12% nos falta pruebas con libreria L700 y la documentación
APL1,APL2, APL3 y APL5 8% nos falta probar y la documentación
Documentación entregada.
- Diseño de Arquitectura v15
- Diagramas por servidor de SAP/FiCo
- Plan de trabajo v14
- Mejores Practicas S.O. En AIX, en Solaris, TSM en AIX y Solaris
- Matriz de mejores practicas Velocidad de transmisión de datos por segundo
- Sheduler de programación de respaldos
Pendientes.
- Entrega de memoria tecnica de TSM1, DEV
Facturación.
El 23 de diciembre se reporto un avance del 25%. El avance al dia de hoy es del 48%
Porcentaje de Avance Monto de la Fase 1 Importe a reconocer
23% $ X8,500.00 USD $ X3,x55.00 USD
(Trece X cuatro cientos Xa ) mas IVA.
Atte. Acepto
______________________ ________________________
José Luis Quiroz Lechuga Ing.Armando Ramos / Juan José Dávila
Project Manager IBM Coordinador de proyecto GEDAS / Lider de
Proyecto
70
BUSINESS CONTINUITY &
RECOVERY SERVICES
BUSINESS RECOVERY CONSULTING
DRP – Disaster Recovery Plan
Infonavit
AGENDA
1. Introducción
2. Resumen Ejecutivo
3. Términos y Condiciones
OBJETIVO:
Apoyar al Infonavit en el desarrollo de su estrategia y
Plan de Recuperación en caso de Desastre; para el
procesamiento de datos soportado por su
infraestructura de Hw y Sw, y basándose en la
metodología e infraestructura de IBM para tal efecto.
1. Introducción
71
ANTECEDENTES:
La consultoría en recuperación, ha evolucionado y en la
actualidad se conoce como un proceso interactivo y
estructurado, que comienza con la recopilación de
información, donde intervienen especialistas de IBM,
trabajando en forma coordinada con los dueños y
usuarios de los procesos de negocio del Infonavit y
culmina con la entrega de varios productos:
1. Análisis del Impacto en el Negocio (BIA)
2. Análisis de Ambiente(EA) de IT y Ambiente de Riesgo
(RA) de IT
3. Estudio de Alternativas de Recuperación (RAS)
4. Elaboración del Plan de Recuperación
5. Soporte a la primera prueba del Plan de Recuperación
CONSIDERACIONESEl plan de Recuperación incluye las actividades a realizar
antes, durante y después de la contingencia, así como el
conjunto de tareas y responsabilidades de cada grupo de
recuperación . El plan debe tomar el flujo completo en
cada caso.
SOLUCION
Apoyar al Infonavit en la identificación de los elementos
necesarios para minimizar el impacto de una
contingencia, permitiendo la continuidad de los procesos
críticos del negocio ante interrupciones prolongadas y el
restablecimiento de las operaciones del negocio.
Esto se logra desarrollando un Plan de Recuperación de
Desastres, efectivo.
2. Resumen Ejecutivo
72
Aplicando la metodología de IBM es posible un enfoque
integral que considere todos los aspectos relacionados a la
recuperación del Infonavit dentro de la ventana de tiempo
definida como "tolerable".
Para lograr nuestro objetivo, el proyecto se divide en 5
fases donde se recopila, analiza y genera la información
que nos permita mantener la continuidad operativa del
Infonavit
Fase 1 Análisis de Impacto en el Negocio (BIA)
Fase 2 Análisis de Ambiente de IT (EA) y de Riesgo de IT (RA)
Fase 3 Estudio de Alternativas de Recuperación (RAS)
Fase 4 Elaboración del Plan de Recuperación
Fase 5 Soporte a la primera prueba del Plan de Recuperación
1.- El Análisis del Impacto en el Negocio (BIA) nos permite
cuantificar las pérdidas tangibles e intangibles de una
interrupción en el procesamiento normal de datos, así se
proyecta el impacto por alcance y duración de la
suspensión.
Lost SaleO ver t im e
Fr audFines and Penalt ies
Char ges or Fees
0
2
4
6
8
10
CreditTot al
TANGIBLE IM PACTS AND EXPOSURES
8 Hours48 Hours
72 Hours1 Week
1 Mont h
0
1
2
3
4
5
6
7
8
CreditTot al
RELATIVE IM PACT OVER TIM E
Mar ket Shar
Pr oduct ivit y
Cust omer Ser vice
Employee Mor ale
Labor Relat ions
0
2
4
6
8
10
CreditTot al
INTANGIBLE IM PACTS
73
El Análisis de Impacto en el Negocio (BIA) para el
Infonavit comprende las areas de negocio
relacionadas al servicio de Informática, con datos del
Infonavit y considera las funciones críticas:
2.- El Análisis de Ambiente (EA) de IT identifica los
requerimientos tecnológicos y la interacción de los
diversos elementos a fin de facilitar la identificación de
una configuración mínima de recuperación.
Se revisa la situación actual y la capacidad de recuperación a
través del análisis de la infraestructura de informática:
instalaciones, hardware, software y comunicaciones, así como
la validación de los procesos de respaldo y restauraciónlos
requerimientos de recuperación y el costo de la contingencia
identificados en el BIA, junto con los requerimientos de IT
obtenidos en el EA, son las variables claves para determinar
las Estrategias de Recuperación.
Costo de Recuperación Tiempo para RecuperarCosto de la Interrupción $$ Duración de la Interrupción
Restauración de
Cintas de Respaldo
Costo Máximo
Tolerable
Costo
Tiempo
Ventana
Costo/Tiempo
Valor Total del NegocioAlta Disponibilidad
74
3.- Durante el Estudio de Alternativas de Recuperación
(RAS) se evaluán las estrategias, seleccionando la más
conveniente para el centro alterno de respaldo, resaltando
las ventajas y desventajas de cada una de las alternativas
de recuperación analizadas y aplicables.
La información recopilada en cada etapa se consolida para
conformar el Plan de Recuperación que satisface la ventana
de recuperación y los niveles de operación aceptables.
Recovery Strategies
Cost/Benefits Analyses
Skills Assessment
File Management AssessmentNetwork AssessmentSecurity AssessmentFacility Assessment
ISM Processes AssessmentDocumentation Assessment
Voice assessment
Recovery Alternatives
/Recommendations
Recovery Assessment
By Business
Function
Maximum Tolerable Outage Cost of outage
Critical Resources
Application priorities
Vital Records
Critical processes
Data Vintage
Análisis de Impacto al Negocio BIA Análisis de Ambiente EA Estudio de Alternativas
de Recuperación RAS
El resultado de las tres fases anteriores es un Plan de
Recuperación en caso de desastres. Se desarrolla el plan de
Recuperación con todas sus fase, retornando a la localidad
original, después de presentarse alguna contingencia que
afecte el soporte de IT.
Se obtendrán los elementos que en su conjunto
representarán la estrategia de protección y
recuperación del Infonavit
Análisis de Impacto en el Negocio (BIA)
Análisis de Ambiente de IT (EA)
Estudio de Alternativas de Recuperación (RAS)
Plan de Recuperación en caso de Desastres
Back up ProceduresRecovery Procedures
Teams &
Responsibilities
Escalation plan
Maintenance Plan
Relocation and Migration plan
Test Plan
Contact ListsEquipment
Inventory
Disaster Recovery
Implementation plan
75
IMPLEMENTACION
La duración estimada de todo proyecto es en semanas, en
donde de manera continua el equipo de trabajo del
Infonavit e IBM realizarán las actividades correspondientes
a cada fase.
1413121110987654321
321TIEMPO/
ACTIVIDAD
PRUEBA
IMPLANTACION
BRP
RAS
EA
BIA
ALCANCEEl alcance resulta y es afinado a lo largo de la definición de los
requerimientos, por los equipos de trabajo IBM y el Infonavit a
través de entrevistas, sesiones de trabajo y cuestionarios.
Entrevistas y sesiones de trabajo
Revisión de la documentación existente
Revisión Técnica de la Infraestructura de IT de Infonavit
Juntas de revisión
Entrega de Recomendaciones
FINDINGS
RECOMMENDATIONS
ACTION PLANS
Presentaciónfinal y entrega de
documentos generados
Cuestionarios
Revisión de Documentación
3. Términos y Condiciones
ENTREGABLESPara el Análisis (BIA) los entregables corresponden a un
documento de análisis del impacto en el negocio, que
incluye la evaluación del impacto durante una contingencia,
priorización de funciones y aplicaciones críticas, ventanas
de recuperación y recursos de usuario mínimos necesarios.
Con la siguiente guía:
INTRODUCCIÓN
PREMISAS
RESUMEN EJECUTIVO
METODOLOGÍA IBM
ANÁLISIS DE LAS ÁREAS DE NEGOCIO
ANALISIS DE IMPACTO
SECUENCIA DE RECUPERACIÓN DE APLICACIONES
HALLAZGOS, CONCLUSIONES Y RECOMENDACIONES
CALIFICACION DEL PROCESO DE CONTINUIDAD
76
Los Entregables en el Análisis de Ambiente de IT (EA) en
base a la revisión de la situación actual son:
Documento de análisis de ambiente incluyendo los
hallazgos, conclusiones y recomendaciones necesarias.
Con la siguiente guía:
INTRODUCCIÓN
PREMISAS
RESUMEN EJECUTIVO
AMBIENTE ACTUAL DE INFORMÁTICA
EVALUACIÓN DEL AMBIENTE INFORMATICO
HALLAZGOS
CONCLUSIONES
RECOMENDACIONES
Los entregables del Estudio de Alternativas de Recuperación
(RAS) son:
Documento de análisis de ambiente incluyendo los hallazgos,
conclusiones y recomendaciones necesarias, con la
siguiente guía:
INTRODUCCIÓN
PREMISAS
RESUMEN EJECUTIVO
AMBIENTE ACTUAL DE INFORMÁTICA
EVALUACIÓN DEL AMBIENTE INFORMATICO
HALLAZGOS
CONCLUSIONES
RECOMENDACIONES:
Los entregables del Plan de Recuperación son:
Documento conteniendo el plan de recuperación de
operaciones, orientado a a superar toda interrupción en los
servicios de informática; incluye la definición de los equipos de
trabajo, la descripción de actividades para la implementación
del plan, políticas de pruebas y mantenimiento. Con la siguiente
guía:
INFORMACIÓN GENERAL DEL PLAN DE RECUPERACIÓN
PARA EL CLIENTE
EQUIPOS DE TRABAJO Y RESPONSABILIDADES
IMPLEMENTACIÓN (EJECUCIÓN) DEL PLAN DE
RECUPERACIÓN
ACTIVIDADES DEL PLAN DE RECUPERACIÓN
ACTIVIDADES POR EQUIPO DE TRABAJO
PRUEBAS DEL PLAN DE RECUPERACIÓN
MANTENIMIENTO DEL PLAN DE RECUPERACIÓN
77
EQUIPO DE TRABAJOEl personal involucrado en la realización de este proyecto
intervendrá de acuerdo a su rol, en los diferentes momentos
en los que por su especialidad y responsabilidades sea
requerido.
Estructura Gerencial del proyecto
Ejecutivo de Proyecto
IBM
Ejecutivo de Proyecto
Cliente
Consultores
de recuperación
Especialistas
Técnicos
Gerente de Proyecto
IBM
Dueños de
Procesos de negocio
Personal
Técnico
Gerente de Proyecto
Cliente
IBM Global Services
© Copyright IBM Corporation 2003
INFONAVIT México - IBM Confidencial
Revisión del Plan de Recuperación
Revisión al 7 de Octubre del 2004
IBM Global Services
© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México
Agenda
Revisión del alcance del servicio general
Revisión de avance
Actividades Pendientes
Siguiente reunión de avance
78
IBM Global Services
© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México
2.Alcance General
Actividad Responsable
1.- Procedimientos de recolección y traslado de respaldos INFONAVIT/IBM
2.- Recolección de respaldos INFONAVIT/IBM
3.- Recuperación de respaldos INFONAVIT/IBM
4.- Procedimiento de mantenimiento al plan INFONAVIT/IBM
5.- Generación de respaldos (Procedimiento) INFONAVIT/IBM
6.- Procedimiento de operación de sistemas INFONAVIT/IBM
7.- Estudio de Aplicaciones Criticas INFONAVIT/IBM
8.- Planificación de pruebas INFONAVIT/IBM
Capacitación de uso de software LDRPS (Living Disarter Recovery Plan System) INFONAVIT/IBM
IBM Global Services
© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México
1. Avance
Actividad % Responsable
Procedimientos de recolección y traslado de cintas 90% INFONAVIT/IBM
Recoleccion de respaldos 100% INFONAVIT/IBM
Procedimiento de recuperación de respaldos 90% INFONAVIT/IBM
Procedimiento para el mantenimiento al plan 90% INFONAVIT/IBM
Aplicaciónes Criticas
-Revisión del estudio anterior
-Identificación de aplicaciones criticas (4)
20% INFONAVIT/IBM
Procedimientos de Generación de respaldos:
-Documentación de estrategia
-Solicitud de información a Raúl Cortes
20% INFONAVIT/IBM
IBM Global Services
© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México
3.Pendientes....
ActividadFecha
compromisoResponsable
1.- Procedimientos de recolección y traslado de respaldos
Entrega del documento
Firma de aceptación de Infonavit
15 OCT
20 OCT
IBM
INFONAVIT
2.- Recolección de respaldos
Revisión de alcance del contrato 14 OCT INFONAVIT/IBM
3.- Recuperación de respaldos
Matriz de escalamiento
Entrega del documento
Firma de aceptación de Infonavit
15 OCT
15 OCT
20 OCT
IBM
IBM
INFONAVIT
4.- Procedimiento de mantenimiento al plan
Entrega del documento
Firma de aceptación de Infonavit
15 OCT
20 OCT
IBM
INFONAVIT
5.- Generación de respaldos (Procedimiento)
Entrega de procedimientos 14 OCT INFONAVIT
79
IBM Global Services
© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México
Pendientes.
ActividadFecha
compromisoResponsable
6.- Procedimiento de operación de sistemas
Se solicitará lo requerido (Proveedores Criticos, Directorio
de personal de usuarios de aplicaciones, Definición de sitios
de reunión, etc)
Entrega de información solicitada
7 OCTIBM
INFONAVIT
7.- Estudio de Aplicaciones Criticas
Lista de aplicaciones actualizada (7 jun / 16 ago)
Solicitud de información a responsables (7 jun / 16 ago)
INFONAVIT
INFONAVIT
8.- Planificación de pruebas Pendiente de cerrar actividades
anteriores
9.-
Fecha Capacitación de uso de software LDRPS (Living Disarter
Recovery Plan System) (Agosto)
Especificar el equipo donde va ha recidir el sofware
Fecha Demo del producto con proveedor
INFONAVIT
INFONAVIT
IBM
10.- Plan de seguimiento de actividades anteriores 14 OCT IBM
IBM Global Services
© Copyright IBM Corporation 200330 de septiembre de 2010 Infonavit México
Junta de seguimiento
Siguiente reunión:
- Lunes 14 de Octubre, 12:00 AM
80
FLUJOGRAMA: RECOLECCIÓN Y TRASLADO DE DE RESPALDOS A IBM
INICIOSe presenta ENOperación de
sistemas de INFONAVIT en días y
horarios convenidos contractualmente
Recibe del personal del
INFONAVIT el oficio en el cual se
relacionan los respaldos
Conjuntamente con personal del
INFONAVIT abren el contenedor y
revisan que lo relacionado en el
oficio corresponda al contenido.
El mismo día de la recolección se
debe entregar el contenedor con
los respaldos en la bóveda de
almacenamiento externo de IBM
Recibe la dos copias del oficio y el
contenedor con los resplados
Revisa que los marbetes, sellos o
candados de seguridad no hayan
sido violados o rotos.
Una vez revisado y verif icado el
oficio V.S. los cartuchos en el
contenedor, f irma de recibido en el
oficio (original y 2 copias)
Mensajería IBM Bóv eda de almacenamiento
Proced.
Recuperación de
respaldos en
caso de
contingencia
Empaca Cartuchos en el
contenedor, y lo cierran
utilizando marbetes,
sellos o candados de
seguridad
Traslada el contenedor con los
respaldos hacia la bóveda de
almacenamiento de IBM
(Nota: respetar y cumpir con los
procedimientos de seguridad de
accesos del Instituto)
Recibe, del personal de
INFONAVIT 2 copias del oficio
firmado por ambas partes
Los sellos, marbetes o
candados del contenedor
han sido violados?
No
Sí
Conjuntamente con personal de
Mensajería abren el contenedor y
revisan que lo relacionado en el
oficio corresponda al contenido.
Firma de recibido en las dos
copias. Se queda con una copia y
el personal de mensajería se
queda con la otra copia
Rcibe. resguarda y administra los
respaldos recibidos con base a sus
procedimientos internos
81
Diagrama del Plan de Acción ( FASE DE PREVENCION)
EQUIPO COORDINADOR
DE RECUPERACION
EQUIPO DE
OPERACIÓN
EQUIPO PLAN.
FISICA
EQUIPOS
TÉCNICOS
PLANEACION A LA
PRODUCCION
Mantener actualizados
los directorios
10
Definir políticas para
situaciones legales
55
Elaborar presupuesto anual
para DRP
65
Resguardar los
respaldos en Bóveda
Externa
25
Identificar manuales de
operación que deban
estar en bóveda externa
35
Mantener actualizados los
directorios
10
Actualizar los Directorios
necesarios para comunicar
la contingencia
15
Contar con planos
estructurales
32
Identificar al Responsable
del Centro de Cómputo
Alterno
40
Mantener actualizados los directorios
necesarios (proveedores, clientes, personal)
Actualizar al personal de cada equipo de
recuperación
Actualizar los requerimientos mínimos y
Registros Vitales
Contar con la documentación de la
configuración de los equipos de su
responsabilidad
Contactar a los proveedores de software
para el uso de licencias de software en el
centro de cómputo alterno
Actualizar el uso de Licencias de Software en
el Centro de Cómputo Alterno
Evaluar el portafolio de aplicaciones críticas
cada seis meses
Documentar los procedimientos de
recuperación de acuerdo a su área de resp.
Obtener passwords para los productos no
IBM en el Centro de cómputo alterno
Validar la actualización de los procedimientos
de recuperación.
Realizar pruebas a los respaldos de
información
Mantener actualizados los
directorios necesarios
(proveedores, clientes,
personal)
10
Verificar la actualización
de los requerimientos
mínimos y registros
vitales
15
Actualizar al personal de
su equipo de
recuperación
25
Contar con copia de los
planes de ejecución en
bóveda externa
30
Asegurar que los respaldos de información
crítica son enviados a la bóveda externa.
Asegurar el Mantenimiento
al plan de Recuperación
10
De acuerdo a los riesgos
Contratar Seguros
45
Asegurar la capacitación de
los Equipos de Recuperación
75
Actualizar al personal de su
equipo de recuperación
15
Actualizar la configuración
del equipo cada 6 meses
20
Contar con la relación
de cartuchos de
respaldos en bóveda
externa
45
Actualizar al personal de su
equipo
15
Revisar los servicios que
mantienen la seguridad
física
20
Revisar los servicios de
emergencia
25
Revisar cada 6 meses las
instalaciones del edificio
30
Revisar las localidades de
recuperación cada 6 meses
35
Actualizar los planes de
ejecución
35
Participar en los
simulacros del DRP
Diagrama del Plan de Acción ( FASE DE PREVENCION)
EQUIPO COORDINADOR
DE RECUPERACION
EQUIPO DE
OPERACIÓN
EQUIPO DE PLAN.
FISICA
EQUIPOS
TÉCNICOS
PLANEACION A LA
PRODUCCION
Contratar servicio de red para DRP con
proveedores
Contar con Manuales de Operación en
Centro de Cómputo alterno
Desarrollar los checklist de evaluación de
desastre
Planear y coordinar la realización de
simulacros en forma periódica
Desarrollar checklist de evaluación del
desastre de acuerdo a su área de resp.
Realizar una consolidación de información
en servidores de recuperación y
documentar
Definir requerimientos de la red para el
DRP
SINIESTRO
Desarrollar el Checklist
para evaluar el
Desastre
40
Planear la ejecución de
simulacros de seguridad
45
Participar en la ejecución
de las pruebas del DRP
50
Revisar la actualización
checklist para evaluación
de desastre
95
Planear y coordinar la
realización de pruebas del
plan
120
Definir políticas de
activación del DRP
125
Preparar y notificar fecha
de simulacros a los equipos
de recuperación
135
Participar en la ejecución
de las pruebas del DRP
140
Elaborar checklist
para evaluar el
desastre
50
Documentar y
actualizar
procedimiento de
IPL
55
Documentar y
actualizar
procedimiento de
IPL
55
Participar de manera
activa en los
simulacros de DRP
65
Diagrama del Plan de Acción ( FASE DE RESPUESTA)
EQUIPO COORDINADOR
DE RECUPERACION
EQUIPO DE
OPERACIÓN
EQUIPO DE PLAN.
FISICA
EQUIPOS
TÉCNICOS
PLANEACION A LA
PRODUCCION
Declarar el Desastre
Notificar el Desastre
SINIESTRO
Establecer
Comunicación con los
Equipos
Contactar Servicios de
Emergencia
y Asistencia Médica
Solicitar la Evaluación del
Impacto del Desastre
Es un Desastre
Obvio ?
Evaluar la disponibilidad
del personal
asignado al Centro de
Cómputo alterno
Establecer
Comunicación con los
Equipos
Notificar el Desastre
Si
Solicitar la Evaluación del
Impacto del Desastre
Es técnico
y/o problema físico
severo ?
Evaluar la disponibilidad
del personal
asignado al Centro de
Cómputo Alterno
Establecer Comunicación
con los Equipos
Continuar Proceso Resolución
de Problemas (Matriz de
Escalamiento)
Solución < 72 hrs.
Corrige falla
Regreso a
Operación
Normal
Si
No
No
No
No
Si
Evaluar la disponibilidad
del personal
asignado al Centro de
Cómputo alterno
Si
82
Diagrama del Plan de Acción ( FASE DE
RECUPERACIÓN)
EQUIPO COORDINADOR
DE RECUPERACIÓN
EQUIPO DE
OPERACIÓN
EQUIPO DE PLAN.
FISICA
EQUIPOS
TÉCNICOS
PLANEACION A LA
PRODUCCION
Realiza actividades de
atención a la emergencia
10
Asegurar que todos los
integrantes han sido
notificados sobre el
desastre
Apoyar al personal que
haya resultado herido
40
Desarrollar plan de trabajo
para renovar el equipo o
instalaciones
60
Trabajar con los proveedores
de equipo para su
reconstrucción
80
Registrar en bitácora las
desviaciones
62
Asegurar que todos los
integrantes han sido notificados
sobre el desastre
10
Hacer la evaluación del desastre
y determinar daños
Tomar las acciones apropiadas para
restablecer el Centro de Cómputo
Primario
Solicitar requerimientos de equipo
necesarios para reestablecer
comunicaciones, u otros equipos
Trasladarse al centro de cómputo
alterno
Ir por los respaldos y registros vitales
de la bóveda externa
Recuperar e sistema en el Centro de
Cómputo (producción y WEB)
Recuperar los servidores en el centro
de cómputo alterno
Solicitar los registros
vitales a la bóveda
externa
25
Prepara noticias que serán
liberadas a medios de
información
40
Asegurar que todos los
integrantes han sido
notificados sobre el
desastre
10
Establecer acuerdos con los
líderes de equipos de
recuperación
130
Registrar en bitácora las
desviaciones así como las
acciones tomadas
132
Mantener contacto con las
unidades de negocio para
notificar la situación
135
Coordinar solución de
problemas legales
140
Contactar empresas de
seguros
78
Contactar proveedores
de servicio para
restaurar Centro de
Cómputo
25
Obtener de la bóveda
los respaldos y
manuales de operación
90
Restaurar el ambiente
de producción
100
Restaurar el ambiente
WEB
120
Coordinar los
suministros con
proveedores
150
Realizar los respaldos
de información
y enviar a bóveda
170
Validar el daño a la
localidad y a sistemas de
soporte
35
Operar con los procedimientos
diseñados en la etapa anterior
Asegurar que todos los
integrantes han sido
notificados sobre el
desastre
10
Informar a los proveedores,
usuarios la situación de
desastre
17
Definir acciones a
seguir para los
procesos batch
40
Diagrama del Plan de Acción(FASE DE REANUDACIÓN Y
RECUPERACIÓN)
EQUIPO COORDINADOR
DE RECUPERACIÓN
EQUIPO DE
OPERACIÓN
EQUIPO DE PLAN.
FISICA
EQUIPOS
TÉCNICOS
PLANEACION A LA
PRODUCCION
Verificar que los accesos a los
equipos y BD trabajan
adecuadamente
Dar seguimiento a los acuerdos
establecidos por los líderes de los
equipos de recuperación
Reconstrucción del Centro de
Cómputo primario
Registrar en bitácora los problemas
presentados y las acciones tomadas
Registrar en bitácora
actividades así como
problemas detectados
47
Ejecutar las alternativas
para actualizar la
información de respaldos
40
Iniciar la operación de las
aplicaciones críticas
60
Entrega del producto
final al usuario y
esperar el VoBo
70
Obtener aprobaciones de
autoridades civiles
95
Registrar en bitácora las
desviaciones presentadas
187
Dar seguimiento a las
actividades de
Reparación al Centro de
Cómputo
190
Trabajar con los equipos
técnicos para la
reocupación del Centro
de Cómputo
85
Establecer fechas
compromiso para
restaurar el Centro de
Cómputo
150
Diagrama del Plan de Acción ( FASE DE RESTAURACIÓN)
EQUIPO COORDINADOR
DE RECUPERACIÓN
EQUIPO DE
OPERACIÓN
EQUIPO DE PLAN.
FISICA
EQUIPOS
TÉCNICOS
PLANEACION A LA
PRODUCCION
Declarar la terminación del
desastre
15
Evaluar el plan de acción y
desempeño de los equipos en el
proceso de continuidad y
reanudación
60
Evaluar el plan de
acción y desempeño de
los equipos en el
proceso de continuidad
y reanudación
120
Informar la estabilidad de la
infr. De equipos estratégicos
para garantizar la operación
10
Evaluar el plan de acción y
desempeño de los Equipos
en el proceso de
continuidad y reanudación
12
Contactar autoridades
civiles para implantar
procedimientos
15
Realizar plan de trabajo para
regreso de operación
Entregar los registros vitales
Supervisar la toma de
respaldos
Borrar información del Centro
de Cómputo alterno
Restaurar los ambientes de
producción y WEB
Aplicar checklist de validación
de ambientes
Evaluar el plan de acción y
desempeño de los Equipos
en el proceso de continuidad
y reanudación
Entregar los registros
vitales
5
Validar ambiente
productivo
20
Evaluar el plan de acción
y desempeño de los
Equipos en el proceso de
continuidad yreanudación
40
FIN
Terminar operaciones en el centro
de cómputo alterno
20
Controlar y enviar los registros
vitales a la bóveda externa
35
Solicitar a la aseguradora la
remuneración de daños
55
Implantar cambios a
procedimientos
65
Verificar el plan de pruebas y los
alcances
75
Entregar los requerimientos
mínimos y registros vitales
15
Respaldar información del
ambiente de producción y
WEB
40
Enviar respaldos y
documentación al centro
cómputo primario
50
Restaurar los ambientes de
producción y WEB
90
Actualizar los
procedimientos
125
Actualizar procedimientos
20
Actualizar procedimientos
Revisión de procesos y
decidir acciones a tomar
30
Actualizar procedimientos
45
83
2.13 Conclusiones Administración de Proyectos Sinceramente la metodología de administración de proyectos antes mencionada es de gran utilidad para llevar adecuadamente un proyecto.
84
Me gustaría solo comentar algunas cosas que creo relevantes: a.- Cuando se nos asigne un proyecto es importante saber que es exactamente lo que se esta esperando de nosotros, y el nivel de autoridad que tendremos en el mismo, posiblemente en algunas organizaciones los recursos que estén bajo nuestro cargo tienen su jefe administrativo, es importante dialogar con el y el equipo de trabajo para que todos tengan claro la forma de trabajar. b.- Revisar con el cliente el contrato antes de empezar su ejecución, para asegurarnos que los dos estamos esperando lo mismo c.- Realizar la reunión de Kickoff, en donde se generará la minuta de arranque donde se plasmara de forma general cuales son los canales de comunicación, quienes son los responsables por ambas compañías y listar los primeros compromisos c.- Una vez empezado el proyecto e identificado a los participantes y definido el alcance revisar o generar el plan de trabajo el cual deberá de ser autorizado por el cliente y mostrado a los participantes para que todos estén esterados de las fechas y quienes son los responsables de las actividades También es importante hacer la carpeta de control de proyectos con la documentación mas importante del proyecto, con una pestaña de control financiero. Si hay gastos de viáticos, sugiero llevar un a carpeta complementaria, el manejo de los proveedores deberá de quedar en la carpeta principal junto con los contrato o acuerdo tomados con ellos. d.- Documentar semanalmente o quincenalmente el avance del proyecto, en caso de desviaciones también deberán de quedar asentadas aquí, en caso de que los contratiempos ocasionen un incumplimiento del plan de trabajo, es necesario generar un control de cambios el cual se debe de documentar y ser aprobado por el cliente (En caso de que el cliente no lo apruebe también se debe de documentar y la razón) e.- Asegurarse de cumplir con los entregables del contrato, si el cliente desea cambiar alguna actividad ya definida previamente, se deberé de documentar con un control de cambios, de igual forma si el cliente nos pide algo adicional sin importar si afecta o no el plan se deberá de evaluar y definir si se realiza dentro de este proyecto o mejor se genera un proyecto en paralelo para realizar esta actividad, les sugiero que por ningún motivo se retrase las fechas de un proyecto a no ser que sea por causa mayor y que este correctamente documentado. f.- Es importante que se revise periódicamente los gastos, la facturación con el cliente para que sepa cuanto se ha gastado y según lo planeado cuanto más se ira gastando, en caso de que se gaste más de lo planeado se deberá de generar un control de cambios documentándolo y deberá de ser aprobado por el cliente.
85
g.- En los reportes de avance que se tenga con el cliente se deben de ir marcando las tÁreas terminadas y si se ha cumplido con el contrato. h.- Antes de cerrar el proyecto revisar con el cliente que efectivamente se cubrieron los puntos acordados tanto en el contrato como durante el proyecto, y si algún punto no se quedará cubierto presentarle al cliente la razón y la documentación del por que no. i.-Generar carta de terminación y realizar la encuesta de satisfacción, para saber que tan satisfecho esta el cliente con nuestro trabajo. En caso de que el proyecto duré más de 6 meses, se recomienda hacer una encuesta de satisfacción a la mitad del proyecto o al término de cada fase. Anexo algunos formatos que considero importantes para manejar un proyecto y algunos de evaluación. Dentro de IBM tuve la fortuna de administrar varios proyectos.
86
Conclusiones. Con todo lo antes expuesto, creo que he comprobado mi experiencia dentro del área de informática por los últimos 15 años, he aprendido muchas cosas y siento que aun me falta muchas más por aprender y certificarme. Considero que en la vida de todo Licenciado en Informática debe de entender que hay tres cosas que siempre deberá de considerar.
- Siempre hay un cliente que tiene algún problema y que requiere de nuestra ayuda, la destreza y conocimientos de cada uno será la diferencia de satisfacción del cliente
- Siempre necesitaremos de un equipo de trabajo el cual será nuestro apoyo para el éxito de un proyecto
- Nosotros somos parte del equipo de trabajo y necesariamente debemos de aprender a comunicarnos claramente.
87
Bibliografía
- Documentación proyectos IBM DE 1997 – 2002 v1.5 - Metodología Conversión año 2000 IBM - Management Empresarial El diario Financial Times (Chile) - Project Management Body of Knowledge (PMBOK Guide) - Project Management Fundamentals v2.4 IBM
- Project Management
http://img.redusers.com/imagenes/libros/lpcue024/capitulogratis.pdf
88
ANEXOS Formato de Kickoff
Fecha y Lugar Tipo de Reunión Horario Participantes Agenda Narrativa
_________________________________________________ Julio 04, del 2000. Banco Santander Mexicano Manuel Avila Camacho 170 1er. Piso Col. Lomas San Isidro CP 11620 _________________________________________________ Kickoff. _________________________________________________ 11.30 - 13.00 hrs _________________________________________________
Nombre
Puesto
Siglas
Emilio Porras Alonso
Gerente de Proyecto Santander
EP
Wuilbert Martinez
Soporte
WM
Jose Luis Quiroz
Gerente de Proyecto IBM
JLQ
1. Presentación del equipo de trabajo 2. Solicitud de requerimientos por parte de IBM LAC presento a los nuevos integrantes del quipo de trabajo quedando conformado de la siguiente forma: Gerente de proyecto por parte de Santander Emilio Porras Alonso
89
Gerente de proyecto por parte de IBM 2. Solicitud de requerimientos por parte del proveedor 3. Revisión del plan de trabajo 4. Revisión de requerimientos
Acuerdos 1.- EP estuvo de acuerdo con los integrantes del equipo de trabajo y la forma de comunicación en ambas partes.
Compromisos 1.- EP quedo de enviar la lista de la gente que participará por parte del Banco. …..
90
Formato de Minuta
Fecha y Lugar
Julio 20 de 2000. BBVA Madrid, España
Tipo de Reunión
Reunión de Trabajo.
Horario 09:00 – 18:00 hrs Participantes BBVA Área IBM Latinoamérica Arturo Gil Sistemas
Operativos
Luis Enrique Sanchez
Patricia García DB2/UDB Jorge Combes Maria Lucero
García NES Jorge Benitez
José María Rodriguez
Comunicaciones José Luis Luna
Emilio Delgado MQSERIES/XCOM
Jorge Yaqui
Agenda Software Base – AIX, SOLARIS HACMP
Tivoli Websphere Application Server, Netscape Enterprise Server,
DB2/UDB: Narrativa TEMA: Reunión. Software Base (AIX, SOLARIS), HACMP, Java
Run Time, Tivoli: 1.- AIX. Y S.O. SUN. HACMP. 2. TIVOLI. Los contactos directos para aclaración de dudas será: -
Acuerdos AIX.
Compromisos Software Base (AIX, SOLARIS), HACMP, Java Run Time, Tivoli:
91
Formato de Reporte de Seguimiento Ing. Juan Carlos Zurita Por medio de la presente le hago llegar el reporte semanal de las horas trabajadas del periodo 4 de Enero al 6 de Enero del 2001 para el Proyecto “Banca a Distancia”.
Nombre Actividades Horas
Jorge Combes Soporte aplicatvo Revision de configuración actual Reunión de trabajo …..
28 horas
Patricia Armendariz
Reinstalación de Network Dispatcher …..
10 horas
Jorge Benitez / Mikalonis
Revisión de ambiente …
28 horas
José Luis Quiroz Revisión con BBVA Bancomer del avance que se tiene en el proyecto
…
18 horas
Total de horas 84 horas
Informe de avance. Seguridad Mqseries Aplicación….
Conclusiones:…….
Pendientes: Seguridad……. Aplicación.…… Atte. Autorizo ______________________ ________________________ José Luis Quiroz Lechuga Ing.Juan Carlos Zurita Project Manager IBM Líder de proyecto BBVA Bancomer
92
Control de Cambios
FORMATO DE SOLICITUD DE CAMBIO No ___2
CLIENTE BBVA Bancomer S.A.
PROYECTO Banca a Distancia
SECCIÓN 1: DESCRIPCIÓN DEL CAMBIO Requerimiento que afecta: Cambio en cronograma
Descripción del Cambio: De acuerdo a la solicitud de BBVA Bancomer
Se detiene el proyecto a partir del 29 de septiembre del 2000, estimando reiniciarlo el 10 de
Octubre del 2000. Debido a que el desarrollo del aplicativo no esta terminada por BBVA España,
Y la infraestructura esta casi terminada, se detendrá hasta que el aplicativo este listo.
José Luis Quiroz Lechuga IBM 2-Oct-00 Nombre Firma Compañía Fecha
SECCIÓN 2 : ANÁLISIS DEL CAMBIO Costos Estimados $ 0 Evaluado Por Juan Carlos Zurita Tiempo Estimado 0 hrs Fecha 2 de octubre del 2000 Solución Propuesta: Esperar que el aplicativo este listo para continuar con la
puesta a
Punto de la infraestructura y probar con el aplicativo. Se acordó continuar con la configura-
……….
Parte del Contrato que Modifica: Cronograma
SECCIÓN 3 : DEFINICIÓN DEL CAMBIO Aprobado Si. Rechazado Diferido Juan Carlos Zurita BBVA Bancomer 2-oct-00 Nombre Firma Compañía Fecha
Sergio Mendoza BBVA Bancomer 2-Oct-00 Nombre Firma Compañía Fecha
93
Plan de trabajo Formato de un proyecto
94
Formato de Cierre Ing. Juan Carlos Zurita Le informo que de acuerdo al anexo “Banca a Distancia” Number Contract MXAAAYY Work Number MXABAY del contrato firmado entre IBM de México y Bancomer S.A. No 3098000171. Se da por terminado satisfactoriamente la instalación y configuración de la infraestructura con la aplicación BBVNET: Entre las Áreas relevantes realizadas en esta Fase II fueron: 1- Se instalo la versión del aplicativo 1.0 enviado por España y se hicieron pruebas de a travez de la infraestructura validando cada uno de los componentes instalados los cuales se pusieron a punto y se dejaron funcionando. 2.- Se instalo la nueva imagen del aplicativo y se hicieron pruebas de volumen en el ambiente productivo con una transacción y que esta funcionamiento, pero al mandar 10 usuarios concurrentes con 10 transacciones no se recibió respuesta de host y se continua revisando para identificar cual es el problema. 3.- Se integro el equipo de operadores que darán el servicio de 7 x 24 a partir del 12 de enero y se les dio una inducción de los productos instalados. Ellos solo son responsables de la operación, en caso de algún problema seguirán la matriz de escalamiento. 4.- Se entregó un draft de la documentación de la operación de los productos instalados en los equipos IBM. Se esta trabajando en la ultima versión. 5.- Se continua haciendo pruebas para identificar donde están las demoras en los tiempos de respuestas. 6.- Se entregó el ambiente estable aunque falta por terminar hacer pruebas Pido de favor firme al calce dando por finalizada la fase II del proyecto, así como satisfactoria los entregables marcados en el anexo del contrato firmado entre IBM y Bancomer. Atte. Acepto ______________________ ________________________ José Luis Quiroz Lechuga Ing.Juan Carlos Zurita Project Manager IBM Líder de proyecto BBVA Bancomer
95
Formato de Carta de Terminación Ing. Carolina Santana Me es grato informarle que el proyecto “Instalación del VTS” OMSYS ha concluido satisfactoriamente, terminándose las actividades marcadas en el plan de trabajo. Se dio la capacitación información transfiriendo los conocimientos del proceso satisfactoriamente. Solo me queda agradecerle las facilidades brindadas para el éxito de este proyecto y quedo a sus ordenes para cualquier otro requerimiento que necesiten. Por favor firme al calce de aceptación servicios y cumplimiento con todos los entregables marcados en el contrato. Atte. Acepto ______________________ ________________________ José Luis Quiroz Lechuga Ing.Carolina Santana Project Manager IBM Líder de Proyectos EDS
96
Formato de Encuesta de satisfacción del cliente Le agradeceremos se tome algunos minutos para describir su nivel de satisfacción con el desempeño de nuestro equipo de trabajo en el proyecto: “ “ Su retroalimentación nos ayudara a mejorar nuestro servicio. ¿ Que tan satisfecho esta? :
1. De que IBM cubrió sus expectativas en todo lo relacionado al contrato o proyecto.
Comentario.______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión
2. De que IBM entendió las necesidades de su negocio en el diseño de este contrato o proyecto?
Comentario.________________________________________________________________________________________________________________________________________________________________________________________________________________________________
( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión
3. De que IBM mantuvimos comunicaciones claras durante todas las fases del contrato o proyecto?
Comentario.______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión
4. Con las habilidades de la gente que trabajó en este contrato o proyecto?
Comentario.____________________________________________________________________________________________________________________________________________________________________________________________________________________________
( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión
5. Con el valor recibido por ustedes en relación con la inversión que hicieron en este contrato o proyecto?
Comentario.______________________________________________________________________________________________________________________________________
( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy
97
_______________________________________________________________________________________________
Insatisfecho ( ) 0 Sin Opinión
6. De que este contrato o proyecto fue administrado eficazmente?
Comentario.______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión
7. De que cumplimos los compromisos que hicimos respeto a la ejecución de los servicios o entrega e instalación de los productos?
Comentario._____________________________________________________________________________________________________________________________________________________________________________________
( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión
8. Si requiriera servicios adicionales en el futuro, escogeria a IBM como su proveedor?
Comentario.______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión
9. Considerando todos los aspectos del contrato o proyecto, la solución, la gente y la entrega de la solución, por favor díganos su nivel general de satisfacción.
Comentario._____________________________________________________________________________________________________________________________________
( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión
10. Basado en su experiencia en este contrato o proyecto. ¿Recomendaría a IBM a otros? Comentario.______________________________________________________________________________________________________________________________________________________________________________________
( ) 5 Muy Satisfecho ( ) 4 Satisfecho ( ) 3 Ni satisfecho Ni insatisfecho ( ) 2 Insatisfecho ( ) 1 Muy Insatisfecho ( ) 0 Sin Opinión
11. Le gustaría que IBM lo contactará acerca de los resultados de esta encuesta?
( ) Si ( ) No
98
Nombre :_______________________________________ Puesto: ______________________ Número Tel.: _______________ Firma: ______________________ Fecha: ________________ A ser completado por el entrevistador: Razón Social del Cliente: _______________________________________________________________ Proyecto: _______________________________________________________________ Línea de Servicios: ______________________ Fecha del proyecto __/__/__ - __/__/__ Número de contrato (De aplicar): _______________ Número de Cliente ___________ GB __________ Nombre del Entrevistador : _________________________________________