Universidad de Los Andes ESICO RESUMEN ADQUISICION DE SOFTWARE EN

Universidad de Los Andes ESICO RESUMEN ADQUISICION DE SOFTWARE EN LA UNIVERSIDAD DE LOS ANDES GUIA METODOLÓGICA RESUMEN ADRIANA HERNANDEZ MUÑOZ UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE INDUSTRIAL ESPECIALIZACIÓN EN SISTEMAS DE CONTROL ORGANIZACIONAL Y DE GESTIÓN BOGOTÁ D.C. 2002 4 Universidad de Los Andes ESICO RESUMEN ADQUISICION DE SOFTWARE EN LA UNIVERSIDAD DE LOS ANDES GUIA METODOLÓGICA RESUMEN Trabajo Final para optar al título de Especialista en Sistemas de Control Organizacional y de Gestión Asesores Internos OLGA LUCIA GIRALDO DE LÓPEZ JORGE ALBERTO GIL PEÑALOZA Asesor Externo FERNANDO SALCEDO GÓMEZ ADRIANA HERNANDEZ MUÑOZ Ingeniero de Sistemas y Computación UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE INDUSTRIAL ESPECIALIZACIÓN EN SISTEMAS DE CONTROL ORGANIZACIONAL Y DE GESTIÓN BOGOTÁ D.C. 2002 5 Universidad de Los Andes ESICO RESUMEN CONTENIDO INTRODUCCION 1. 2. 3. 4. 5. 6. OBJETIVO GENERAL....................................................................................................................... 13 OBJETIVOS ESPECIFICOS.............................................................................................................. 13 ALCANCE ............................................................................................................................................ 13 PLAN DE TRABAJO .......................................................................................................................... 14 MARCO TEORICO ............................................................................................................................ 16 PROCESO DE ADQUISCION DE SOFTWARE .......................................................................... 25 6.1. 6.2. 7. CADENA DE VALOR ....................................................................................................................... 27 FORMAS PARA ADQUIRIR SOFTWARE ........................................................................................... 30 METODOLOGIAS FUENTE ............................................................................................................ 36 7.1. CAPABILITY MATURITY MODEL (CMM)......................................................................... 39 7.1.1. Antecedentes ............................................................................................................................. 39 7.1.2. 7.1.3. Estructura ................................................................................................................................. 40 Beneficios del CMM ................................................................................................................. 44 7.2. INTERNATIONAL ORGANIZATION FOR STANDARZATION – ISO............................ 45 ISO 9000 NORMAS DE SISTEMAS DE GESTIÓN DE CALIDAD ................................................... 45 7.2.1. Introducción ............................................................................................................................. 45 7.2.2. Alcance ..................................................................................................................................... 46 7.3. CONTROL OBJETIVES FOR INFORMATION AND RELATED TECHNOLOGY – COBIT 48 7.3.1. Introducción ............................................................................................................................. 48 7.3.2. 7.3.4. 7.3.5. 7.3.6. 7.4. 8. Definición de Control .............................................................................................................. 49 Características ......................................................................................................................... 50 Componentes ............................................................................................................................ 51 Ventajas .................................................................................................................................... 53 COMPARACION........................................................................................................................ 54 EXPERIENCIA ACTUAL .................................................................................................................. 56 8.1. 8.2. 8.3. 8.4. SISTEMA DE BIBLIOTECAS............................................................................................................ 56 SISTEMA DE ADMINISTRACIÓN DE ADMISIONES Y REGISTRO – BANNER................................ 58 SISTEMA DE LA OFICINA DE RECURSOS HUMANOS – NÓMINA Y APLICACIÓN WEB.................. 60 SISTEMA INTERACTIVO DE CURSOS DE LA UNIVERSIDAD DE LOS ANDES. ................................. 62 9. ANALISIS DE RIESGOS PARA EL PROCESO DE ADQUISICION ...................................... 66 10.1. 10.2. 10.3. 10.4. ¿QUÉ ES UN ANÁLISIS DE RIESGOS? ............................................................................................. 66 ¿PARA QUÉ SIRVE? ....................................................................................................................... 68 ¿CÓMO REALIZAR UNA ANÁLISIS DE RIESGOS?........................................................................... 69 ANÁLISIS DE RIESGOS EN EL PROCESO DE ADQUISICIÓN DE SOFTWARE .................................. 70 6 Universidad de Los Andes ESICO RESUMEN 10. 11. 12.1. 12.2. 12.3. PUNTOS CLAVES EN EL PROCESO DE ADQUISICION................................................... 81 GUIA METODOLOGICA ............................................................................................................ 85 INTRODUCCIÓN ............................................................................................................................. 86 PROPUESTA GUÍA METODOLÓGICA PARA EL PROCESO DE ADQUISICIÓN DE SOFTWARE ....... 87 DESCRIPCIÓN Y RAZONES DE LAS ETAPAS PROPUESTAS ............................................................. 90 CONCLUSIONES BIBLIOGRAFÍA 7 Universidad de Los Andes ESICO RESUMEN GLOSARIO Proceso de Software: Conjunto de actividades, métodos, prácticas y transformaciones para desarrollar, y mantener software y productos asociados. Capacidad de un proceso: Rango de resultados esperados que se pueden obtener tras seguir un proceso. Madurez de un proceso de software: Punto en el cual un determinado proceso es explícitamente definido, administrado, medido, controlado y efectivo. Nivel de Madurez: Plataforma bien definida desde la cual se obtiene un proceso maduro de software. Grado de institucionalización y pertenencia que puede llegar a tener un proceso o proyecto en el diario vivir de la organización. Institucionalizar: Identificar una infraestructura y una cultura que soporte los métodos, las prácticas y los procesos para que estos sean la manera real de hacer negocios. Actividad: Cualquier paso o función que se realiza (mental o física) para alcanzar algún objetivo. Rendimiento del los procesos de software: Resultados actuales logrados siguiendo los procesos de software. Área clave de proceso: Grupo de actividades relacionadas que cuando se llevan a cabo en conjunto alcanzan un conjunto de metas (consideradas importantes para aumentar la capacidad del proceso). KPAs Stakeholders: Grupos de interés participantes de forma indirecta o directa en el desarrollo de un proceso. Definir de manera correcta estos grupos influye en el éxito y fortalezas del proceso o proyecto. 8 Universidad de Los Andes ESICO RESUMEN Propiedades emergente: Características que surgen y se desarrollan a medida que un sistema es coherente, autorregulado y autónomo; dichas características no son tangibles. Lista de chequeo: Serie de pasos, secuenciales y relacionados entre sí en ocasiones, los cuales proveen información sobre el correcto funcionamiento de procesos, sistemas y comportamientos. Outsorcing: Mecanismo de provisión de servicios. Recursos IT: Datos, sistemas aplicativos, tecnología, facilitadores y personal. “Firewall” == Contrafuego : Un cortafuegos es una barrera para evitar que el fuego se expanda. Los edificios disponen de cortafuegos, muros de ladrillos que dividen las diferentes secciones del edificio. En un coche, un cortafuegos es la plancha de metal que separa al motor del compartimiento de los pasajeros. La misión de los cortafuegos de Internet es garantizar la seguridad de nuestro equipo ante los peligros cibernéticos de la red de área local (LAN) o bien, mantener a los miembros de esa LAN al margen de las malignas intenciones de Internet. http://ibiblio.org/pub/Linux/docs/HOWTO/translations/es/Cortafuegos-COMO.gz CMM: Capability Maturity Model. Es una metodología que describe elementos claves de un proceso de software eficaz, describe una ruta de mejoramiento evolutivo para pasar desde un proceso inmaduro a un proceso maduro y disciplinado, basado en conicimiento9s adquiridos de evaluaciones de los procesos de software y extensas retroalimentaciones con el entrono donde interactúa la organización. COBIT: Control Objetive for Information and related Techonogy. Es una entidad que proporciona unos principios para los administradores de proceso que se desarrollan en Tecnologías de información y que deben responder de manera eficiente y efectiva tanto para el negocio de la organización como para su control. 9 Universidad de Los Andes ESICO RESUMEN ISO: International Organization for Standardization. Conjunto de normas y directrices internacionales para la gestión de calidad. Caja negra cerrada: Solución de Tecnologías de información, donde no se conoce su funcionamiento interno, el código fuente no es entregado y no es posible su intervención por terceros. Caja negra modificada o parametrizada: Solución de Tecnologías de información, donde no se conoce su funcionamiento interno, el código fuente no es entregado y es posible su intervención por terceros y su parametrización. 10 Universidad de Los Andes ESICO RESUMEN INTRODUCCION En la actualidad parte del valor agregado de una organización se ve representado en (el alto nivel de entrenamiento de) su personal, herramientas tecnológicas1, sistemas e información. Todas las mediciones, aunque dependen de las actividades, responsabilidad y desempeño del personal, también deben tener en cuenta el papel que juegan las herramientas tecnológicas en el día a día y su impacto. Cuando se habla de herramientas tecnológicas, se hace referencia a la capacidad y estado de los servidores y aditamentos físicos; infraestructura de los canales de comunicación utilizados y el software, constituido por todas aquellas aplicaciones desarrolladas o adquiridas por la organización para cumplir con las metas organizacionales. Al hablar de software, se ingresa en un campo amplio en el cual actividades como: levantamiento de requerimientos, búsqueda en el mercado de soluciones, realización de términos de referencia, evaluación de propuestas, adquisición, implementación, capacitación, puesta en producción y seguimiento del software, son eslabones de una cadena. Algunas parte de la cadena pueden cambiar si se trata de adquirir un producto desarrollo a la medida y en casa, o hecho a la medida y fuera de casa, o una solución genérica y adaptable2 a la organización. El problema de la adquisición de software y aplicaciones para la Universidad de Los Andes, radica en que cada unidad de la organización es autónoma para la compra de los mismos. Lo anterior genera y hace que surjan demoras e Herramientas Tecnológicas: Conjunto de comprendes de Software, Hardware e infraestructura de comunicaciones. Solución adaptable : Solución de sistemas de información, que cumpla con todos los requerimientos de funcionamiento y la integración con otros sistemas de información existentes sea del 95%. 2 1 11 Universidad de Los Andes ESICO RESUMEN inconvenientes dentro del funcionamiento normal da la organización, ya que la infraestructura se puede ver afectada por la adquisición de herramientas sin el debido conocimiento de la misma; como ejemplo de esto tenemos el caso de la Facultad de Administración, la cual adquirió como plataforma de trabajo en grupo Exchange de Microsoft, sin tener en cuenta la seguridad de la Universidad , la red y hasta el momento no han logrado poner a funcionar en la totalidad la solución. Surge entonces la pregunta: ¿Cómo se puede escoger correctamente un software que responda a las necesidades de la organización de forma armónica y siendo parte activa del engranaje que forma la infraestructura informática de la empresa?. Hay que revisar y evaluar los procesos y/o metodologías de adquisición de software que se utilizan, qué tan representativos son para las necesidades de la empresa, quiénes participan en el proceso de adquisición, cómo se evalúa el nuevo producto, etc. Se debe tener en cuenta que la Universidad está compuesta por dos tipos de población en su estructura organizacional, a saber: Las dependencias administrativas (Recursos Humanos, Planta Física, DTI, etc), y las dependencias o departamentos académicos (Facultades y departamentos). Dentro de algunas dependencias académicas se encuentran centros de cómputo, los cuales influyen en la adquisición de software. 12 Universidad de Los Andes ESICO RESUMEN 1. OBJETIVO GENERAL Aplicar los conocimientos adquiridos en la Especialización de Sistemas de Control Organizacional y de Gestión, para generar una solución viable al problema de adquisición de software para la Universidad de Los Andes. El problema se abordará desde el punto de vista de la Auditoria de Sistemas y del Control Organizacional. 2. OBJETIVOS ESPECIFICOS o Realizar la revisión y evaluación de la forma como, hoy en día, se hace el proceso de adquisición en la institución en forma general. o Crear una guía metodológica que precise los parámetros adecuados para el proceso de adquisición de software, e integre a todas las unidades organizacionales de la Universidad que estén involucradas en el proceso mencionado. De esta manera se aumenta la probabilidad de escoger mejor el producto y el mas adecuado a las necesidades existentes, soportando, apoyando, mejorando y fortaleciendo los procesos y en consecuencia obtener los más altos beneficios en el rendimiento del personal en unión con la plataforma tecnológica existente en la Universidad. 3. ALCANCE Utilizando metodologías ya existentes para el proceso de adquisición de software, la revisión y evaluación del estado actual del proceso antes mencionado, se generará una 13 Universidad de Los Andes ESICO RESUMEN Guía Metodológica propia y específica para la adquisición de software para las áreas administrativa y académica de la Universidad de Los Andes. 4. PLAN DE TRABAJO Es una guía metodológica no una nueva metodología, debido a que no se propone una nueva teoría para hacer las cosas, simplemente se trata de tomar puntos claves de diferentes metodologías, analizar su viabilidad, aplicabilidad en el entorno y cultura organizacional de la Universidad para luego documentarla. “Vale la pena aclarar que una metodología nueva es algo más complejo que da para una disertación de doctorado”3. Para la realización de este trabajo, se proponen para ser analizadas y tomar puntos claves, 3 metodologías: “Capability Maturity Model” (CMM), ISO 9000 y “Control Objectives for Information and related Technology” (COBIT), esperando que éstas sean flexibles y adaptables a la taxonomía y cultura organizacional. No se pretende ser exhaustivo en esta revisión bibliográfica, sino tomar las más representativas y las que, en la actualidad en el entorno académico, se consideran relevantes. En paralelo al trabajo teórico, se realizará un trabajo de campo, el cual consiste en plasmar algunas de las experiencias que ha tenido la Universidad en el proceso de adquisición y que su nivel de impacto sea alto en la comunidad uniandina. Luego de identificar herramientas, debilidades y fortalezas a la hora de hacer la adquisición de un producto, se generan recomendaciones. Por último y con base a toda la 3 Frase citada por el profesor Jorge Alberto Gil Peñaloza. Universidad de los Andes. Abril de 2002 14 Universidad de Los Andes ESICO RESUMEN información antes citada, se creará la Guía Metodológica para la adquisición de software en la Universidad de Los Andes. Se tendrá en cuenta un análisis de riesgos para el proceso de adquisición; en la actualidad esta documentación no existe debido a que esta nueva área de estudio solo es disciplina desde hace aproximadamente cinco años. Para hacer un poco mas claro el plan de trabajo y luego de haber explicado las fases del proyecto, se presenta a continuación un diagrama de flujo que resume ésta labor y está conformado por el objetivo, dos grandes tipos de investigación (teórica y trabajo de campo) y por último el compendio de esta investigación. DIGRAMA DE FLUJO DEL PLAN DE TRABAJO. OBJETIVO Crear una Guía Metodológica para la Adquisición de Software para las áreas administrativas y académicas de la Universidad de Los Andes. Escoger 3 metodologías existentes para la adquisición de software. Aquellos que se acerquen mas a las características estructurales de la Universidad. Propuestas: CMM, COBIT e ISO Levantamiento de información: Experiencia actual, existencia de auditorias, estudios preliminares, documento de riesgos, entrevistas. Guía Metodológica 15 Universidad de Los Andes ESICO RESUMEN Figura 0. Plan de Trabajo 5. MARCO TEORICO La escogencia y modificación de la(s) estrategia(s) para el óptimo cumplimiento de las metas y objetivos que tiene una organización, se apoyan en los datos que generan los diferentes sistemas información. Los sistemas de información se pueden alimentar de datos simples (cifras, fechas) que no tienen relación entre si, pero también pueden alimentarse o ser parte del un sistema de control de gestión. El reto estratégico es, construir una organización que sea capaz simultáneamente de ajustar las expectativas de los “stakeholders” y la capacidad de recursos a una respuesta para los cambios que el entorno produce, de forma ágil y práctica para la adaptación, siempre y cuanto se conozca la realidad de la organización tanto interna como externa. El cambio de estrategia debe ser un proceso continuo de ajustes pequeños de la estrategia o de los controles de gestión existentes, en los subsistemas que necesiten los cambios. [2] Para valorar la capacidad estratégica de la organización, se puede apoyar en el análisis de recursos como herramienta. Esta herramienta se ve reflejada en la utilización de la “Cadena de Valor”, la cual tiene tres características principales: Ayuda a comprender la capacidad estratégica de la organización. 16 Universidad de Los Andes ESICO RESUMEN - Se concentra en actividades de valor y los vínculos entre estas actividades. Existe una relación entre la capacidad y la forma en que se utilizan y controlan los recursos. Para el área tecnológica, la cadena de valor puede tener variantes dependiendo el negocio de la Organización que se analice, debido a que sus actividades primarias pueden están enfocadas en la atención al cliente, soporte de equipos únicamente o los dos, por ejemplo. A continuación se mostraran dos tipos de de cadenas de valor para el área tecnológica, la primera representa un el contexto genérico y la siguiente, refleja la cadena de valor del área tecnológica para la Universidad de Los Andes, tomando como mayor centro de computo la Dirección de Tecnologías de Información. Actividades de apoyo INFRAESTRUCTURA TECNOLÓGICA AUDITORIA Y CONTROL OPERACIÓN Logística de Entrada Producción Implementación Mercado y Soporte Actividades primarias Figura 1. Cadena de Valor área tecnológica 17 Universidad de Los Andes ESICO RESUMEN Actividades de Apoyo Infraestructura Redes y Telefonía Seguridad Bases de Datos DIRECCION DE TECNOLOGIAS DE INFORMACION Administración Servidores, Equipos e infraestructura Administración De Sistemas de Información Administración Servicios Web, Producción, Dominio .CO Línea 3333 Atención al Usuario en todas las áreas Actividades Primarias Figura 2. Cadena de Valor Dirección de Tecnologías de Información En la Figura 1, tenemos como actividades principales la logística de entrada y producción, que serían el equivalente de administración en todas las actividades primarias de la Figura 2, debido a que el administrar implica dar soporte y estar al tanto de las posibles necesidades que pueden llegar a tener los usuarios de los sistemas y por lo tanto soluciones validas y efectivas. Las soluciones pueden reflejarse inmediatamente en el área de producción ya sea que se desarrolle o adquiera algún tipo de software. La relación entre las necesidades o logística de entrada y el desarrollo es estrecha, de su comunicación depende el éxito de las estrategias impartidas para las metas organizacionales. 18 Universidad de Los Andes ESICO RESUMEN Precisamente una de esas relaciones, es el proceso de la Adquisición de Software el cual debe responder a las expectativas y necesidades de los grupos de interés que conforman la organización. El comportamiento de éste proceso es el mismo que el de un sistema –el todo es mayor que la suma de sus partes - , cuenta también con subsistemas, los cuales tienen propiedades emergentes y están relacionados entre sí. La estrategia para la adquisición de software es sólo una parte del rompecabezas de las estrategias genéricas que hacen parte de la estrategia de cada dependencia y a si mismo de la estrategia mayor de una organización. El proceso de adquisición se asimila a un sistema, su comportamiento y partes que lo conforman pueden variar, dependiendo el objetivo del negocio de la organización o su enfoque hacia ciertas prácticas y sus políticas internas. En la cadena de valor del proceso, las actividades relacionadas con el cómo se responde a las necesidades de los usuarios puede variar, subdividirse y en algunas ocasiones producir actividades dentro de cada actividad primaria predefinida. Actividades de Apoyo Control y Monitoreo de Servicios Conocimiento del Mercado y proveedores de software Capacitación técnica Seguimiento Adquisición De Software Necesidades de los usuarios: Funcionales y No funcionales Estudio de las posibles soluciones a las necesidades de los usuarios == Adquisición del Producto. Implementación E Implantación de la solución Mantenimiento y monitoreo de la solución adquirida. Actividades Primarias Figura 3. Cadena de Valor para el proceso de Adquisición de Software 19 Universidad de Los Andes ESICO RESUMEN Al ver el proceso como un sistema, se puede asimilar con el ciclo de vida de un producto, tiene un inicio y un fin y en cada etapa se requiere de un resultado que es prerrequisito de la siguiente etapa; así todos los pasos están relacionados y son eslabones que forman una cadena. Surgen así los factores críticos del proceso, tanto para las actividades primarias como para las apoyo. Para el caso de éste trabajo, el interés es el conocimiento y análisis de proceso de adquisición en la Universidad de Los Andes, a continuación se enunciarán los factores críticos de las actividades de la cadena de valor, basados en el entorno y funcionalidad de dicha organización. 20 Universidad de Los Andes ESICO RESUMEN A T ID D C IV A PR A IA IM R FA T R CO C ÍT O R IC A R ED N R D L PO T E T O E PR C SO OE Identifica los posibles quiebres entre los sistem yprocesos que realiza la as organización, por lotantom sus ejora relaciones. Identificar correctam ente: origen, causas de los vacíos a. N ecesidades de los usuarios: que esté generandoel sistem origen, causas de los vacíos Funcionales ynofuncionales que esté generandola falta de autom atizaciónde unproceso. N todas las soluciones a las o necesidades requierenel E studiode las posibles pra soluciones ==A dquisicióndel desarrolloocom de un softw Identificar de form are. a producto. puntual los casos donde se deba desarrolla ocom su prar, viabilidadyresultados deseados. Im entacióne plem im plantaciónde lasolución. Im entación: Etapas de plem diseño, desarrolloy/o adquisición segúnloestablecidoenlos Térm de R inos eferencia. Im plantación: H cum los acer plir T.R Yresponder a la necesidad. . R ealizar unanálisis concienzudode la situaciónyposibles soluciones, ahorra a la organizacióntiem yrecursos a la hora de po em prender el procesode im entación. plem A adquirir unsoftw conlas l are características específicas para la solución del problem reduce costos yaum los a enta beneficios entre los procesos que se integren. Establecer cronogram de control a ecanism para m el os edir M antenim yM iento onitoreode ym desem de la herram peño ienta. lasoluciónadquirida. Seguim ycom iento paraciónde resultados. A a evaluar si la soluciónfue la m yuda as correcta ycercana a laesperadoyhacer que el procesode adquisiciónevolucione según las condiciones que el m ercadoyla organizacióndicten. (N de M ivel adurez) Figura 4. Actividades Primarias- Factores Críticos 21 Universidad de Los Andes ESICO RESUMEN A T ID D C IV A A Y PO O FA T R CO C ÍT O R IC M paracontrolar laform edir a com se presta el servicio, nivel o de satisfaccióndel usuarioy posibles quiebres enla com unicación. A R ED N R D L PO T E T O E PR C SO OE Identificafallas ynecesidades tantodel usuariocom de los adm o inistradores del servicioyla organización. Evolucionar alapar conlas necesidades de laorganizaciónydel entornotecnológico. C ontrol yM onitoreodel Servicio Investigar de nuevos productos y A alaevolucióntecnológicadela yuda ercadoofrece. organizacióneidentificar los posibles C onocim del m iento ercadoy soluciones que el m proveedores conm desem enel ejor peño proveedores de softw are R enovacióndeproductos. m ercado. Preparar r al personal que adm inistrarálaherram para ienta undesem excepcional y peño conocim total del producto. iento Identificar cam factibles y bios viales quesedebanhacer al productoparaajustarloalas necesidades. Evitadem alahoraderesponder anteun oras im previsto. C apacitaciónT écnica Seguim iento A entalasatisfaccióndelos usuarios ala um horadeutilizar el servicio. Ser innovadores. Figura 5. Actividades de Apoyo- Factores Críticos A partir de una visión integrada de las características y debilidades de la empresa se puede diseñar un sistema que va a controlar el Plan de Gestión de la misma, basado en los siguientes instrumentos: 22 Universidad de Los Andes ESICO RESUMEN - La definición de los factores claves de éxito del negocio relacionadas con los del proceso: investigación, innovación y continua evolución en los proceso. - La identificación de los indicadores que van a permitir medir la evolución de los factores clave de éxito. - La fijación de objetivos cuantificados para cada indicador. El diseño de los cuadros de mando. El diseño de la organización de control: órgano de control, periodicidad, responsables, gestión de incidencias y desviaciones, etc. Para esto, se necesita que la empresa haya evolucionado con respecto a la visión de si misma y tenga en cuenta las diferentes formas de pensar para observar, analizar, controlar y hablar acerca de lo que es la organización como sistema. Por lo tanto el control no sólo se percibe como una herramienta de vigilancia, sino también como una nueva forma de gerenciar y administrar organización y cada uno de sus procesos. La forma de administrar se pude visualizar en cada una de los procesos que genera la adquisición, que se reflejan en las diferentes cadenas de valor que se pueden generar según sea el caso. Al ver a la organización como un sistema, donde uno de sus subsistemas es el proceso de adquisición de software y que de la administración correcta y coherente del proyecto depende su éxito, y futuras implementaciones y desarrollo de otros, ingresamos a la evaluación y revisión de las etapas del proceso y del mismo como marco general(actividades primarias-cadena de valor). Para ésta labor se incorpora la auditoria; está actividad debe estar encaminada a un objetivo específico, que es el de evaluar la eficiencia y eficacia con que se adquirió e implemento el software y cumplimiento del objetivo fundamental del proceso; el resultado de la auditoria es ayudar a la toma decisiones que permitan corregir los errores, en caso de que existan, o bien mejorar la forma de actuación para proyectos futuros. [1] 23 Universidad de Los Andes ESICO RESUMEN En términos generales el auditor hará énfasis en la revisión y evaluación de las actividades que conforman el proceso, para luego elaborar un informe para el ejecutivo, encaminado a un objetivo específico en el ambiente del proceso de adquisición de una herramienta computacional para los sistemas de información de una organización. [4] 24 Universidad de Los Andes ESICO RESUMEN 6. PROCESO DE ADQUISCION DE SOFTWARE El proceso de adquisición de software, involucra una serie de etapas que están relacionadas entre sí como se muestra en el capitulo anterior en la Figura 3. Cadena de Valor para el proceso de Adquisición de Software, que deben reflejar las soluciones a necesidades de la organización. Así mismo estas soluciones se basan en recursos tanto de personal como técnicos. La importancia de este proceso, se debe a que desde hace aproximadamente 2 décadas el principal desafío de la industria es mejorar la calidad del producto y reducir su costos. [6] “Las enormes capacidades de procesamiento y almacenamiento del hardware moderno representa un gran potencial de cálculo. El software es el mecanismo que nos facilita utilizar y explotar este potencial.”4 Cada organización debe formularse así misma una pregunta esencial: ¿Qué software necesitamos?. La respuesta siempre será valiosa para asegurar que la compra y utilización de software sea eficiente y efectiva. Adicionalmente la respuesta a esta pregunta guiará sus esfuerzos para trabajar en el marco de la ley. [5] Para dar respuesta a esta inquietud, se podría complementar el proceso con las siguientes preguntas: a. ¿La empresa está utilizando el software más adecuado para satisfacer sus necesidades?. 4 Roger S. Pressman. Ingeniería del Software- Un enfoque práctico. 25 Universidad de Los Andes ESICO RESUMEN b. ¿Su personal está satisfecho con los programas actualmente utilizados en la empresa? . c. ¿Hay otros programas que permitirán a su empresa operar de una manera más eficiente?. d. ¿Tiene instalado en sus equipos programas que ya no utiliza?. El proceso de adquisición debe ser capaz de integrar los siguiente aspectos: • • • • Identificar las necesidad de los usuarios, tanto funcionales como no funcionales. Desarrollar términos de referencia. ¿Qué y cómo es lo que se necesita?. Construir un Plan de Adquisición/Subcontratación/desarrollo de Software . Una lista de chequeo práctica/útil para determinar la estrategia de adquisición/desarrollo. • • • • Seleccionar un proveedor. Realizar el seguimiento de un proveedor. Evaluar la eficiencia de un proveedor. Aceptar los productos entregados por el proveedor de acuerdo con los requerimientos especificados previamente en los Términos de Referencia. • • • • • Realizar la transición al uso de los productos. Pruebas. Mantenimiento correctivo, preventivo y adaptativo. Soporte a usuarios. Capacitación a administradores y usuarios del producto. 26 Universidad de Los Andes ESICO RESUMEN • Documentar todos los procesos y actividades para conducir una sesión de lecciones aprendidas para un proyecto que involucra la adquisición de software a terceros. 6.1. Cadena de valor El análisis de la cadena de valor es un método útil para relacionar los recursos con los propósitos estratégicos. Es la clave para comprender la capacidad estratégica, ya que requiere un análisis que va más allá de un examen de recursos e investiga en detalle de qué manera se utilizan, controlan y articulan los mismos. Para cada proceso en la organización, se puede aplicar una cadena de valor, para así aumentar el nivel de competición de la empresa. Por esta razón a continuación se plantea el proceso de adquisición de software – solución caja negra - como un proceso que genera valor a la empresa, formando su propia cadena de valor relacionada con el ciclo de vida de un producto, debido a que para este documento, el producto es un proceso que se inicia con la carencia de herramientas y culmina con la implantación y capacitación para el manejo de la herramienta y suplir las necesidades que se generaron. Actividades de apoyo INFRAESTRUCTURA TECNOLÓGICA AUDITORIA Y CONTROL OPERACIÓN Logística de Entrada Producción Implementación Mercado y Soporte Actividades primarias 27 Universidad de Los Andes ESICO RESUMEN Figura 6. Cadena de Valor área tecnológica Actividades de Apoyo: Infraestructura tecnológica: Hace referencia al conjunto de sistemas de información, equipos y dispositivos técnicos que tenga la organización para facilitar los mecanismos de comunicaciones de la organización dentro de si misma y hacia fuera, de igual manera tiene en cuenta todos los mecanismos de almacenamiento de datos e información y en la estructura y rutinas de la organización que sustentan la cultura de ésta. Auditoria y Control: Son las tareas de vigilancia y acompañamiento a todos los procesos de la empresa. Esta tarea debe producir una serie de recomendaciones a seguir para el correcto funcionamiento de las labores diarias. Operación: Es el diario vivir de la organización, tareas las cuales se soportan directamente en la infraestructura tecnológica y aquellas que son independiente y no sistematizadas; pero que en conjunto forman la organización. Actividades Primarias: Logística de Entrada : Hacen parte de esta actividad todas aquellas tareas que tienen que ver con la identificación de necesidades tanto satisfechas como insatisfechas, nuevas potencialidades del negocio, problemas prioritarios a resolver. Producción: Podemos ver la actividad de producción como dos grandes grupos, el primero es la etapa de identificación de la necesidad, levantamiento de información, elaboración de los términos de referencia y seguridad, y la segunda con el mantenimiento. Como se puede observar el primer grupo de tareas hace referencia a la etapa de pre-adquisición , mientras la segunda se inicia en la postventa. De acuerdo a la forma de contratación de productos, aquí se tiene diseño, 28 Universidad de Los Andes ESICO RESUMEN codificación y prueba, o licitación, asignación, invitación a proponer o estudio de mercado, etc- diseño de pruebas, interventoría y aplicación de pruebas, documentación etc. - Implementación: Esta actividad hace parte de la cadena de adquisición de software, del eslabón de compra en adelante, debido a que en la implementación está la capacitación, documentación, puesta en marcha y divulgación. - Mercadeo y Soporte: Para cerrar de forma satisfactoria la adquisición de software se inician las tareas de seguimiento al proceso de implementación y “help desk” para la aplicación. Por último, la actividad que hace que el ciclo se cierre es la de Mantenimiento ya sean correctivo, preventivo o adaptativo. Sin embargo no es donde termina la cadena, debido a que es un ciclo que se inicia, dentro de cada eslabón. Necesidades insatisfechas. Nuevas oportunidades. Prioridades en el mercado Procesos Alternativos para la solución: Búsqueda en el mercado Levantamiento de información. Términos de referencia. Fin del ciclo Inicio del nuevo proceso Selección del producto Seguimiento Help desk Mantenimiento Implementación Capacitación Documentación Divulgación Puesta en marcha Figura 7. Ciclo de Vida del Producto 29 Universidad de Los Andes ESICO RESUMEN En las actividades de levantamiento de información y términos de referencia, la documentación ya existente es una gran avance, poder contar y reforzar los éxitos ya tenidos por la empresa en otros procesos, genera un valor agregado de conocimiento para la organización, debido a que de ésta manera los errores del pasado no se repetirán. Al llevar una bitácora de actividades y hacer seguimiento a los procesos de implementación y de mantenimiento se genera disminución de los errores y control de los mismo si son detectados a tiempo , ahorrando tiempo y dinero a la empresa, creando una buena imagen ante el mercado, como una organización seria y que cree en sus procedimientos y documentación. 6.2. Formas para adquirir software La calidad y capacidad del proceso de software afecta: El rango de resultados esperados que pueden ser alcanzados por una organización si hace su propio software. Habilidad de una organización para desarrollar y mantener software de alta calidad, entregada a tiempo y dentro de los costos estimados. Hay que resaltar que si se desea mejorar la calidad del software, hay que mejorar considerablemente primero el proceso de adquisición. Cualquier adquisición de software, debe cumplir con las siguientes características para aumentar la calidad: Satisfacer las necesidades de los usuarios. Contar con la robustez requerida para su confiabilidad. Ser entregado a tiempo y dentro de lo presupuestado. 30 Universidad de Los Andes ESICO RESUMEN Pero la organización también puede contemplar la posibilidad de dejar a terceros los procesos sistematizados o los cuales no hacen parte del núcleo del negocio, es decir, aquellos proceso que son tan estándares y que se cumplen en todas las empresas de forma que existen terceros para realizarlos “outsorcing” o acompañamientos para realizar dichas labores. Por ejemplo, pago de nóminas, aseo, papelería, entre otros. En general podemos hablar de las siguientes variantes a la hora de adquirir software y definir la cadena de valor para cada uno: Comprar un producto a terceros, donde éste sea totalmente parametrizado por el productor y no sea posible ningún tipo de intervención al código fuente o implementación para su correcto funcionamiento en la organización. de caja negra”. “Solución Actividades de apoyo Control y Monitoreo de Servicios Conocimiento del mercado y proveedores de software Capacitación técnica Seguimiento Necesidades de los usuarios: Funcionales y no funcionales. - Términos de Referencias. - Revisión en el mercado. - Compra del producto a un tercero. - Instalación del software o entrega de medios. - Pruebas. - Capacitación a los usuarios. -Mercado producto. - Soporte. -Actualizació n de versiones. Adquisición Solución Caja Negra Actividades primarias Figura 8. Cadena de Valor-Solución Caja Negra La “Solución de caja negra”, se puede utilizar para aquellas adquisiciones donde el producto es genérico en su totalidad y no necesita ningún tipo de ajuste para ser 31 Universidad de Los Andes ESICO RESUMEN implementado en la empresa; tiene como ventaja que los costos en mantenimiento y/o revisiones solo pasan a ser actividades de actualización de versiones o compra de licencias. Otra ventaja puede ser la no dependencia directa hacia el producto, si la versión no cumple con lo esperado o las necesidades de la empresa cambian de tal manera que el producto pasa a ser obsoleto, se puede migrar o pasar a otro producto, sin mayores complicaciones. Por ejemplo: las herramientas de Office y StarOffice, programas para estadísticas, entre otros. Comprar un producto a terceros, donde exista la posibilidad de intervenir el código fuente y su implementación sea necesaria para poder interactuar con los sistemas de información ya existentes y responder a las necesidades de la organización. La implementación puede realizarla la empresa que vende el producto, una compañía externa o quien lo adquiere. “Solución hecha fuera de casa y adaptada para la casa”. Actividades de apoyo Control y Monitoreo de Servicios Conocimiento del mercado y proveedores de software Capacitación técnica Seguimiento Necesidades de los usuarios: Funcionales y no funcionales. - Implementación: - Términos de Instalación del Referencias. software. - Revisión en el Parametrización mercado. del software. -Compra del - Implantación: producto a un Pruebas. tercero. Capacitación a los administradores. Actividades primarias ** En todas las etapas en especial las de implementación, implantación debe existir la documentación correcta. -Mercado producto. - Soporte. -Actualización de versiones. -Capacitación a los usuarios. Mantenimiento Adquisición Dela solución A terceros. Intervenir Código Fuente 32 Universidad de Los Andes ESICO RESUMEN Figura 9. Cadena de Valor-Intervenir código fuente. La ventaja y a la vez desventaja de esta solución, es el nivel de complejidad de la manipulación del código fuente. Esto debido a que hay factores como lenguaje utilizado para la creación del producto, carencia en los comentarios del programa, falta de conocimiento del lenguaje utilizado, carencia de tiempo, entre otros pueden causar un mal manejo del producto y así fracasar en su implementación. Pero por otro lado si se cuenta con el conocimiento adecuado, las herramientas y la coordinación precisa la labor de implementación y funcionamiento puede ser todo un éxito. Desarrollar un producto hecho a la medida de la organización y que cumpla de forma precisa y específica las necesidades detectadas en la empresa. “Solución hecha en casa y para la casa”. Esta solución puede tener dos variantes, la primera tener en cuenta a un tercero para la elaboración del producto y la segunda es hacerlo en la empresa por personal perteneciente a la misma. 33 Universidad de Los Andes ESICO RESUMEN Caso 1. Actividades de apoyo Control y Monitoreo de Servicios Capacitación técnica Diseño y Desarrollo Conocimiento del mercado y proveedores de software Seguimiento 1. -Diseño del sistema. -Términos de Referencias. -Revisión en el mercado. -Evaluación de propuestas. -Puesta en marcha del proyecto. -Diseño -Codificación -Desarrollo del sistema. - Implementación: Instalación del software. Parametrización del software. -Implantación: Compatibilidad con otros sistemas. Pruebas. Ajustes y parametrizaciones. - Pruebas de caja blanca y caja negra. Capacitación a los administradores. -Mercado producto. - Soporte. -Capacitación a los usuarios. -Mantenimiento. -Mantenimiento: Correctivo,preve ntivo o adaptativo. Adquisición. Solución hecha en casa y para la casa. Contratando A un Tercero Actividades primarias ** En todas las etapas en especial las de implementación, implantación debe existir la documentación correcta. Figura 10. Cadena de Valor- Solución hecha en casa y para la casa. Caso 1. 34 Universidad de Los Andes ESICO RESUMEN Caso 2. Actividades de apoyo Control y Monitoreo de Servicios Capacitación técnica Diseño y Desarrollo Investigación de tendencias tecnológicas en aplicaciones. Seguimiento 1. -Diseño -Codificación -Diseño del -Desarrollo del sistema. sistema. - Implementación: -Términos de Instalación del software. Referencias. -Implantación: -Planeación del Compatibilidad con otros proyecto. sistemas. -Cronogramas. Pruebas. -Puesta en Ajustes y parametrizaciones. marcha del -Pruebas de caja blanca y caja proyecto. negra. -Capacitación a los administradores. -Mercado producto. - Soporte. -Capacitación a los usuarios. -Mantenimiento: Correctivo,preve ntivo o adaptativo. Adquisición. Solución hecha en casa y para la casa. Realizado por personal de la empresa Actividades primarias ** En todas las etapas en especial las de implementación, implantación debe existir la documentación correcta. Figura 11. Cadena de Valor- Solución hecha en casa y para la casa.- Caso 2 La solución de hacer las cosas en casa y a la medida, tiene la ventaja de responder a las necesidades exactas de la organización, sin embargo se puede caer en el error de desarrollar una aplicación que ya exista en el mercado y que los costos pueden ser iguales a los del desarrollo o que el producto desarrollado no corresponda a las necesidades planteadas inicialmente. Una gran desventaja que presenta esta alternativa es el mantenimiento posterior que se le debe dar al producto teniendo en cuenta que esta etapa es la mas larga y costosa del ciclo de vida del software. 35 Universidad de Los Andes ESICO RESUMEN 7. METODOLOGIAS FUENTE En esta sección se presentará el marco teórico de metodologías para prácticas de desarrollo de software y calidad de los procesos; la escogencia de las metodologías que se presentaran a continuación van encaminadas a mejorar las actividades pertenecientes al proceso de desarrollo de la adquisición de software, a través del patrón de Gestión, producción y provisión de un servicio. Adicional se presentarán las formas de identificar las falencias en el proceso de adquisición y tener directrices para realizar los cambios adecuados y necesarios para mejorar el proceso de adquisición. Hablar de calidad, efectividad, eficiencia y administración de procesos puede traer a la luz muchas siglas de normas, estándares, metodologías o modelos dedicados a dar pautas a seguir para poder mejorar los aspectos mencionados. En el mercado existen varias metodologías para la revisión de procesos, cuidado de calidad, control y en general para la labor de auditoria, algunas que podemos citar son: - Control Objectives for Information and related Technology – COBIT (1996): El cual se ha desarrollado como estándar para mejorar las prácticas de control y seguridad de las TI.[20] - Systems Auditability and Control – SAC(1991-1994): Ofrece asistencia para los auditores internos de control y de sistemas de información. [20] The Committee of spponsoring organizations of the tradway Commission´s Internal Control –Integrates Framework –COSO: Realiza recomendaciones para los administradores de como evaluar, reportar y mejorar los sistemas de control. [20] 36 Universidad de Los Andes ESICO RESUMEN - Internal Control Structure in a Financial Statement Audit – SAS 55/78: Provee una guía para auditores externos, en relación con el impacto del control interno, la planeación y ejecución de una intervención a los estados financieros de una organización.[20] - Capability Maturity Model –CMM (1996) : Describe los elementos claves de un proceso de software eficaz, describe una ruta de mejoramiento evolutivo para pasas desde un procesos inmaduro a uno maduro y disciplinado.[7] International Organization for Standardization- ISO (2000) : Conjunto de normas y directrices internacionales para la gestión de la calidad. Existen diferentes ISO, según sea el campo a tratar. ISO 9001: Modelo para el aseguramiento de la calidad en diseño, desarrollo, producción, instalación y servicio; ISO 9002 : Modelo para el aseguramiento de la calidad en producción instalación y servicio; ISO 9003 : Modelo para el aseguramiento de calidad en inspección y ensayo finales y por último ISO 9004: Guías para los sistemas y la administración de calidad. - Otros ISO : [22] ISO/IEC 2382 : Information technology – Vocabulary Part 8:1998 Security. ISO/IEC 8073:1997 Information technology – Open systems interconnection – Protocol for providing the connection-mode transport service ISO/IEC 8602:1995 Information technology – Protocol for providing the OSI connectionless-mode transport service ISO/IEC TR 13335: Information technology – Guidelines for the management of IT security. Part 1:1996 Part 2:1997 Part 3:1998 Concepts and models for IT security Managing and planning IT security Techniques for the management of IT security ISO 10164: Audit - This Joint Australia/New Zealand Standard- AS/NZS 4444 : Compuesto por dos 37 Universidad de Los Andes ESICO RESUMEN partes primera administración de seguridad informática en general y la segunda administración de seguridad informática especifica. [21] - ISO 11770/ Administración Clave: Este estándar de tres porciones identifica los objetivos de la administración clave y describe un modelo general en el cual se basan los mecanismos primordiales de la gerencia. Define los servicios dominantes de la gerencia, los mecanismos y los recursos en la actividad a través de su ciclo vital. El estándar se promulga en las tres piezas: Marco; Mecanismos usando técnicas simétricas; y mecanismos usando técnicas asimétricas. [23] De las anteriores alternativas se escogieron tres, las cuales reunían características de generalidad, es decir aplicables a todo tipo de organización; flexibilidad debido a que solo se puede aplicar parte de su metodología a la Universidad o utilizar como referencia y por último que estén ligadas al manejo de Sistemas de Información y de riesgos. No hay que olvidar la parte de calidad y nivel de retroalimentación que debe tener el proceso para que evoluciona y se adapte a las áreas académicas y administrativas de Uniandes. Adicional a lo anterior y siendo básicamente: “El criterio de selección de estas metodologías fue teniendo en cuenta el valor tanto académico como su uso en el medio colombiano; aunque no se excluye que diversas empresas usen diferentes metodologías para adquirir software, se seleccionaron las que, en otras especializaciones5 de la Universidad de los Andes, son enseñadas en la actualidad.”6 Tres de las principales pautas a seguir en este trabajo, son las especificadas por la organización internacional de estándares (ISO, su sigla en inglés), la propuesta del Instituto de Ingeniería de Software (SEI, su sigla en inglés-CMM) y por último los Objetivos de Control de TI internacionales (COBIT por sus siglas en inglés). Se escogieron estas tres metodologías como fuente para ser analizadas, adoptadas y generar una guía en el proceso de adquisición en la Universidad de Los Andes. Se escogieron porque la primera va encaminada en hacer un seguimiento al proceso y la 5 6 Esico, esored, Ecos Olga Lucia Giraldo- Uniandes 38 Universidad de Los Andes ESICO RESUMEN madurez que con la organización realiza los diferentes actividades donde involucra la compra de software, se conoce como Capability Maturity Model –CMM- ; la segunda es el ISO 9000 de Sistemas de Gestión de la Calidad, porque es vital importancia cuidar el ciclo de vida del producto y esto se maneja revisando en cada etapa el nivel de seguridad y de calidad; y la tercera está encaminada a revisar el Control sobre las Tecnologías de información la cual es conocida como Control Objetives for Information and related Technology – COBIT, esta herramienta debe orientar y fijar parámetros para el manejo, auditoria del proceso, levantamiento de información y para el análisis de riegos. 7.1. 7.1.1. CAPABILITY MATURITY MODEL (CMM) Antecedentes El CMM es un contexto que describe elementos claves de un proceso de software eficaz, describe un camino de mejoramiento evolutivo para pasar desde un proceso inmaduro a un proceso maduro y disciplinado, basado en conocimientos adquiridos de evaluaciones de los procesos de software y extensas retroalimentaciones con el entorno donde interactúa la organización. Una de las metas del CMM es alcanzar la evolución hacia una cultura de excelencia tanto en la Ingeniería como en la Administración del software y sus procesos. Se incluyen prácticas de planeación, ingeniería y administración de desarrollo y mantenimiento de software; la idea es aumentar la habilidad con que una organización puede alcanzar metas como costos, programa, funcionalidad y alta calidad en el producto final, que para el caso de este documento, es la excelencia en la adquisición de software.[5] El modelo presenta un conjunto de prácticas divididas en 18 áreas claves del proceso que acrecientan la capacidad de los procesos de software. Si la organización se enfoca en estas 18 áreas de actividades y se trabaja de forma constante y evolutiva se puede mejorar de manera estable y gradual el proceso de adquisición. 39 Universidad de Los Andes ESICO RESUMEN Una de las ventajas de esta metodología es el permanente sistema de evolución que se debe tener, en la revisión de actividades dentro de los procesos. Esto ayudará a que la organización se acople a las nuevas situaciones y necesidades del mercado y las de sus integrantes. 7.1.2. Estructura El CMM se basa en el conocimiento de la organización y de los procesos; está conformado por cinco niveles de madurez, los cuales son progresivos, no autónomos y se organizan según su importancia o prioridad. Los niveles están conformados por áreas claves de procesos(KPAs), que permiten alcanzar ciertas metas. Las KPAs tiene cinco distintas características comunes las cuales son: compromiso, habilidades necesarias, actividades realizadas, medición y análisis, y por último verificación e implementación, las cuales buscan la implementación o institucionalización de las áreas claves; y las características contienen a su vez prácticas claves que se deben realizar para satisfacer a determinada KPA. 40 Universidad de Los Andes ESICO RESUMEN Figura 12 . Niveles de Madurez de la Organización Nivel 1: Inicial Es el punto base donde está ubicada una organización si sus procesos son caóticos. No existe un ambiente estable en el cual se puede desarrollar o mantener un software. Por lo general en este nivel no se alcanzan las metas definidas, ni el tiempo programado, ni el costo ni los recursos planeados. Sin embargo, si por algún motivo el proyecto es un éxito, se debe a la excelencia de las personas que trabajaron en el mismo, mas no en la madurez y organización de los procesos. Las características de os otros niveles se pueden apreciar en la Figura 12 . Niveles de Madurez de la Organización. 41 Universidad de Los Andes ESICO RESUMEN Al estar en el ultimo nivel, la organización ha logrado un nivel tal de retroalimentación y ajuste que se puede adaptar y prepararse a cambios. La comunicación de procesos se ve como un sistema que interactúa de la siguiente forma: Figura 13 . Nivel 5 en al optimización del proceso El nivel uno es el único nivel de madurez que no tiene KPA. Se tienen 18 KPAs distribuidas en los 4 niveles restantes, organizados en 3 categorías: gerencia (planeación de proyecto, administración del software, etc), organizacional (capacitación e infraestructura) e ingeniería(análisis de requerimientos, diseño, codificación, etc). Categorías de Proceso por nivel Gerencia Organizacional Ingeniería Administración de cambios tecnológicos 5 Administración del cambio de procesos 4 Prevención de defectos y errores Administración cuantitativa del proceso Administración de la 42 Universidad de Los Andes ESICO RESUMEN calidad de software 3 -Administración de la integración del software -Coordinación intergrupal -Enfoque en el proceso de la organización -Definición del proceso de la organización -Programa de capacitación 2 -Admón. de Requerimientos -Planeación de proyectos de software -Seguimiento y supervisión de proyectos de software -Administración de subcontratistas de software -Aseguramiento de la calidad de software -Administración de la configuración de software 1 Procesos Ad-hoc Figura 14. KPAs por Categoría de Proceso -Ingeniería del producto de software -Revisión entre colegas La metodología CMM agrupa en cinco grupos prácticas claves para el buen desarrollo de los procesos de software: 43 Universidad de Los Andes ESICO RESUMEN 1. Compromiso: Acciones que la organización debe realizar para asegurar que el proceso sea establecido y persista. organizacionales y liderazgo. 2. Habilidades necesarias: Condiciones previas que deben existir en el proyecto u organización para poder implementar el proceso competentemente. Involucra recursos, estructuras organizacionales y capacitación. 3. Actividades realizadas: Actividades, roles y procedimientos necesarios para implementar una KPA. Involucra el establecer planes y procedimientos, realizar el trabajo, darle seguimiento, y tomar acciones correctivas según sea necesario. 4. Medición y análisis: Prácticas básicas de medición que son necesarias para determinar el estatus en relación al proceso. Se utilizan para controlar y mejorar los procesos. 5. Verificación e implementación : Pasos para asegurarse que las actividades son llevadas a cabo de acuerdo con el proceso que se ha establecido. Abarca revisiones y auditorias por parte de la administración y aseguramiento de la calidad del software. Involucra el establecimiento de políticas 7.1.3. Beneficios del CMM La metodología de CMM ayuda a las organizaciones a la adquisición, a la selección o la administración sus recursos y procesos de software. Su objetivo principal es describir buenas prácticas de administración y de ingeniería estructuradas en un marco de madurez. Por lo anterior se tienen como beneficios: Formar una visión compartida, lo que significa mejoramiento de proceso a nivel organizacional. Establecer un lenguaje común al hablar de determinado proceso. Definir un conjunto de prioridades para atacar los problemas de software. Proveer una estructura conceptual para mejorar la administración y desarrollo de productos de software en una manera disciplinada y consistente. 44 Universidad de Los Andes ESICO RESUMEN Aumentar la posibilidad de que una organización alcance sus metas de costos, calidad y productividad de una manera disciplinada y consistente. 7.2. INTERNATIONAL ORGANIZATION FOR STANDARZATION – ISO ISO 9000 NORMAS DE SISTEMAS DE GESTIÓN DE CALIDAD 7.2.1. Introducción La estandardización internacional es establecida para muchas tecnologías en los campos diversos tales como la tratamiento de la información y las comunicaciones, textiles, empaquetando, distribución de mercancías, de la producción energética y de la utilización, de la construcción naval, de actividades bancarias y de servicios financieros. Continuará creciendo en la importancia para todos los sectores de actividad industrial para el futuro próximo. Las razones principales son: El progreso mundial en economías de hoy del libremercado de la liberalización comercial cada vez más diversas de la fuente y proporciona las oportunidades para los mercados que se amplían. En el lado de la tecnología, la competencia leal necesita ser basada en las referencias comunes identificables, claramente definidas que se reconocen a partir de un país al siguiente, y a partir de una región a la otra. Las Normas ISO 9000 son un conjunto de normas y directrices internacionales para la gestión de calidad, esta serie fue creada por comités integrados por representantes de 27 países, los cuales a su vez se encargan de revisarlas y mantenerlas actualizadas; ha sido adoptadas por más de 70 países. Desde su publicación inicial en 1987, han obtenido una reputación global como base para el establecimiento de sistemas de gestión de calidad. Las normas de aseguramiento de calidad más modernas tiene su origen en las relaciones contractuales entre fabricantes y suministradores de algunos sectores en los que requería la mayor fiabilidad. 45 Universidad de Los Andes ESICO RESUMEN Los protocolos de ISO requieren que todas las normas sean revisadas al menos cada cinco años para determinar si deben mantenerse, revisarse o anularse. La versión de 1994 de las normas pertenecientes a la familia ISO 9000, fue revisada por el Comité Técnico ISO/TC 176, publicándose el 15 de diciembre del año 2000. Existen cuatro vertientes de las normas ISO: ISO 9001. Modelo para el aseguramiento de la calidad en: diseño, desarrollo, producción, instalación y servicio. ISO 9002. Modelo para el aseguramiento de la calidad en: producción, instalación y servicio. ISO 9003. Modelo para el aseguramiento de la calidad en: inspección y ensayos finales. ISO 9004. Guías para los sistemas y la administración de la calidad. Las normas requieren de sistemas documentados que permitan controlar los procesos que se utilizan para desarrollar y fabricar productos. Estos tipos de normas se fundamentan en la idea de que hay ciertos elementos que todo sistema de calidad debe tener bajo control, con el fin de garantizar que los productos y servicios de calidad se fabriquen en forma consistente y a tiempo. 7.2.2. Alcance La revisión de las normas ISO 9001:2000 se ha basado en los Principios de Gestión de Calidad, que reflejan las mejores prácticas de gestión. Estos principios se pueden utilizar por la dirección como un marco de referencia para guiar a las organizaciones hacia la consecución de la mejora del desempeño. [19] Principio 1- Organización orientada al cliente: Las organizaciones dependen de sus clientes y por lo tanto deberían comprender las necesidades actuales y futuras de los mismos, satisfacer sus requisitos y esforzarse en exceder sus expectativas. 46 Universidad de Los Andes ESICO RESUMEN Principio 2- Liderazgo : Los líderes establecen la unidad de propósito y la orientación de la dirección de la organización. Ellos deberían crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organización. Principio 3- Participación del personal: El personal, a todos los niveles, es la esencia de una organización y su total implicación posibilita que sus habilidades sean usadas para el beneficio de la organización. Principio 4- Enfoques basados en procesos: Un resultado deseado se alcanza más eficientemente cuando las actividades y los recursos relacionados se gestionan como un proceso. Principio 5- Enfoques de sistemas para la gestión: Identificar, entender y gestionar los procesos interrelacionados como un sistema contribuye a la eficacia de una organización en el logro de sus objetivos. Principio 6- Mejora continua: La mejora continua en el desempeño global de la organización debería ser un objetivo permanente de ésta área. Principio 7- Enfoque basado en hechos para la toma de decisión: Las decisiones eficaces se basan en el análisis de los datos y la información. Principio 8- Relación mutuamente beneficiosa con el proveedor: Una organización y sus proveedores son interdependientes, y una relación mutuamente beneficiosa aumenta la capacidad de ambos para crear valor. 47 Universidad de Los Andes ESICO RESUMEN Figura 15. Visión de la Norma ISO en un proceso. 7.3. CONTROL OBJETIVES FOR INFORMATION AND RELATED TECHNOLOGY – COBIT 7.3.1. Introducción COBIT es un entidad que proporciona unos principios para los administradores de procesos que se desarrollan en Tecnologías de información y que deben responder de manera eficiente y efectiva tanto para el negocio de la organización como para su control. Por otro lado SAC ofrece ayuda a los interventores internos en el control y la intervención de los sistemas y de la tecnología de información. Mientras COSO hace recomendaciones a la gerencia sobre cómo evaluar, divulgar, y mejorar sistemas de control que puede enriquecerse con SAS 55/78 el cual proporciona la dirección a los interventores externos con respecto al impacto del control interno en el planeamiento y la ejecución de una intervención de los estados financieros de una organización. 48 Universidad de Los Andes ESICO RESUMEN La importancia de que existan diferentes entidades tanto a nivel académico como organizacional que investiguen y mejoren las prácticas de control en diferentes campos, es que cada documento se centra en control interno y cada audiencia, es decir, interventores internos, gerencia, e interventores externos, dedica muchas horas y esfuerzo hacia establecer controles internos y a la evaluación de los mismos. Por lo tanto, comparar los conceptos internos del control presentados en estos documentos es de interés para los miembros de las tres audiencias. [9] 7.3.2. Definición de Control La Fundación de Auditoria y Control de sistemas de información (ISACF por sus siglas en inglés) desarrolló los Objetivos del Control para la Información y Tecnología relacionada (COBIT) al servicio de la seguridad y del control para la supervisión de las tecnologías de información y sus servicios, permite que los interventores verifiquen sus opiniones sobre control interno y que aconsejen sobre su posición ante materias tales como la seguridad y el control. La motivación primaria para proporcionar este marco es permitir el desarrollo de la política clara y de las buenas prácticas para de la misma sobre el control a través de la industria de la tecnología. La definición de control para COBIT proviene de COSO: “Conjunto de políticas, procedimientos, prácticas y estructura organizacional diseñadas para proporcionar un aseguramiento real para que los objetivos de negocio sean alcanzados y que los acontecimientos indeseados sean prevenidos, detectados y corregidos a tiempo. “ [4] Para COBIT el control de la tecnología es un propósito deseado, el cual debe ser alcanzado, por medio de la implementación directamente relacionadas con la tecnología. de procesos de control en actividades En general COBIT orienta sus esfuerzo a: calidad, responsabilidad y seguridad en la información financiera. 49 Universidad de Los Andes ESICO RESUMEN 7.3.4. Características COBIT ha sido desarrollado como estándares generalmente aplicables y aceptados para mejorar las prácticas de control y seguridad de las Tecnologías de Información (TI), aportando un marco de referencia para los administradores, usuarios y auditores de tecnología. El objetivo de esta metodología es investigar, desarrollar, publicar y divulgar Objetivos de Control de TI internacionales, actualizados a la realidad y necesidades actuales para ser usado por los Gerentes de Negocios y Auditores. Esta conformado por cuatro libros: - Resumen ejecutivo: Provee a la administración un entendimiento de los principios y conceptos claves de COBIT y el marco para el administrador esta formado por 4 dominios que a su vez estad formados por procesos, en total 34. - Antecedentes y Marco de Referencia: Describe en detalle los 34 objetivos de control de TI, identifica los requerimientos del negocio para la información e impactos preliminares de los recursos involucrados en la TI de la organización. - Guías de Auditoria: Contienen pasos de auditoria sugeridos correspondientes a cada uno de los 34 objetivos de control de TI, para asistir a los auditores de sistemas de información y proveer seguridad a la administración. Herramientas de Implementación: Contiene el conocimiento de la Administración y diagnóstico de Control de TI, FAQ, casos de estudio y presentaciones entre otras ayudas. Alguna de las características y campos de acción de la metodología son : CAMPO ALCANCE 50 Universidad de Los Andes ESICO RESUMEN Grupo Objetivo Administradores usuarios, de TI de y en general, de auditores sistemas información. El control interno visto como Conjunto de procesos que incluyen las políticas, procedimientos, prácticas y estructura organizacional. Objetivos Organizacionales del Efectividad y eficiencia de las operaciones. Condidencialidad, integridad y validez de la información. Divulgación de la información financiera confiable. Desarrolladas dentro de la normatividad necesaria. Componentes o Dominios Planeación y Organización. Adquisición e implementación Entrega y soporte Monitoreo Interés Información Tecnológica control interno Eficacia en la evaluación del control Procedimiento periódico de la evaluación y interno Responsabilidad control interno Figura 16. Campos de acción de COBIT procesos. del sistema del Responsabilidad del Administrador 7.3.5. Componentes COBIT incorpora cinco componentes derivados de COSO y SAC. Ambiente de Control : Es un componente y parte de la actividad en si misma. Los factores que afectan el ambiente del control incluyen la integridad y los valores éticos de la gerencia, de la 51 Universidad de Los Andes ESICO RESUMEN capacidad del personal, del estilo de la filosofía de la gerencia y del funcionamiento, cómo se asignan la autoridad y las responsabilidades, y de la dirección proporcionada por la junta directiva. COBIT teje las implicaciones del ambiente de control en todos los objetivos aplicables del control. Categorizar los procesos dentro del planeamiento y de la organización, de la adquisición y de la puesta en práctica, de la entrega y de la ayuda, y de la supervisión. Información y sistemas de comunicación: El interés exclusivo de COBIT, es el establecer un marco de la referencia para la seguridad y el control en tecnología de información. Define un acoplamiento claro entre los controles de sistemas de información y los objetivos de negocio. Además, proporciona los objetivos globales validados desde el punto de vista del control para cada proceso de la tecnología de información que dé la dirección de la organización. COBIT también proporciona una herramienta para facilitar comunicaciones entre la gerencia, usuarios e interventores con respecto a controles de sistemas de información. Actividades de control: Examina los procedimientos del control concernientes al sistema de información automatizado de una entidad y los procesos que lo componen. Además clasifica los controles en 32 procesos agrupados naturalmente en cuatro dominios aplicables a cualquier ambiente de la tratamiento de la información y organización. Análisis de Riesgos: Identifica un proceso dentro del ambiente de la tecnología de información como un posible generador de riesgos para el sistema. Este proceso en particular se realiza en el dominio del Planeación y de Organización, y tiene seis objetivos específicos del control asociados a él. 52 Universidad de Los Andes ESICO RESUMEN Trata en profundidad, varios componentes del análisis de riesgo en un ambiente de tecnología de información. Éstos incluyen el análisis de riesgos del negocio, el acercamiento de riesgos, la identificación del riesgo, la medida de riesgo, el plan de acción del riesgo y la aceptación del riesgo. Se ocupa directamente de los tipos de riesgos de la tecnología de información, tales como tecnología, seguridad, continuidad y riesgos reguladores. Además, trata riesgos de una perspectiva global y sistema-específica. Monitoreo Incluye explícitamente la supervisión y monitoreo como componente del sistema del control interno. COBIT da la responsabilidad a la gerencia de supervisar todos los procesos de la tecnología de información y denota la necesidad de obtener aseguramiento independiente en controles. Clasifica la supervisión como dominio -- en línea con el ciclo de la gerencia. 7.3.6. Ventajas COBIT proporciona la definición de controles y de los objetivos del control para los procesos específicos de la tecnología de información; los informes de los problemas internos del control se asumen para estar disponibles a una variedad de fuentes para el responsable del proceso del negocio. Éstos pueden extenderse de la autovaloración del control a las revisiones externas de la intervención. Este modelo apoya evaluaciones como punto de partida y periódicas, dependiendo de la preferencia del revisor y las necesidades de la organización. Como proporciona la dirección del modelo para los 32 objetivos de los procesos, esta dirección toma la forma sobre de 250 objetivos del control. Por lo tanto proporciona más ayudas de navegación a los usuarios, dependiendo de su perspectiva particular, ponen en ejecución para 53 Universidad de Los Andes ESICO RESUMEN organizar y categorizar objetivos del control según COBIT, los criterios de la información o los recurso de controles existentes. 7.4. COMPARACION Normalmente cuando una organización se encuentra en la posición de decidir qué norma o modelo se utilizará para mantener y mejorar la calidad de la misma, se llega a una encrucijada, en este caso ¿ISO o CMM o COBIT?. Para tomar una decisión se evalúan las tres opciones; pero la realidad es que no se pueden comparar estas metodologías, ya que aunque buscan alcanzar el un alto grado de calidad, el enfoque es distinto. El enfoque de COBIT se encuentra exclusivamente sobre controles en tecnología de información para ayudar al alcance de los objetivos de negocio; debido a que es una colección global variables de objetivos del control, organizada en procesos y dominios, y ligada a los requisitos del negocio para la información El enfoque de las normas ISO otorga una certificación y mediante futuras inspecciones se revisa si la organización ha continuado con la correcta aplicación de la norma; ISO no mide si ha habido un avance en el proceso que implementa una organización desde la última visita. Por otro lado, con CMM no se habla de un criterio de si se cubre o no , ni se certifica a la empresa. Con CMM se habla de una escala de niveles en la que una organización se puede posicionar, con esto la misma cubrirá las prácticas que su nivel de definir, documentar, medir, administrar, controlar y efectividad marquen. Entre mayor sea el nivel de madurez, mayor será la capacidad de la organización para brindar y mantener la calidad en el software (producto y procesos). Lo que se puede observar es la relación y principales características de ISO y CMM. El CMM tiene en cuenta las ISO, procesos reales, valoración del proceso y las mejores prácticas para los procesos; se debe tener en cuenta que CMM es una estrategia de mejora, una señalización de deficiencias dentro de la organización y una guía para 54 Universidad de Los Andes ESICO RESUMEN avanzar hacia una cultura de calidad y tomar decisiones. No es una solución rápida, tampoco un “checklists”. Se requiere más tiempo y dinero por persona para poder implantar CMM que el requerido por ISO. Sin embargo, la calidad y la productividad aumentan considerablemente comparado con ISO. Así que como organización, se debe evaluar cuál es el objetivo y posibilidades. Se debe evaluar el tiempo y cantidad de inversión que se está dispuesto o que se puede invertir para obtener un sistema de calidad. 55 Universidad de Los Andes ESICO RESUMEN 8. EXPERIENCIA ACTUAL En la actualidad existen muchas aplicaciones realizadas en y para la Universidad de Los Andes. Para este documento se analizaron 4 aplicaciones, las cuales tienen un impacto alto dentro de la comunidad uniandina (empleados, profesores y estudiantes). 8.1. Sistema de Bibliotecas En la década de los 70´s, mas exactamente en el año de 1974 se inicia la sistematización de los procesos existentes en la Biblioteca de la Universidad de Los Andes. El trabajo es liderado y un técnico de la OEA, que dictó talleres para la catalogación y los otros procesos por medio de tecnología, a las personas que trabajaban en la biblioteca. [11] El proceso se inició con la captura de datos de los libros y clasificación topográfica, utilizando el servidor IBM360 existente en el antiguo Centro de Cómputo. Por cada libro se debían perforar mínimo 2 tarjetas, de las cuales se tenía un par de fichas o tarjetas perforadas para el servicio de préstamo de libros. A final del día se sabía qué libros estaban prestados, ya que las tarjetas compañeras de los libros que se prestaban iban al Centro de Cómputo para ser leídas y generar el listado de libros prestados. A comienzos de los 80 se inicia un proceso de búsqueda de una aplicación que soporte los procesos que genera la biblioteca. Por esa misma época el Instituto Colombiano para el Fomento a la Educación Superior -ICFES inicia un proyecto para la creación de una “Red de bibliotecas Universitarias”; el proyecto no causa mayor impacto y es dejado al olvido. Años después el proyecto es retomado y ofrecido a diferentes universidades, entre esas 56 Universidad de Los Andes ESICO RESUMEN Los Andes, la del Valle y Antioquia. La aplicación que el ICFES ofrece a la Universidad se llamó LIBROUNAM el cual venía de la Universidad Autónoma de México, ésta institución solo entregaba las cintas y el manual de instalación, en ningún momento ofrecían el soporte técnico ni el de instalación. Para poner en funcionamiento LIBROUNAM se utilizó en un servidor Burrouhs 6800 y se contrató un ingeniero mecánico con maestría en bibliotecología para manejar los programas y en general administrar la aplicación. La aplicación estaba compuesta por los módulos: de catalogación, consulta en línea y compra De éstos solo el módulo de catalogación se desarrolló e implementó en su totalidad. Sin embargo, se siguió trabajando con tarjetas perforadas. Los procesos de adquisición de libros y circulación se realizaban utilizando un editor de texto, lo cual producía errores diferentes tipos. El manejo y administrando la aplicación fue cada día menos eficiente, ya que el ingeniero se desvinculó de la Universidad y la documentación que dejó no daba mayor ayuda. La aplicación que remplazó la propuesta del ICFES, fue NOTIS y se logró gracias a un convenio de cooperación con la Biblioteca Luis Ángel Arango. El convenio consistía en registro de los libros que se tenían en Uniandes en el servidor de la biblioteca Luis Ángel Arango. La biblioteca de los Andes se conectó a la Luis Ángel Arango, para que estudiantes y posteriormente externos pudieran consultar esta información. La nueva aplicación sólo preveía el módulo de catalogación y permitia que personas externas pidieran préstamos Interbibliotecarios; sin embargo la autonomía y la independencia que en algún momento tenía la Universidad, se perdió por completo debido a que semanalmente existía un día en el cual se debía enviar un listado a la Luis Ángel Arango para actualizar catálogos y seguir utilizando la red. NOTIS se utilizó durante 3 años aproximadamente. 57 Universidad de Los Andes ESICO RESUMEN Esto sirvió extraer y convertir toda la información de los libros ya catalogados y almacenados a NOTIS. Como se resalta en párrafos anteriores, la dependencia hacia NOTIS fue tal que se inició un proceso de levantamiento de requerimientos y búsqueda en el mercado de otras herramientas. Dentro de las opciones se evaluaron Oracle-Librery y la versión mejorada de NOTIS que se llamaba Horizonte. La Universidad se decidió por Horizonte que contaba con todos los módulos para el funcionamiento del sistema. Años después la representación de HORIZONTE se acabo en el país, y esta misma firma se encargó de introducir en el mercado una nueva herramienta llamada UNICORNIO. La decisión de la dirección de Biblioteca General, fue esperar resultados de las otras universidades que ya habían migrado de Horizonte a Unicornio. Las pruebas fueron exitosas y se inició el proceso de migración por parte de la Universidad. Hasta la actualidad que seguimos en la última versión de Unicornio. La diferencia entre Horizonte y Unicornio, se basa en la interfaz del usuario y el administrador, Unicornio no tienen todas las herramientas necesarios pero tiene un buen enfoque e interfaz de usuario, lo cual es valioso para la interacción que diariamente realizan los cientos de estudiantes y empleados que utilizan el catálogo en línea de la biblioteca. 8.2. Sistema de Administración de Admisiones y Registro – BANNER En la actualidad el sistema se conoce como BANNER, se adquirió tal y como venia el paquete, no se adaptó y la política fue de cero programación. Existe la documentación de dicho proceso.[12] 58 Universidad de Los Andes ESICO RESUMEN Antes de 1998 el sistema que apoyaba la labor de la Admisiones y Registro se llamaba SIRAC, el cual fue desarrollado en lenguaje Cobol por personal de la Universidad, respondía a las necesidades que tenia la dependencia y a los procesos que se realizaban, sin embargo la administración cada vez era mas pesada y en el mercado ya existían herramientas especializadas para el manejo de estos temas. Para 1998 se toma la decisión de modernizar el sistema, por lo tanto se inicia la búsqueda de alternativas, se contaban con herramientas tanto internacionales como nacionales, alrededor de unas 22. Se realizó un documento donde se especificaban las necesidades de la institución, las funcionalidades que debería el nuevo software tanto para Admisiones y Registro como para cumplir con las políticas de la D.T.I. (Sistema Operativo Solaris y Bases de datos Oracle). Luego de casi 7 meses de búsqueda y revisar documentos del mercado, se encontró a BANNER, producto americano. Se realizó su presentación y fue aceptado por las directivas de la institución y personal vinculado con la labor académica. En el proceso de evolución participaron las personas que en su tiempo desempeñaban los siguientes cargos: Vicerrector administrativo, director y asistente de la Oficina de Admisiones y Registro, Director antiguo Centro de Cómputo y un grupo del Departamento de Ingeniería de Sistemas que evaluaba la parte funcional y técnica. El proceso de contratación se inicio el 30 de septiembre del mismo año, el proveedor fue quien redactó el contrato, sin embargo con la oficina jurídica de la Universidad se llegó a un acuerdo realizando dos cambos al original; uno de los cambios fue acordar el pago en cuotas, el otro fue que se pactó mantenimiento por 5 años, tarifa de mantenimiento (actualización de versiones, asesoría y) De ésta forma la Universidad es la primera en el país y la segunda a nivel latinoamericano – luego de Venezuela herramienta. en utilizar esta Ventajas que ha tenido la herramienta son la funcionalidad, siguen los parámetros establecidos, fácil de utilizar para las labores administrativas y el apoyo por parte del proveedor ha contribuido para utilización de forma efectiva. 59 Universidad de Los Andes ESICO RESUMEN En cuanto al hardware, éste se adquirió con el proveedor de servidores que utiliza la DTI y con las mismas políticas de contratación. El equipo no se encontraba en el país por lo tanto se trajo hasta enero de 1999 se inició la instalación. Para el 18 de febrero de 1999, se inicia formalmente el proyecto de implantación de BANNER en la universidad; durante todo el año de implementación se probó cada uno de los módulos, los resultados fueron buenos y se contó con la participación y respaldo de los técnicos de SCT (representantes del producto). Sale a producción en diciembre de 1999. 8.3. Sistema de la Oficina de Recursos Humanos – Nómina y Aplicación web. Antes del año de 1989 el Sistema de Recursos Humanos en la Universidad, consistía en un conjunto de programas desarrollados por ingenieros de la institución y cumplía con las fechas y demás normas que establecía el código de trabajo y la ley. [13] Sin embargo para ese mismo año se decidió diseñar y desarrollar otro sistema en unión con la Dirección de Tecnologías de Información antiguo Centro de Computo; dicho sistema tomo el nombre de SINU y manejaría todo lo relaciona con el proceso de nómina y registro de hojas de vida. Se hizo el levantamiento de requerimientos y de funcionalidad para la labor de nómina. Se inicio el proceso de programación de la misma, sin embargo un cambio de políticas en el manejo de recursos humanos, hizo necesario abortar el proceso y se decidió optar por la adquisición del software existente en el mercado. En 1996 se conforma un grupo donde participa un comité de la Vicerrectoría administrativa, ingenieros y participantes externos, esta labor se asume como una Decisión Institucional. El estudio es detallado y minucioso, arrojando información y resultados de la investigación, elaboración de Términos de Referencia y mercadeo. Se adquiere una aplicación que integra el proceso de liquidación de nómina y maneja información de empleados (hoja de vida, contratos, prestaciones, etc). Se selecciona OpenSystem, el cual 60 Universidad de Los Andes ESICO RESUMEN toma el nombre de CENIX tiempo después vuelve al nombre original, y que actualmente se conoce en el área de RRHH como SCRH. Para Julio de 1997 se inicia la implantación de la nueva herramienta, el proceso termina en marzo de 1998 y desde esa fecha se ha utilizado Universidad hasta el día de hoy. para ejecutar los procesos de la Sin embargo el soporte brindado por SCRH a la aplicación OpenSystem desaparece en 1999, adquiriendo los derechos la empresa SQLSoft. La empresa brindaba dos opciones a los clientes que tenían la herramienta: la primera utilizar los cambios implantados por SQLSoft donde se tenia en cuenta la preventa realizada pero no se realizaba la migración de la aplicación y tampoco se daba soporte sobre CENIX, la otra opción era mirar los otros sistemas que ofreciera el mercado. La Universidad escogió la segunda opción y en la actualidad se está en el proceso de escogencia de una aplicación que cubra las necesidades y expectativas de la Dirección de Recursos Humanos. Se encuentran dos pospuestas, una es la evaluación de productos de gestión de RRHH y la otra, que está en la fase de Términos de referencia es un outsorcing del proceso de nómina. Para las anteriores actividades e ha contado con un grupo interdisciplinario que tiene diferentes funciones: - Comité de Sistema de Información: Encargado de definir y relacionar procesos. Comité Técnico : Compuesto por las direcciones de Financiera, RRHH y D.T.I. Comité de Consulta: Compuesto por los directores de cada dependencia. Para evitar contratiempos en el proceso de nómina, se tiene un plan de contingencia, el cual está formado por dos opciones: Ante cualquier eventualidad y falla del sistema, se recuperar en 5 días el sistema. Se cuenta con un backup completo del sistema y su información, el cual es recuperado en un servidor ubicado en la D.T.I. Ante cualquier eventualidad y/o falla del sistema, todos los meses se deja una copia de la forma en que se realizó el pago de nómina. 61 Universidad de Los Andes ESICO RESUMEN En la actualidad existe una aplicación Web que fue desarrollada por una empresa externa para exclusiva para la Universidad. Dicha aplicación reúne actividades como: beneflex; contratos de cátedra, civiles, monitores y planta ; bonificaciones; hojas de vida, certificados y formularios; y la parte de administración que es el manejo de contenido. 8.4. Sistema interactivo de cursos de la Universidad de Los Andes. SICUA es el Sistema Interactivo de Cursos de la Universidad de los Andes desarrollado en las dependencias de la DTI7, el apoyo del Departamento Ingeniería de Sistemas y fondos del International Development Research Centre, Otawa, Canada. [http://sicua.uniandes.edu.co] [14] Este desarrollo se hizo con el propósito de servir como espacio virtual donde docentes y estudiantes puedan compartir información, acceder a la programación de los cursos, su contenido, entre otros servicios. Diseñado para la Universidad por personal de la institución y puesta en producción como piloto desde 1998, y se ha ido gradualmente generando mejoras tales como: [15] Cambio de infraestructura : En un principio la aplicación respondía a los requerimientos de 48 cursos, debido a que el Sistema fue desarrollado como piloto y no se proyectó un crecimiento y acogida tan grande por parte de los usuarios. La aplicación ha tenido la siguiente evolución: 7 Dirección de Tecnología de Información 62 Universidad de Los Andes ESICO RESUMEN Estadisticas del sistema # secciones en el año 1998 # secciones en el año 1999 # secciones I semestre 2000 # secciones en vacaciones de 2000 # secciones II semestre 2000 # secciones I semestre 2001 # secciones para vacaciones de 2001 # secciones II semestre 2001 # secciones I semeste de 2002 # secciones para vacaciones de 2002 Figura 17. Estadísticas de SICUA # 20 200 330 14 379 496 55 498 900 130 Por lo anterior se pasó a adquirir en noviembre de 2000 un servidor DELL 2400 con memoria en RAM de 1Giga, dos discos duros de 18Gb, procesador pentium III, linux Red Hot 6.2, PHP 4 y postegrss 7. Se automatizaron procesos del sistema: solicitud de cursos, ingreso de estudiantes al curso, creación de lista de correo, periodos académicos tanto para pregrado como postgrado. Depuración periódica de la base de datos. La base de datos no cuenta con llaves primarias y no contiene índices, solo hasta enero de 2002 se colocaron índices, aumentando su tiempo de respuesta en un 95%. Documentación. Existe solo una pequeña parte de la aplicación que se encuentra documentadas. No existen documentos de diseño ni de los scripts, ni de los programas ni de la base de datos. El código está documentado por saltos y no cumple que un estándar. Solo a partir de noviembre de 2000 se han comentado los cambios realizados. Respaldos de información. Generación de backups automáticos y copia de la base de datos, todos los días. Capacidad de Almacenamiento. Paso de 2 megas a 5 megas. Manual e interfaz gráfica . Estos son algunos cambios que se han realizado desde agosto de 2000 hasta enero de 2002, la mayoría en el primer semestre de 2001. 63 Universidad de Los Andes ESICO RESUMEN Sin embargo estos cambios no han sido lo suficientemente fuertes para corregir las fallas de codificación del sistema. Por lo anterior la Vicerectoria Académica inició en el segundo semestre de 2001 el levantamiento de requerimientos e información para adquirir un herramienta de e-learning. El proyecto es liderado por la DTI; se inició con un grupo interdisciplinario (profesores, ingenieros, comunicadores sociales) el objetivo buscar que era lo que en la actualidad buscaba el área académica para realizar sus cursos con ayuda de una herramienta que representara el curso de forma virtual. Luego de hacer el levantamiento de información y de necesidades, se inicio la búsqueda en el mercado de las herramientas actuales y con representación en Colombia. Entre algunos productos: WebCt, BlackBoard, Learnign Space y Docent entre otros. La siguiente fase fue revisar los benchmark de cada producto, hablar con los representantes, invitarlos a presentaciones en la Universidad, primero técnicas y luego enfocadas al sector académico. Para las presentaciones se realizaron unas 3 para cada área académica y técnica. Una vez se decidió el perfil de la nueva aplicación se realizaron los términos de referencia para la licitación de la nueva herramienta que reemplazaría SICUA. Luego de evaluar las propuestas, comparar beneficios Vs. costos, evaluar las necesidades y requerimientos propuestos por el grupo LIDIE8, la nueva aplicación que remplazara al Sistema actual es WebCT. Se ha contado con el respaldo y soporte del representante del producto para Colombia en un 100%, brindando cursos de capacitación tanto para administradores de la herramientas (técnico) como para profesores. El “Nuevo SICUA” saldrá a producción según cronograma el primero de agosto para ser utilizado en paralelo con SICUA, durante el segundo semestre de 2002. 8 LIDIE: Laboratorio de Investigación y desarrollo en informática educativa. 64 Universidad de Los Andes ESICO RESUMEN El cambio de herramienta en general se debió a que ya existían en el mercado opciones que realizaban las tareas y respondían a las necesidades de los profesores de la Universidad y a las nuevas generaciones de estudiantes que inician sus clases. 65 Universidad de Los Andes ESICO RESUMEN 9. ANALISIS DE RIESGOS PARA EL PROCESO DE ADQUISICION 10.1. ¿Qué es un análisis de riesgos? La información de un organización, tanto a nivel del negocio como la del campo tecnológico, se ha convertido en uno de los activos mas valiosos de la organización. Por lo anterior se requieren actividades y procesos efectivos para la administración de riesgos que puedan llegar hacerse realidad y afectar el patrimonio del a empresa; no basta con proteger los activos informáticos (hardware, software, infraestructura de redes, etc), sino también a la organización como tal. El control de los riesgos no solamente debe verse como una función técnica del área de informática sino como una función esencial de la administración de la empresa. Todo sistema de información, procedimiento o actividad tiene un comportamiento similar a la de un ser vivo, por lo anterior podemos reconocer, cómo se nombra en capítulos anteriores el ciclo de vida del producto; para ésta sección se tomará el ciclo de vida de los sistemas de información: [26] Iniciación: Detección de necesidades. Desarrollo/adquisición: Diseño del sistema, comprado, programado, desarrollado o construido según las necesidades encontradas. Implementación: El sistema se aprueba e instala. Operación/mantenimiento: Puesta en producción del sistema. Se inicia una etapa de monitoreo constante para detectar fallas y realizar modificaciones (compra, cambios, procedimientos, ajustes). Destrucción: Fin del sistema, invalidación de los datos y equipos. Obsolescencia del sistema. 66 Universidad de Los Andes ESICO RESUMEN AMENAZAS ACTIVOS IMPACTO VULVENARIBILDAD RIESGOS Figura 18. Elementos de conformación del mapa de exposición de la organización Para poder llevar a la organización a un nivel aceptable de riesgos, debe realizarse un plan de mitigación de los mismo. Este plan tiene por objetivo prevenir, limitar, detectar y responder ante las vulnerabilidades: Prevenir: Eliminar la amenaza quitando la o falla o vulnerabilidad. Limitar: Implantar controles que restringen el impacto de una amenaza. Detectar y responder: Detectar la ocurrencia de una amenaza y tomar acción. 67 Universidad de Los Andes ESICO RESUMEN Para encontrar los controles adecuados para llevar a cabo y medir el plan de mitigación, se puede hacer una análisis de éstos por diferentes enfoques : Controles extraídos de políticas y guías de seguridad, procedimientos de operación de los sistemas, especificaciones de seguridad, estándares y buenas prácticas. Controles técnicos: Preventivos (control de acceso, antivirus, autenticaciones, encripción, etc), Detectivos (logs, ids) y Correctivos (prueba caja negra o blanca). Controles operacionales (personal, seguridad, física, etc): Preventivos (entrenamiento, investigaciones), planes de contingencia y de recuperación, Detectivos (revisiones de seguridad y auditorias) y Correctivos (pruebas de seguridad). Controles administrativos: Revisión de auditorias, evaluación de riegos, reglas de comportamiento. Luego para implementarlos, se clasifican en: Controles Técnicos: apoyo, prevención, detectar y recuperar. Controles Administrativos: segregación de tareas y creación de políticas. Controles Operacionales: seguridad física y de acceso. 10.2. ¿Para qué sirve? Contar con una análisis de riesgos actualizado de la empresa, permite balancear los costos operacionales y económicos de los controles con la efectividad de los mismos. Además es necesario para mantener los valores y controles necesarios sobre los diferentes aspectos y campos que conforma la organización: nivel del servicio, imagen, competitividad, rentabilidad, permanencia, cumplimiento de la legalidad, reducción de costos, entre otros. 68 Universidad de Los Andes ESICO RESUMEN Adicional a los factores anteriores el análisis y gestión de riesgos juega un papel vital en el derecho y obligación de preservar la confidencialidad y privacidad de los datos, tanto de las personas que trabajan para la empresa, como aquellos que forman el activo de la organización. Hay que sumar a esto, la protección de los miembros de la organización. 10.3. ¿Cómo realizar una análisis de riesgos? En la actualidad se puede encontrar variedad de bibliografía acerca de metodologías sobre la administración de riesgos; para el análisis y gestión de riesgos se pueden clasificar las metodologías existentes en: [17] De uso libre: Aquellas elaboradas y patrocinadas por las administraciones públicas de diferentes nacionalidades. Privadas: Desarrolladas por empresas consultoras para su propio uso. Orientadas a escenarios: Procedimientos genéricos y propios tanto del sistema de información como de la época. Utilización como Guía y Patrón de calidad para seguir y realizar consultorías especificas. Como ejemplo de Metodologías libres tenemos una desarrollada por el Consejo Superior de Informática para uso en Administraciones Públicas, Magerit que se basa en un submodelo de eventos donde calcula los riesgos, las funciones y los mecanismos para salvaguardar los bienes informáticos [27]. Para tal fin estudia los riesgos que soporta un sistema de información y el entorno asociado con él, entendiendo por riesgo la posibilidad de que suceda un daño o perjuicio. Recomienda las medidas apropiadas que deberían adoptarse para conocer, prevenir, impedir, reducir o controlar los riesgos investigados. [16] Para realizar un análisis de riesgos e iniciar su gestión es conveniente tener en cuenta los objetivos que guiarán la labor, sea cualquiera de las metodologías existentes a usar [18]: 69 Universidad de Los Andes ESICO RESUMEN Identificar los riegos que afecten a un sistema de información. Recomendar y desarrollar medidas y técnicas que prevengan impidan o controlen los riesgos identificados. Auditar el grado de seguridad de los sistemas y adaptar los mecanismos de controles existentes y necesarios para salvaguardar los bienes. 10.4. Análisis de Riesgos en el proceso de Adquisición de Software En el momento de realizar el análisis de riesgos para el proceso, se debe tener en cuenta los roles que intervienen en la adquisición de software: [26] Directivas: Autorizan la compra de software, realizan un balance costobeneficio. Responsables del sistema o la información: Responsable del software, capacitación a terceros, administrador de riegos en la efectividad general de la aplicación. Oficiales de seguridad: Normalmente es un grupo independiente dentro de la empresa, que tiene como misión ser el responsable de la seguridad informática de los sistemas (hardware, software y datos). Debe seleccionar los controles apropiados para la adquisición e implementaicón de una sistema de información o software. Tiene voz y voto en la elección de los productos. Administrador del sistema: Monitorea el sistema luego de realizar modificaciones. Estar al tanto de posibles problemas que tengan algún tipo de incidencia o impacto en el sistema y por ende en la organización. Usuarios finales: Quienes utilizaran los sistemas de información o software según las políticas establecidas y la capacitación para las mismas. Para el caso de análisis de riegos para el proceso la adquisición de software en Uniandes, se utilizará la Metodología Magerit . Dicha metodología está compuesta de los siguientes pasos: 70 Universidad de Los Andes ESICO RESUMEN - Definición del escenario: Se define el contexto de tecnología donde se trabajará y que se quiere analizar. - Inventario de Activos: Se listan los recursos del sistema de información o relacionados con el contexto, necesarios para que la organización funcione correctamente. - Inventario de Amenazas: Se identifican las amenazas que puede tener el sistema. Inventario de Vulnerabilidades: Se listan las relaciones emergentes entre un activo y una amenaza. - Análisis del Impacto: Se hace un inventario de las posibles consecuencias de materializarse una amenaza. - Inventario y análisis de Riesgos: Se identifican los riesgos relacionados con el sistema y su correcto funcionamiento. - Calculo del Riesgo: Es el coste acumulado durante un periodo de los riesgos. Salvaguardas: Acciones preventiva, correctivas y mitigadoras que reducen el riesgo. 71 Universidad de Los Andes ESICO RESUMEN Análisis y Gestión de Riesgos para el Proceso de Adquisición de Software de Uniandes ♦ Definición del Escenario: Proceso Adqusicón de software Uniandes ACTIVOS Amenazas Internas Externas Area Admin Area Académica Mecanísmos de Salaguarda Vulnerabilidad Impacto Uniandes Salvaguardas Correctivos Población Uniandina: estudiantes, académicos, apoyo institucional, externos Servicos WEB Servicios Académicos Servicios internos RIESGOS Proeceso de Adquisición Salavagaurdas Preventivas Figura 19. Definición del Escenario de Activos de Uniandes. Inventario de Activos Para el inventario de activos se tomarán en general los que conforman a la Universidad y aquellos que se involucran más de cerca en el proceso de adquisición. Serán los recursos 72 Universidad de Los Andes ESICO RESUMEN del sistema de información o del software adquirido, o aquellos relacionados los cuales son necesarios para que la organización funcione correctamente y llegue a los objetivos. OTROS ACTIVOS: Expectativas de los usuarios finales hacia la nueva herramienta. Imagen de la Universidad como pionera en el uso de tecnología. FUNCIONALIDAD: Procesos y usuarios involucrados en la producción y utilización de la nueva herramienta (nómina, beneflex, banner,sicua, etc). INFORMACIÓN: Procesos involucrados en la implementación de la herramienta. Datos afectados o sensibles al instalas la herramienta (consultas). Conocimiento previo de otros herramientas ya implantadas en la Universidad. Capacitación para administradores y usuarios finales. SISTEMAS DE INFORMACIÓN: Infraestructura de redes y comunicaciones involucradas en la implementación. Sistemas de información involucrados o afectados por la nueva herramienta. ENTORNO: Necesidades que originan la adquisición del producto. Población de la comunidad Uniandina la cual necesita la herramienta Comité Ejecutivo-Rectoría - otros Area Recursos Financieros Areas responsables de la herramienta Figura 20. Inventario de Activos. Amenazas Son los eventos que puedan desencadenar un incidente en la Universidad independientes del proceso de adquisición de software. Puede producir daños materiales o pérdidas inmateriales en los activos (información de notas, por ejemplo). Accidentes: No responden las UPS´s del Centro del Cómputo. Daño de uno de los discos donde se instale la aplicación. Incendio en el Centro de Cómputo o en los lugares donde repose el software. 73 Universidad de Los Andes ESICO RESUMEN Destrucción por incendio o catástrofe de los instaladores o copias del software. Pérdida por incendio o catástrofe de los términos de referencia de la aplicación y documentación del proceso. Errores: No hacer un adecuado estudio de las necesidades existentes. No tener en cuenta la infraestructura de red actual de la Universidad. No buscar en el mercado otras herramientas u opciones. Fallas en el momento de redactar los términos de referencia para la participación de proveedores. Error en la configuración del servidor donde repose la aplicación. Error en la instalación del software. Falta de un plan adecuado de capacitación por perfiles. Falta de un plan de seguridad para la nueva herramienta. No activación de algún tipo de validación para utilizar la herramienta. Falta de un análisis de las diferentes comunicaciones que puede llegar a tener la aplicación con otras u otros servidores. Intencionales presenciales: Usuario no capacitado. Usuario del sistema desleal. Falta de atención al momento de ejecutar instrucciones. Pérdida de los medios para la instalación. Ejecución de un comando indebido y no restringido. Intencionales remotas: Ataque pasivo de hackers (sniffer). Ataque activo de crackers (virus, troyanos, denegación de servicios). Ataque activo de hackers (manipulación de datos). Ataque activo de ckackers (Sistemas operativos). Suplantación de perfiles y permisos. 74 Universidad de Los Andes ESICO RESUMEN Vulnerabilidades La vulnerabilidad es una propiedad de la relación entre el activo y una amenaza. Se pueden dividir en dos: Potencialidad autónoma: Calidad de la instalaciones eléctricas. Material insuficiente para las instrucciones tanto en el momento de configuración de equipos, software o la capacitación. Frecuencia de las fallas del “Firewall”. Ingreso a privilegios mal configurados. Ejecución de un comando indebido y no restringido. Falta de capacitación para administradores o perfil no adecuado. Probabilidad de daño en discos duros o componentes del servidor. Probabilidad de daño de los medios para la instalación. Potencialidad derivada intencional Personal no calificado para la manipulación del software. Herramientas del software que no cumplen con las expectativas. Impactos El impacto es un resultado de la materialización de las amenazas en los activos. Dependiendo el tipo de pérdidas el impacto será: Cualitativo con pérdidas funcionales: Resultados que puedan intervenir en la correcta prestación de los sistemas de validación: Errores a autenticación contra LDAP. 75 Universidad de Los Andes ESICO RESUMEN Cualitativo con pérdidas orgánicas: Resultados que puedan afectar la imagen de la organización: Confidencialidad e integridad de los datos manejados por los diferentes sistemas de información notas, financiero, clases, certificados, entre otros. Cuantitativo: Resultados donde las pérdidas se pueden traducir o buscar una equivalencia en dinero o tiempo. Disponibilidad de los servicios que ofrece la Universidad vía Web: elaboración de horario, inscripción de materias, aceptación de matriculas, inscripción de estudiantes nuevos. Estar fuera de servicio por un ataque de denegación de servicios. Riesgo Posibilidad de producirse un impacto determinado en un activo, en un proceso en toda la organización. Existen tres tipos de riesgos: Riesgo calculado intrínseco: Evaluación realizada antes de aplicar algún tipo de salvaguardia. Ver Figura 21. Riesgo calculado residual: Evaluación después de aplicar las salvaguardias necesarias. Ver Figura 21. Sin embargo y por más de que se trate de mitigar los riesgos, éstos nunca desaparecen; por lo tanto existe un Umbral de riesgo que es el valor establecido para decidir si un nivel de riesgo es asumible o no por la organización. 76 Universidad de Los Andes ESICO RESUMEN Cálculo del Riesgo Se evalúa la importancia de cada una de los impactos y su nivel de repercusión en los proceso de la organización. Cualitativo con pérdidas funcionales: Cualitativo con pérdidas orgánicas: Autenticación. Impacto: Alto Vulnerabilidad: Baja Riesgo: Medio Cuantitativo: Prestación de Confidencialidad e integridad. Impacto: Alto Vulnerabilidad: Baja Riesgo: Bajo servicios Para el proceso de la adquisición de software que interactué con diferentes sistemas de información su calificación debe ser: Autenticación: Impacto – alto Vulnerabilidad – baja Riesgo – medio Confidencialidad e integridad: Impacto – alto Vulnerabilidad – baja Riesgo – medio Prestación de servicio: Impacto – alto Vulnerabilidad – media Riesgo – medio Figura 21. Cuadro de Riesgos. informáticos y de apoyo. Impacto: Alto Vulnerabilidad: Medio Riesgo: Medio Salvaguardas Serán todas aquellas acciones que se tomen para reducir el riesgo. Existen funciones preventivas que actúan sobre la vulnerabilidad y por lo tanto reducen la potencialidad del 77 Universidad de Los Andes ESICO RESUMEN impacto. Así mismo existen mecanismos de salvaduarda, que son los procedimientos o dispositivos que reducen el riesgo. Cualitativo con pérdidas funcionales: Cualitativo con pérdidas orgánicas: Autenticación. Detección de intrusos o usuarios Confidencialidad e integridad. no Evitar errores en la información y formación de los datos que maneje el sistema. permitidos ni registrados en el sistema. Disuasión para ingresar a un sistema el cual Monitoreo del sistema para corregir errores no está autorizado. y estar alerta sobre acciones que causen recuperación del sistema. Cuantitativo: Prestación de servicios Para el proceso de la adquisición de software que interactué con diferentes informáticos y de apoyo. Monitoreo del servicio, para controlar su sistemas de información los salvaguardas estado y comportamiento, para ejercer las son: acciones preventivas necesarias para Responder a las necesidades para lo cual fue garantizar integridad y confidencialidad a adquirido. la hora de ser autenticado y validado ante El costo de la adquisición tiene una doble un sistema. forma de ser valorado, uno por lo que costó su adquisición y otro por el nivel de dificultad de su implantación. Estar ligado o responder 100% a la infraestructura de red y servidores que maneja la Universidad por medio de la DTI. Monitoreo constante, corrección preventiva o adaptativa. Sistemas de backups para hacer recuperación de información en cualquier momento. Figura 22. Cuadro de Salvarguardas. 78 Universidad de Los Andes ESICO RESUMEN Riesgo Residual Los riegos no desaparecen así se controlen las posibles causas. Para la Universidad y en general para cada sistema o aplicación adquirida se tiene: La posibilidad de que el sistema falle y salga de línea. Los virus, aunque son detectados y eliminados del sistema, siempre existirá una versión mas avanzada. El impacto es alto si el sistema es de uso masivo y requiere el módulo de autenticación contra LDAP [28]. No existe una garantía del 100% sobre la invulnerabilidad ante ataques hacia los sistemas operativos de los servidores y aun mas, sobre los servicios que se prestan. El análisis y gestión de riesgos para el proceso de Adquisición de riesgos, debe responder a la prioridad del negocio, es decir, a la educación superior e investigación; para dicha actividad se puede iniciar con la recolección de datos históricos, sin embargo esto no debe ser el eje fundamental del proceso de adquisición. Durante el ciclo de vida del proceso, pueden surgir problemas relacionados con la identificación de las necesidades, implantación, características: La solución puede ser de alto riesgo, sin embargo sino funciona hay vuelta atrás. El usuario deseará estar y debe estar involucrado en el proceso de detección de riesgos, levantamiento de requerimientos. Se debe contar con toda la documentación posible. divulgación y mantenimiento; estos pasos tienen las siguiente Todas las anteriores características y los controles de mitigación de riesgos ante el proceso de adquisición de software en Uniandes, deben responder a tres premisas: autenticación 79 Universidad de Los Andes ESICO RESUMEN ante servicios computacionales, confidencialidad e integridad de los datos almacenados en los sistemas de información y la prestación de servicios informáticos y de apoyo. Un conjunto de riesgos que están latentes en el inicio del proceso de adquisición de software a un tercero, al no contar con un plan a seguir en el proyecto, son: [29] No tener total control sobre el diseño e implementación del producto o servicio. El proveedor usualmente no publica las especificaciones completas del producto o de una lista completa de todas sus funciones. No se dispone de código fuente. (Casi nunca) El proveedor no garantiza que el producto opere satisfactoriamente, a pesar de las declaraciones registradas en los documentos o literatura promocional. El usuario/equipo de prueba no es dueña del producto, está licenciado a usuario bajo ciertas condiciones. De un buen análisis de riesgos, realizado de forma concienzuda y una plantación del proyecto alimentada por experiencias anteriores y documentadas, depende el éxito de la compra y puesta en producción de la nueva herramienta. 80 Universidad de Los Andes ESICO RESUMEN 10. PUNTOS CLAVES EN EL PROCESO DE ADQUISICION Para la elaboración de este trabajo, se ha venido desarrollando una labor de investigación y búsqueda de metodologías para procesos y haciendo énfasis en aquellos que tienen relación con los sistemas de información. De igual forma se revisó en capítulos previos las diferentes formas de adquisición de un software, sus implicaciones y los riesgos genéricos que puede tener el proceso al realizarse en el contexto de la Universidad de Los Andes. Sin embargo al tocar el tema de adquisición, no es simple replicar este ejercicio para cada tipo de satisfacción de necesidades de los usuarios y la organización en general. Por tal motivo se reducirá al análisis y generación de pasos para la adquisición de un software ya existente en el mercado y que será adaptado (parametrizado, intervención código fuente), según las necesidades de los sistemas de información existentes y contexto de la Universidad. Así es necesario entonces poder determinar el grado de madurez de los procesos actuales e identificar los puntos claves en donde se deberá enfocar la atención de mejorar, para lograr por una aparte calidad en el software y por otra el mejoramiento de dichos procesos. Se puede iniciar por dos puntos muy generales, pero vitales a la hora de saber el nivel de funcionalidad del software, para responder a aquellas necesidades que se deben satisfacer: 1. Valoración del Proceso de Software • • Determinar el estado del proceso de software actual de la organización, Determinar los asuntos de mayor prioridad en cuanto al proceso que enfrenta una organización y • Obtener el apoyo de la organización para la mejora del proceso de software. 81 Universidad de Los Andes ESICO RESUMEN 2. Evaluación de la Capacidad de Software • Identificar contratistas que sean calificados para realizar el trabajo de software y • Monitorear el estado del proceso de software empleado en un esfuerzo existente de software. Para estas dos fases se puede tener en cuenta el siguiente gráfico, el cual se comporta y representa el diagrama de flujo de las actividades y etapas dentro del desarrollo de la propuesta de CMM. Figura 23. Pasos Comunes para evaluación y valoración 82 Universidad de Los Andes ESICO RESUMEN De lo anterior, de puede resaltar la importancia de Seleccionar un equipo interdisciplinario, capaz de realizar una evaluación y valoración de los requerimiento y las posibles soluciones. El perfil del grupo debe estar compuesto por un alto conocimiento en la práctica de adquisición, implementación, capacitación y divulgación de software, pero se debe contar con un perfil humanista el cual enfoque las funcionalidades del nuevo producto al sector de impacto. Se puede seguir el proceso con una encuesta tanto para el levantamiento de información y requerimientos, como para realizar un diagnóstico del estado actual de la organización y conocer el nivel de madurez de sus procesos y proyectos. Una vez que toda la información ha sido recabada el equipo evalúa y determina aquellas fortalezas y puntos de mejora para la organización y el posible software candidatos a ser implementado para responder a las necesidades del momento y las proyectadas. Para la labor de revisión de objetivos de la institución se puede recurrir a COBIT, ya que proporciona un idea a los administradores de procesos de Tecnologías de información y para responder de manera eficiente y efectiva tanto al negocio como para su control. Hay que tener en cuenta entonces en el proceso de adquisición : Ambiente de Control - ADC - : Conocer en sí mismo el proceso de adquisición, en pocas palabras la planeación de dicha labor. Información y sistemas de comunicación - IYSDC- : Establecer el diseño, desarrollo, implantación, implementación e interacción con otros sistemas de la Universidad. Define que se quiere y cómo hacerlo. Actividades de control - ACDC - : Seguimiento del plan establecido para el procedimiento de adquisición y realización de los términos de referencia. Análisis de Riesgos - ADR - : Busca las posibles causas generadores de riesgos para el sistema y por lo tanto para la institución. Incluye el análisis de riesgos del negocio, el 83 Universidad de Los Andes ESICO RESUMEN acercamiento de riesgos, la identificación del riesgo, la medida de riesgo, el plan de acción del riesgo y la aceptación del riesgo. Monitoreo – M -: Actividades de supervisión y monitoreo como componente del sistema del control interno. COBIT da la responsabilidad a la gerencia de supervisar todos los procesos de la tecnología de información y denota la necesidad de obtener aseguramiento independiente en controles. Todos los puntos clave anteriormente mencionados, deben estar ligado a la siguiente cadena de valor : Actividades de apoyo Control y Monitoreo de Servicios Conocimiento del mercado y proveedores de software Capacitación técnica Seguimiento Necesidades de los usuarios: Funcionales y no funcionales. - Implementación: - Términos de Instalación del Referencias. software. - Revisión en el Parametrización mercado. del software. -Compra del - Implantación: producto a un Pruebas. tercero. Capacitación a los administradores. Actividades primarias ** En todas las etapas en especial las de implementación, implantación debe existir la documentación correcta. -Mercado producto. - Soporte. -Actualización de versiones. -Capacitación a los usuarios. - Mantenimiento Adquisición Dela solución A terceros. Intervenir Código Fuente Figura 9. Cadena de Valor-Intervenir código fuente. 84 Universidad de Los Andes ESICO RESUMEN Actividades de apoyo A -- ADC IYSDC B -- IYSDC C -M ACDC ADR M D -- ACDC UNO ADC IYSDC DOS ADC ADR M TRES IYSDC M CUATRO ACDC M Adquisición Dela solución A terceros. Intervenir Código Fuente Actividades primarias Figura 24. COBIT + Cadena de Valor Adquisición de software. Donde las actividades primarias se verán afectadas según sea la planeación para llevar a cabo el proyecto a adquirir un nuevo software. 11. GUIA METODOLOGICA 85 Universidad de Los Andes ESICO RESUMEN 12.1. Introducción Este capítulo propone una guía metodológica, la cual trata de responder a exigencias tales como la eficacia y eficiencia a la hora de realizar el proceso de adquisición de software. Esta guía pretende sugerir a la organización en la selección de estrategias, determinando la madurez del proceso actual e identificando los puntos importantes que se deben atacar para así mejorar tanto el proceso como la calidad del software. La Guía está compuesto por 7 pasos a seguir, los cuales reflejan la estructura orgánica de la Universidad de Los Andes y sus necesidades como ente investigador y generador de conocimiento, el cual se apoya en el área administrativa. En la actualidad el proceso de adquisición se hace de la siguiente forma para software de impacto medio y que cubren el 30% aproximadamente de la población uniandina: - Todas las áreas, tanto académicas como administrativas tienen una cifra tope la cual pueden destinar para compras y adquisiciones, entre otras de software; quien toma la decisión es el jefe de dependencia o departamento. - Si la dependencia académica genera los recursos suficientes para la adquisición del software que se necesita, la ejecución de la acción la hace el jefe de departamento y la orden de compra es remitida a la Oficina de Compras. - Si la dependencia académica no cuenta con los recursos suficientes, la propuesta es presentada al Consejo Académico para que se apruebe la compra y acordar el porcentaje el cual aportará cada una de las partes. - Para las áreas administrativas, el software es adquirido con dinero que se le asigna desde inicio de año y que está en el presupuesto. En todas las áreas, tanto académicas como administrativas, se realiza un plan de gastos para el año siguiente, donde se contempla las necesidades del área y las posibles formas de solucionar los vacíos existentes. 86 Universidad de Los Andes ESICO RESUMEN En cuanto a software que afecte a un porcentaje del 70% aproximadamente de la población, cuando su funcionamiento sea eje central o complementario de las actividades desarrolladas por la Universidad, y se integre con otros sistemas de información existentes, se crea un comité, se evalúan las propuestas y se determina la herramienta a ser implementada. Esto a grandes rasgos se muestra en la Figura 25. SURGEN SURGEN NECESIDADES RESPUESTAS: COMPRA DE UNA HERRAMIENTA. Investigación y exploración de las opciones. Decisión de comprar Aprobación del proyecto No Revisar la existencia de Recursos. No Yes Fin del proceso Greneración de la orden de compra Figura 25. Estructura de compra 12.2. Propuesta Guía Metodológica para el Proceso de Adquisición de Software 87 Universidad de Los Andes ESICO RESUMEN 1. Crear un comité interdisciplinario para el proyecto. 2. Diagnosticar el problema. 3. Investigar las opciones que ofrece el mercado. 4. Selección del software. 5. Plan operativo. 6. Plan de Pruebas y Seguimiento. 7. Documentación. 88 Universidad de Los Andes ESICO RESUMEN GUIA ADQUISICIÓN DE SOFTWARE “TODA HERRAMIENTA INFORMATICA ES PARA SER MANEJAD POR PERSONAS Y PARA BRINDAR SERVICIOS A PERSONAS. “ Creación de un comité interdisciplinario. Diagnosticar el Problema. No hay necesidad de comprar un software. Hay que revisar la comunicación y procedimientos. Documentación Buscar Plan de Pruebas y seguimiento Opciones en el Mercado Plan Operativo Plan de implementación Mercadeo del producto Selección del Software Elaboración Términos de Referencia. ¿Qué es lo mejor para el usuario final ? Evaluación de propuestas. Figura 28. Mapa del proceso de adquisición de software. 89 Universidad de Los Andes ESICO RESUMEN 12.3. Descripción y razones de las etapas propuestas 1. Crear un comité interdisciplinario. Por qué Es importante que la adquisición de software no se haga tendiendo en cuenta solo una de las siguiente perspectivas: Desde el punto de vista técnico, o del ejercicio diario del usuario final, o desde el administrador del sistema ó desde los usuarios avanzados. Si el proceso carece de una faceta técnica cae en el error de adquirir un sistema no compatible con los actuales, o si la se falla en la parte humanista será difícil entender que quiere el usuario final, si se comete un error en la redacción del contrato se puede estar infringiendo alguna ley o haciendo un mal negocio, y así sucesivamente se puede llegar a incurrir en riesgos como perdida de imagen, perdida de continuidad o perdida financiera.. El tener en cuenta diferentes perfiles apoya tanto el proceso de levantamiento de requerimientos, revisión y evaluación de las propuestas, como a la revisión legal y criterio financiero. Para qué El contar con un grupo interdisciplinario facilita la comprensión de términos técnicos, traducir las necesidades de los usuarios a instrucciones a ejecutar por el sistema, comprender la elaboración del contrato. Permite tener una regularidad y consistencia en los historiales, estándares y en la información que llega a los usuarios, que en ocasiones se convierte en rumores sin validez alguna. Cómo La creación del comité no es una actividad que deba verse como oficial o dictatorial, sino como un muy buen grupo de trabajo que tendrá como reto satisfacer ciertas necesidades 90 Universidad de Los Andes ESICO RESUMEN de los usuarios en relación con la tecnología y sus actividades diarias. Este grupo no debe superar más de 5 personas y su conformación dependerá del tipo de software a ser adquirido. o Área Académica: El objetivo de ésta área y campo de acción se enfoca en la investigación y desarrollo de nuevos caminos para apoyar e impulsar la labor educativa tanto a nivel pregrado como postgrado. Se debe tener en cuenta que las necesidades de las diferentes facultades y departamentos, aunque se encaminan al área educativa e investigación, son propias de cada campo y que también existen otras necesidades que son comunes a toda la comunidad académica, desde estudiantes hasta profesores. Por lo tanto se sugiere que el grupo esté conformado así, según sea el caso: Un usuario actual del sistema a ser reemplazado : estudiante, profesor y/o investigador. Un usuario que sea afectado de forma directa o indirecta por la carencia de la herramienta que se necesita: estudiante, profesor y/o investigador. El administrador del sistema existente o en su defecto un ingeniero de sistemas con conocimientos en el área. Una persona que represente al Comité de Tecnologías de la Universidad. Un representante del centro de cómputo donde se instalará la aplicación. Un representante de la DTI, si el nuevo sistema o aplicación tiene comunicación con aplicaciones ya existentes o sistemas de autenticación. Anexo 1.Reglamento sobre el uso de servicios y de la infraestructura de red de la Universidad. 91 Universidad de Los Andes ESICO RESUMEN Como asesor jurídico, un abogado de la Oficina Jurídica de la Universidad, una vez se vaya a realizar el contrato. o Área Administrativa: El objetivo primordial de la parte de apoyo institucional es brindar soporte logístico a todos las labores que conforman el negocio de la Universidad. Las adquisiciones que realiza esta área estarán enfocadas a dos campos, el primero a la labor diaria y herramientas de apoyo administrativo (nómina, tesorería, beneflex) y el segundo campo es el educativo, luego son herramientas administradas por el área de apoyo institucional que interactúan con otros sistemas de información y que son utilizadas por los estudiantes y profesores. Por lo tanto se sugiere que el grupo esté conformado así, según sea el caso: Un usuario actual del sistema a ser reemplazado: estudiante, profesor y/o investigador si es una herramienta para el área académica. Si es para utilización administrativa un empleado de dicha área. Un usuario que sea afectado de forma directa o indirecta por la carencia de la herramienta que se necesita: un empleado de la dependencia o aquellos que representes diferentes roles. El administrador del sistema existente o en su defecto un ingeniero de sistemas con conocimientos en el área y que pertenezca a la dependencia. Una persona que represente al comité de Tecnologías de la Universidad. Un representante de Recursos Humanos. 92 Universidad de Los Andes ESICO RESUMEN Un representante del centro de cómputo donde se instalará la aplicación. Un representante de la DTI si el nuevo sistema tiene comunicación con aplicaciones ya existentes o sistemas de autenticación. Anexo 1. Como asesor jurídico, un abogado de la Oficina Jurídica de la Universidad, una vez se vaya a realizar el contrato. 2. Diagnosticar el problema. Identificar de forma concreta las necesidades que se estén creando en las labores diarias según los roles y actividades existentes en la Universidad y la estrategia organizacional. Realizar una matriz de correlación entre las necesidades detectadas, las herramientas tecnológicas utilizadas, es importante dentro del proceso de diagnostico, adicional a esto se debe tener en cuenta los posibles riegos que pueden surgir durante el proceso y puesta en producción del software. resultados: la “comprar Es factible llegar a un diagnóstico que no arroje como ó donde el factor de un producto que haga YYYYY”, capacitación y divulgación sea la clave de todo ó simplemente que el factor clave para ser competitivo en dicha tarea es enfatizar la comunicación y capacitación ante algunas herramientas ya existentes en la Universidad. Por qué Es de vital importancia conocer exactamente cuáles son las necesidades a nivel tecnológico que puede llegar a tener la comunidad Uniandina y la labores de investigación que realiza la institución, además de saber dónde se está generando y su por qué. El resultado será el eje fundamental de un nuevo proyecto, por eso la importancia de realizar una buena investigación sobre las necesidades. Para qué Conocer las necesidades de forma clara y concreta, hace que la búsqueda a solución y la respuesta sea mejor y enfocada al verdadero problema no a distractores. 93 Universidad de Los Andes ESICO RESUMEN Se puede llegar a encontrar causas que este generando otros cuellos de botella o quiebres en las actividades relacionadas con las necesidades detectadas. Cómo Se puede recurrir a diversas metodologías, talleres, ejercicios y documentación. Sin embargo se recomienda: - Realizar reuniones previas del comité o grupo de trabajo. Donde el grupo expondrá las posibles necesidades y sus causas. Elaboración de hipótesis. - Identificar un grupo objetivo que este relacionado con la labor o actividad que esté causando el quiebre. - Realizar talleres, entrevistas y charlas donde con ayuda de los usuarios se identifiquen las necesidades y causas. - Realizar un documento final donde se recopile los ejercicios anteriores, la problemática y por lo tanto las recomendaciones que hace el grupo interdisciplinario. - Iniciar el proceso de análisis de riesgos para el proceso de adquisición e identificar los factores críticos que afecten el proceso. - Iniciar el proceso de análisis para establecer los parámetros de compra del software, desde el área técnica hasta la financiera de los proveedores. 3. Investigar opciones que ofrece el mercado. Por qué Expandir el horizonte y conocer mas allá de las fronteras, sirve para buscar todas las posibles opciones de compra, conocer tendencias, comportamiento y desempeño de los software existentes. Para qué 94 Universidad de Los Andes ESICO RESUMEN Cubrir todas la opciones, sirve para comparar y realizar un buen cuadro de análisis y saber que soluciones son las mas viables desde la parte funcional, no funcional hasta la económica. Cómo Realizar dos tipos de investigación. Una donde cada uno de los integrantes del grupo interdisciplinario haga su propia investigación; y la otra con ayuda de los proveedores tecnológicos que tiene la Universidad. Se debe tener en cuenta características a la hora de hacerla investigación como: o o o o o o o Qué hace el software Para qué área está enfocado Cómo se utiliza Características no funcionales. Características funcionales Bajo qué exigencias de hardware funciona Bajo qué exigencias de software funciona(sistema operativo, lenguajes, web server, etc) o o o o Tipo de licenciamiento Clase de soporte Qué entidades lo utilizan Experiencias previas en otras organizaciones Adicional a la labor de investigar las alternativas, los análisis de riesgos y los de parámetros de compra se deben ir perfeccionando y depurando; de manera que cada vez se acerque más al objetivo y metas del proyecto y las necesidades detectadas. 4. Selección del software 95 Universidad de Los Andes ESICO RESUMEN Este paso está conformado por dos actividades una: Elaboración de los términos de referencia y la segunda es la evaluación de las propuestas. Elaboración de los términos de referencia Por qué El documento pone en blanco y negro lo que se necesita y establece las reglas de juego. Para qué Los Términos de Referencia, son el documento que refleja y plasma de forma clara la labor de investigación del grupo interdisciplinario, las necesidades de los usuarios, sus expectativas y la solución. Cómo El documento debe estar conformado por los siguientes capítulos: Objetivo: Por lo general esta conformado por mas de dos ideas. La primera es hacer una invitación a diferentes empresas que puedan llegar a tener un software que supla las necesidades de la organización. El que se espera de esa solución y del proveedor. Ejemplo. “El objetivo de esta invitación a presentas propuestas, es seleccionar un proveedor que suministre, implante, capacite y ofrezca soporte técnico a la Universidad de Los Andes en un producto de software ........ que permita ........ manejar los recursos de la Universidad en un esquema de ......... y que interactué con otros sistema de información existentes en la institución. ” Anexo 2. Términos de Referencia. UBICACIÓN: Lugar donde será instalado el software y donde se le dará soporte la mismo. ANTECEDENTES: Este capítulo habla de las experiencias previas que se han tenido con otras aplicaciones similares al que se desea adquirir. Se 96 Universidad de Los Andes ESICO RESUMEN habla de la historia, instalación, funcionamiento y características del sistema. De esta forma se le muestra al posible proveedor que es lo básico que debe tener la nueva solución y se sugieren también las expectativas originadas por debilidades del sistema original. En este capítulo se deben tocar temas como, lenguaje, sistema operativo, funcionalidades, políticas de uso, estructura de la red de la Universidad, en general todos aquellos detalles que hacen que la aplicación actual funcione. REQUERIMIENTOS MINIMOS DE LA UNIVERSIDAD: Se pueden subdividir en otros capítulos, en general se expresa las condiciones básicas que se deben cumplir para participar en la selección del software. CONSIDERACIONES DE CALIDAD DEL SERVICIO: Esta sección enfatiza el tipo de servicio que se debe prestar, documentación, acompañamiento, entre otros. DURACIÓN DEL CONTRATO: Dependiendo la herramienta y el tipo de licenciamiento, el software puede ser comprado o tomado en arriendo. En este capítulo es donde ingresa la parte jurídica, se habla de las pólizas de cumplimiento y condiciones de uso del software. IMPUESTOS: Se aclara qué tipo de impuestos se van a pagar y a cuál de las partes le corresponde cancelarlos. FORMA DE PRESENTAR LA PROPUESTA: proveedor sólo se puede hacer Se aclara que por cada una propuesta y presentarla; además se establece el formato de presentación de la propuesta. PROPUESTA COMERCIAL: En esta parte se habla del dinero, cómo serán realizado los pagos y en qué formato se debe presentar el valor de la 97 Universidad de Los Andes ESICO RESUMEN solución(US, $, €). Adicional, se aclara la forma en que los puntos anteriores deben presentarse. CRONOGRAMA: Acá se toma el tema del tiempo, cuáles son las fechas y tiempos que la Universidad tiene para: revisar, reuniones aclaratorias, presentaciones, revisión de propuestas, selección, implementación e implantación, y puesta en producción. VALOR AGREADO: La Universidad, hace claro en servicios son visto como atención especial para la institución y que no tienen ningún valor en dinero. Pueden ser cursos, herramientas adicionales y otros que el proponente exponga. CERTIFICACIONES: Puede existir la posibilidad de que empresas extrajeras participen, por lo tanto se solicita los documentos que las acrediten como representantes y la facilidad para trabajar en el País y brindar el soporte requerido. REUNIONES ACLARATORIA: Es muy importante que los posibles proponentes tengan algún contacto previo con las personas están llevando a cabo la labor de investigación y puesta en marcha del proyecto. En esta sección se establece una fecha en la cual se pude atender al proveedor para que sus inquietudes sean resueltas. PLAZOS PARA LA PRESENTACIÓN DE PROPUESTAS: Se aclara el lugar y fecha exacta en la cual la Universidad espera recibir la documentación que contiene la propuesta de cada proveedor participante. CRITERIOS PARA LA EVALUACIÓN DE LAS PROPUESTAS: Se hace explícito sobre qué puntos y características se calificarán las propuestas y qué aspectos son obligatorios y por lo tanto no tendrán algún tipo de puntaje. 98 Universidad de Los Andes ESICO RESUMEN COSTO DE PREPARACIÓN DE LA PROPUESTA: Se aclara quién es el que propone el valor de la solución, quién asumirá costos adicionales que impliquen la presentación de la propuesta. POSIBILIDAD DE DECLARAR DESIERTA LA INVITACIÓN: La Universidad no está obligada a dar a conocer las razones por las cuales no acepta ninguna propuesta. Puede ser que no se cumplan con los requerimientos básico o que ninguna empresa de haya presentado a la selección. CONFIDENCIALIDAD DEL PROCESO: Se aclara las condiciones y datos que no serán conocidos por los proveedores y qué información puede ser suministrada a los mismos. GLOSARIO: Su mismo nombre da tema para el capítulo. Todas aquellas palabras de uso diario de los usuarios relacionados con el sistema existente o los que interactúan con la posible nueva herramienta se debe aclarar, el vocabulario de cada organización es propio. Evaluación de las propuestas Por qué Se debe revisar que propuestas cumplen lo requerimientos básicos, para ahorrar tiempo y dejar las mejores opciones. Adicionalmente se revisa que tan vulnerable es el software a los riegos detectados en las etapas anteriores. Para qué Revisar qué tan enfocado se está en la búsqueda de soluciones a los vacíos y quiebres que se están generando, y si la solución en realidad esta en el área de tecnología. Cómo 99 Universidad de Los Andes ESICO RESUMEN El grupo interdisciplinario realizará dicha evaluación en acompañamiento del personal que necesite para una buena labor de revisión y para cubrir todos los campos en que el software será utilizado. La evaluación puede estar conformada por dos etapas. La primera está relacionada con la revisión y calificación de los parámetros básicos que debe cumplir el software; y en la segunda se alimentará la matriz de relación entre las alternativas, los riegos y parámetros de compra. ALTERNATIVAS A1. A2 PARAMTROS P1 DE P2 COMPRA .............. Pn .......... An Cuadro 1. Matriz Alternativas/Parámetros de compra de software. RIESGOS R1-A1 PARAMTROS P1 DE P2 COMPRA .............. Pn DE CADA R2-A1 ALTERNATIVA .......... Rn-An Cuadro 2. Matriz Riegos para cada parámetro de compra según la alternativa. 100 Universidad de Los Andes ESICO RESUMEN ANALISIS RIESGOS DE CADA ALTERNATIVA Riesgo Innerente PARA CADA al parámetro PARAMETRO DE COMPRA R1-A1-P1 R1-A1-P2 .............. RI-A1-Pn Alto-Medio-Bajo .......... .......... .......... DE Controles posibles para disminuir el riesgo .......... .......... .......... Alto-Medio-Bajo RIESGOS Controles Riesgo residual sugeridos para luego de aplicar disminuir el riesgo residual controles (opcional) .......... .......... Alto-Medio-Bajo .......... .......... Alto-Medio-Bajo .......... .......... Cuadro 3. Análisis de riegos para cada parámetro de compra de software según la alternativa. 5. Plan Operativo Este paso, al igual que el anterior, está compuesto varias actividades, divididas en tres campos, uno enfocado hacia el usuario final, ¿qué es lo mejor para él?; la otra se basa en la respuesta del usuario para saber cómo realizará la puesta en producción del software y por último cómo llegarle a usuario, que es la etapa de capacitación y mercadeo del producto. ¿Qué es lo mejor para el usuario final? Por qué Ayuda a visualizar nuevamente los tipos de roles que intervienen en la actividad, tipos de capacitación y posibles problemas. Lo cual previene fallas, inconvenientes o contratiempos que se pueda tener a la hora de divulgar la herramienta. La parte humana es el punto clave de todo este proceso; se adquiere software para que sea manejado por personas para ofrecer servicios a otras personas. 101 Universidad de Los Andes ESICO RESUMEN Para qué Esta acción dibuja los posibles ambientes en el cual se desarrollará la implementación e implantación del software. El saber qué puede ser contraproducente para el usuario es clave para el plan de implementación, puesta en producción, soporte, en general cómo vender el producto. Cómo Se pueden utilizar diferentes formas, entrevistas, reuniones con grupos foco de los diferentes usuarios (roles), hacer un análisis de la situación y las posibles reacciones de los usuarios, desde la optimista hasta el rechazo. Técnicas de mercadeo unidas a la frase “ponerse en los zapatos del otros” se muy recomendable. Se deben tener en cuenta cosas como: Familiaridad del usuario con la nueva herramienta. Frecuencia con que utilizará el software. Perfiles que utilizarán el software. Experiencias con software similares en la Universidad. Expectativas del mismo grupo interdisciplinario. Qué pueden esperar los usuarios y qué no. Posibles escenarios al momento de salir a producción. Plan de implementación. Por qué Se debe tener un cronograma de tareas y acciones a seguir para evitar pérdidas de tiempo y por lo tanto incumplimiento en el cronograma inicial fijado por el grupo de lidera el proyecto. Para qué 102 Universidad de Los Andes ESICO RESUMEN Se analicen aspectos de cada función, cuáles son críticos para el proyecto, por lo tanto se determina la meta y los objetivos de las funciones que realizará la herramientas y los medios para cumplir. Cómo: Esta sección está muy ligada a la cadena de valor de la adquisición de software a terceros y parametrizado o con intervención a código fuente, con respecto a la tercera actividad primaria: 3 - Implementación: Instalación del software. Parametrización del software. - Implantación: Pruebas. Capacitación a los administradores. Figura 26. Actividades primarias número tres para el plan de implementación Adicional a las actividad 3 primaria, se utiliza la información recolectada en el punto ¿Qué es lo mejor para el usuario final ?. El objetivo del Plan de implementación del software, es hacerlo en el menor tiempo, de la mejor forma y si causar contratiempos en el trabajo de los usuarios finales. Plan de Implementación: 1. Realizar la estimación de recursos necesarios para iniciar la instalación del software. ¿Qué , cómo y cuándo se va hacer la instalación?. Se debe tener en cuenta fechas que no afecten la labor diaria de los usuarios finales, tampoco debe coincidir con la 103 Universidad de Los Andes ESICO RESUMEN ejecución de actividades críticas para el negocio, por ejemplo: galpón, proceso de nómina, semana de retiros, entre otros. Adicional a esto se puede contar con experiencias previas en instalación de software. 2. Realizar el diseño de la instalación. Es decir unir y hallar las relaciones y equilibrio entre las necesidades de los usuarios finales y los recursos requeridos para la instalación. Ver Figura 28. COBIT+ Cadena de valor. 3. Realizar el inventario, lista de chequeo y documentación de la parametrización e intervención a código fuente que se debe realizar para ajustar el software. De igual forma se deben realizar prueba parciales y anotar sus resultados a medida que se hacen cambios. 4. Capacitación a los administradores del software. Se debe ofrecer las herramientas y recursos (material, manuales, etc), necesarios para que el administrador del nuevo software conozca el funcionamiento de la aplicación y pueda a su vez brindar una atención y soporte técnico a usuarios finales. Esta labor se debe hacer cumplir por parte del proveedor. Capacitación a usuario final y mercadeo del producto Por qué Es necesaria que una vez se conozca que es lo mejor para el usuario, se identifique cómo se llaga a él, cómo vender la idea de utilizar una nueva herramienta, que por ser innovadora pueda estar obligándolo a utilizar otras formas de hacer sus actividades diarias, ya mecanizadas. Para qué Además de escoger de forma correcta el software y que éste responda a las necesidades, se necesita que los usuarios utilicen la herramienta, si no se realiza una buena labor de 104 Universidad de Los Andes ESICO RESUMEN mercadeo, es posible que no se utilice a menos de que sea impuesta. Razón que solo cubriría a una población de la Universidad, la administrativa; y no funcionaria para el área académica. Cómo Como se dijo en los primeros puntos de la guía, hay que reconocer los diferentes roles que intervendrán en la utilización del software, identificar en qué área se utilizará la herramienta y qué labor cubrirá dicha herramienta. Pero hay que motivar al usuario final, para que le encuentre beneficio para su trabajo. Se debe pensar en la herramienta como un producto nuevo en el mercado, producto que se encontrará con barreras de penetración como el rechazo, la indiferencia o aceptación. El proceso es una cuestión de esfuerzo continuado lo que implica duro trabajo buen conocimiento y mucha experiencia, así como herramientas efectivas y muchos contactos con la comunidad que utilizará el software. Para la divulgación se debe tener en cuenta el perfil de los usuarios: • Administrativos: Normalmente se adquiere una herramienta para que sea utilizada para determinadas actividades, independiente de la opinión del usuario. Sin embargo hay que motivarlo para que la utilice; por eso unas charlas previas para hacer la presentación del producto, unas pequeñas guías y un soporte técnico son el mejor mecanismo para que utilicen el software y no se sienta la presión de la imposición. • Académicos: Pueden existir dos clase de software, aquel que se utiliza para gestión académica y otro para actividades diarias pero que no es indispensable para la labor docente. Para el primero se puede seguir la misma táctica del área administrativa. Para el software que se utiliza por demanda, se puede iniciar el proceso con charlas y presentación del producto, a toda la comunidad docente y de estudiantes, luego reducir el grupo a aquellos interesados a utilizar la herramienta, capacitarlos, ofrecer asistencia técnica, crear manuales de usuario; la ventaja de iniciar con un grupo de interés el proceso de divulgación y capacitación, es que serán futuros multiplicadores de conocimiento, convirtiéndose en participes del proyecto y un recurso activo del mismo. 105 Universidad de Los Andes ESICO RESUMEN 6. Plan de Pruebas y Seguimiento. 4 -Mercado producto. - Soporte. -Actualización de versiones. -Capacitación a los usuarios. Mantenimiento Figura 27. Actividades primarias numero cuatro para el plan de implementación Por qué Evitar salir a producción con errores; garantizar la integridad de la información majada por el software y la seguridad física del servidor donde se instale; establecer políticas de control para backups y copias de seguridad; garantizar la continuidad del servicio y la alta calidad del mismo. Sirve para actualizar el análisis y gestión de riesgos tanto en los campo de infraestructura como de sistemas de información, debido a que se debe examinar la cobertura de los controles en caso de que una nueva amenaza exista para la seguridad lógica. Adicionalmente la labor de pruebas determina si se respondió a las necesidades inicialmente establecidas; en el caso de no ser así o necesitar ajuste el mantenimiento correctivo, prefectivo y adaptativo hacer que el software no pierda vigencia o se vuelva obsoleto un lapso corto. 106 Universidad de Los Andes ESICO RESUMEN Para qué Detectar errores a tiempo y aplicar medidas correctivas adecuadas, viables y efectivas; definir el alcance y repercusión de los errores para evitar un deterioro en la imagen del nuevo producto y una posible falla del servicio. De igual forma el identificar y evaluar los posible errores ayuda a ajustar los controles y preparar los recursos necesarios para corregirlos. En el momento en preparar los recursos disponibles se deben establecer los tiempos de mantenimiento correctivo. No solo se detectan los errores, también se detectan la deficiencias, copias de seguridad, planes de recuperación, en caso de una falla. Cómo Las pruebas se deben realizar, como se dijo en un numeral anterior, en el momento de hacer cambios al código fuente; pero también es importante hacer una prueba general del software antes de salir a producción y pruebas continuas del funcionamiento, que se le puede llamar labor de mantenimiento. Para los tres tipos anteriores de pruebas se debe tener en cuenta [29]: Determinar el alcance de las pruebas, magnitud y prioridad. o Establecer el ambiente de pruebas: Ejecución del software con el propósito de detectar errores; determinar y visualizar riesgos, revisión y aceptación de las fallas para minimizar el riesgo. o Establecer qué es lo que se está evaluando: Una aplicación, un sistema, un sistema de sistemas, la interacción con otros sistemas y/o aplicaciones. ¿Cuáles son los elementos claves en el plan de pruebas? o Definir los responsables y tareas dentro de cada nivel de pruebas: Desarrollar y distribuir una guía de pruebas indicando las políticas, principios, estrategias y procesos 107 Universidad de Los Andes ESICO RESUMEN relevantes en la planeación, ejecución y divulgación de cada nivel de pruebas. o Definir y asignar labores, responsabilidades y expectativas de las pruebas: Establecer políticas y procedimientos para asegurar la confiabilidad de los resultados de las pruebas. Realizar una librería de pruebas. o o Autenticar y validar para ingresar al software. Calidad y seguridad de la información: Integridad y confiabilidad de los datos. o Establecer claramente los estándares del contenido de los informes, formato y frecuencia de las pruebas: Generar reportes con información consistente para facilitar el análisis y sintetizar la información del informe del proyecto de pruebas. o Generar de indicadores de estado de pruebas, y pruebas completas. Plan de pruebas o Estimar un presupuesto y efectuar el requerimiento de fondos suficientes para satisfacer requerimientos de prueba. o Definir una estructura de pruebas: Quién, criterios de conformidad. o Prueba de unidades de software: Procedimientos y datos de prueba. Corregir errores. o Incluir procesos de documentación y administrativos para identificar, controlar y reportar cambios a los sistemas y componentes del sistema. o Prueba del software integrado: Procedimientos y datos de prueba. Corregir errores. los recursos y 108 Universidad de Los Andes ESICO RESUMEN o Incluir procesos de documentación y administrativos para identificar, controlar y reportar cambios a los sistemas y componentes del sistema. o Pruebas al sistema completo: Procedimientos y datos de prueba. Corregir errores. o Incluir procesos de documentación y administrativos para identificar, controlar y reportar cambios a los sistemas y componentes del sistema. o o Prueba End-to-end: Usuarios finales. Corregir errores. Incluir procesos de documentación y administrativos para identificar, controlar y reportar cambios a los sistemas y componentes del sistema. Rol de una auditoria en la fase de pruebas. Opcional. La auditoria o actividad encargada de: o Asegurar que los planes y estrategias de pruebas se están usando e implementando de acuerdo al plan establecido. o o Determinar los recursos para pruebas. Revisar la integridad, confiabilidad y eficiencia de las metodologías y resultado de las pruebas. o Verificar que la seguridad y sistemas de control implementados sena consistentes después de haber efectuado los cambios al software. 7. Documentación. Este paso, hace parte y debe ser inherente a todos los numerales descritos en la guía. 109 Universidad de Los Andes ESICO RESUMEN Por qué Es la memoria de todo el proceso de adquisición de software. Una documentación profesional proporciona una información rápida, clara y fiable tanto a nivel de producción interna como para el cliente final y para las personas que en un futuro se encarguen de la administración y asistencia técnica del software. Para qué Aprender y evolucionar con respecto de las experiencias anteriores en la adquisición. Para localizar, recopilar y reutilizar el conocimiento de la Universidad en el área de tecnología de forma rápida y eficiente. Cómo Cada etapa de la guía debe contar con un documentación que relate las experiencias, forma de instalación del software, resultados de investigaciones, de pruebas, certificaciones, entre otros. Los documentos deben ser atrayentes y bien estructurados. En la actualidad existe un gran variedad de metodologías y formatos para llevar la documentación de procesos, entre estas podemos contar las normar ISO 9000 en el área de Documentación de sistemas de calidad bajo la norma ISO 9001:2000, la cual tiene por objetivos: Comprender el proceso de documentación, comprender los procesos de control de documentos y datos y por último aprender los principales enfoques para la elaboración de manuales de calidad, procedimientos e instructivos. La idea básica de la documentación es hacerla bien, de manera que personas que no hayan participado en el proceso de adquisición comprendan el proceso y sea posible replicarlo en caso de ser necesario, sobre todo en el momento de se reinstalado el software. Lo mínimo que debe tener cada documento generado en cada uno de los pasos es: o Encabezado: Título relacionado con el tema y la etapa del proceso; la fecha de elaboración del documento y el o los autores. o Objetivo (s): Se enumeran los puntos clave del documento. 110 Universidad de Los Andes ESICO RESUMEN o o Alcance (s): Qué temas cubrirá el documento y que se pretende con estos. Índice (Opcional): Si el documento está compuesto por varios temas, es mejor enumerarlos primero. o Descripción de cada tema: prerrequisitos para instalación del software, pasos para su instalación, tipo de pruebas, resultado de las pruebas, resultado de encuestas, estadísticas. o Recomendaciones: Después de desarrollar determinada fase de una etapa, que sugerencias se hacen para continuar. o Pendientes: Que tareas y actividades quedaron pendientes en dicha etapa y por qué. o Conclusiones (Opcional) 111 Universidad de Los Andes ESICO RESUMEN CONCLUSIONES Visto globalmente el proceso de adquisición de software, puede cobrar tantos matices como necesidades puedan llegar a tener Universidad de Los Andes. los usuarios y diferentes actores de la Las necesidades que surjan en un mundo de la investigación, la docencia y gestión administrativa de Uniandes, son perfectamente compatibles con el mercado de la tecnología de información y de telecomunicaciones. Debido a la competencia que existe en el mercado informático el beneficio es alto a la hora de buscar software que responda a determinadas expectativas de la Universidad, sin embargo el reto y objetivo es saber hacer una selección adecuada de los posibles proveedores; una evaluación concienzuda basada en las necesidades y requerimientos reales; una fase de pruebas donde no se sacrifique la imagen del producto, la calidad del mismo y el tiempo de salir a producción, y por último en una buena campaña de divulgación y capacitación. La atención que se le preste a la interacción entre la parte humana –usuarios -, el mercado y las necesidades emergentes cada día es la garantía para llevar a buenos términos el proceso de adquisición, sea para la compra de software no parametrizado y genérico como Word, Excel, Dreamweaver, Flash, o software adaptado a la organización sistemas financieros, de nómina, de gestión académica o investigativa. 112 Universidad de Los Andes ESICO RESUMEN Al momento de iniciar la búsqueda hay que tener en cuenta la infraestructura de la Universidad, la cual está compuesta por elementos físicos como: cableado estructurado, equipos de interconectividad, servidores; y elementos lógicos como el sistema operativo para todos los servicios (Solaris y Linux), aplicaciones y sistemas de información. Adicional a la infraestructura se debe tener en cuenta las necesidades funcionales y no funcionales; el presupuesto y tiempo en que debe entrar a producción el nuevo software. Para facilitar dicha tarea se puede recurrir a la guía enunciada en este documento, etapas que en algunas ocasiones y dependencias ya se a aplicado, tal vez no es su totalidad, pero si se cuenta con cierto nivel de experiencia, es cuestión de unificar esfuerzos. La variable de tiempo es muy importante en un proyecto de estos, donde se sabe que se va a adquirir un producto y que tal vez hay que adaptarlo. Actividades que no son simplemente intervenir código sino realizar pruebas, por ningún motivo se deben dejar de lado o eliminar del cronograma. “En la valoración de la calidad de un servicio por parte del cliente, prevalece la impresión del conjunto y es por eso que cuando existe una falla en alguno de los pasos o componentes, el cliente tiende a generalizar el defecto a todo el servicio. Por esta misma razón cuantos mas elementos involucre la prestación del servicio, es mayor el riesgo de cometer errores y generar insatisfacción en el cliente. ”9 Sin embargo, nunca dejará de existir controversia al momento de adquirir una nueva herramienta computacional, la Universidad cuenta con una población aproximada de 12 mil personas (11 mil estudiantes, 1200 profesores y 2 mil de apoyo institucional o administrativos); por lo tanto son 12 mil formas de juzgar, observar y tomar decisiones.; decisiones que en algunas ocasiones son institucionales, en otras se deja al libre albedrío; Pero no implica que estas reacciones sean contraproducentes a la hora de adquirir un software, al contrario, son parte de esa universalidad y pluralismo que es la Universidad de Los Andes. 9 Tesis Adriana Aranguren, estudiante de ESIO, Universidad de Los Andes 2002 113 Universidad de Los Andes ESICO RESUMEN BIBLIOGRAFÍA [1] Business dynamics : systems thinking and modeling for a complex world / John D.Sterman.Sterman, John D. [2] Dirección estratégica / Gerry Johnson, Kevan Scholes ; traducción: Yago Moreno revisión técnica: Juan M. de la Fuente Sabaté, Esther de Quevedo Puente. Johnson, Ferry. [3] Al éxito por la cooperación : un enfoque humano de la estrategia empresarial / Reinhard Mohn ; introducción de Alvin Toffler ; traducción de Thomas Wahling. Mohn, Reinhard [4] Información Systmes audit and Control Association. http://www.isaca.org/isacafx.htm. Junio 6 de 2002- 8:58. [5] 21, Allee V. (2000) Reconfiguring the value Network. Journal of Business Strategy. vol no.4, July-Aug 2000 : http://vernaallee.com [6] Ingeniería del software, un enfoque práctico / Roger S. Pressman ; traducción: Carlos Cervigón Ruckaüer, Luis Hernández Yañez. Pressman, Roger S. [7] El Modelo de Capacidad de Madurez y su Aplicación en Empresas Mexicana de Software. Tesis profesional presentada por Claudia Ivette García Romero. http://mailweb.udlap.mx/~tesis/lis/garcia_r_ci/capitulo5.html16-05-2002 :58pm [8] La Cadena de Valor y el Conocimiento Organizacional en la sociedad del conocimiento. http://www.gestiondelconocimiento.com/documentos2/caridad/cadena.htm 18-05-2002 8:55 p.m. 114 Universidad de Los Andes ESICO RESUMEN [9] A Comparison of Internal Controls: Janet L. Colbert, Ph.D., CPA, CIA http://www.isaca.org/bkr_cbt3.htm COBIT®, SAC, COSO and SAS 55/78 By: and Paul L. Bowen, Ph.D., CPA. 26-06-2002 4:50 p.m. [10] SEGURIDAD INFORMATICA EN LA UNIVERSIDAD DE LOS ANDES. - Tesis de Grado de pregrado Andes - 2002. - Ensayo Control de Gestión, Adriana Hernández Muñoz 2001. Andrés Holguín Coral – Universidad de Los [14] Documentación y entrevista realizada a Adriana Hernández – Ingeniera DTI [15] Documento Informe sobre diferentes productos de e-learning- Adriana Hernández – Mauricio González [16] http://www.um.es/estructura/escuelas/ept/cagrsi.html [17] Análisis y Gestión de riesgos en internet- Seminario de Seguridad en internet 2002 Fernando Espona Bauret. [18] 2002. [19] Teoría de Administración de riegos- Néstor Orlando Romero ABCP,Msc-Mayo www.iso.org [20] www.isaca.org [21] INFORMATION SYSTEMS SECURITY STANDARDS HANDBOOK - Estándar BS7799/ NZ 4444 [22] Estándar BS7799/ NZ 4444 [23] MANUAL DE LOS ESTÁNDARES DE LA SEGURIDAD DE LOS SISTEMAS DE INFORMACIÓN - ESTÁNDAR BS7799/NZ 4444 115 Universidad de Los Andes ESICO RESUMEN [24] Información suministrada por la Oficina de Admisiones y Registro, datos primer semestre de 2002. [25] Information Systems control and Audit. Ron Weber. Pretince Hall . 1998 [26] Teoría de Administración de riegos- Néstor Orlando Romero ABCP,Msc-Mayo 2002. [27] http://www.map.es/csi/pg2005.htm [28] 2002. [29] Tesis de Grado de pregrado - Andrés Holguín Coral – Universidad de Los Andes - Estrategias de Prueba, Planes de Contingencia y Auditoria al proyecto Año 2000. Febrero de 1999. AUDISIS [30] www.y2kexperts.com OTROS TITULOS Requisitos del Sistema de calidad. http://www.emprendedor.com/Iso9000/00_contenido.htm Auditoria de Operaciones - Belt Ibérica http://www.belt.es/servicios/auditoria/eva_proc_adq.htm . 04 -28-2002 1:35 a.m. Carnegei Mellon – Software Engieneering Institute - Capability Maturity Model® for Software (SW-CMM®) http://www.sei.cmu.edu/cmm/cmm.html , 04- 28-2002 3:50a.m. http://www.sei.cmu.edu/publications/documents/94.reports/94.tr.012.html http://www.sei.cmu.edu/pub/documents/94.reports/pdf/tr12.94.pdf Monografias.com – Conceptos de la Auditoria de Sistemas http://www.monografias.com/trabajos3/concepaudit/concepaudit.shtml 6:30p.m. 14-05-2002 116 Universidad de Los Andes ESICO RESUMEN ISO 9000 http://www.emprendedor.com/Iso9000/ 14-05-2002 7:45 p.m. International Organization Standardization http://www.iso.ch/iso/en/ISOOnline.frontpage 14-05-2002 10:00 p.m. http://www.aenor.es/iso9000.htm http://www.isoeasy.org/ http://www.homoqualitas.com/castella/infos/iso90002000/portada.htm http://www.markem.com/html/policies/ISO.jsp Gerencia de Mercado – Ciencias Económicas y Administrativas – El Análisis de la Cadena de Valor. http://www.3w3search.com/Edu/Merc/Es/GMerc081.htm COBIT y Estándares de auditoria http://www.ucpr.edu.co/auditores/estandares/index.htm 117 Universidad de Los Andes ESICO RESUMEN FIGURAS Figura 0. Plan de Trabajo Figura 1. Cadena de Valor área tecnológica Figura 2. Cadena de Valor Dirección de Tecnologías de Información Figura 3. Cadena de Valor para el proceso de Adquisición de Software Figura 4. Actividades Primarias- Factores Críticos Figura 5. Actividades de Apoyo- Factores Críticos Figura 6. Cadena de Valor área tecnológica Figura 7. Ciclo de Vida del Producto Figura 8. Cadena de Valor-Solución Caja Negra Figura 9. Cadena de Valor-Intervenir código fuente. Figura 10. Cadena de Valor- Solución hecha en casa y para la casa. Caso 1. Figura 11. Cadena de Valor- Solución hecha en casa y para la casa.- Caso 2 Figura 12 . Niveles de Madurez de la Organización Figura 13 . Nivel 5 en al optimización del proceso Figura 14. KPAs por Categoría de Proceso Figura 15. Visión de la Norma ISO en un proceso. Figura 16. Campos de acción de COBIT Figura 17. Estadísticas de SICUA Figura 18. Elementos de conformación del mapa de exposición de la organización Figura 19. Definición del Escenario de Activos de Uniandes. Figura 20. Inventario de Activos. Figura 21. Cuadro de Riesgos. Figura 22. Cuadro de Salvarguardas. Figura 23. Pasos Comunes para evaluación y valoración Figura 24. COBIT + Cadena de Valor Adquisición de software. Figura 25. Estructura de compra Figura 26. Actividades primarias numero tres para el plan de implementación Figura 27. Actividades primarias numero cuatro para el plan de implementación Figura 28. Mapa del proceso de adquisición de software. 118 Universidad de Los Andes ESICO RESUMEN CUADROS Cuadro 1. Matriz Alternativas/Parámetros de compra de software. Cuadro 2. Matriz Riegos para cada parámetro de compra según la alternativa. Cuadro 3. Análisis de riegos para cada parámetro de compra de software según la alternativa. 119 Universidad de Los Andes ESICO RESUMEN ANEXOS Anexo 1. Términos de Referencias para una plataforma e-learning. 120 Universidad de Los Andes ESICO RESUMEN Anexo 2. Reglamento de para el Uso de Servicios de Tecnología de información y telecomunicaciones- Universidad de Los Andes. Julio 22 de 2002-08-29 121 Universidad de Los Andes ESICO RESUMEN Anexo 3. Entrevistas a personal de la Universidad de Los Andes. [11] Entrevista realizada a Ángela María Mejía –Directora Biblioteca General Luis Alfonso Barrera C. Jefe Técnico Sistema de Biblioteca Entrevista realizada Alejandro Rico – Admisiones y Registro [12] [13] Entrevista realizada a Elsa Josefina Amaya - Dirección Recursos Humanos. 122