Haga clic aquí para instalar Silverlight*
LatinoaméricaCambiar|Todos los sitios de Microsoft
Microsoft TechNet
|Suscríbase|Descarga|Contáctenos|Simplified

El propósito de la tecnología

Publicado: 18/09/2006
El propósito de la tecnología

Por Daniel Elías Robles

Consultor Tecnología de Información y Seguridad

CISSP, MCSE Security, CCSP, Security, Linux, MCT, MVP

Con el surgimiento de las nuevas pasiones y la creación de nuevos paradigmas sobre la utilidad del software hay quienes han olvidado el rol que la tecnología juega en el mundo de las instituciones.

En este análisis me quiero concentrar, básicamente, en las instituciones cuya actividad es la generación de negocios, pero en general puede también aplicarse a todo tipo de institución que tenga una meta definida.

Hoy por hoy, y especialmente con el surgimiento del software libre, ha aparecido también toda una nueva clase de asesores, que al parecer tienen un solo fin: la tecnología como fin.

Con esto me refiero en que inducir a la alta gerencia en discusiones técnicas, y ponerlos a manejar numeroso conceptos, ya sea de lo propietario o lo libre, en nada ayuda a la institución en el logro del bottom line que como toda institución, es lo que cada presidente, director y gerentes preocupados persiguen como si fuera el santo grial.

Quiero entonces llamar a su atención lo que es la condición sine qua non de los recursos informáticos de las empresas ¿cómo me ayuda tal tecnología a lograr mis objetivos de negocio? Entonces, si nos concentramos en este punto podremos hacer propuestas que hagan sentido a la alta gerencia, aparecerán los presupuestos, las aprobaciones, los casos de éxito, las promociones, y especialmente, la salud de la institución.

En este apasionado mundo de la tecnología, no faltan quienes hacen propuestas de un movimiento radical a una nueva corriente, y al parecer tienen toda la energía del mundo para empujar su propósito, crear cambios, y aunque el cambio es importante, este por sí no responde a la pregunta vital de la tecnología, que en pocas palabras es apoyar los planes de negocio de las empresas.

Por eso, cuando en el medio que te desenvuelves ves las señales de quienes quieren empujar un cambio, simplemente porque sí, o porque así seremos más libres, por la democratización del software, y otra gran cantidad de slogans ya muy conocidos por los que nos movemos en este medio, la manera más eficaz de responder a estas propuestas es con la pregunta vital empresas ¿cómo me ayuda tal tecnología a lograr mis objetivos de negocio?

Les quiero proponer el siguiente esquema de trabajo para que podamos entender el impacto del cambio en la infraestructura, y consiste de seis puntos críticos los cuales deben arrojar un balance positivo que apoye la intención del cambio, si el balance no es suficientemente mayor que los costos que involucra, entonces no hace sentido la propuesta que se le está haciendo a la gerencia.

Estos puntos son:

• Funcionalidad

• Manejabilidad

• Presupuesto

• Estabilidad

• Seguridad

• Soporte

En este artículo, haremos foco en las dos primeras: Funcionalidad y Manejabilidad.

Funcionalidad

Con frecuencia, el entusiasmo por el cambio nos hace olvidar que el propósito del software es proveer una funcionalidad, y que por lo tanto debemos tener bien claro cuales de estas funcionalidades son vitales para la operación, cuales son pueden esperar por no ser tan críticas, y cuales definitivamente son las cosas que nos gustaría tener pero que no son necesarias para la operación.

El no tener estos tres elementos ordenados correctamente por prioridad, de acuerdo al impacto de la presencia o no de estas funcionalidad, puede conducirnos a un callejón sin salida, que lamentablemente nos damos cuenta cuando ya es un poco tarde y la operación se ve impactada negativamente por la falta de funcionalidades críticas o importantes que fueron relegadas a un lugar de menor importancia, a veces por complacer un capricho, que bien pudiera venir del administrador de sistemas, o del presidente de la empresa.

Todo cambio en busca de funcionalidades debe buscar enriquecer la operación agregando nuevas funcionalidades que ayuden a los planes de negocio. Si luego de un cambio tengo exactamente la misma funcionalidad, solo he logrado distraer tiempo y recursos de la empresa para la cual trabajo.

Bajo ninguna circunstancia se deben ignorar las necesidades funcionales de los diferentes grupos, pues al hacerlo estamos frenando el desarrollo de la empresa.

Manejabilidad

En esto es necesario hacer un inventario de las capacidades técnicas de nuestro cliente, y no partir de donde ellos deberían estar, sino de donde ellos están hoy, recuerda no todo el mundo tiene estas siglas como apellido, MVP. De manera que la referencia no puedes ser tú mismo.

De seguro que hemos escuchado decir “los verdaderos hombres programan en Assembler”, y esto creo que tiene más una base en el ego que en las ventajas reales que se reciben, pero sabemos que por lo oscuro y poco manejable ha caído en desuso.

Lo mismo también se aplica en el área de infraestructura y toda las demás soluciones, nosotros necesitamos herramientas que nos permitan mejorar tiempo de respuesta, poder ser más competitivos, y la tendencia es buscar aquellas herramientas que nos ayuden en la administración, no restarnos eficiencia.

Cuando consideremos este tipo de cambios tiene que ser evidente que la solución propuesta tiene que fortalecer los planes de negocios de la institución al permitirnos mejorar los tiempos de respuesta en los requerimientos que manejamos.

Aunque existen muchas soluciones de directorio, no me viene a la mente ninguna que presente el nivel de integración y de funcionalidad que nos ofrece Active Directory, con sus políticas de grupo que hacen de la administración de recursos toda una experiencia. Podemos hacer tantas cosas desde un solo interfase gráfica, lo cual no es posible si quisiéramos administrar los mismos recursos desde aplicaciones discretas, donde cada una tiene su propia interfase y demanda de un nivel de experto para su administración.

El propósito de estas herramientas es abstraer ciertos detalles técnicos que al final del día no son necesarios para el día a día, que en cierta manera podamos hacer gala de lo hombre que somos, pero que nos ayudan mucho en la administración de tareas comunes, que representan el grueso de la operación.

Soporte

El tema de la formalidad adquiere mucho valor en este punto, pues sin importar quien sea el proveedor, siempre necesitamos de una institución a la cual acudir cuando tenemos problemas, y ciertamente, los problemas vendrán.

Cuando hablamos de soporte formal, me refiero a esa institución, no individuo, que está en capacidad de tomar mi requerimiento, analizarlo, resolverlo y facturarme por ello, de manera que luego de haber agotado mis recursos internos yo pueda confiar que una institución está trabajando en este caso.

¿Por qué tanto énfasis en el término institución? Porque finalmente, las instituciones tienen relaciones con instituciones, los individuos –aunque capaces por sus conocimientos técnicos– no disponen de los recursos necesarios para responder a nuestra necesidad, no tienen infraestructura humana, recursos, inversión, etc. Y dependiendo del tipo de institución en que trabajes y el volumen de negocios, simplemente no te puedes dar el lujo de contar con individuos, necesitas poder transferir ciertas actividades de soporte.

Consideremos el caso de una avería mayor con cierta línea de producto que es crítica para la empresa. En esos casos, el personal llegó tan lejos como podía, pero que no hay nadie a quien recurrir para que tome el control del juego hasta que se normalice la situación. ¿Cuáles son los posibles impactos económicos, operacionales y hasta legales? Como puedes ver son muchos, demasiados como para ignorarlos.

Si el soporte formal no existe entonces tú tienes que proveerlo y al mismo tiempo asumir el riesgo de tus limitaciones, en particular tendrías que profundizar en detalles técnicos que simplemente te consumirían tiempo y recursos que son necesarios para dedicarlos a los planes de negocio de la empresa para la cual trabajas.

Presupuesto

Cuando llegamos a este punto pensamos en las grandes sumas de dinero que laa empresas podrían ahorrar si decidieran hacer un simple cambio a su solución de IT. Pensamos, muchas veces, que es un argumento imbatible, pero prestemos atención al cuadro completo. Y la única palabra que abarca todo el tema de presupuesto en su mayor expresión es la que en inglés se conoce como TCO (Coste Total de Propiedad).

Para no reinventar la rueda voy a citar la definición de Wikipedia sobre este tema “El coste total de propiedad, proveniente del término anglosajón Total Cost of Ownership (TCO), es un método de cálculo diseñado para ayudar a los usuarios y a los gestores empresariales a determinar los costes directos e indirectos, así como los beneficios, relacionados con la compra de equipos o programas informáticos. El CTP ofrece idealmente un resumen final que refleja no sólo el coste de la compra sino aspectos del uso y mantenimiento. Esto incluye formación para el personal de soporte y para usuarios, el coste de operación, y de los equipos o trabajos de consultoría necesarios.”

Como podemos ver, esta definición es más que reveladora, pues el costo real de un cambio no solo es el costo de licencia, sino que se consideran todos los costos, directos e indirectos que componen la totalidad.

Algunos aspectos que hay que tener en cuenta y que afectan el TCO

Implementación. Aunque el costo inicial sea próximo a cero, la mano de obra no lo es, y regularmente el costo de labores profesionales es mucho más costoso, pues muchas veces demanda más labor y más especialización

Entrenamiento. Por más compatibles que sean dos soluciones siempre hay diferencias las cuales la empresa tiene que comunicar a sus empleados para que no se afecte la producción ni la administración. Este tiempo en entrenamiento tiene un costo, siempre que sacas parte de tu personal para entrenarlo tienes que pagarle este tiempo.

Soporte Técnico. Algo que la gente olvida es que siempre que hay tiempo involucrado hay un costo, y que se puede volver recurrente. El hecho de que tu personal lo pueda conseguir en Internet sin pagar nada no significa que no te costó, pues hay que pagarle a los administradores y personal de soporte.

Otro detalle, es que ciertas empresas ofrecen soporte técnico, pero estos contratos suelen ser costosos, por lo que el concepto de aplicación de la “libertad” tiene un costo tangible, y lo más delicado, que se puede manifestar como costos ocultos.

Estabilidad

En el proceso de lograr la estabilidad se invierten cientos y hasta miles de horas en análisis, desarrollo, implementación y soporte. Ciertamente pueden transcurrir meses y hasta años antes de que una infraestructura alcance la madurez, y una vez logrado, es necesario protegerla mediante un exigente ejercicio de análisis y control de cambio.

Por esta razón hay que realizar toda la investigación necesaria antes de realizar cambios en la infraestructura, pues un cambio motivado no en la empresa sino en alguna causa romántica, puede hacernos retroceder años en el tiempo, pues ahora sería necesario conocer y resolver todas las eventualidades que toda transformación mayor involucra.

Esta es una realidad aun cuando se hagan cambios dentro de la misma familia de productos o nuevas versiones de un mismo proveedor.

De nuevo ¿cómo me ayudaría a estabilizar la plataforma los cambios propuestos? ¿Es obligatoria una solución técnica o la causa a las dificultades radica en procesos deficientes y la no observación de las mejores prácticas del área?

No pocas veces he visto como se quiere corregir con tecnología problemas que son el resultado de falta de análisis, implementaciones deficientes y administración pobre. El cambio de infraestructura para salvar estas situaciones solo logrará mover el problema, nunca lo solucionará.

La estabilidad cuesta tiempo, por lo tanto dinero, y al final son nuestros clientes los que se ven afectados por estos cambios, por que es obligatorio analizar fríamente lo indispensable de los cambios, pues todo cambio trae consigo sus sorpresas y la necesidad de adquirir nuevas experiencias.

Cuando el cambio es muy radical con frecuencia se pierden todas las habilidades que se tenían en las soluciones anteriores, creando esto un riesgo mayor que los aparentes beneficios que se podrían recibir.

Seguridad

Algo que el tiempo se ha encargado de demostrar es que todos los productos de software están expuestos a presentar problemas de seguridad, y para esto les quiero referir al siguiente enlace http://www.cert.org/nav/index_red.html Aquí se puede ver que absolutamente todos los proveedores aparecen con eventos relacionados a sus productos.

Ahora, cada vez que se producen las llamadas brechas de seguridad ¿es consecuencia del producto o una debilidad administrativa?, regularmente, en el 95 por ciento de los casos, encontramos que los grandes compromisos suceden cuando no se cumplen los procesos adecuados.

Por esta razón, sin pretender ignorar las vulnerabilidades inherentes a ciertos productos, encontramos que es mayor la incidencia de la administración que de la tecnología.

No es raro leer que algunos proyectos que distribuyen productos de Open Source experimentan compromisos al mismo ritmo o más que los más cerrados de los productos del mundo propietario.

No deja de ser cierto que a pesar de que a diario se presentan notificaciones de vulnerabilidades y sus consecuentes exploits, muchos de ellos caen dentro del marco teórico, una demostración de concepto más que un peligro real o evidente en el mundo práctico.

Además, muchas otras tantas veces no representan el grueso de las configuraciones y/o solo afectan a un reducido número de usuarios.

Con lo anterior expuesto lo que quiero llamar la atención de que el conocido término “más seguro” puede caer en lo relativo, pues la seguridad no siempre radica en la tecnología, sino en la administración y en la observación de los principios de debida diligencia y debido cuidado. Muchas veces, la solución ya existía al momento de suceder el incidente.

http://www.openssh.com/txt/trojan.adv

http://www.debian.org/News/2006/20060713



©2017 Microsoft Corporation. Todos los derechos reservados. Póngase en contacto con nosotros |Aviso Legal |Marcas registradas |Privacidad
Microsoft