You are on page 1of 5

INVESTIGACION

¿Qué fallas podrían afectar significativamente mi empresa?


Usted debe examinar cada parte de su organización e identificar cada sistema que juega un
rol en cada una de esas partes, y asignar prioridades de acuerdo al potencial de daño ó
interrupción que una falla en el sistema puede provocar.
El primer paso es llevar a cabo un inventario de cada sistema en su empresa, no sólo
aquellos que usted cree que tienen sistemas incrustados en él. El tipo de sistemas que incluya
dependerá de la naturaleza de su empresa. Debe conseguir detalles incluyendo número del
modelo, proveedor y compañía manufacturadora, si está aún disponible, detalles del número de
serie y versión del software. Esto es importante cuando se requiere de detalles que manejan los
proveedores de los equipos.
Lo siguiente es llevar a cabo una medida de impacto, durante la cual lleva un registro los
sistemas, estableciendo una jerarquía en grado de importancia. Mientras mayor el efecto, mayor la
importancia del sistema. Considere tres áreas:
1. La seguridad del público y personal que trabaja en la empresa.
2. El efecto sobre el entorno
3. La capacidad de la empresa de seguir trabajando, en términos de personal
presente y equipos operacionales.
(Una lista de sistemas incrustados puede ser muy útil al llevar el inventario. Puede
encontrar una lista de estos sistemas en "A Business Guide to the Year 2000", publicada
por Cambridge Publishers Ltd).
La siguiente tabla pude ser útil en el momento de decidir el impacto relativo de las fallas del
sistema
Alto Impacto Mediano Impacto Bajo Impacto
Fallas en la seguridad, Pérdidas menores de No se produce pérdida
caídas en la producción,producción, problema menorde seguridad ó producción, ni
problemas con el medio del medio, ó seguridad problemas de entorno
Usted debe revisar la importancia de los sistemas con respecto de las regulaciones ó
códigos actualmente vigentes. La falla de ciertos sistemas podrían significar que usted debe
detener la producción.

¿Cómo identifico los sistemas que podrían fallar?


El inventario en este escenario sólo indica cuáles sistemas podrían sufrir fallos el año 2000,
en orden de importancia. El siguiente paso es construir un cuadro de cómo puede fallar cada
sistema. Para esto, se debe contar con toda la información disponible acerca de cada sistema.
Esto debe establecerse según un orden de importancia previamente establecido.
Las fuentes de información podrían ser:
• Documentos de componentes y sistemas.
• Reportes de usuarios y mantenedores de los componentes y sistemas
• Los proveedores y diseñadores de los mismos.

¿Quién puede responder mis preguntas?


En caso de sistemas que tengan que ver con elementos de la construcción, la
acción dependerá si usted es ó no propietario. En el primer caso, deberá ubicar a los
diseñadores ó proveedores de los sistemas en cuestión. De lo contrario, deberá ubicar al
dueño de la construcción, y pedirle que realice la investigación correspondiente. Deben
proveerle evidencia de cualquier trabajo que se realice para resolver problemas durante la
investigación.
Con respecto a elementos pertenecientes a su empresa, debería poder obtenerse
información acerca de si un cambio en la fecha afecta alguna de sus funciones, ó si no
depende de ella. Esta información sólo puede ser utilizada como un indicador que el
sistema puede fallar. Si la fecha no puede modificarse, no debe considerarse como un
signo de su operatividad. Aunque podría significar que es menos sensible a fallas, ya que si
la fecha no puede cambiarse, puede ocurrir que ésta nunca haya sido correcta, por o que
no sea relevante.
Manutención externa puede poseer similar grado de detalles, e incluso manejar
mayor conocimiento en profundidad del sistema ó los componentes en cuestión. Cada
fuente de información debe ser apropiadamente registrada.
Documentos asociados con los componentes ó el sistema pueden indicar
dependencia de la fecha, pero debe tenerse en cuenta que no puede concluirse
directamente si el sistema será operante ó no. No debe asumirse, además, que la
documentación contiene absolutamente todo acerca del sistema ó componente en
cuestión. Por otra parte, cualquier información proveniente de los diseñadores ó
proveedores debe venir por escrito, los que deberín ser capaces de identificar los sistemas
dependientes del tiempo.
Recuerde ser cuidadoso cuando trate con sistemas que tienen componentes
identificables de hardware y software. El diseñador de hardware puede declarar que el
sistema es operante porque el reloj y el sistema operativo lo son. Esto no significa que la
aplicación de software lo sea, por lo que deberá contactar al proveedor de software en
forma separada.

¿Qué indicios debo buscar?


Algunos sistemas que tienen dependencias son obvios de localizar. Otros no.
Ejemplos de los obvios son:
• Despliegue de la fecha actual
• Impresiones fechadas
• Sistemas que realizan ciertas funciones en días específicos
• Sistemas que almacenan información para estadísticas
¿Qué preguntas debo realizar a mis proveedores y diseñadores?
Se necesita establecer el status de operabilidad de un componente ó sistema. Debe
realizar preguntas que ayuden a determinar qué tan confiable es la información que ellos le
proveen. Por ejemplo, no confíe en la operabilidad de un sistema que dependa de la fecha,
si el proveedor no le indica cómo fue testeado para garantizar su correcto funcionamiento.
Algunos ejemplos de preguntas que pueden realizarse son los siguientes:
1. ¿Este producto contiene un reloj ó un reloj de tiempo real (RTC)? Los resultados
de las pruebas pueden variar en ambos casos, pues en un caso se almacenan dos dígitos
para el año, mientras que en el otro se pueden almacenar cuatro. 2. ¿Qué función cumple
el producto que requiere una fecha? Si sólo despliega la fecha, la naturaleza de la falla es
muy inferior a la de otro que emplee este dato en forma más compleja. Por ejemplo, si la
almacena por 30 días. 3. ¿El proveedor ha testeado el producto? Deben conocerse los
resultados. 4. ¿En qué forma ha sido testeado? Podría no ser suficiente que simplemente
cambiaran la fecha al año 2000, y chequearan si el sistema sigue funcionando ó no. Debe
estudiarse con cierto detalle la funcionalidad del equipo al acercarse al 2000 5. ¿Para qué
fechas se ha testeado el producto? Deben revisarse todas las posibles fallas, lo cual va
más allá de sólo revisar si del 31 de diciembre al 1 de enero el equipo trabaja ó no.

EL PLAN

¿Cuál es el siguiente paso?


La información conseguida durante su investigación le ayudará a decidir qué hacer.
Dependerá en gran medida de qué tan importante sea para usted cada sistema en particular. La
acción a llevarse a cabo puede dividirse en tres planos, los cuales corresponden a los tres niveles
de importancia del sistema asignado de acuerdo al grado de impacto en sus actividades. Parte de
su plan debe identificar cuánto tiempo puede esperar como máximo antes de tomar una decisión
sin la respuesta de sus proveedores. En algunos casos, dependiendo de la importancia del
sistema, no será una opción no hacer nada. En estos casos, debe usted tener en cuenta con
especial cuidado el tiempo que le tomará implementar una solución una vez que haya obtenido
una respuesta satisfactoria.
Usted puede decidir el grado de prueba que requerirá para determinar si un sistema es no-
operativo. Recuerde que al hacer una prueba, puede estar introduciendo otras fallas en el sistema,
por lo que su prueba deberá tener un nivel razonable de incertidumbre. No tener esto en cuenta
podría significar fallas ó pérdidas de producción no esperadas.
Si usted sabe que bajo el escenario planteado, el sistema es no-operativo, usted tiene un
número de opciones.
• No hacer nada. Esto es razonable si es una falla trivial, y no afecta la operación
global de sus sistemas. Por ejemplo, un sistema que no pueda desplegar una
fecha, pero no afecte la funcionalidad del equipo.
• Actualizar el sistema. Podría ocurrir que el sistema fuese no-operativo, pero el
proveedor ó el diseñador pudieran arreglarlo mediante actualizaciones de los
equipos. Tenga cuidado con esta opción, pues podría tomar mucho tiempo.
Debe asegurarse que el diseñador ó el proveedor sea capaz de entregarle un
equipo testeado antes del 2000. Si el sistema fuese personalizado, deberá
trabajar en contacto con el diseñador.
• Reemplazar el sistema. Podría suceder que el sistema fuese no-operativo, más
el proveedor ya no pudiese ofrecerle soporte. (Por ejemplo, por obsolescencia).
Al adquirir un nuevo sistema, asegúrese que haya sido testead, y sea operativo.
• Apague el sistema, y realice el control en forma manual (Si es posible). El
sistema podría ser muy caro de actualizar, con respecto a su importancia.
• Prepárese para tomar el control en forma manual en caso que el sistema falle.
Si no está seguro si el sistema fallará ó no, esta puede ser la opción más
indicada.
Desde luego, la acción que tome dependerá del nivel de importancia del sistema
que usted esté considerando.

¿Cómo testeo mis sistemas?


Realizar la prueba sobre el equipo debería ser el último recurso (No juegue a cambiar los
relojes), y debe tomar este camino sólo si el nivel de impacto del sistema es muy alto y el
proveedor no ha sido capaz de darle un grado de certidumbre.

¿Qué tanto puede demorar my programa para el año 2000?


En cualquier caso, su programa debe estar listo a mediados de 1999. Debe darse cuenta
que debe comenzar cuanto antes, pues el tiempo de desarrollo del programa puede impedirle
hacerlo efectivo a tiempo.

OTRAS ACCIONES
¿Qué más se puede hacer?
Debe estar seguro que sus proveedores seguirán en el rubro; después de eso, pregúnteles
acerca de sus programas y el año 2000. Ellos deberán:
• Sugerirle proveedores alternativos
• Darle ideas con respecto a la implementación de su propio programa año 2000.
• Darle alguna garantía que no habrá gran interrupción en proveerle.
¿Dónde conseguir más información?
Algunos organismos a los cuales puede recurrir son

British Computer Society (BCS) www.bcs.org.uk


Health & Safety Executive (HSE) www.hsbooks.co.uk
Institution of Electrical Engineers(IEE) www.iee.org.uk
Real Time Engineering Ltd www.rtel.co.uk
Action 2000 www.open.gov.uk/bug2000.htm
Fuente: Proyecto U2000. Universidad de Chile.

You might also like