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
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
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.
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.
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
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.
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
Á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.
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,
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
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.
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.
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
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
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.
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.
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.
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
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.
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.
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
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.
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
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.
• 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.
• 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.
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.
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.
NATURAL.
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
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.
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
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:
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.
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
- 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
