|
|
Errores en Administración de TI
José Camilo Daccach T.
Hemos tenido acceso a múltiples situaciones, casos y artículos que denotan errores en la administración de la tecnología informática, errores que pueden ser evitados mediante el conocimiento de los mismos y posibles mejoras de la misma implementación.
Cuadro triple derecha
En los últimos meses hemos tenido acceso a múltiples situaciones, casos y artículos que denotan errores en la administración de la tecnología informática, errores que pueden ser evitados mediante el conocimiento de los mismos y posibles mejoras de la misma implementación. Fallar en la Estrategia de Outsourcing El outsourcing es una estrategia aceptada de nivelación de recursos, de aplicar el dicho de "zapatero a tus zapatos", pero mal aplicada genera errores altamente costosos y hasta irremediables. Los errores con respecto a la estrategia de outsourcing se pueden clasificar en dos tipos: de exceso, y de defecto. Los errores de exceso son los que permiten entregar a un tercero funciones importantes del departamento de TI, solo para evitar hacer el trabajo duro de entender estas funciones. Entregar estas funciones puede hacer que hasta las pequeñas cosas se demoren eternidades en efectuarse. Los errores por defecto, es dejar al interior de la empresa procesos que hasta por su misma naturaleza deberían estar fuera de la misma. Un claro ejemplo es manejar internamente el servicio de correo electrónico cuando los costos para mantener un sistema con alta disponibilidad de un recurso tan importante son demasiado altos, y la tecnología para tenerlo en otro sitio es de fácil acceso. No se debe sacar todo fuera de la empresa, pero tampoco se deben dejar procesos que aunque importantes, no tiene sentido ni económico ni técnico mantenerlos en la empresa. Descartar o adorar las aplicaciones Open Source Por décadas, los departamentos de Tecnología Informática son susceptibles a comportamiento "religioso", es decir, una devoción ciega hacia una tecnología o plataforma en particular. Esto también es cierto del manejo del concepto de las aplicaciones de código abierto. Por un lado, los departamentos más conservadores no tienen en cuenta este tipo de aplicaciones, simplemente por política empresarial, convirtiéndose en un grave error simplemente descartar la posibilidad de aprovechar las ventajas que ésta da. Sentarse a esperar significa dejar pasar soluciones de bajo costo, probadas, estables, y escalables, como Linux, Apache, MySQL, y PHP. Por el otro, insistir en solo software de código abierto en su empresa puede ser un error garrafal y puede atrasar el desarrollo ya que los ingenieros tendrían que integrar aplicaciones posiblemente inferiores donde de pronto existe una solución comercial ya elaborada. Somos fanáticos del pensamiento inductivo , y la posibilidad de implementar soluciones de muy bajo costo para probar conceptos no se puede dejar pasar por "purismo". También predicamos que para "el que tiene solo un martillo, todos los problemas tienen que ser clavos" y no se deben descartar soluciones ya elaboradas simplemente por ahorrar costos directos. Olvidarse de amenazas internas de seguridad Se repite en muchos escenarios que el enfoque en amenazas externas de forma exclusiva genera una falsa sensación de seguridad. Según varios estudios, aproximadamente el 70% de los incidentes de seguridad que conllevan pérdidas reales son trabajos de adentro, haciendo la amenaza interna el mayor problema de seguridad. No extender el perímetro de Seguridad El cómputo empresarial ya se extiende por redes que no están bajo el control del departamento de TI. La aparición de Hot Spots por todas partes en los países desarrollados, y la rápida implementación que se prevé para el 2005 en América Latina, hacen que se revalúe la necesidad de ampliar el perímetro de navegación segura hacia estos puntos de acceso a los cuales los ejecutivos de la empresa se conectarán. El manejo centralizado que se le da a la seguridad sobre el tráfico protegiendo algunos puertos con un firewall ya no es suficiente, por lo que se debe pensar también en la encripción del tráfico sobre la LAN.
Segunda Parte | Tercera Parte
|