Llegamos a ustedes gracias a:



Columnas de opinión

Seis simples piezas: Cómo hacer un mejor análisis del costo de propiedad

Por: John Schlosser, consultor de Administración Senior para la oficina Scorpion dentro del Grupo de Sistemas y Tecnología – Servicios de Laboratorio y Entrenamiento– de IBM

[04/02/2010] Si el análisis del costo de propiedad es un ejercicio doloroso para las organizaciones deTI, ¿por qué casi todas las compañías lo han hecho (y continúan haciéndolo) múltiples veces? Simplemente porque la administración requiere de un entendimiento preciso de los costos y fortalezas actuales de TI, de modo que puedan evaluar mejor nuevas ideas y tecnologías. En este artículo, identificaremos seis elementos clave para realizar un análisis efectivo del costo de propiedad, los cuales puede utilizar para mejorar la exactitud y eliminar la frustración asociada con este paso necesario en su evolución de TI.

1. Analice plataformas, no servidores
Primero evalúe las actuales "plataformas" dentro de su ambiente, incluyendo todos los servidores de todos los tipos, con el fin de simplificar el proceso. Una de las cosas más difíciles de "hacer bien" en un análisis de este tipo es una correspondencia exacta entre una tecnología dada y los costos asociados. La forma más fácil de hacer esto es no limitar el alcance de la tecnología a unas pocas máquinas o a una sola aplicación nueva, sino expandirla para que corresponda a toda la tecnología en el presupuesto TI. Limitar el alcance hace que el costo de adquisición sea simple de determinar, pero hace que todos los otros costos sean casi imposible de cuantificar sin controversia.
Un enfoque en las plataformas resultará en el desarrollo de una nueva "visión" del presupuesto de TI que está basado en la plataforma. La ventaja de este enfoque es que el total en esta visión debe corresponder al total en el presupuesto. Esto le da al equipo de estudio una tremenda ventaja si las discusiones discurren hacia "Creo que esta cantidad es muy alta para la plataforma A". Así que si la cantidad es reducida para la plataforma A, debe ser elevada para la plataforma B. ¿Qué es lo que B piensa de eso? Eso coloca a todas las discusiones de costos sobre bases sólidas -el presupuesto de TI- y permite que el proceso sea manejado desapasionadamente, una clave para una posterior aceptación de los resultados.
2. Enfóquese en una aplicación representativa e incluya todas las partes
Siguiente, considere una nueva aplicación de negocios crítica o un flujo de trabajo que requiere una selección de plataformas. Una vez más, la clave para el éxito es no limitar la visión a un subconjunto de componentes. Por definición, una aplicación crítica requerirá un diseño cuidadoso, una cuidadosa clasificación por tamaño, un cuidadoso mantenimiento, así como operación, soporte y recuperación de desastres. También podría requerir que una nueva o dedicada infraestructura, pero en un mínimo, gravara la infraestructura existente. Cada uno de estos componentes y sus costos asociados, deberían ser incluidos en cualquier comparación de costo de propiedad. La "visión" desarrollada en el paso previo debería facilitar este tipo de análisis.
En los últimos diez años, nuestro grupo dentro de IBM Lab Services ha estado haciendo estudios de Optimización de SistemasTI y Almacenamiento ("Scorpion") que se enfocan en este tipo de visión y análisis basado en componentes. Nuestros hallazgos muestran que una típica proporción de producción web, aplicación y servidores de base de datos a "todo lo demás" es alrededor de uno a uno. Esto significa que cualquier análisis que omita esos otros componentes para soporte, mantenimiento y recuperación de desastres, etc. podría perder la mitad de los costos reales. Esta discrepancia crece en aplicaciones críticas muy grandes, y es en gran medida la razón de que a nuestra industria no le haya ido tan bien dimensionando muchas nuevas suites de aplicaciones corporativas. Todos hemos oído las historias.
3. Considere la capacidad práctica, no los rátings de los fabricantes
La capacidad del sistema y el desempeño pueden volverse rápidamente una discusión muy tediosa y esotérica, y en muchos esfuerzos de costo de propiedad, lo hacen. Los proveedores alimentan esta controversia para ganar ventaja competitiva. Esto debe evitarse. Nuestra experiencia es que el aspecto más importante del análisis de desempeño dentro del costo de propiedad no es qué afirmación del fabricante o cuál benchmark es usada como base, sino (a) ¿qué usos del sistema son "normales" en su ambiente actual?; y (b) ¿cuál es una expectativa razonable para el futuro?
Generalmente, los usos de servidor distribuido son muy lentos y hay una buena razón para ello. Un servidor poco utilizado no requiere planeación de capacidad. La mayoría de los análisis de costos son considerados parte de un proceso de adquisición de tecnología, de modo que se asumen usos en condiciones futuras más altas. Si los usos de los servidores promedio en su ambiente son bajos, modele una condición futura que sea dos o tres veces la actual para cada componente en la posible solución. No más altas. Use cualquier métrica de desempeño razonable -los usos previstos son mucho más importantes-.
Esto es particularmente cierto con el aumento de la virtualización, la cual es casi siempre asumida en las comparaciones de costo de propiedad. Hacer la transición de un ambiente de servidor no virtualizado a uno virtualizado tiene algunas ventajas significativas, que incluyen un mayor uso del potencial. Sin embargo, tiene un costo: la capacidad debe ser administrada. No asuma números de uso de clase mundial a menos que sepa qué clase de esfuerzo tomaría obtenerlos.
4. No ignore los costos de mano de obra para proteger al inocente
El tema más difícil dentro del costo de propiedad es indudablemente el costo de mano de obra. En un ciclo de economía a la baja, la mayoría del personal no ve nada positivo en cuantificar el costo de la mano de obra para "su" plataforma. Las tasas Equivalentes a una Alta Jornada Completa (FTE, por sus siglas en inglés) han sido un objetivo de la industria por años, y la mayoría de los profesionales de TI pueden citar las mejores prácticas actuales y describir cómo ellos las están excediendo. Allí reside un problema.
Las organizaciones de soporte de infraestructura TI han estado atinándole a estas tasas por años usando dos estrategias básicas: (a) mejorar la eficiencia; o (b) distribuir trabajo a otras partes de la organización TI. Cualquier análisis de costo de propiedad que limite los cálculos de la mano de obra al recuento del soporte de infraestructura TI probablemente pasará por alto grandes porciones de los costos de soporte reales y sesgará los resultados.
Una buena solución a este problema es un enfoque similar al primer ítem. Considere a la organización TI entera y reparta proporcionalmente cada grupo que no es verdaderamente neutral en plataforma (e incluso a los individuos dentro de un grupo de otro modo neutral, como soporte de red) a la categoría apropiada de trabajo por plataforma. La misma clase de "visión" se desarrolla ahora para asignar el trabajo, con el diagrama de la organización subyacente como la base.
Los resultados lucirán bastante distintos de las normas publicadas por la industria. Podrían ser mayores -hasta dos veces o más en las plataformas x86- y reflejarán un verdadero entendimiento del costo. Debido a que los números de mano de obra resultantes cruzan líneas organizacionales, ningún grupo se sentirá responsable por ellos, o por disminuirlos. La resistencia al proceso debe ser disminuida y, una vez más, se debe mejorar el convencimiento.
Un beneficio lateral del proceso se deriva de las dos estrategias generalmente usadas para manejar tasas FTE -la mejora de la productividad y la limitación de la responsabilidad. Si las tasas de FET son cambiadas significativamente por la nueva "visión" de la organización, la necesidad de herramientas de productividad será evidente. En los años en los que he estado trabajando con clientes haciendo estos estudios, hemos visto una alarmante tendencia hacia la alta complejidad dentro de sistemas distribuidos -hardware viejo, software viejo, múltiples lanzamientos de todo para ser mantenido- y una falta de inversión en software de administración de sistemas.
5. Cuantifique QoS de forma que tenga sentido
La QoS es un tema elusivo ya que tiene tantos aspectos que difieren en importancia entre compañías, pero algunas tendencias generales pueden ofrecer orientación. En esta era de sistemas en tiempo real, la recuperación de desastres se ha vuelto una necesidad universal. Dos métricas clave en la recuperación de desastres son el Objetivo de Tiempo de Recuperación (RTO, por sus siglas en inglés -el tiempo para traer sistemas alternativos en línea para utilizar-) y el Objetivo de Punto de Recuperación (RPO -la edad de los datos en esos sistemas recuperados-). Si consideramos el dominante RTO y RPO para una plataforma dada, ganamos entendimiento tanto en costos como en QoS.
El cómputo en la nube y otros servicios medidos ciertamente ofrecerán una opción recuperable y aquí yace una oportunidad. Ya que las TI tendrán que competir con nubes públicas, el análisis de costos anteriormente citado puede ser usado para establecer guías de costos internos para una infraestructura de nube corporativa muy pronto en el proceso de desarrollo de la nube. O puede ser utilizado para conducir flujos de trabajo hacia la plataforma que ya es recuperable, eliminando así algo de la necesidad de desarrollar una capacidad de recuperación donde actualmente no existe.
6. Vea los costos de modo creciente: diseñe su propio rumbo
El último tema a considerar es básicamente financiero. Hay un "costo hundido" y un "costo creciente" asociado con la infraestructura TI que debe ser considerado. Así como el primer chip que sale de una línea de fabricación vale miles de millones, y el segundo vale centavos, la primera carga de trabajo para una plataforma es mucho más costosa de aprovisionar que las subsecuentes. Esto es especialmente cierto para el mainframe, ya que la tecnología puede ser físicamente renovada, pero financieramente la transacción se maneja como una actualización. Esto es distinto al mundo distribuido, donde la tecnología y el valor en los libros están vinculados.
Explotar estas áreas de bajo costo creciente para soportar el crecimiento puede mejorar significativamente el costo general de las TI. Se espera que la virtualización tenga un efecto significativo en otras plataformas, así que la necesidad es universal y está creciendo.
CIO.com
Con 33 años en IBM, John Schlosser es actualmente un Consultor de Administración Senior para la oficina Scorpion dentro del Grupo de Sistemas y Tecnología – Servicios de Laboratorio y Entrenamiento– de IBM. Él es un miembro fundador del grupo, que se inició en 1999. Ha desarrollado y modificado muchas de las metodologías que el equipo utiliza para el análisis de costos de la infraestructura de TI.