Saltar al contenido principal
LibreTexts Español

9.6: Costo total de propiedad (TCO) - Los costos tecnológicos van mucho más allá del precio

  • Page ID
    61002
    • Anonymous
    • LibreTexts

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)

    Objetivos de aprendizaje

    Después de estudiar esta sección deberías poder hacer lo siguiente:

    1. Enumere las diferentes categorías de costos que comprenden el costo total de propiedad.
    2. Entender que una vez que se implementa un sistema, los costos de mantenimiento y soporte del sistema continúan.
    3. Enumere las razones por las que fracasan los proyectos de desarrollo tecnológico y las medidas que se pueden tomar para aumentar la probabilidad de éxito.

    Los gerentes deben reconocer que hay una gran cantidad de costos asociados con la creación y el soporte de los sistemas de información de una organización. Por supuesto, hay costos de programación para software personalizado así como costos de compra, configuración y licencia para el software empaquetado, pero hay mucho, mucho más.

    Hay costos asociados al diseño y documentación (tanto para programadores como para usuarios). También hay costos de prueba. Los nuevos programas deben probarse minuciosamente a través de los diversos tipos de hardware que utiliza la empresa, y en conjunto con el software y los sistemas existentes, antes de ser implementados en toda la organización. Cualquier error que no se detecta puede ralentizar un negocio o conducir a errores costosos que podrían repercutir en toda una organización y sus socios. Los estudios han demostrado que los errores no capturados antes del despliegue podrían ser cien veces más costosos de corregir que si fueran detectados y corregidos de antemano (Charette, 2005).

    Una vez que un sistema está “encendido”, el trabajo no termina ahí. Las empresas necesitan participar constantemente en una serie de actividades para apoyar el sistema que también pueden incluir las siguientes:

    • proporcionar capacitación y soporte al usuario final
    • recopilar y retransmitir comentarios para mejoras en el sistema
    • sistemas de auditoría para garantizar el cumplimiento (es decir, que el sistema opera dentro de las limitaciones legales de la firma y las obligaciones de la industria)
    • proporcionar copias de seguridad regulares de datos críticos
    • planeación de redundancia y recuperación ante desastres en caso de interrupción
    • administrar vigilantemente el objetivo móvil de los problemas de seguridad informática

    Con tanto que hacer, no es de extrañar que las empresas gasten del 70 al 80 por ciento de sus presupuestos de sistemas de información (IS) solo para mantener sus sistemas funcionando (Rettig, 2007). El precio y la complejidad de estas tareas pueden empujar a algunos gerentes a pensar en la tecnología como un sumidero de costos en lugar de un recurso estratégico. Estas tareas a menudo se denominan colectivamente el costo total de propiedad (TCO) de un sistema de información. Comprender el TCO es fundamental a la hora de tomar decisiones de inversión tecnológica. El TCO también es una fuerza impulsora importante detrás de los cambios masivos de la industria tecnológica discutidos en el Capítulo 10 “Software en flujo: parcialmente nublado y a veces libre”.

  • ¿Por qué fallan los proyectos tecnológicos?

    A pesar de que los sistemas de información representan la mayor parte del gasto de capital en la mayoría de las empresas, uno asombroso de cada tres proyectos de desarrollo tecnológico no se implementa con éxito (Dignan, 2007). Imagínese si una firma pierde su inversión en una de cada tres compras de terrenos, o al construir una de cada tres fábricas. ¡Estas estadísticas son pésimas! Escribiendo en IEEE Spectrum, el consultor de riesgos Robert Charette proporciona una evaluación aleccionadora del costo de las fallas de software, afirmando: “La pestaña anual para software fallido y problemático de manera conservadora va desde $60 a $70 mil millones solo en Estados Unidos. Por ese dinero, podrías lanzar el transbordador espacial cien veces, construir y desplegar todo el Sistema de Posicionamiento Global de 24 satélites, y desarrollar el Boeing 777 desde cero, y todavía te sobran algunos miles de millones” (Charette, 2005).

    ¿Por qué un historial tan malo? A veces la propia tecnología es la culpable, otras veces es una falla al probar los sistemas de manera adecuada, y a veces es un desglose de los procesos y procedimientos utilizados para establecer especificaciones y administrar proyectos. En un ejemplo, una pérdida multimillonaria en el Observador de Marte de la NASA se remonta a un descuido risiblemente simple: los contratistas de Lockheed Martin que usaban medidas en inglés, mientras que la gente de la NASA utilizó el sistema métrico (Lloyd, 1999). Sí, se perdió una inversión contribuyente de 125 millones de dólares porque un grupo de científicos de cohetes no prestaron atención a las matemáticas de tercer grado. Cuando se trata del éxito o fracaso de los proyectos técnicos, el diablo realmente está en los detalles.

    Los proyectos rara vez fallan por una sola razón. Las post-mortems de los proyectos a menudo apuntan a una combinación de errores técnicos, de gestión de proyectos y de decisiones comerciales. Los factores más comunes incluyen los siguientes 2:

    • Objetivos poco realistas o poco claros del proyecto
    • Mal liderazgo del proyecto y débil compromiso ejecutivo
    • Estimaciones inexactas de los recursos necesarios
    • Requisitos del sistema mal definidos y permitiendo “fluencia de características” durante el desarrollo
    • Mal reporte del estado del proyecto
    • Mala comunicación entre clientes, desarrolladores y usuarios
    • Uso de tecnología inmadura
    • Riesgos no gestionados
    • Incapacidad para manejar la complejidad del proyecto
    • Prácticas de desarrollo y pruebas descuidadas
    • Mala gestión de proyectos
    • Política de las partes interesadas
    • Presiones comerciales (por ejemplo, dejar un tiempo inadecuado o fomentar el corte de esquina)

    Los gerentes necesitan comprender la complejidad que implica sus inversiones en tecnología, y que lograr el éxito rara vez radica solo en la fuerza de la tecnología.

    Pero hay esperanza. Las organizaciones de sistemas de información pueden trabajar para implementar procedimientos que mejoren la calidad general de sus prácticas de desarrollo. Los mecanismos para mejorar la calidad incluyen la integración del modelo de madurez de capacidades (CMMI), que mide la madurez de los procesos y la capacidad de una organización en áreas críticas para desarrollar e implementar proyectos tecnológicos, y proporciona un conjunto cuidadosamente elegido de mejores prácticas y pautas para ayudar calidad y mejora de procesos 1 (Kay, 2005).

    Las empresas también están bien servidas para aprovechar las metodologías establecidas de planificación de proyectos y desarrollo de software que describen los procesos críticos de negocios y etapas al ejecutar proyectos de desarrollo de software a gran escala La idea detrás de estas metodologías es sencilla: por qué reinventar la rueda cuando existe la oportunidad de aprender y seguir los planos utilizados por quienes han ejecutado esfuerzos exitosos. Cuando se aplican metodologías a proyectos que se enmarcan con objetivos de negocio claros y métricas de negocio, y que involucran un liderazgo ejecutivo comprometido, las tasas de éxito pueden mejorar drásticamente (Shenhar & Dvir, 2007).

    Si bien las metodologías de desarrollo de software son el tema de cursos de tecnología más avanzados, el gerente inteligente sabe lo suficiente como para indagar sobre las metodologías de desarrollo y los programas de calidad utilizados para apoyar proyectos de desarrollo a gran escala, y puede usar estas investigaciones como insumo adicional al evaluar si quienes supervisan esfuerzos a gran escala tienen lo que se necesita para hacer el trabajo.

    Claves para llevar

    • El cuidado y la alimentación de los sistemas de información pueden ser complejos y costosos. El costo total de propiedad de los sistemas puede incluir desarrollo y documentación de software, o el precio de compra y las tarifas de licencia y soporte continuas, además de configuración, pruebas, implementación, mantenimiento, soporte, capacitación, auditoría de cumplimiento, seguridad, respaldo y provisiones para la recuperación ante desastres. Estos costos se denominan colectivamente TCO, o costo total de propiedad de un sistema.
    • Los proyectos de desarrollo de sistemas de información fracasan a un ritmo sorprendentemente alto. Las razones de fracaso pueden provenir de cualquier combinación de decisiones técnicas, de proceso y gerenciales.
    • Las organizaciones de IS pueden aprovechar las metodologías de desarrollo de software para mejorar sus procedimientos de desarrollo de sistemas, y las empresas pueden esforzarse por mejorar el nivel general de procedimientos utilizados en la organización a través de modelos como CMMI. Sin embargo, también es fundamental involucrar un liderazgo ejecutivo comprometido en los proyectos y enmarcar proyectos utilizando métricas y resultados comerciales para mejorar las posibilidades de éxito.
    • Los errores del sistema que no se detectan antes de la implementación pueden ralentizar un negocio o conducir a errores costosos que podrían ondularse en toda una organización. Los estudios han demostrado que los errores no capturados antes del despliegue podrían ser 100 veces más costosos de corregir que si fueran detectados y corregidos de antemano.
    • Las empresas gastan del 70 al 80 por ciento de sus presupuestos de IS solo para mantener sus sistemas funcionando.
    • Uno de cada tres proyectos de desarrollo tecnológico no se implementa con éxito.
    • Las organizaciones de IS pueden emplear metodologías de planificación de proyectos y desarrollo de software para implementar procedimientos que mejoren la calidad general de sus prácticas de desarrollo.

    Preguntas y ejercicios

    1. Enumere los tipos de costos totales de propiedad asociados con la creación y el soporte de los sistemas de información de una organización.
    2. En promedio, ¿qué porcentaje de los presupuestos de IS de las empresas se gasta para mantener sus sistemas funcionando?
    3. ¿Cuáles son los posibles efectos de no detectar y corregir errores importantes del sistema antes de la implementación?
    4. Enumere algunas de las razones del fracaso de los proyectos de desarrollo tecnológico.
    5. ¿Cuál es el costo anual estimado de los proyectos fallidos de desarrollo tecnológico?
    6. ¿Cuál fue la razón atribuida al fracaso del proyecto NASA Mars Observer?
    7. ¿Qué es la integración del modelo de madurez de capacidades (CMMI) y cómo se utiliza para mejorar la calidad general de las prácticas de desarrollo de una empresa?
    8. Realizar una búsqueda en Internet de “IBM Rational Portfolio Manager”. ¿Cómo podría el software Rational Portfolio Manager de IBM ayudar a las empresas a obtener más beneficios de sus gastos en proyectos de desarrollo de sistemas informáticos ¿Qué versiones competidoras de este producto ofrecen otras organizaciones?

  • This page titled 9.6: Costo total de propiedad (TCO) - Los costos tecnológicos van mucho más allá del precio is shared under a CC BY-NC-SA 3.0 license and was authored, remixed, and/or curated by Anonymous via source content that was edited to the style and standards of the LibreTexts platform.