Errores en Administarción de TI

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. En anteriores entregas hemos analizado temas como Outsourcing, Open Source, seguridad, desarrollo de software, control de calidad, y manejo del cambio.

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.

Promover la gente equivocada
En ocasiones a los mejores técnicos se les promueven a posiciones administrativas, y parecería como una movida apropiada dado los logros de estas personas y el potencial que se les ve. Sin embargo, en muchas ocasiones los técnicos no están listos para dejar de un lado el trabajo constante de primera línea con la tecnología a cambio de funciones más orientadas hacia las personas.
El empleado promovido puede levantar resentimientos entre sus antiguos colegas y puede que no le llamen la atención las nuevas tareas administrativas, lo que puede llevar a bajo desempeño. Adicionalmente el nuevo administrador puede estar "obligado" a aferrarse a esa nueva posición porque la que desempeñaba anteriormente ya ha sido cubierta o eliminada.
Promover a la persona en el momento equivocado puede ser de los peores errores que se pueden cometer, porque pierde a un excelente técnico y tiene que despedir al recién nombrado administrador.
Mal manejo de la Administración del Cambio
La administración del cambio es una, sino la más importante, labor de los gerentes en general, y en particular de los Gerentes de TI. En ocasiones administradores de sistemas, llenos de talento, y con mucho arrojo, toman decisiones no calculadas de cambios en los procesos de mantenimiento de los sistemas, llevando a situaciones desastrosas. Los procesos de mantenimiento calculados tienen sus razones de ser, y por encima de todo, siempre tienen un plan de contingencia en caso que el trabajo no se pueda llevar a cabo, Introducir cambios en estos procesos sin el debido análisis pueden llevar a la parálisis el negocio.
No se deje llevar por los impulsos. LA administración del cambio es cultural y empieza a la cabeza. Si los administradores toman atajos, también los tomarán los subalternos.
Descontrol en el desarrollo de software
Los proyectos de desarrollo de software siempre tienen sus complicaciones, y la mayor de todas se genera por no saber exactamente qué se debe hacer cuando, es decir, por tener una combinación de mala planeación, ejecución y manejo de cambios dentro del proyecto. En el proceso de planeación por lo general se calculan en forma "genérica" las horas hombre que requieren desarrollar el código, sin embargo estos tiempos son demasiado dependientes de la persona que efectúe el desarrollo y de su experiencia. Pesa mucho más la calidad del funcionario que la cantidad, y estos conceptos no se tienen en cuenta cuando solo se usa la métrica de horas-hombre.
Durante la ejecución del proyecto, el manejo de los tiempos y entregables del mismo es en buena parte de los casos, inexistente, por lo que siempre se entrega tarde, con mayor costos, e incompleto. Un cliente hace ya una décadas me dijo, "en sistemas es como en la construcción, se piden tres cotizaciones, y SE SUMAN!" queriendo explicar que tanto los tiempos como los costos terminaban siempre desbordados. Hoy hay herramientas y metodologías que permiten mantener los proyectos de desarrollo e implementación bajo control.

Dejar que cada ingeniero haga su control de calidad
Es un principio del desarrollo de aplicaciones que el mismo ingeniero no puede él mismo efectuar las tareas de aseguramiento de la calidad en su desarrollo, sin embargo en los pequeños grupos de desarrollo siempre está la tentación de tomar atajos y la administración duerme con éste problema. Permitir que los mismos ingenieros efectúen su propio control de calidad es similar a permitir que los defendidos en un juicio sean también los jueces y los jurados.
Desarrollo de aplicaciones solo para IE
A pesar que las aplicaciones de misión crítica siguen su rumbo hacia el visor de Internet y que Windows continúa su dominio del PC Corporativo, los desarrolladores de aplicaciones Web deberían evitar caer en la tentación de desarrollar solo para el Internet Explorer. Las empresas que desarrollen exclusivamente para el IE verán muy difícil su migración a otro visor de Internet en caso que los ataques sobre falencias de seguridad del Explorer pongan en riesgo su compañía.
Adicionalmente, la presentación de estas aplicaciones de cara a los usuarios externos podría ser compleja si solo se maneja un visor. Hasta hace unos meses, desarrollar para el Explorer exclusivamente implicaba obtener atención efectiva de más del 95% de los usuarios. Hoy le movimiento del software abierto y su Firefox presentan alternativas de alta aceptación en la comunidad de navegantes.
Resolver los problemas de la red con ancho de banda
Uno de los problemas que más debe atender el departamento de TI es que la red "está más lenta que de costumbre". LA reacción inmediata es ampliar el ancho de banda dándole más capacidad a la red. En algunos casos esta puede ser la solución adecuada, pero también puede ser muy equivocada en otras ocasiones. Sin el adecuado análisis, aumentar la capacidad puede ser una decisión costosa y equivocada.
Dejando la capacidad a un lado, los errores comunes para la lentitud en una red incluye la difusión de tráfico no deseado en la red proveniente de sistemas o aplicaciones viejas, o sistemas mal configurados o aplicaciones ineficientes que despachan chorros de paquetes hacia la red en tiempos inconvenientes.
Permitir claves de acceso débiles
En la era de Internet, nuevas amenazas como los virus, los gusanos y el phishing atraen toda la atención en cuanto a seguridad, sin embargo uno de los mayores problemas es el establecimiento de malas claves de acceso o un sistema de autenticación débil. La vulnerabilidad de claves más común incluye claves débiles o inexistentes, cuentas de usuario con claves altamente visibles (como las notas que se pegan en los monitores), cuentas administrativas con claves comunes, o sistemas de encripción sin la debida seguridad.Evitar este problema de autenticación requiere una política clara, detallada y consistente para el manejo de las claves del sistema.
Atrasarse en tecnologías que surgen
Mantenerse al día puede prevenir desastres. Por ejemplo, la aparición de tecnologías que permiten puntos de acceso inalámbrico en los últimos años ha significado que cualquiera puede crear una red inalámbrica, un problema real para cualquier ambiente de TI razonablemente estructurado. Estar desatento a este surgimiento, evita que se generen los procedimientos respectivos para mantener bajo control la incorporación de nuevos equipos a la red.
Por otra parte el surgimiento de tecnologías más económicas o que permitan resolver o habilitar una solución que antes de esta tecnología hubiese sido muy costoso, son las que convierten al gerente de tecnología alerta, en pieza fundamental para el mejoramiento de la compañía y la implementación de ventajas competitivas.
Subestimando el PHP
Cuando se desarrollan aplicaciones escalables, por lo general solo se miran las funcionalidades ofrecidas por J2EE y .NET, desconociendo las bondades de lenguajes de scripting como el PHP. El PHP maneja un criterio de compartir nada, por lo que cada requerimiento se maneja en forma independiente de todos los demás y la escalabilidad horizontal se puede implementar fácilmente, agregando más equipos. Cualquier cuello de botella se limita al escalamiento de las bases de datos y sus servidores.
PHP no es para todas las soluciones pero no contemplarlo dentro de las posibles alternativas cuando ya se tienen ejemplos de escalabilidad efectiva, sería un error.
ConclusionesAprender de los errores es una de las premisas de la experiencia. Hemos mencionado los más frecuentes que nos hemos topado en los últimos meses con nuestros clientes. Esperamos que su divulgación les permita a ustedes no cometer los mismos errores.