Servicios Personalizados
Revista
Articulo
Indicadores
-
Citado por SciELO
-
Accesos
Links relacionados
-
Similares en SciELO
Compartir
Revista Técnica de la Facultad de Ingeniería Universidad del Zulia
versión impresa ISSN 0254-0770
Rev. Téc. Ing. Univ. Zulia v.27 n.2 Maracaibo ago. 2004
Evaluation system model for remote control software
Pedro N. Bonillo R.
Facultad de Ciencias, Universidad Central de Venezuela. Apdo. 47002, Los Chaguaramos, Caracas 1041-A, Venezuela. E-mail: pbonillo@kuaimare.ciens.ucv.ve
Abstract
This article aims to describe a system model for software tools evaluation. Software evaluation is commonly associated to a checklist that verifies the existence of some relevant characteristics involved in the use of software. Some other key factors of software evaluation that are taken into account are: the context and the whole process in which software is involved before being applied by the users, and the evaluators standpoint. In this evaluation process, the entities, attributes, and relationships that mainly affect to the organization are integrated. All this suggested the use of a system model through which the evaluation could be modeled as an open system. This research establishes the relationships as well as the required conditions between the systemic thought and the evaluation perspective, into a model that allows both an acceptable estimation and a set of premises to evaluate successfully software use towards the framework of business interests by taking as a study case, the remote control software tools of the internal support organization of CANTV, a Venezuelan communications firm.
Key words: Remote control, general theory of systems, systemic model of evaluation, complexity of the management of Ti.
Modelo sistémico de evaluación de herramientas de software de control remoto (MOSEHSARF)
Resumen
El objetivo de este artículo es presentar y describir un Modelo Sistémico para la Evaluación de Herramientas de Software. Al hablar de evaluación de software, lo más sencillo y fácilmente manejable que viene a la cabeza es una lista de cotejo en la que se verifica la existencia o ausencia de determinadas características o procesos involucrados en su uso. Es también fácilmente justificable que no se puede hablar de una evaluación aislada del contexto y los procesos por los que transita el software antes de llegar a las manos del usuario, o bien, divorciada de los objetivos que tiene quien conduce la evaluación. En este proceso de evaluación, se evidencian la existencia de entidades, atributos, y relaciones que afectan en gran medida a la organización, y que sugieren la utilización del enfoque sistémico, a través del cual la evaluación pueda ser modelada como un sistema abierto. Esta investigación busca establecer las relaciones y condiciones necesarias entre el pensamiento sistémico y la perspectiva de evaluación, dentro de un modelo diferenciador que permita obtener una buena estimación y un conjunto de criterios para evaluar exitosamente el uso del software en el marco de los intereses del negocio, tomando como caso de estudio la herramienta de software de control remoto en la organización de soporte interno de la empresa venezolana CANTV.
Palabras clave: Herramienta de software de control remoto de fallas, teoría general de sistemas, modelo sistémico de evaluación, complejidad de la gerencia de Ti.
En forma revisada el 15 de Marzo de 2004
La tecnología de la información (TI) está continuamente en rápida evolución, al mismo tiempo que lo está el ambiente de los negocios, lo cual coloca presión sobre las Organizaciones que están seguras de que pueden soportar los cambios fundamentales que en ellas ocurren. La tecnología de la información soporta las Organizaciones sobre el tiempo y el espacio, sin embargo las Organizaciones no tienen aún la cantidad de soluciones suficientes y coherentes para desarrollar la dimensión de la estructura organizacional, la estrategia, los recursos humanos, la tecnología y los procesos del negocio. Los cambios producidos en las Ciencias de la Computación han sido para encontrar una manera de atacar este problema mediante acciones continuas y rápidas a través del desarrollo de nuevas interrelaciones entre la tecnología de la información y la de la comunicación, alineándolas tanto con las necesidades sociales del grupo de usuarios cooperativos, como con la administración de los requerimientos de las Organizaciones formales. Paul Strassmann, conocido consultor norteamericano que ha estudiado con profundidad el impacto de las tecnologías de la información en las organizaciones, señala que no hay una relación directa entre la inversión de las empresas en TI y el retorno que consiguen de esa inversión [1].
En general, los criterios que se utilizan para evaluar software en las organizaciones, son más bien cualitativos, sin presentar una estandarización que permita a los especialistas valorar aspectos y evidenciar criterios mínimos de confiabilidad [2]. Cabe señalar que, aunque este es un problema ampliamente reconocido, existen escasas instancias de evaluación de software que permitan determinar su influencia positiva sobre la Organización [3].
En muchas áreas de aplicaciones de software, a menudo, es más económico adquirirlo que realizar su desarrollo. Los Gerentes de sistemas se enfrentan a una decisión, de hacer-o-comprar, que se puede complicar con varias opciones de adquisición: (1) Se pueden adquirir programas (o una licencia de uso); (2) Se pueden comprar programas y modificarlos luego para que se ajuste a las necesidades específicas y (3) Se puede encargar a una tercera parte la construcción de un programa que se ajuste a las especificaciones del comprador.
En los países subdesarrollados, se requiere de esfuerzos tecnológicos orientados a obtener un equilibrio adecuado entre la adquisición de la tecnología del exterior, el desarrollo y utilización de la capacidad tecnológica de la propia empresa y la selección, adaptación y generación de la tecnología que demanda para producir; ya que, en estos países, las empresas no poseen capacidad ni tradición suficientes en el desarrollo de tecnologías, siendo la principal opción el recurrir a la transferencia de tecnología, provenientes éstas de países desarrollados [4].
Asimismo, la Gerencia de Tecnología de la Información se enfrenta al reto de prestar soporte a un número mayor de usuarios, con computadoras personales cada vez más complejas y con una movilidad en aumento, sin acrecentar los costos o incluso reduciéndolos. Esto representa un reto enorme [5]. Como apoyo a la Gerencia de Tecnología de la Información, en este enorme reto, las Organizaciones normalmente cuentan con una Mesa de Ayuda o Helpdesk. Esta Mesa de Ayuda constituye la primera línea de defensa en la mayoría de las organizaciones de soporte y tiene a su cargo la detección y resolución de problemas a través del teléfono con el fin de reducir la necesidad de que un técnico se desplace hasta el usuario o que el usuario tenga que llevar su computadora a un centro de soporte. En estas dos alternativas, la productividad se ve afectada y los costos del soporte aumentan drásticamente. Según una encuesta realizada por la compañía Forrester Research, el 60 por ciento de los encuestados reportaron que sus técnicos tuvieron que visitar los sistemas de los usuarios para resolver problemas (el 43 por ciento varias veces al día y el 17 por ciento varias veces a la semana) [5].
Dentro de las nuevas tecnologías que apoyan al personal del centro de soporte a sopesar este tipo de inconveniente tenemos las herramientas de atención remota de fallas (Remote Control), las cuales permiten a los técnicos tomar el control de la Computadora Personal (PC) del usuario a través de la red y trabajar con ella como si fuera una computadora local. De esta forma, los problemas se resuelven rápida y sencillamente, sin necesidad de que el técnico abandone el centro de soporte, disminuyendo el tiempo de atención, y enseñando al cliente mediante el enfoque de aprender haciendo [6]. El Grupo Gartner estima que, en un periodo de 3 años, las herramientas de control remoto pueden reducir los costos anuales de los centros de soporte entre un 6% y un 13%. Se estima que los costos anuales de los centros de soporte se encuentran en un rango de los 158 a los 1,447 dólares por PC. Esto significa un ahorro anual de 21 a 77 dólares por PC, o de 153,800 a 576,900 dólares en un entorno con 2,500 computadoras personales [5].
Las empresas en Venezuela toman decisiones referentes a la tecnología que utilizan, pero sin tener mucha conciencia de ello; se utilizan enfoques que tienden a subestimar o ignorar aspectos importantes de la selección y uso de la tecnología que compran. Esto, obviamente repercute de manera sensible sobre el rendimiento económico de las empresas y sus posibilidades de desarrollo futuro. Comúnmente la tecnología de información en las organizaciones venezolanas se adquiere por moda, sin previo estudio, sin un análisis o evaluación y sólo después de que se compra el producto y se exige una métrica de la gestión del mismo, o una justificación de los costos asociados, es que se comienza a evaluar tanto el producto, como su efecto sobre los procesos del negocio. La carencia de un enfoque de evaluación de software en estas organizaciones ha generado problemas en la productividad y la calidad, así como en la evaluación, cada vez que una nueva tecnología y metodología es aplicada a la organización.
La pregunta normal, de las organizaciones, al enfrentarse al término de evaluación es: ¿Por qué no tenemos mediciones adecuadas actualmente? Las respuestas: (1) Se requiere tiempo y esfuerzo; (2) La evaluación responde a la cultura existente en la organización: (2.1) históricamente no se ha medido la calidad de las funciones de servicios y las administrativas; (2.2) históricamente las mediciones se han usado para castigar, no para recompensar; (2.3) las expectativas y necesidades tendrán que ser definidas más claramente. Para mejorar debemos saber dónde nos encontramos, y para saber dónde nos encontramos debemos evaluar, medir y estimar [7].
La pretensión de ofrecer un Modelo Sistémico de Evaluación de Herramientas de Software de Control Remoto, como reza el título de este articulo, pasa entonces por la definición de los tres elementos esenciales: evaluación: (para qué evaluamos) qué se pretende hacer con los resultados de la evaluación y quién está interesado en hacerlo; comparación: qué base de comparación se utiliza para juzgar el valor, es decir, cuáles son los criterios valorativos que servirán de patrón para contrastar con ellos la situación conocida; conceptualización: qué es necesario conocer de las herramientas a evaluar, lo cual supone claridad conceptual sobre las dimensiones que encierra la situación a la que se le da nombre, y desglosar esas dimensiones en aspectos concretos, que sirven para definir un conjunto de indicadores que se puedan observar, describir o medir. La garantía para la validez de ese conocimiento sobre lo que se pretende evaluar incluye definir cómo se obtiene, es decir, qué modelos, metodologías, métodos y técnicas se utilizarán, con una fundamentación teórica que garantice esa validez.
Todos estos elementos de comparación dentro de un modelo sistémico y orientado a la evaluación de herramientas de control remoto permitirán desglosar esas dimensiones en aspectos concretos, que sirvan para definir un conjunto de indicadores que se puedan observar, describir o medir. Esta investigación busca establecer las relaciones y condiciones necesarias entre el pensamiento sistémico y la perspectiva de evaluación, dentro de un modelo diferenciador que permita obtener una buena estimación y un conjunto de criterios para evaluar exitosamente el uso del software en el marco de los intereses del negocio, utilizando como caso de estudio las herramientas de software de control remoto. En la próxima sección se estudia en detalle la metodología aplicada para llevar a cabo esta investigación y el desarrollo y aplicación del modelo.
La metodología propuesta para la elaboración de esta investigación, es una instanciación de la metodología Systemic Evaluation for Stakeholder Learning (SESL) propuesta por Magnus Ramage en 1997, para los sistemas de trabajo cooperativo (Cooperative Work): La combinación de la tecnología, personas y la organización que facilita la comunicación y coordinación necesaria para que un grupo trabaje efectivamente con la finalidad de alcanzar un objetivo común [8]. Teniendo en cuenta que los escritorios de ayuda (Helpdesk) y las herramientas de control remoto de fallas junto con la Organización constituyen un sistema de trabajo cooperativo, y tomando como referencia la metodología SESL, se propone una instanciación de esta metodología a través de los siguientes pasos: (1) Determinar la naturaleza del sistema para conformar el marco teórico referencial; (2) Determinar el tipo de evaluación; (3) Identificar individuos que afectan al sistema; (4) Estudiar y analizar las preguntas claves; (5) Diseñar el Modelo Sistémico de Evaluación de Herramientas de Software de Control Remoto; (6) Aplicar el modelo y (7) Retroalimentación de los resultados. Como se muestra en la Figura 1.
Donde el paso 5 involucra la elaboración de un conjunto de preguntas que servirán como instrumento de medición de acuerdo a los insumos del paso 4 y tomando como referencia los usuarios identificados en el paso 3, cumpliendo además con las restricciones impuestas en los pasos 1 y 2. Finalmente el paso 6 consiste en la ejecución del modelo a un caso del mundo real (utilizando como ambiente la organización CANTV caso de estudio que en detalle puede ser consultado en la tesis respectiva) a través del instrumento de evaluación y la ponderación respectiva de acuerdo al modelo matemático propuesto en el paso 5.
A continuación en la próxima sección se presentan los resultados de aplicar la metodología, obteniendo así el Modelo Sistémico de Evaluación de Herramientas de Software de Control Remoto (MOSEHSARF).
III. Resultados
El modelo sistémico de evaluación MOSEHSARF puede describirse en términos de la Teoría General de Sistemas (TGS) como un conjunto de ENTIDADES caracterizadas por poseer ciertos ATRIBUTOS, los cuales mantienen RELACIONES entre sí y están localizados en un determinado AMBIENTE de acuerdo a un cierto OBJETIVO [9]. La representación del sistema de estudio utilizando la teoría general de sistemas, presenta una utilidad práctica, ligada a la sencillez, proponiendo un enfoque top-down en su descripción (Figura 2).
De acuerdo al estudio del sistema a evaluar (primer paso de la metodología) los individuos afectados (stakeholders) pueden ser definidos a través de las entidades. Se estudian además los intereses de cada uno de ellos. De acuerdo a los intereses establecidos para los stakeholders, a continuación es necesario establecer las preguntas claves y aplicar algún instrumento para obtener los resultados (sugerido: cuestionarios).
La arquitectura del modelo propuesto (Figura 3), contempla seis etapas: (1) Complejidad: cuantificación de la complejidad de la organización de soporte interno; (2) Costo de Soporte: costos de la organización de soporte interno sin herramientas de control remoto de fallas; (3) Impacto Control Remoto: impacto de las herramientas de control remoto de fallas sobre los costos de la organización de soporte interno. Disminución en tiempos de atención y número de llamadas; (4) Costo Control Remoto: cuantificación del costo total (planificación, procura, implementación, operación, adquisición y reemplazo) de la herramienta de control remoto; (5) Efecto Económico: cuantificación final del beneficio económico; (6) Retroalimentación: comunicación de los resultados de la evaluación, el proceso de decisión asociado y de aprendizaje organizacional (ya sea para la evaluación de los efectos o de la compra). Inicialmente en el modelo se realiza el cálculo de la complejidad según la Tabla 1.
Factores que determinan la Complejidad de la Gerencia de TI. Adaptado [10]
% Factor | Factor | Medición | ||||
0.225 (1) | Complejidad de la Estructura | Altamente Centralizada 0.20 | Centralizada 0.40 | Dispersa 0.60 | Descentralizada 0.80 | Altamente Descentralizada 1 |
0.375 (1) | Madurez de los Procesos | Tiene, usa, documenta, administra y optimiza los procesos de TI 0.20 | Tiene, usa, documenta, administra los procesos de TI 0.40 | Tiene, usa, documenta los proceso de TI 0.60 | Tiene y usa los procesos de TI 0.80 | Tiene proceso de TI 1 |
0.051 (1) | Dispersión de los Usuarios | Altamente Centralizados 0.20 | Centralizados 0.40 | Dispersos 0.60 | Descentralizados 0.80 | Altamente Descentralizados 1 |
0.0495(1) | Disponibilidad de los Servicios de TI | 5x8 díasxhora 0.20 | 6x9 díasxhora 0.40 | 7x12 díasxhora 0.60 | 7x15 díasxhora 0.80 | 7x24 díasxhora 1 |
0.0495 (1) | Niveles de Acuerdo de Servicio | Próximo día o mejor esfuerzo 0.20 | Próximo día garantizado 0.40 | Mismo día garantizado 0.60 | 4 horas 0.80 | Inmediato o menor a 30 minutos 1 |
0.067 (2) | % de Aplicaciones que son Cliente / servidor | 20 o menos 0.20 | 40 0.40 | 60 0.60 | 80 0.80 | 100 1 |
Tabla 1
(Continuación)
% Factor | Factor | Medición | ||||
0.0335 (2) | Numero de Plataformas de Sistemas Operativos Diferentes | 1 0.20 | 2 0.40 | 4 0.60 | 6 0.80 | Mayor a 6 1 |
0.02512 (2) | Tiempo promedio de reemplazo de Aplicaciones Cliente / servidor | 3 meses 0.20 | 6 meses 0.40 | 12 meses 0.60 | 24 meses 0.80 | Mayor a 30 meses 1 |
0.02512 (2) | % Aplicaciones Criticas | 20 o menos 0.20 | 40 0.40 | 60 0.60 | 80 0.80 | 100 1 |
0.01675 (2) | % Aplicaciones de Productividad Personal | 100 0.20 | 80 0.40 | 60 0.60 | 40 0.80 | Menor a 20 1 |
0.04125 (3) | # de Arquitecturas Distintas de Hardware | 1 0.20 | 2 0.40 | 4 0.60 | 6 0.80 | Mayor a 6 1 |
0.02475 (3) | Porcentaje Anual de Reposición de PC | 10% o menos 0.20 | 20% 0.40 | 50% 0.60 | 70% 0.80 | 100% 1 |
0.00825 (3) | Redundancia (% de Servidores, ubs, router con redundancia) | 100% 0.20 | 70% 0.40 | 50% 0.60 | 20% 0.80 | 10% o menos 1 |
0.00825 (3) | % de Dispositivos Móviles o Portátiles | 10% o menos 0.20 | 20% 0.40 | 50% 0.60 | 70% 0.80 | 100% 1 |
A partir del cálculo del porcentaje de Complejidad se puede utilizar una escala (0-9) con la finalidad de establecer un nivel de complejidad de la gerencia de TI en la organización.
Nivel Complejidad = 1+ (8x% Complejidad) (1)
El estudio predictivo toma los cambios en los factores de complejidad y los aplica a todos los cálculos de costos a fin de predecir los nuevos valores.
Una vez establecido el porcentaje y el nivel de complejidad de la Gerencia de TI, se procede a realizar el cálculo del costo de soporte, para lo cual es necesario calcular el número total de llamadas en el periodo de evaluación, de acuerdo a la siguiente ecuación:
llamadas = PC ´ [meses ´ llampromusu] + [(ActSOP + ActApli) ´ (llampromAct)] (2)
Donde, el símbolo PC representa el número de computadoras personales, meses el número de meses del periodo de evaluación, llampromusu las llamadas mensuales promedio por usuario, ActSOP la cantidad de actualizaciones de sistema operativo, ActApli las actualizaciones de aplicaciones y llampromAct el número promedio de llamadas por actualización.
llamadas (mejor caso)= PC x (meses + 5) (3)
llamadas(peor caso) = PC ´ [(meses ´ 3.5) + 14] (4)
Gartner Group, nuevamente sugiere una distribución para los tipos de llamadas y sus tiempos de atención en el primero y segundo nivel en un mejor y peor caso (Tabla 2).
Porcentajes de Distribución de las llamadas y Tiempos promedio de Atención para el Helpdesk (1er. Niv.) y Soporte en Sitio (2do. Niv.). Fuente: Adaptado de Gartner Group [10]
Tipo de llamada | (di-) (mejor) 1er.Niv. | (di+) (peor) 1er.Niv. | (ti-) (mejor) 1er.Niv. | (ti+) (peor) 1er.Niv. | (di-) (mejor) 2do.Niv. | (di+) (peor) 2do.Niv. | (ti-) (mejor) 2do.Niv. | (ti+) (peor) 2do.Niv. |
Requerimiento de Servicio | 22% | 4% | 7.5 min. | 15 min. | 0% | 0% | 7.5 min. | 15 min. |
Mantenimiento | 8% | 2% | 7.5 min. | 15 min. | 30% | 50% | 30 min. | 60 min. |
Mudanza | 2% | 2% | 7.5 min. | 15 min. | 60% | 80% | 30 min. | 60 min. |
Instalación | 8% | 1% | 7.5 min. | 15 min. | 60% | 80% | 30 min. | 60 min. |
Consulta | 36% | 27% | 15 min. | 30 min. | 0% | 10% | 15 min. | 30 min. |
Reparación | 10% | 14% | 15 min. | 30 min. | 18% | 25% | 15 min. | 30 min. |
Cambio de Clave | 2% | 25% | 7.5 min. | 15 min. | 0% | 2% | 7.5 min. | 15 min. |
Interrupción | 12% | 25% | 3.7 min. | 7.5 min. | 50% | 60% | 30 min. | 60 min. |
A continuación se tiene que
Costo_ Operación = llamadas ´ tiempo promaten ´ costoop (5)
Donde 0 < i < 9 representa el tipo de llamada, i=1 requerimiento de servicio, i=2 mantenimiento, i=3 mudanza, i=4 instalación, i=5 consulta, i=6 reparación, i=7 cambio de clave, i=8 interrupción. La variable llamadas representa el número total de llamadas en el periodo de evaluación, tiempopromaten es el tiempo promedio de atención, costop es el costo de operación en dólares por hora y costohelpdesk es el costo en dólares por hora del helpdesk.
Finalmente el costo original de soporte (COS) se determina a partir de:
Donde j representa los diferentes niveles de soporte de la organización. Por ejemplo j=1 Helpdesk, j=2 Servicio de Campo, j=3 Proveedor Nacional, j=4 Proveedor Regional, j=5 Proveedor Internacional.
Los dji son el porcentaje de llamadas tipo i del nivel de soporte j-1 que pasan al nivel de soporte j. Con d0i=1
tji representa el tiempo promedio de resolución para el tipo de llamada i por el nivel de soporte j.
costoj es el costo en horas asociado al nivel de soporte j.
Es importante aclarar que las llamadas atendidas en el nivel j son un porcentaje de las atendidas en el nivel j-1 es por esto que existe la multiplicación de los factores d(j-1)i x dj
Una vez establecido el costo original de soporte es necesario calcular el mismo costo pero aplicando el impacto de implementar las herramientas de control remoto, para esto se pueden tomar mediciones en el caso de que el software haya sido implementado antes del estudio o se pueden utilizar las siguientes mediciones sugeridas por el Gartner Group Tabla 3.
Impacto de las herramientas de control remoto de fallas sobre la operación del Helpdesk y servicio de campo. Fuente: adaptado de Gartner Group [10]
%Disminución Tiempo (min) (mejor caso) | % Disminución Tiempo (min) (Peor caso) | % Disminución # llamadas (mejor caso) | % Disminución # llamadas (peor caso) | |||||
Tipo de llamada | 0% | Soporte sitio | Helpdesk | Soporte sitio | Helpdesk | Soporte sitio | Helpdesk | Soporte sitio |
Requerimiento de servicio | 30% | 0% | 0% | 0% | 0% | 0% | 0% | 0% |
Mantenimiento | 0% | 0% | 15% | 0% | 0% | 0% | 0% | 0% |
Mudanza | 30% | 0% | 0% | 0% | 0% | 0% | 0% | 0% |
Instalación | 80% | 30% | 15% | 15% | 0% | 5% | 0% | 0% |
Consulta | 30% | 80% | 70% | 70% | 5% | 5% | 0% | 0% |
Reparación | 0% | 0% | 10% | 0% | 5% | 0% | 0% | 0% |
Cambio de clave | 0% | 0% | 0% | 0% | 0% | 0% | 0% | 0% |
Interrupción | 0% | 0% | 0% | 0% | 0% | 0% | 0% |
De tal forma que el Costo de soporte con RC o Costo Reducido de Soporte (CRS), se expresa de la siguiente manera:
Donde j representa los diferentes niveles de soporte de la organización. Por ejemplo j=1 Helpdesk, j=2 Servicio de Campo, j=3 Proveedor Nacional, j=4 Proveedor Regional, j=5 Proveedor Internacional.
dlji = es el porcentaje de disminución por uso de la herramienta en el número de llamadas del tipo i del total de llamadas asociadas al nivel de soporte j. Con i y j como en los casos anteriores. Con d0i=1
dtji = es el porcentaje de disminución por uso de la herramienta en el tiempo promedio atención del tipo de llamada i del total de llamadas asociadas al nivel de soporte j. Con i y j como en los casos anteriores. Con d0i=1
tji = representa el tiempo promedio de resolución para el tipo de llamada i por el nivel de soporte j.
cj = es el costo en horas asociado al nivel de soporte j.
Una vez calculado el costo de soporte con la reducción introducida por la herramienta, a continuación es necesario calcular el costo de la herramienta H, tomando en cuenta las características discutidas referentes a los costos asociados al ciclo de vida del producto, el cual puede calcularse de acuerdo a la siguiente ecuación:
H = {PC ´ [Hplan ´ Plan + Hneg ´ Neg + Himple ´ Im ple + Hop ´ Op]}+ Licen + Mant + Sop + Re (9)
Donde H representa el costo de la Herramienta, PC es el numero de computadoras personales, Hplan corresponde a las horas de planeación, Plan al costo de planeación, Hneg las horas de negociación o procura, Neg el costo de negociación, Himple las horas de implementación, Imple el costo de implementación, Hop las horas de operación, Op el costo de operación, Licen el costo de licenciamiento, Mant el costo de mantenimiento, Sop el costo de soporte y Re el costo de reemplazo.
Se pueden tomar los costos en caso de que ya se haya realizado la implementación del producto, o se pueden asumir los costos que sugiere Gartner Group mostrados a través de la Tabla 4.
Costos de la Herramientas de Control Remoto de Fallas. Fuente: Adaptado [10]
| Horas x PC | Horas x PC |
Tipo de Costo | (mejor caso) | (peor caso) |
TOTAL Planeación | 0.016 | 0.048 |
TOTAL Negociación | 0.002 | 0.01 |
TOTAL Implementación | 0.2644 | 0.7312 |
Instalación y tareas relacionadas | 0.1076 | 0.2812 |
Actualización | 0.088 | 0.2436 |
Instalación al Usuario Final | 0.0688 | 0.2064 |
Costo $ x Hora (mejor caso) | Costo $ x Hora (peor caso) | |
TOTAL Operación | 0.02 | 0.04 |
Entrenamiento | 0.02 | 0.04 |
TOTAL Adquisición | $32.50 | $174.50 |
Licenciamiento | $10.00 | $100.00 |
Hardware | $15.00 | $30.00 |
Soporte (anual) | $2.00 | $20.00 |
Mantenimiento Hardware (anual) | $2.50 | $4.50 |
Mantenimiento Software (anual) | $3.00 | $20.00 |
Costo $ x Hora (mejor caso) | Costo $ x Hora (peor caso) | |
Líder de Proyecto | $60.00 | $80.00 |
Especialista de TI | $50.00 | $60.00 |
Técnico | $30.00 | $50.00 |
Finalmente generalizando la ecuación 9 a partir de la ecuación 8 para diferentes niveles ecuación 10 de soporte y tipos de llamadas, se obtiene la ecuación 10 Costo Real (CR):
Esta ecuación debe ser mayor que cero para obtener un efecto económico positivo, lo que indica que lo que pagaba antes la empresa por mantener la operación debe ser mayor de lo que se pagará al reducir los costos a consecuencia de implementar la herramienta, además del costo en el que la organización incurre al ejecutar el proyecto. Donde el Costo Original de Soporte - Costo Reducido de Soporte es el Ahorro que se obtiene al implementar la herramienta sin incluir el costo del proyecto (H).
De la ecuaciones 11 y 12 con un ECC positivo se deriva la siguiente desigualdad:
Esta ecuación (ecuación 12), indica que si se conoce la situación actual y se aproxima con certeza el costo del proyecto de implantación de la herramienta, se obtiene una meta mínima del nuevo costo reducido. Si el Costo Reducido es igual al Costo Anterior, la empresa se encuentra en la situación inicial, es decir no mejoro al implantar la herramienta. Si el Costo Reducido es cero, quiere decir que la herramienta elimina todas las llamadas o llevó todos los tiempos a cero y ésto es una situación utópica.
Finalmente el modelo establece la realización de una fase de retroalimentación donde se comuniquen los resultados. Luego de obtener los datos finales de la relación de la evaluación, éstos son analizados con el objetivo de obtener resultados que conduzcan a conclusiones relevantes en cuanto al comportamiento del modelo de evaluación y de las herramientas de control remoto en la organización de soporte interno.
Si se conducen ambos estudios, el estudio predictivo con las tablas de Gartner por que se desea comprar la aplicación y el estudio evaluativo ya que la aplicación está en funcionamiento, se puede realizar un tercer análisis correspondiente a un estudio comparativo entre los dos resultados utilizando la arquitectura del modelo.
Para la aplicación del modelo de evaluación, se tomó la empresa venezolana CANTV, en la cual se contemplaron cada una de las seis etapas propuestas en la arquitectura del modelo. Con la finalidad de validar el modelo en su totalidad, se realizaron dos estudios de evaluación separados: un estudio predictivo y un estudio evaluativo en base a los dos años de utilización de la herramienta de software Remote Control de IBM-Tivoli implementada en CANTV a partir del 1 de enero del 2000.
IV. Discusión de Resultados y Conclusiones
Comparando este modelo con los propuestos por Flagg 1990, Strovink 1998 y Garner Group 2000 y algunos otros autores asociados a la calidad del producto de software (Booch 1994, Segovia 1996, Fenton 1997, Hopkins 1997, Rumbaugh 1998 y Patrick 2000) se evidencia que sus bondades fundamentales se encuentran en la utilización de la teoría general de sistemas en la representación del sistema objeto y la organización de soporte como un sistema abierto, así como el subsistema de control que lo sustenta, permitiendo establecer una abstracción del mismo que garantice su aplicación no sólo en el ámbito de otras organizaciones de soporte y otras herramientas de control remoto, sino en especial en la evaluación de otro tipo de software, igualmente se destaca en este estudio la relación entre la complejidad de la gerencia de tecnología de la información y el retorno de inversión asociado a las inversiones de software en el marco de los intereses del negocio.
El Modelo, permite obtener una visión clara de la organización de soporte interno y de su entorno en cuanto a la capacidad, necesidad y voluntariedad para adoptar y usar una herramienta de control remoto, así como su participación en el logro de los objetivos, de manera que se reduzcan los riesgos asociados a su implantación y uso.
El Modelo determina como influye la complejidad de la Organización en el componente económico, en la efectividad del soporte y en la efectividad del proyecto, teniendo en cuenta factores de costos que normalmente no son utilizados al medir el impacto del software en la organización (costo de negociación, planeación, implementación, reemplazo, etc.). Así como también, permite determinar tendencias, detectar debilidades y factores de mejora asociados a la obtención de un efecto económico positivo.
A través de este estudio se puede determinar que la complejidad de la organización, el tiempo promedio de atención, el factor de disminución y el costo del proyecto son los factores claves en la organización de soporte interno. Los costos por hora en el modelo predictivo, dan una cota de hasta cuanto debe pagar la organización para mantener el proyecto, es decir ellos influyen directamente en el ahorro y éste último acota el presupuesto asociado a la herramienta. Cuando se aumentan los costos por hora de los diferentes niveles de soporte se disminuye el potencial de efecto económico positivo. Además los costos de atención están en función de la disminución en los tiempos de atención y llamadas evitadas. El hecho de que los costos de soporte disminuyan notablemente no implica que se obtendrá un efecto económico positivo, si se siguen manteniendo igual los porcentajes de disminución asociados al impacto de la herramienta.
En cuanto a las limitaciones se tiene que el modelo aplica. Sin embargo, existen otras variaciones de la organización de soporte interno que pueden involucrar que los costos disminuyan y se calculen de una forma diferente al modelo. Cabe destacar que los resultados finales obtenidos se ajustan al caso de estudio en particular. Es decir, al cambiar las condiciones del caso, los resultados obtenidos en la aplicación del Modelo podrían ser diferentes. Las limitaciones confrontadas en cuanto a la veracidad de las respuestas de los cuestionarios, impiden asegurar con total certeza la representatividad de la muestra. Esta situación restringe la validez estadísticas de las generalizaciones a las poblaciones de las muestras. Pero los trabajos que brindan información sobre el comportamiento de usuarios reales son necesarios y deseables para el progreso y el desarrollo de sistemas de control aún cuando el comportamiento sea observado en muestras pequeñas no controladas.
Otros estudios futuros podrían orientarse en la evaluación del método desde la perspectiva de la investigación de operaciones con la finalidad de obtener valores exactos de la forma como las variables pueden combinarse para garantizar la eficacia de la organización. Además de concluir / desarrollar estudios topológicos.
El Modelo fue programado en Excel a fin de ser implementado en forma predictiva y evaluativa obteniendo una herramienta de automatización denominada MOSEHSARF.
V. Agradecimientos
El Autor desea agradecer toda la colaboración recibida de las compañías involucradas que permitieron una aproximación a una realidad venezolana.
Referencias Bibliográficas
1. Strassmann, P.: Getting better value from information management Information Economics Journal, 2003. [ Links ]
2. Flagg, B.: Software Evaluation. Hillsdale, New Jersey. Lawrence Erlbaum Associates, Publishers 1990. [ Links ]
3. Campos, F., Campos, G. & Rocher, A.: Dez etapas o desenvolvimiento de software. 3er congreso iberoamericano de informática, Barranquilla Colombia 1996. [ Links ]
4. Paredes, L.: Gestión Tecnológica y reconversión industrial. Revista Espacios, Vol 12. Num. 3. pp. 59-77, 1991. [ Links ]
5. Garner Group Inc. Hiring for the 21st Century. The Public Workshops 2000. [ Links ]
6. Symantec Latin America Headquarters. Enterprise remote control 2001. [ Links ]
7. Evans, J.: Administración y control de la calidad. International Thomson Editorial. S.A. México 5ta Edición 2001. [ Links ]
8. Manus, R.: Developing a Methodology for the Evaluation Cooperative Systems 1997. [ Links ]
9. Johansen, B. Introducción a la teoría general de sistemas. Editorial Limusa, Mexico DF. 1997. [ Links ]
10. Strovink, K., Paquet, R., Keyworth, B., Ardito, Smith. Lowering Support Costs UIT LAN Management Tools. Strategic Analysis Report Garner Group 1998. [ Links ]