|
|
|
|
| INTRODUCCIÓN |
Retomamos en el presente informe el tema, intentando ahora ofrecer una visión general del espectro de soluciones que pueden darse (y que de hecho ya le están dando las instituciones más previsoras) al problema que nos ocupa; sus particularidades, la definición de proyectos, los aspectos a tener en cuenta según la metodología empleada y algunas sugerencias para los que aún no han iniciado la tarea, serán algunos de los tópicos a tratar.
Resumiendo el citado informe, y a modo de introducción al presente, el planteamiento del problema del año 2000 puede ser realizado en los siguientes términos:
| TRATAMIENTO |
Específicamente en el ámbito empresarial, deben tenerse en cuenta las siguientes áreas fundamentales a atacar:
El primer paso, como en todo proyecto de I&D, será el estudio de la situación actual en el mercado, qué están haciendo las otras empresas, qué productos hay para ayudar a desarrollar el proyecto, qué metodologías se han desarrollado y cuáles han sido sus ventajas y desventajas según el caso, y todo otro aporte que pueda encontrarse en la bibliografía gráfica o electrónica. Es importante en este estadio del proyecto, relacionarse con otros responsables de proyecto Año 2000, ya sea asistiendo a Congresos y Seminarios sobre el tema, o por medio de la participación en foros especializados.
· Estado Actual
Antes de iniciar las tareas orientadas a solucionar el problema de lo que la empresa tiene ya en funcionamiento, conviene efectuar algunas especificaciones sobre las nuevas adquisiciones de tecnología que la misma haga de ahora en más; esta conveniencia estriba en la posible incorporación, durante el desarrollo del proyecto y aún a posteriori, de equipos y programas informáticos, los cuales si no tienen cierta norma de adquisición pueden ocasionar nuevos problemas a los ya existentes.
Debe establecerse si la empresa ya ha tomado sus recaudos frente a esta problemática de nuevas contrataciones.
· Incidencia
Como ya se indicó, la compra de nuevo hardware y/o software sin el adecuado control respecto de su buen funcionamiento para fechas posteriores al 31/12/1999, producirá vacíos dentro del Proyecto Año 2000 encarado, dejándolo desactualizado sin siquiera darnos cuenta.
· Acciones
Específicamente hablamos de determinar un mínimo procedimiento de "Certificación de compatibilidad con el año 2000" para cualquier equipo o programa que se compre (pruebas establecidas claramente por el responsable del proyecto según el producto de que se trate) y el establecimiento de cláusulas contractuales estándares (elaboradas por los abogados de la empresa en conjunto con el responsable del proyecto), que indiquen esta exigencia de compatibilidad a los proveedores de los mismos, fehacientemente.
Es un tema escabroso. Ninguna norma de "Certificación Año 2000" ha demostrado ser absolutamente segura hasta el presente, pero con solo tener presente el tema y discutirlo con el proveedor, se logran buenos resultados (y en última instancia, los letrados de la empresa se encargarán de hacérselo recordar de presentarse luego problemas).
Como referencias sobre este tema, pueden consultarse las cláusulas
y notas propuestas por la Oficina del Proyecto 2000 del gobierno
del Estado de Texas (www.dir.state.tx.us/y2k/resources/Y2KGuideApx.htm)
y la "Norma Año 2000" del Instituto Británico de Estándares
(que establece en cuatro reglas generales lo que un sistema informático
debería cumplir para asegurar su transición al año
2000 sin problemas).
· Estado Actual
Todo equipamiento en funcionamiento en la empresa, que tenga de alguna
forma incorporado algún microprocesador o dispositivo programable/configurable,
debe ser relevado. Se debe confeccionar para los mismos una ficha técnica
en donde se especifiquen sus características principales y su uso
(tipo, marca, modelo, memoria, canales, conexiones, utilización
primaria, software instalado, etc.) y anotado en una planilla de equipamiento
inventariado, que a modo de ejemplo, podría contener los siguientes
datos:
|
|
|
|||||
|
|
|
|
|
|
|
|
· Incidencia
Para cada equipo relevado debe determinarse cómo incide un mal funcionamiento del mismo en el desarrollo de las actividades usuales de la empresa. Si interviene en algún procedimiento crítico, deberá asignársele mayor prioridad (columna PRI de la planilla anterior) a su prueba y resolución del problema, en caso de existir. Equipos destinados a procedimientos no críticos tendrán menor prioridad; esta determinación debe ser realizada concienzudamente para asegurar el correcto funcionamiento de la empresa toda al llegar el 2000.
· Acciones
Las acciones generales a desarrollar en el área de equipamiento son entonces:
Según los tipos de dispositivos controlados, los problemas pueden no existir, existir y no importar (un mal pase de año desde el 1999 al 2000 con la máquina encendida, en una empresa que no trabajará el 31/12/1999 por la noche), requerir un cambio menor (cambio del BIOS en ciertas PC) o necesitar un recambio completo, en el caso más desfavorable.
En el caso de cambio menor o recambio completo, debe tenerse en cuenta
el convenio firmado con el proveedor. Es posible que exista alguna garantía,
o que ya se trate de un equipamiento comprado con la cláusula de
"Compatibilidad
2000" incorporada.
No sólo se deben preparar los programas utilizados para el año 2000, sino que la empresa debe seguir funcionando hasta que llegue el bendito año, por lo cual los sistemas en ejecución deben seguir siendo adecuados a las distintas realidades que impone el mercado, requiriendo frecuentes modificaciones que colisionarán con las del Proyecto Año 2000.
· Estado Actual
De igual forma que con el equipamiento, todo el software en funcionamiento
en la empresa (y hablamos de TODO: sistemas operativos, sistemas de aplicación,
herramientas de productividad de oficina, programas de automatización
fabril, de telecontrol, etc.) debe ser relevado y debidamente anotado en
una planilla de inventario de tipo similar a la siguiente:
|
|
|
|||||
|
|
|
|
|
|
|
|
Donde en el apartado "Descripción" debe indicarse fabricante, modelo, versión, tipo de producto, plataforma sobre la que corre, proveedor, máquina en la que está instalado, y todo otro dato que el responsable del proyecto crea conducente a establecer su prioridad y posibles problemas con el manejo de fechas.
En particular, para los sistemas de aplicación desarrollados por la empresa o por terceros, debe indicarse por separado cada programa componente con su nombre, versión, función resumida y qué archivos o estructuras de almacenamiento de cualquier tipo utiliza. No deben escapar a este escrutiño, los procedimientos por lotes del sistema operativo (JCL), en especial los referidos a ejecuciones programadas en el tiempo y los correspondientes a resguardos de información.
· Incidencia
El mal funcionamiento de los sistemas operativos o de aplicación de la empresa, puede dejar a la firma fuera de servicio por completo en alguna fecha crítica, lo que ocasionaría evidentes daños monetarios.
Pero peor aún será el caso, si todo aparenta funcionar correctamente y luego de algún tiempo, se descubre que los cálculos han fallado. El daño ya se habrá producido y, probablemente, se habrá propagado a clientes y proveedores, ya sea por erróneos cálculos de vencimientos e intereses o por la transmisión de archivos con fechas en mal estado. No sólo se expone la empresa a pérdidas económicas, financieras y comerciales, sino a problemas legales !!!
Es muy difícil predecir las consecuencias de estos problemas y, en realidad, dependerán de qué tantas transacciones procese la empresa (y qué monto involucren las mismas) antes de identificar y solucionar el problema producido.
La determinación de cuáles son los procesos críticos del negocio es, valga la redundancia, crítica.
Pero hemos hablado de los inconvenientes de la empresa en su conjunto al no encarar el problema del año 2000 a tiempo, desde el punto de vista del negocio.
Informáticamente hablando, y al encarar el problema que nos ocupa, la incidencia en los programas y sistemas de aplicación debe determinarse efectuando una inspección de código, para lo cual puede ayudar algún analizador automático estándar o algún parser diseñado expresamente (en nuestro ámbito de la Facultad Córdoba de la UTN, el Ing. M. Marcizack y yo hemos delineado algunas de estas herramientas automáticas y se las está ya probando). Es primordial identificar todos los puntos de tratamiento de fechas dentro de los programas fuente (cálculos y actualizaciones de archivos) para luego poder reparar el código que se considere necesario. Esto, por supuesto, suponiendo que los programas fuente existan, que los mismos corresponden a las versiones actualmente en ejecución, y ... que haya técnicos capacitados y disponibles para hacerlo.
Económicamente, la incidencia de estas tareas está determinada por el tipo de lenguaje de aplicación utilizado en el desarrollo de los sistemas de aplicación y por el volumen de líneas de código a analizar. Como referencia, se está cotizando en nuestro mercado entre $1,00 y $1,60$ la inspección de la línea de programa escrito en lenguaje COBOL (y va en aumento mes a mes); en grandes sistemas este valor representa un considerable costo de conversión, pero se estima que sería mucho mayor el producido por no atacar el problema a tiempo. Algunas empresas quizás no sobrevivan !!!
· Acciones
No cabe duda que la primera acción a emprender, es la formación del grupo de trabajo que determine el método de realización del análisis de impacto del problema del año 2000 en los sistemas y programas utilizados. Una vez terminado este proceso, debe establecerse la metodología de trabajo y la estrategia de solución del problema, para luego iniciar las tareas en forma efectiva.
Como se indicó en el artículo "El Año 2000 y su Gravedad", la combinación de consultores externos y de personal interno de sistemas asignado al proyecto, ha sido hasta ahora la alternativa de conformación de grupo de tareas que mejores resultados ha dado.
No todo es desalentador. Muchas empresas han tomado este problema como una oportunidad para efectuar una revisión completa de sus procedimientos y sistemas, convirtiendo el problema en una ventaja competitiva. El escaso tiempo y el costo involucrado, determinan hoy en día la factibilidad o no de este tipo de acción optimizadora.
En lo referente a Sistemas Operativos y software estándar de automatización de oficina, los proveedores de los mismos en general proveen actualizaciones para solucionar el problema. Otra cosa es la utilización que se haya hecho de estos programas; la capacidad de una planilla de cálculo de representar los años con cuatro dígitos, no asegura que el formato de fechas que el usuario esté utilizando efectivamente en sus documentos tenga cuatro dígitos para el año. Debe por esto, en algunos casos puntuales, inspeccionarse ya no sólo el software utilizado sino el diseño de los documentos realizados con el mismo y sus procedimientos correspondientes.
En cuanto a los sistemas de aplicación desarrollados por la empresa o por terceras partes a medida, en algunos artículos, se nombra a los posibles caminos de solución como el conjunto de las cuatro erres: Reingeniería, Reemplazo, Reprogramación o Reparación, cada una de ellas con sus ventajas y desventajas según el caso.
Se abandonan las técnicas tradicionales de la administración funcional y se orientan los esfuerzos a la definición transfuncional de los procedimientos, optimizándolos cualitativa y cuantitativamente.
Este proceso trae necesariamente aparejada, la construcción de un sistema de información (control y soporte de decisión) que apoye la nueva empresa rediseñada.
La reingeniería de procesos es altamente recomendada por los principales especialistas en el tema, sin embargo, a mi criterio, para una empresa mediana o grande, no solucionará el problema del año 2000 ya que no se dispone de tiempo suficiente para llevar a cabo el proyecto. Es una excelente mezcla, que utilizaron algunas empresas que iniciaron el proyecto año 2000 con la suficiente antelación.
Esta alternativa ha sido seleccionada por muchas grandes empresas en el mundo, pero al igual que para proyectos de reingeniería, el tiempo disponible actualmente no es suficiente.
En pequeñas y medianas empresas, tal vez todavía pueda pensarse en el reemplazo total de sistemas, para lo cual sólo se deberán hacerse consideraciones de funcionalidad y económicas.
Sin embargo, con el poco tiempo disponible para solucionar la cuestión del año 2000, cada vez se tiende más a emprender proyectos de este tipo, sobre todo en organizaciones que disponen de sistemas a medida difícilmente reemplazables por paquetes integrados standard.
Existen varias técnicas que pueden utilizarse bajo esta alternativa, y el uso de una u otra depende en general del tipo de información que la organización maneje, de su antiguedad y del tipo de sistemas que posea. Básicamente podemos mencionar las siguientes, como las más habituales:
1. Expansión de Fechas.
La solución es técnicamente sencilla y consistente; el mayor problema de este tipo de implementación de la reparación de sistemas, es la coordinación del proyecto. Los archivos ya modificados no pueden ser "vistos" o actualizados correctamente por los programas aún no modificados, por lo cual la conversión de estructuras de datos en el almacenamiento físico y la modificación de los programas de aplicación deberá hacerse simultáneamente. En esquemas de subsistemas autónomos, es posible hacer esto por partes, pero en esquemas altamente integrados, esta técnica se hace casi inmanejable.
La indudable ventaja es que el problema queda totalmente terminado,
no requiriéndose modificaciones futuras.
La elección del año pivote, debe hacerse en base al estudio de la antigüedad de la información almacenada en los archivos de la organización. Si el dato más antiguo que la compañía maneja corresponde a 1985, por ejemplo, el año pivote será el 85, con lo cual la lógica de programación indicará que una fecha como 15/02/95, corresponde en la realidad al 15/02/1995 y una como 27/12/15 a 27/12/2015.
Esa técnica no requiere de modificaciones en las estructuras de datos almacenados (salvo en aquellos en que las fechas actúen como variables ordenadoras !!!), pero tiene dos desventajas:
a. El problema no queda totalmente solucionado, ya que en el año 2085 se volverá a presentar el problema.
b. No puede aplicarse si la organización cuenta con datos
almacenados del siglo pasado o muy cercanos al principio del siglo veinte.
Consiste en restar a todos los años de las fechas almacenadas un número fijo (que nuevamente podríamos denominar año pivote) y efectuar modificaciones en la lógica de los programas para que reconviertan las fechas al mostrarlas o exportarlas de alguna forma. Los cálculos de "lapsos" permanecerán de esta forma inalterados, por lo cual no debe preocuparse de los mismos.
Puede ser comparada a la técnica de ventana, ya que opera de
forma similar; sin embargo es engorrosa desde el momento en que la inspección
directa de los archivos brinda información errónea de fechas
y además no puede ser implementada en etapas: todos los programas
deben cambiarse al mismo tiempo que el desplazamiento en los datos almacenados
es efectuado.
Esta técnica es difícil de implementar en un sistema ya en funcionamiento, porque implica la reescritura de todas las rutinas dependientes del tiempo y de todas las estructuras de datos.
Otras empresas han optado por efectuar codificaciones que no necesiten la modificación de estructuras de datos, que es el punto más conflictivo en el proceso de reparación. Por ejemplo, utilizar letras como secuencia para los años: 99 significa 1999, A0 significa 2000, A1 significa 2001, etc.
En este tipo de codificación, la lógica de fechas debe
ser alterada pero no es necesario cambiar el tamaño de los archivos
(aunque sí las estructuras de datos de fecha de numéricas
a alfanuméricas).
En este caso, no puede aplicarse directamente la técnica de ventanas ni la de desplazamiento. Por otro lado, la complicación que implicaría una técnica de codificación no creemos que esté justificada contra sus beneficios. Lo indicado entonces sería efectuar la expansión de fechas con lo cual se solucionaría el problema sin necesitarse futuros cambios.
Sin embargo, el alto índice de modificación que tienen los programas (en su mayoría en lenguaje COBOL) en funcionamiento y su importante volumen, hace poco viable efectuar una reparación completa de estructuras de datos almacenadas y programas de una sola vuelta, como se necesita en esta técnica.
Por ello, ideamos una nueva estrategia de solución que básicamente consistiría en efectuar el proceso de reparación en dos etapas operativas bien diferenciadas (una vez concluido un estudio minucioso del problema, por supuesto):
Por último, esparcir en estos campos de relleno la secuencia 19.
Esto es fundamental sobre todo en un esquema de alto índice de
alteración de programas, situación muy común en sistemas
antiguos.
Aquí debe tenerse en cuenta no sólo los formularios de uso interno, sino los de uso externo que, consecuentemente con su modificación y reimpresión, posiblemente generen presentaciones ante los entes fiscalizadores.
· Estado Actual
Debe efectuarse también frente a este ítem, un relevamiento de todos los formularios de la empresa y un estudio de los mismos para determinar si deben ser modificados o no.
· Incidencia
El impacto de tener formularios mal diseñados para la inscripción de fechas del próximo milenio, es en general poco nocivo. La mayoría de los problemas podrán solucionarse si no se cuenta con nuevos formularios, mediante agregados a mano en los mismos o con una inteligente interpretación de carga de datos, cuando los mismos deban ser volcados a las computadoras. Si los sistemas de aplicación están ya arreglados (cualquiera sea la solución elegida), los mismos no dejarán que se ingresen datos erróneos.
· Acciones
Una vez identificado el estado actual de los formularios y sus procedimientos de control y gestión, deberán rediseñarse los mismos y prever con suficiente tiempo el pedido a imprenta de su reimpresión ya que también las imprentas van ha estar muy ocupadas, meses antes del 2000.
Si esta reimpresión requiriera alguna presentación ante
los entes de fiscalización impositiva, deberá averiguarse
e irse pensando desde ya el modo y la oportunidad de efectuar la misma,
para producir mínimas demoras en el trámite y aprovechar
al máximo los formularios preimpresos de que se disponga en la actualidad.
| RESUMEN |
Resumiendo lo expuesto, el tratamiento del problema del año 2000 deberá seguir aproximadamente las siguientes etapas:
|
|
