Soy una persona que se adapta. Disfruto de los cambios y los desafíos. Pero, últimamente, me he sentido como si estuviera viajando por el hiperespacio en el Halcón Milenario de Han Solo.

En la última década, la lista de avances en el campo de TI parece una broma del tipo "buenas noticias/malas noticias": si bien las pantallas verdes del sistema CICS basadas en mainframe y de administración centralizada prácticamente se han extinguido, nunca han sido el blanco de ataques de hackers. Cuando el control estaba centralizado, los usuarios de estaciones de trabajo personalizables no llamaban a la mesa de ayuda para quejarse de que no veían la pantalla de inicio de sesión (después de haber aumentado la resolución de pantalla más allá de lo razonable).

Además de los cambios en la informática centralizada de tipo "glass house", hacemos frente a la informática inalámbrica, con dispositivos portátiles que realizan funciones para las que antes se necesitaban conexiones por cable y otras innovaciones "du jour".

Tomemos como ejemplo el correo electrónico. Hace dos años, los estudiantes de George Washington University aprovechaban cada oportunidad que tenían para revisar sus cuentas de correo electrónico. Hoy, el correo electrónico está pasado de moda, y ha sido reemplazado por otras tecnologías, como la mensajería instantánea, los mensajes de texto, los blogs y Facebook, que ofrecen comunicación de punto a punto, minuto a minuto. Cuando algo nuevo se pone de moda, los estudiantes aprenden a usarlo incluso antes de que nuestro equipo de TI se entere de que existe. Además, las universidades no pueden prohibir los dispositivos. Solamente podemos colocarlos en la lista de "no respaldados".

Administración de entornos complejos

Los entornos que administramos en la actualidad nos permiten brindar servicios a los usuarios que en el pasado resultaban imposibles. Sin embargo, los numerosos nuevos productos y utilidades de TI que se necesitan para prestar este servicio ampliado han creado un entorno cuya administración es sumamente compleja.

En George Washington University, utilizamos el sistema ERP Banner, de la serie Higher Education de SunGard, y el sistema ERP Oracle Financials. También estamos implementando la serie de productos Documentum® de EMC en toda la empresa. El sólo hecho de programar upgrades y pruebas es complicado, debido a los ciclos del negocio de la universidad en cuanto a los procesos de selección, ingreso, asistencia financiera, inscripción, alojamiento, etc,, y las operaciones del año fiscal que deben realizarse, por ejemplo, para los informes al gobierno federal. Nuestro análisis más reciente demostró que el período de upgrade ideal es el quinto jueves de marzo de los años bisiestos.

Eso en lo que respecta a los sistemas a los que acceden los usuarios. Las bases de datos, los servidores, los sistemas operativos, los sistemas de utilidades, el SAN y el software de backup tienen ciclos de actualización específicos. George Washington University posee entornos de prueba y desarrollo para cada aplicación y servidor de producción; administra data centers duales con soporte mutuo. Aún así, es difícil encontrar el momento menos complicado para implementar un componente.

Además, incluso cuando se supone que el enfoque de TI está cambiando hacia arquitecturas orientadas al servicio, tanto las cargas de trabajo de los usuarios finales para comprender nuevas funciones de software como las pruebas y la configuración que realizamos de dichas funciones exigen un mayor compromiso por parte de todos los involucrados. (Todavía no me ha pasado que un jefe de departamento me pida que deje de simplificarle las tareas que debe realizar). Sin embargo, algunas empresas líderes en la industria de TI están desarrollando componentes plug-and-play para ayudarnos a realizar cambios en la infraestructura sobre la marcha y que no requieren un grado de participación del usuario final riesgoso e insostenible.

Énfasis en la cooperación para la realización de pruebas

Para implementar nuevas versiones y upgrades de clase ERP, desarrollamos (y estamos perfeccionando) un proceso que pone énfasis en la cooperación para la realización de pruebas entre los usuarios y el equipo de TI.

Durante el primer tercio de un proyecto, nuestro equipo de TI analiza el contenido de la nueva versión e identifica los principales cambios y mejoras. El equipo se prepara de muchísimas formas para realizar pruebas exhaustivas; por ejemplo, organizan servidores y bases de datos, realizan pruebas en clientes de escritorio, analizan la seguridad y preparan scripts centrales para las pruebas de usuarios finales. Cada hora que se invierte en la preparación da como resultado un análisis más exhaustivo y un menor impacto en las operaciones del campus.

Luego, el equipo de TI capacita a los "usuarios avanzados" de oficinas críticas en el uso de las nuevas características y les enseña a capacitar a los usuarios finales. Los usuarios avanzados aplican scripts de prueba de TI, el conocimiento de sus operaciones y de la versión anterior del software para analizar y verificar la precisión de la funcionalidad "nueva y mejorada".

Se registran todas las anomalías. Algunas de ellas son problemas reales, otras son malentendidos y otras son anomalías de los scripts de prueba. Por lo general, las anomalías surgen de informes que se refieren a elementos de bases de datos modificados, interfaces o pasos de navegación desconocidos, o modificaciones que identifican factores previamente aceptados. Nuestros programadores trabajan junto con el proveedor de ERP para investigar todos los problemas. Normalmente, se solucionan con rapidez y se reenvían a los usuarios para su confirmación.

En la última etapa, los representantes de los usuarios principales aprueban el upgrade, y un comité ejecutivo de nivel C confirma la aprobación. Se realizan ajustes de los últimos detalles técnicos y se migra el software a producción. Se da comienzo al plan de transferencia (es un plan sumamente detallado, por lo general, en incrementos de fracciones de horas) y el sistema se pone en ejecución en una fecha y hora específicas.

Es necesario seguir un proceso de este tipo debido a los miles de usuarios de la universidad, las ventanas limitadas para implementar cambios importantes en el sistema y la gran inversión de tiempo y esfuerzo requerida para implementarlos. En el caso de revisiones de seguridad o de upgrades de bases de datos menos intensivas, aplicamos una versión de menor escala del proceso para confirmar que el sistema funcione como antes, aunque de manera más eficaz o segura.

Nuestra atención a los detalles nos permitió actualizar varios sistemas de clase ERP sin necesidad de volver a la versión anterior por problemas imprevistos. Sin embargo, cada plan de upgrade incluye una fecha de contingencia en caso de que surjan imprevistos a último momento. Esta fecha (que, por lo general, se planifica para dos semanas posteriores, como máximo) disminuye la presión psicológica de tener que llevar a cabo el upgrade independientemente de los riesgos. Además, ofrece una alternativa lógica y práctica para las personas a cargo de la toma de decisiones. El hecho de eliminar la presión da como resultado un análisis de riesgos más pensado.

Bill Gates habría dicho: "Si General Motors hubiese seguido el ritmo de la tecnología como lo hizo la industria de la informática, todos tendríamos automóviles de US$ 25 que rendirían más de 400 Km/l (o 1.000 mpg)". Sin embargo, si la industria automotriz lanzara al mercado tantos cambios como la industria de TI, tendríamos que enviar nuestros vehículos al taller en enero para el reemplazo de neumáticos, en febrero para el cambio de bolsas de aire y en marzo para los nuevos frenos de cerámica.

Como industria, nuestros entornos de TI nunca serán menos complejos. Pero, a medida que realizamos cambios, podemos minimizar el impacto para los usuarios finales. Todos queremos brindar un servicio más eficaz a nuestros usuarios finales. Debemos concentrarnos en reducir el impacto negativo no planeado de los cambios positivos.