GESTIÓN DE RIESGOS EN PROYECTOS INFORMÁTICOS

1. Fundamentos en Gestión de Riesgos 1.1. Gestión de proyectos

La gestión de proyectos es una disciplina con la cual se integran los procesos propios de la gerencia o administración de proyectos. Se ocupa por lo tanto, de organizar y administrar recursos de tal manera que se pueda culminar todo el trabajo requerido en el proyecto dentro del alcance, el tiempo y los costos definidos.

La gestión de proyectos es una disciplina que ha tomado relevancia en la medida en que buena parte de lo que se hace en el ámbito personal, profesional y empresarial se beneficia al aplicar las metodologías que existen para lograr una efectiva gestión de proyectos.

Conseguir el éxito en los proyectos informáticos, como en cualquier otro tipo de proyecto, requiere liderazgo, por lo que vale la pena recordar esta frase célebre:

“Gestión es hacer las cosas bien, liderazgo es hacer las cosas” Peter Drucker

Lo anterior quiere decir que no sólo deberemos ocuparnos de hacer unos excelentes procesos de planeación, sino que tendremos que ocuparnos de ejecutar todo tipo de actividades y contar con el liderazgo necesario para garantizar que éstas sucedan.

En el contexto que nos ocupa, como servidores públicos, la gestión de proyectos tiene aún más relevancia porque nos brinda herramientas para procurar el desarrollo exitoso de los proyectos y por ende, una adecuada ejecución de los recursos públicos asignados a ellos.

1.2. Definición de proyecto

Existen numerosas definiciones de proyecto, pero la que tal vez describe mejor la relevancia de su significado, es aquélla que lo define como “herramienta o instrumento del cambio”. ¿Qué significa lo anterior?

Esto significa que al ejecutar los proyectos lo que realmente hacemos es generar modificaciones que van desde ajustes a la forma de realizar tareas básicas (ejemplo: La automatización de un registro de usuarios), hasta grandes transformaciones en aspectos que conforman nuestro entorno (ejemplo: las grandes obras de infraestructura que actualmente se ejecutan para conectar la totalidad de municipios del país con Internet a alta velocidad).

2

Desde un marco más formal, como el sugerido por el Project Management Institute, podríamos acudir a las siguientes definiciones:

• Un proyecto es un conjunto de actividades planificadas, ejecutadas y supervisadas que con recursos finitos tiene como objetivo crear un producto o servicio único.

• Un proyecto es una actividad que tiene un inicio, que se lleva a cabo para conseguir unos objetivos definidos y tiene un final previsto.

En el marco de las definiciones anteriores, es importante distinguir entre aquello que constituye el desarrollo de operaciones o actividades regulares de la entidad, y lo que realmente es un proyecto. Veamos los ejemplos correspondientes.

EJEMPLO 1: En el primer caso, nos referimos a operaciones que se ejecutan de forma repetitiva para obtener resultados de similares características, como por ejemplo: los procesos de atención a nuestros usuarios.

EJEMPLO 2: En el segundo, nos referimos al conjunto de actividades que se requieren para producir un resultado único, como por ejemplo: la implementación de un _Kiosco Vive Digital_

Como se deriva de los ejemplos anteriores, aunque ambos están relacionados con atención al ciudadano, es evidente que el “proyecto” es un instrumento de transformación porque mejora las condiciones de prestación de los servicios. La prestación de estos servicios se anota en un conjunto de actividades que se desarrollan de manera regular, lo cual se refiere a “operaciones”.

1.3. Característica de un proyecto

A continuación, se mencionan las características o atributos comunes en los proyectos, independientemente de que sean o no informáticos:

• Objetivo: Todo proyecto debe tener un objetivo. El objetivo principal de un proyecto es obtener un resultado en forma de bien o producto para un cliente dentro de unas especificaciones.

• Calendario de actividades: un proyecto debe tener un plan de trabajo que establezca el marco en donde se realizará cada actividad, teniendo en cuenta que el proyecto es un esfuerzo de carácter temporal.

3

• Demanda de recursos: para su ejecución, u proyecto requiere de un conjunto de recursos humanos, logísticos, técnicos y financieros que son de carácter limitado y sin los cuales, no es posible conseguir su objetivo.

• Estructura organizacional: un proyecto requiere una organización que

soporte su ejecución. Esta organización está conformada por personas a quienes se les asignan roles y responsabilidades específicas.

• Sistema de control e información: Un proyecto requiere de un sistema

que le permita registrar la documentación e información relacionada con el mismo.

De acuerdo con el Project Management Institute 1(PMI), un proyecto se caracteriza por:

• Temporal: El final se alcanza cuando se ha logrado el alcance y los objetivos del proyecto o cuando queda claro que el alcance y los objetivos del proyecto no serán o no podrán ser alcanzados, cuando la necesidad por satisfacer –en el proyecto- ya no exista o el proyecto sea cancelado. Temporal no es necesariamente de corta duración, pues algunos proyectos pueden tomar varios años como ocurre en acciones de largo alcance establecidas en el Plan de Desarrollo. En cada caso, sin embargo, la duración de un proyecto es limitada. También es oportuno reiterar que los proyectos no son esfuerzos rutinarios.

• Productos –bienes y/o servicios- o resultados únicos: Un proyecto crea productos entregables-bienes y/o servicios o resultados únicos, así: Un producto-bien o artículo producido que es cuantificable, y que

puede ser un elemento terminado, un componente o un servicio prestado. Por ejemplo, la construcción de un _Kiosco Vive Digital_.

La capacidad de prestar un servicio como, por ejemplo: la capacidad de ofrecer servicios antes no disponibles a través de medios virtuales.

Un resultado como, por ejemplo: un reporte, un nuevo concepto, un diagnóstico.

• Singularidad: La singularidad es una característica importante de los

productos o entregables de un proyecto. Por ejemplo: en la

1 El Project management institute (PMI), es una organización internacional sin fines de lucro que asocia a profesionales relacionados con la Gestión de Proyectos.

4

implementación de sistemas para administrar la información de nómina y personal en las entidades nacionales, existen soluciones que han sido implementadas desde el Departamento Administrativo de la Función Pública, como es el caso del Sistema de Información y Gestión del Empleo Público –SIGEP- PEOPLENET Modelo Gobierno, que no obstante se basan en la misma herramienta tecnológica demandan esfuerzos únicos, como los que se reflejan en la parametrización particular que debe hacer cada insititución. Es decir, en aquellos aspectos en que es necesario especificar en los sistemas para que se adapten a las necesidades particulares de cada entidad (en este caso por ejemplo, reglas particulares inherentes a regímenes de nómina). Esto quiere decir que aunque en proyectos de implementación de este tipo de software se tengan muchos elementos comunes, no se elimina la condición de proyecto único, dado el esfuerzo particular que debe adelantar cada entidad para lograr su adaptación.

• Elaboración gradual: es una característica de los proyectos que acompañan a los conceptos de temporal y único. “Elaboración gradual” significa desarrollar en pasos e ir aumentando con incrementos. Por ejemplo: El alcance de un proyecto se define de forma general al comienzo del proyecto, y se hace más explícito y detallado a medida en que el equipo del proyecto desarrolla un mejor y más completo entendimiento de los objetivos y de los productos –bienes y/o servicio- y entregables asociados. La elaboración gradual no debe confundirse con prácticas que permitan que con el transcurso del tiempo se modifique el alcance: lo que sucede es que en principio, no es posible establecer de manera previa a la ejecución de los proyectos, todas las definiciones y especificaciones que enmarcarán el producto o servicio por obtener, razón por la cual los mismos se van acotando durante la ejecución del proyecto. Esto es muy típico de los proyectos de desarrollo de software o de consultorías especializadas con objetos complejos, como el caso de proyectos de Arquitectura Empresarial.

1.4. Proyectos informáticos

Los proyectos informáticos corresponden a la clasificación de aquellos proyectos cuyo objeto o propósito está relacionado con la informática o comunicaciones.

5

Los proyectos informáticos cubren todo tipo de soluciones: (Productos, Bienes o Servicio) que hacen uso de las tecnologías de la información y las comunicaciones. Además de las actividades y medios de soporte para: La capacitación, Almacenamiento, Procesamiento y distribución de la información. A continuación, se presentarán los tipos más comunes de proyectos informáticos, para analizar sus particularidades.

1.5. Clasificación de Proyectos informáticos

La clasificación de los proyectos informáticos se puede realizar según múltiples criterios, por lo cual resulta importante disponer de una caracterización que facilite la identificación de características comunes, tales como las actividades que se desarrollarán en la ejecución de los mismos, para luego entender sus riesgos asociados. Adicional a lo anterior, es pertinente asociar a la clasificación eminentemente técnica derivada de las actividades del proyecto, aspectos como la complejidad, el riesgo, la frecuencia y la urgencia que representan los mismos. Con esta asociación, se adopta una visión más estratégica de los proyectos informáticos. La gráfica anterior permite analizar aspectos que resultan muy comunes a los proyectos informáticos según su tipo, por ejemplo: los proyectos estratégicos, es decir, aquellos que tiene gran impacto en la organización por ser de carácter misional o cuyo ámbito de aplicación es transversal a las dependencias que la conforman, no son muy comunes pero normalmente implican un alto riesgo y complejidad (ejemplo: proyectos como la implementación de un ModeloIntegrado que gestione toda la información misional de una entidad, será un proyecto que se implemente una sola vez en un período de varios años). Los proyectos de mantenimiento tienen una baja complejidad y riesgo por corresponder a actividades de orden más operativo y rutinario, pero se requieren con mayor frecuencia y urgencia que otros proyectos2. Los proyectos de infraestructura computacional o de redes de comunicaciones suelen ser equilibrados en materia de complejidad, riesgo, frecuencia y urgencia3.

2 Ejemplo: proyectos necesarios para el mantenimiento de la infraestructura informática (equipos de cómputo y demás dispositivos), serán proyectos que se requieren en cada vigencia. 3 Ejemplo: la adquisición de servidores, licencias, servicios de conectividad, etc.

6

2. Tipos de proyectos informáticos 2.1. Proyectos de adquisición de elementos de hardware, periféricos o dispositivos de comunicaciones Este tipo de proyectos corresponde a la adquisición de elementos físicos, tales como hardware, periféricos o dispositivos de comunicaciones.

En el marco de la clasificación establecida anteriormente, estos proyectos corresponden a proyectos de infraestructura. En consecuencia, se consideran equilibrados en materia de complejidad, riesgo, frecuencia y urgencia.

PROYECTOS DE ADQUISICIÓN

¿Cómo se consideran? En general, el objeto de estos proyectos no se considera de alta complejidad ni de alto riesgo y el seguimiento a su ejecución es relativamente sencillo.

¿Cómo se debe hacer el seguimiento? Se deben verificar los modelos y referencias de los bienes adquiridos en función de sus especificaciones y recibo a satisfacción de los servicios complementarios o conexos que se hayan solicitado, tales como la instalación, la configuración, etc.

¿Qué tipos existen? Son proyectos de este tipo los siguientes ejemplos:

• Adquisición de servidores para el procesamiento de datos • Adquisición de equipos de cómputo (de escritorio, portátiles, etc.) • Adquisición de impresoras, scanners o equipos multifuncionales

(soluciones de todo en uno). • Adquisición de equipos de comunicaciones (switches, enrutadores,

etc.) • Adquisición de soluciones tipo “appliance” –dispositivos de

hardware que contienen una serie de funciones o aplicaciones de software- (ejemplo: Sistema de seguridad perimetral que integra varias funciones de seguridad, tales como firewall, antispam, antivirus, sistema de detección de intrusos, etc.)

¿Qué requieren?

7

Los proyectos de este tipo requieren que como parte del proceso precontractual, se haya efectuado un adecuado estudio4 y dimensionamiento de las especificaciones técnicas de los elementos que se van a adquirir, con el objeto de que los mismos atiendan de manera efectiva las necesidades de la entidad. Es una buena práctica en este tipo de proyectos, realizar actividades previas al estudio de mercado que permitan identificar diferentes proveedores que representen diferentes fabricantes, de manera tal que sea posible estructurar un conjunto de especificaciones que enmarquen marcas y modelos de diferentes fabricantes que representen el mismo segmento o nicho de mercado. Lo anterior significa obtener unas especificaciones que representen características homogéneas (o muy similares), dentro de un rango de precio.

Iniciativas en curso En este tipo de proyectos, que implican la adquisición de bienes (tales como equipos o servidores de cómputo) resulta muy importante mencionar dos (2) iniciativas que actualmente está adelantando el Ministerio de Tecnologías de la Información y las Comunicaciones, que van modificar de -manera sustancial- la manera en que actualmente se obtienen. Marco de Referencia de Arquitectura Empresarial para la Gestión de TI en el Estado. Este marco busca que a través de lineamientos, estándares y guías, las entidades públicas se articulen en función del ciudadano y actúen de manera más efectiva y eficiente. Algunos de los lineamientos que se consideran incluir como parte de este Marco, contemplan aspectos como los de orientar a las entidades a contratar servicios -en vez de adquirir bienes- para disponer de capacidades de cómputo o almacenamiento por ejemplo, teniendo en cuenta que en muchas ocasiones las entidades públicas adquieren capacidades con problemas de dimensionamiento, las tecnologías se vuelven obsoletas rápidamente y que una vez adquiridas no permiten aprovechar bondades que sí ofrece el hecho de contratar estas capacidades bajo la modalidad de servicio, como por ejemplo, la

4 El objetivo de lo anterior, es facilitar la realización de un proceso de selección que considere opciones comparables entre sí, sin diferencias técnicas o de precio sustanciales.

8

flexibilidad para ampliar o reducir las capacidades en función de las necesidades reales, pagar sólo por lo que se consume, así como reducir costos y riesgos en aspectos de gestión de las mismas mediante soporte técnico especializado incluido como parte del servicio. Acuerdos Marco de Precio para la adquisición de Bienes y Servicios de TI. Estos acuerdos se están gestionando conjuntamente entre el Ministerio TIC y la Agencia Nacional de Contratación Pública - Colombia Compra Eficiente y han sido diseñados con expertos en TI y profesionales en compras públicas, para que hacer más eficiente y eficaz la compra de tecnología y la adquisición de servicios TI en las entidades públicas. Las entidades podrán adquirir herramientas y servicios más adecuados para el Estado, adelantando un proceso más transparente, rápido y eficiente, con importantes ahorros en tiempo y costos. Por ejemplo, a través de un catálogo como el que ofrece cualquier tienda virtual, las entidades podrán solicitar cotizaciones de un bien o servicio TI -que se encuentre disponible en el catálogo- pasando de un proceso que antes podría tomar 5 o 6 meses, a uno virtual que puede tomar unos pocos días. Lo anterior se logra, dado que Colombia Compra Eficiente con apoyo del Ministerio TIC, adelanta procesos de contratación para seleccionar proveedores de los bienes o servicios TI y una vez habilitados, la entidad con la identificación de una necesidad y la decisión de efectuar un gasto para satisfacerla, verifica si existe un Acuerdo Marco de Precios para ese bien y/o servicio TI particular, que al estar disponible le permite hacer el proceso para obtener una cotización y posteriormente efectuar una orden de compra (equivalente al contrato) en los términos establecidos en el Acuerdo Marco de Precio.

2.2. Proyectos de adquisición de licencias de software Este tipo de proyectos corresponde a la Adquisición de licencias de software comercial o a procesos cuyo propósito es obtener la suscripción para recibir actualizaciones, mantenimiento y soporte de software comercial y de plataformas basadas en código abierto.

9

Estos se enmarcan en la tipología de proyectos de infraestructura. En consecuencia, se consideran equilibrados en materia de complejidad, riesgo, frecuencia y urgencia.

PROYECTOS DE ADQUISICIÓN DE LICENCIAS DE SOFTWARE

• ¿Cómo se debe hacer el seguimiento? En general, su seguimiento se considera sencillo en la medida como se verifiquen los documentos (físicos o electrónicos), que dan cuenta de la obtención de la licencia de software –en el caso de software comercial- o de los respectivos certificados de suscripción a actualizaciones, mantenimiento y soporte.

• ¿Qué tipos existen? Adquisición de licencias de sistemas operativos Adquisición de licencias de bases de datos. Adquisición de licencias de software ofimático (ejemplo :Microsoft

Office) Adquisición de licencias de software especializado (plataformas de

Sistemas de Información Geográfica, aplicaciones de diseño, herramientas estadísticas, etc.)

Suscripción de actualización mantenimiento y soporte de sistemas operativos de código abierto (ejemplo: Red Hat, Suse, etc.)

Renovación de soporte y actualización de licencias Oracle. Adquisición de actualizaciones para migrar software existente a

nuevas versiones.

• ¿Cuál es la importancia de este tipo de proyectos? La importancia de este tipo de proyectos reside en la necesidad de que las entidades acaten las disposiciones vigentes sobre propiedad intelectual y derechos de autor. Estas disposiciones enfatizan sobre la exigencia de que cualquier persona que pretenda utilizar una creación protegida, deberá contar, salvo las excepciones legales, con la autorización previa y expresa del autor, de sus derechohabientes o de los titulares de los derechos patrimoniales, en el caso de tratarse de una obra sobre la cual operó la transferencia de los mismos. Sin su consentimiento, la utilización de la obra podría llegar a ser calificada judicialmente como ilícita, por vulnerar derechos sobre la creación protegida, y es probable la aplicación de sanciones de tipo civil y penal. En este sentido, es oportuno resaltar la diferencia que existe entre lo que significa adquirir una licencia de uso de software, versus lo que implica el

10

desarrollo del software como una obra por encargo, lo cual se detallará en un numeral posterior. La obtención de una licencia de uso de software o programa de computador, es el instrumento, ya sea un contrato o unas instrucciones, por medio de las cuales el titular de derechos patrimoniales autoriza a los usuarios para que se sirvan de la obra en una forma determinada. Por lo general, en el caso del software propietario, sólo son comercializados el código objeto (lenguaje de máquina), y los manuales de funcionamiento, apropiando el titular de manera exclusiva el manejo sobre el código fuente. De esta manera, el programador se asegura de poder explotar su obra en forma sistemática, sin tener que transferir su dominio y al mismo tiempo, resguarda su razonamiento lógico inicial, previniendo que otra persona desarrollo un programa de computador de características similares.

• ¿Qué pasa con el software GNU? En el caso de software basado en código abierto, denominado también software libre, se destaca la Licencia Pública General de GNU –por sus siglas en inglés GNU GPL-, que fue creada por la Free Software Foundation en 1989 (la primera versión), y está orientada principalmente a proteger la libre distribución, modificación y uso de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios. En este tipo de soluciones, también es común la especificación de conceptos como copyleft, método general para hacer que un programa (u otro tipo de trabajo), libre, logre que todas las versiones modificadas y extendidas del mismo sean también libres. No obstante el software basado en código abierto, se puede obtener a través de diferentes fuentes en internet, cuando éste hace parte de plataformas o soluciones como las que disponen las entidades estatales. Se adquieren suscripciones que permiten recibir actualizaciones de manera continua, así como soporte para las mismas, lo cual eleva su seguridad y fiabilidad.

• ¿Cómo solicitar software licenciado? En el caso de adquisición de licencias nuevas de software comercial, es de suma importancia establecer dentro de las especificaciones técnicas, el nombre completo del software para licenciar, la versión (si se pretende

11

tener la última, aclarar, indicando “última versión”), y condiciones técnicas de la plataforma en donde debe poder ser ejecutado el software. Por ejemplo: en el caso de sistemas operativos, podría ser para plataformas de servidores de 32 ó 64 bits. En el caso de software para plataformas de escritorio, podría especificarse que debe funcionar en una o más versiones particulares de sistema operativo (Windows XP, Windows Vista, Windows 7, Windows 8, etc.).

• Suscripciones o renovaciones En cuanto a los suscripciones o renovación de servicios de actualización, mantenimiento y soporte, se debe tener muy claras las condiciones para la obtención de estos servicios, ya que en muchos casos, se trata de contratos previamente especificados por los proveedores, por lo cual la entidad termina adhiriendo prácticamente a las condiciones establecidas en el mismo. ¿Qué ventajas se pueden obtener por la renovación de suscripciones? Se tienen las siguientes: Mejorar la seguridad de los sistemas operacionales y aplicaciones,

dado que permanentemente se detectan y corrigen vulnerabilidades.

Acceder a recursos y asistencia técnica para solucionar problemas o para optimizar su aprovechamiento.

Obtener las últimas novedades de software tan pronto como las mismas estén disponibles.

La ejecución de este tipo de proyectos, constituye un rubro importante dentro de los presupuestos de las áreas de sistemas y tecnología del MinTIC, por lo cual resulta muy importante dimensionar en forma adecuada, los recursos necesarios y programarlos en el presupuesto.

Mediante los Acuerdos Marco de Precio que ya se comentaron en anteriormente, se podrá disponer en el catálogo virtual de algunos de los esquemas de licenciamiento por volumen que actualmente usan las entidades, así como esquemas de adquisición de SaaS - Software as a Service (Software como un servicio), qué significa poder obtener el software como un servicio, pagando por el uso que hacemos del mismo y no por la licencia.

12

2.3. Proyectos de Desarrollo de aplicaciones de software a la medida, Mantenimiento (ajustes, mejoras y nuevas funcionalidades), Parametrización y adaptación de soluciones El estándar IEE 1062, define una clasificación para los productos de software, que se basa en el grado de libertad que tiene el usuario para definir y especificar sus funcionalidades. De esta forma establece tres tipos de software:

COTS – Commercial-off-the-shelf-software: que se refiere a un product comercialmente disponible. Por lo general, este tipo de productos de software están bien definidos y documentados, y su uso por parte de un gran número de usuarios, demuestra su desempeño y aceptación. El proveedor no tiene libertad para modificarlos según las necesidades de un cliente específico. El costo para adquirir el software es de bajo a mediano y la entrega del producto es inmeiata.

MOTS –Modified-off-the-shelf-software: este tipo de producto se caracteriza porque es con-figurable, es decir, corresponde a un producto elaborado pero sobre el cual el proveedor tiene posibilidad de modfi-car determinadas funcionalidades del product de software, según los requisitos del cliente.

El desempeño del producto se puede mostrar en aplicaciones semejantes, configuradas para otros clientes. El cliente tiene un control relativo del mantenimiento del producto y de sus características de calidad, y su implementación tiene tiempos de entrega que varían entre mediano y largos plazo (de unos meses a poco más de un año), y los niveles de costos oscilan entre mediano y alto, según su complejidad.

FD – Fully Developed Software: se refiere estrictamente al software hecho a la medidak es único, y se desarrolla para atender completamente los requerimientos específicos del cliente. Como el producto no tiene precedente, su desempeño no puede ser evaluado previamente, pero el cliente posee total control sobre sus características de calidad y mantenimiento. Por lo general, el costo para el cliente es alto, el tiempo de entrega es a largo plazo (ocho meses a más de un año o incluso, varios años según su complejidad)

En cuanto al mantenimiento del software, muchas veces se subestima el esfuerzo en desarrollo de este tipo de actividades, cuando la práctica demanda un volumen importante de recursos. De hecho, aun cuando es la última etapa en el ciclo de vida del software, las actividades que se desarrollan en esa etapa son muy importantes para mantener la vigencia y capacidad del software. En términos de costos, muchos autores han señalado que el costo de mantenimiento de un producto del software durante toda su vida útil, supone más del doble de la inversión que implicó su desarrollo inicial .

13

Adaptado a partir de GASCA, Gloria. Metodología de Gestión de riesgos para la adquisición de Software en pequeños entornos – MEGRIAD.

Según la terminología ANSI-IEEE, el mantenimiento del software es: “la modificación de un producto software después de su entrega al cliente o usuario para corregir defectos, para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno”.

Este tipo de proyectos corresponde al desarrollo de aplicaciones o software a la medida, es decir, para atender las necesidades particulares de la entidad, así como aquellas que tienen como objeto el mantenimiento a aplicaciones existentes, que tiene como propósito realizar ajustes, mejoras o el desarrollo de nuevas funcionalidades que mejoren las condiciones del software actual. Dentro de esta tipificación, también incluiremos aquellos proyectos cuyo objeto sea la parametrización y adaptación de soluciones de software, como por ejemplo: aquellos programas que se puedan obtener mediante convenios con otras entidades o instituciones.

¿Qué proyectos se clasifican en esta categoría?

En cuanto a complejidad, riesgo, frecuencia y urgencia, es necesario distinguir la diferencia ente los esfuerzos de desarrollo que parten.

¿Cómo se consideran? Desde las especificaciones iniciales cuando no se disponía de alguna herramienta (desarrollo de software desde cero), o la parametrización y adaptación de soluciones, o lo requerido para realizar el mantenimiento a aplicaciones que existan en la entidad. En el primer caso, referido a desarrollos que parten desde cero, usualmente la complejidad y riesgo dependen del tamaño y cobertura de la implementación que por lo general, es proporcional al impacto que tendrá la herramienta en las operaciones de la entidad. Por ejemplo: el desarrollo de un nuevo software que trate los aspectos misionales de la misma, deriva en un esfuerzo de alta complejidad, poco frecuente (lo normal es no estar cambiando de aplicativos que contemplan los aspectos misionales con frecuencia, dado los traumatismos que esto genera), de alto impacto y riesgo; mientras que un desarrollo para un área de apoyo con un alcance muy puntual, usualmente es de bajo riesgo y poca complejidad.

Alcance Aquí en estos dos casos, aunque es importante analizar el alcance de las modificaciones o nuevas funcionalidades que se pretende desarrollar, por

14

lo general no se trata de proyectos muy complejos o de alto riesgo. Sin embargo, es posible que su frecuencia sea alta, si se trata de un software que apoya operaciones rutinarias de la entidad y que en consecuencia, debe estarse adaptando a las necesidades derivadas de la búsqueda permanente de su mejoramiento y optimización.

¿Cómo se debe hacer el seguimiento? A diferencia de los otros dos tipos de proyectos ya mencionados, los aquí clasificados, requieren un seguimiento permanente, una alta interacción tanto con el proveedor/ contratista a cargo de su desarrollo, como con las áreas usuarias. Se debe tener especial cuidado en la revisión de procesos u procedimientos relacionados o impactados por la nueva solución, requerimientos de orden normativo y técnico, así como de articulación con otros sistemas o procesos. Estos aspectos aplican a proyectos que sólo se pueden contratar externamente, y a los que puedan realizarse con recursos internos de la entidad.

¿Qué tipo de mantenimiento puede requerirse? Desde el punto de vista de las actividades que se pretenden resolver con el mantenimiento de software, se pueden establecer tres tipos de mantenimiento.

MANTENIMIENTO CORRECTIVO: Son aquellas actividades destinadas a corregir defectos o “bugs” en el software. Las incorrecciones pueden derivarse de errores no intencionales que se hayan presentado durante el proceso de desarrollo o incluso, de defectos derivados de especi-ficaciones incorrectas que inicialmente se hayan brindado y que no fueron detectados oportunamente para haber sido resueltos. Lo anterior sucede porque a pesar de las pruebas y veri-ficaciones que se realizan durante la recepción de un sistema, es posible que los programas tengan defectos y en consecuencia, pueden fallar . MANTENIMIENTO EVOLUTIVO: Es el conjunto de actividades destinadas a realizar incorporaciones, modificaciones o eliminaciones en los programas que comprende el producto de software para mejorar sus propiedades. En este tipo de mantenimiento, no se realizan modi-ficaciones funcionales, y aunque en algunas oportunidades pueden estar

15

orientadas a aumentar su calidad, son actividades que se valoran más en aspectos técnicos tales como la mantenibilidad (por ejemplo: con acciones para mejorar su documentación), y reusabilidad (por ejemplo: integrar componentes comunes para convertirlos en bibliotecas que puedan ser reusadas posteriormente), del software. MANTENIMIENTO ADAPTATIVO: Comprende actividades destinadas a la adaptabilidad del software a cambios en su entorno técnico. Los cambios del entorno no son sólo los de tipo normativo o procedimental. En este caso, se consideran aquellos relacionados con el entorno tecnológico (por ejemplo: cambios de base de datos, servidor de aplicaciones u otros aspectos de plataforma tecnológica), cada vez más frecuentes debido a la evolución que sufren los componentes que conforman la arquitectura tecnológica de las entidades. Un defecto corresponde a una característica que tiene un sistema, de la cual se pueda derivar un potencial fallo Una falla ocurre cuando el comportamiento de un sistema es diferente a lo establecido según la respectiva especifi-cación. Entre algunos de los fallos más comunes se encuentran los de procesamiento, los de rendimiento, los de programación y los de documentación.

Recomendaciones

En todo proyecto relacionado con software, sea éste un desarrollo hecho a la medida, un proceso de mantenimiento para adecuar sus funcionalidades o una parametrización para adoptar un software existente, se debe adelantar un riguroso proceso de planeación que parta de la identificación más precisa posible de los requerimientos, el acotamiento de su alcance, una adecuada estimación de los recursos requeridos y posteriormente, durante su desarrollo, un seguimiento y control orientado a verificar las condiciones de calidad de los productos. Otro aspecto importante para tener en cuenta, que complementa lo ya establecido en el numeral anterior, es lo referente a la propiedad intelectual, ya que en el caso del software hecho a la medida, ésta se asimila a una obra por encargo y debe especificarse la sesión de los

16

derechos patrimoniales a favor de la entidad, de tal manera que ésta no tenga restricciones posteriores en aspectos tales como su mantenimiento.

2.4. Proyectos de Mantenimiento de infraestructura tecnológica Este tipo de proyectos corresponde a la realización de procesos de mantenimiento que faciliten el adecuado funcionamiento y disponibilidad de los diferentes elementos que conforman la infraestructura tecnológica de las entidades.

¿Cómo se consideran? Estos proyectos por lo general, tienen una baja complejidad y riesgo por corresponder a actividades de orden más operativo y rutinario, pero se requieren con mayor frecuencia y urgencia que otros proyectos. Es obvio que existe una relación entre la especialidad técnica de los elementos para mantener y su complejidad. Por ejemplo: tendrá mayor riesgo y será de mayor complejidad la realización de servicio de mantenimiento a servicios de datos, que a equipos de cómputo

¿Qué tipos existen? Los proyectos de mantenimiento comprenden un conjunto de actividades que se programan cada cierto tiempo, con el fin de prevenir algún tipo de falla o una reducción acelerada de la vida útil de los equipos y materiales que conforman la infraestructura informática de la entidad. Son proyectos de este tipo los siguientes ejemplos: Mantenimiento de servidores Mantenimiento de equipos de cómputo y periféricos (contempla

computadores de escritorio, portátiles, impresoras, scanner, etc.) Mantenimiento de cableado estructurado Servicios de monitoreo y gestión de la red de datos. Servicios de monitoreo y gestión de la red de aplicaciones. Realización de inventario de hardware y software Suministro de repuestos para componentes de infraestructura

tecnológica

MANTENIMIENTO PREVENTIVO: Consiste en realizar un conjunto de actividades que permitan disponer de un ambiente favorable para el adecuado funcionamiento de los componentes que conforman la

17

infraestructura tecnológica de la entidad. Un mantenimiento preventivo rutinario evita daños más costosos a la infraestructura en momentos posteriores. MANTENIMIENTO CORRECTIVO: Consiste en realizar actividades que permitan restablecer el adecuado funcionamiento de los componentes que conforman la infraestructura tecnológica de la entidad, que se hayan visto afectados por algún daño físico o lógico. En el caso de equipos y elementos electrónicos, corresponde a actividades como el cambio de partes, la configuración o ajuste del software o el cambio total de periféricos como el mouse, teclado, monitor, entre otros.

Los inventarios

En este tipo de proyectos, es muy importante tener un adecuado inventario de los componentes por cubrir con el mantenimiento, de tal forma que a partir de modelos y referencias, se pueda establecer los números de partes de repuestos que puedan requerirse.

Acuerdos de servicio Un aspecto importante para tener en cuenta, es que la realización de las actividades de mantenimiento se encomiende a personas idóneas, preferiblemente personal certificado, para reducir el riesgo de que las intervenciones terminen por afectar aún más, cualquiera de los componentes de la infraestructura tecnológica de la entidad. De igual forma, la entidad debe establecer los parámetros con los cuales se fijarán los acuerdos de nivel de servicio que no es otra cosa que un acuerdo formal mediante el cual el proveedor del servicio y la entidad determinan aspectos tales como el entendimiento común de los servicios, prioridades, responsabilidades, garantías y demás, conocidos en forma colectiva como el “nivel de servicio”. Este tema ha ganado cada vez más importancia, considerando la necesidad de garantizar una alta disponibilidad de los servicios soportados en los componentes de infraestructura tecnológica de las entidades.

Infraestructura como Servicio Otro elemento a resaltar para este tipo de proyectos, es que en los esquemas de adquisición de elementos como IaaS – Infraestructure as a Service (Infraestructura como Servicio) que se habilitarán gracias a los Acuerdos Marco de Precio ya mencionados, las entidades podrán preocuparse cada vez menos por hacer contratación de servicios de

18

mantenimiento asociados a Infraestructura Computacional, como por ejemplo, los que se debían contratar posteriormente a la adquisición de servidores o equipos de cómputo dado que éste tipo de mantenimiento hace parte de los servicios que se integran cuando se contrata como servicio.

2.5. Proyectos de Seguridad Informática Este tipo de proyectos corresponde a la provisión de bienes o contratación de servicios que se requieren para el mejoramiento de las condiciones de seguridad de la información en la entidad.

¿Cómo se consideran? En el marco de la clasificación establecida al inicio de este numeral, la mayoría de las actividades por contratar, se consideran equilibradas en materia de complejidad, riesgo, frecuencia y urgencia. No obstante lo anterior, algunas de las actividades son de alto impacto y riesgo, por lo tanto, deben adelantarse con las precauciones que correspondan, Por ejemplo: la ejecución de pruebas de hacking ético que se emplean para diagnósticas, analizar y mejorar condiciones de seguridad en plataformas computacionales.

¿Qué tipos existen? Teniendo en cuenta que los proyectos que se desarrollan en materia de seguridad informática, tratan de asegurar la integridad y la privacidad de los sistemas de información, deben cubrir todos los componentes que forman un sistema de información, esto es, los datos, el software, el hardware, las redes, los usuarios y las instalaciones físicas, entre otros. Son proyectos de este tipo los siguientes:

• Consultoría para la implementación de un Sistema de Gestión de Seguridad de la Información (SGSI)

• Prestación de servicios para el análisis de brechas de seguridad, mediante hacking ético

• Auditorías de seguridad informática • Implementación de servidores de seguridad • Consultoría para implementar un plan de continuidad de negocio • Análisis forense para investigar delitos informáticos • Recuperación de datos en discos duros (borrados, dañados o

afectados por virus) • Implementación de esquemas de firma digital • Capacitación y sensibilización en seguridad informática

19

Aunque son muchos los proyectos que se contemplan en esta clasificación, en general, la mayoría de los proyectos que se desarrollan en esta materia, derivan de un proceso de análisis de riesgos5, a partir del cual se contempla el panorama de las posibles vulnerabilidades que puedan comprometer la información de la entidad y que facilita la priorización de las acciones por ejecutar.

La identificación de los riesgos de seguridad permite aclarar las ideas e identificar los posibles riesgos para la seguridad. La información se recopila en forma de amenazas, vulnerabilidades, puntos débiles y medidas preventivas.

Una vez se hayan identificado los riesgos y los activos de información, se puede plantear de manera más acertada, las acciones de aseguramiento que pueden consistir en acciones que van desde la ejecución de protocolos de aseguramiento o “hardering” de sistemas operativos, hasta la implementación de esquemas para disponer de un plan de continuidad de negocio. La obtención de servicios, así como la adquisición de equipos (por ejemplo: sistemas unificados de gestión de amenazas tipo “appliance”), para este tipo de proyectos, debe encomendarse a proveedores con experiencia, preferiblemente certificados en las plataformas o equipos o en las metodologías que se emplearán, según el caso.

2.6. Proyectos de adecuación de infraestructura para Centros de Datos, hosting o colocation de servidores, sistemas de control de acceso o videovigilancia Este tipo de proyectos corresponde a la realización de obras civiles, adquisición de elementos físicos y lógicos para garantizar una adecuada infraestructura de un sitio de procesamiento de datos, así como a sistemas complementarios que permitan el monitoreo y control físico y ambiental de sus instalaciones.

En el marco de la clasificación establecida al inicio de este numeral, estos corresponden a proyectos de infraestructura. En consecuencia, se consideran equilibrados en materia de complejidad, riesgo, frecuencia y urgencia.

Aunque no siempre estos proyectos están a cargo de las áreas de tecnología de las entidades, es importante mencionarlos porque resultan ser de alto impacto en términos de la disposición de las condiciones óptimas que deben garantizarse para los equipos de procesamiento de datos.

5 Para que este análisis tenga un efecto positivo en la entidad, es necesario identificar los aspectos críticos durante cada proceso de negocio, de forma tal que las acciones se aseguramiento se prioricen conforme con el impacto e importancia que representan los mismos. Esto asegura que las acciones de aseguramiento se prioricen conforme con el impacto e importancia que representan los mismos. Esto asegura que las acciones de implementación se enfocan en las áreas más estratégicas, evitando la afectación de los activos más importantes de la entidad.

20

• ¿Qué tipos existen? Son proyectos de este tipo, los siguientes ejemplos: Adecuación física a Centros de Datos Implementación de sistemas de control ambiental Implementación de sistemas de extinción de incendios Implementación de sistemas de control de acceso Implementación de un sistema de viodeovigilancia Alojamiento de servidores, colocation.

• ¿Por qué los centros de datos?

En la medida en que han venido robusteciendo su infraestructura tecnológica, la mayoría de las entidades tiene como reto, disponer de centros de datos que brinden condiciones adecuadas a su operación. Esto no es tan sencillo, en la medida en que las condiciones en las cuales las entidades empezaron a disponer de Centros de Datos, no tenían reglamentaciones o no se contemplaron en su ejecución, los estándares que rigen actualmente la implementación de este tipo de infraestructura física. Servicio que ofrece la posibilidad de instalar servidores en un edificio exclusivo y especializado en el alojamiento y la conectividad de equipos o Centros de Datos externo a la entidad.

• Aclaraciones Se recomienda la coordinación y acompañamiento a la dependencia responsable con el objeto de participar desde la generación de las especificaciones, hasta la recepción a satisfacción de los productos o resultados. No obstante lo anterior, vale la pena recordar que muchos de los aspectos requeridos por las entidades para contar con capacidad e infraestructura de procesamiento de datos, como las que justificaban anteriormente la construcción de Centros de Datos, hoy día, ya no se consideran como inversiones que deban adelantar las entidades públicas, por cuanto los mismos se pueden adquirir “como servicio” con todas las ventajas que esto implica6.

• ¿Qué otros tipos de proyectos requieren de apoyo del área de tecnología? En cuanto a la implementación de sistemas de control de acceso, control ambiental y videovigilancia, al considerarse que la contratación contempla

6 Mayor flexibilidad, oportunidad, pago por consumo, soporte técnico especializado, etc., todo esto incluido en el costo del servicio. De ahí la importancia de consultar la disponibilidad de los acuerdos marco de precio para disponer de este tipo de servicio.

21

aspectos de hardware y software, es común que se solicite el apoyo del área de tecnología, si es que esta misma no hace directamente el trámite. Las recomendaciones para este tipo de proyectos, son las mismas que se efectuaron en el numeral relativo a los proyectos de adquisición de hardware y periféricos, y debería adecuarse a referentes normativos y estándares técnicos que garanticen las necesidades de la entidad.

• Estándares Ahora bien, respecto de las diferentes posibilidades que existen en el mercado para obtener servicios de alojamiento en centros de datos, vale la pena resaltar el estándar ANSI/TIA-942 Telecommunications Infrastructure Standard for Data Centers, creado por miembros de la industria, consultores y usuarios, que intenta estandarizar el proceso de diseño de los centros de datos. Dentro de este estándar, se establece un concepto que resulta relevante cuando se pretende contratar servicios de alojamiento en un centro de datos, los Tiers7. El concepto de Tier nos indica el nivel de fiabilidad de un centro de datos asociados a cuatro niveles de disponibilidad definidos. A mayor número en el Tier, mayor disponibilidad y son:

TIER – I Centro de datos Básico: Disponibilidad del 99.671%. Este nivel se caracteriza así: El servicio puede interrumpirse por actividades planeadas

o no planeadas. No hay componentes redundantes en la distribución

eléctrica y de refrigeración. Puede o no puede, tener suelos elevados, generadores

auxiliares o UPS. La infraestructura del datacenter deberá estar fuera de

servicio al menos una vez al año, por razones de mantenimiento y/o reparaciones

7 Este sistema de clasificación fue inventado por el Uptime Institute para clasificar la fiabilidad de las instalaciones de un centro de datos basados en unnivel de disponibilidad.

22

TIER - 2: Centro de datos Redundante: Disponibilidad del 99.741%. Este nivel se caracteriza así: Menos susceptible a interrupciones por actividades

planeadas o no planeadas. Componentes redundantes (N+1). Tiene suelos elevados, generadores auxiliares o UPS. Conectados a una única línea de distribución eléctrica y de

refrigeración. El mantenimiento de esta línea de distribución o de otras

partes de la infraestructura, requiere una interrupción de las de servicio.

TIER – 3 Centro de datos Concurrentemente Mantenibles: Disponibilidad del 99.982%. Este nivel se caracteriza así: Permite planifi-car actividades de mantenimiento, sin

afectar el servicio de computación, pero eventos no planeados pueden causar paradas no plani-ficadas.

Componentes redundantes (N+1). Conectadas múltiples líneas de distribución eléctrica y de

refrigeración, pero únicamente con una activa. Hay su-ficiente capacidad y distribución para poder llevar a

cabo tareas de mantenimiento en una línea, mientras se da servicio por otras.

TIER – IV Centro de datos Tolerante a fallos: Disponibilidad del 99.995%. Este nivel se caracteriza así: Permite plani-ficar actividades de mantenimiento, sin

afectar el servicio de computación crítico, y es capaz de soportar por lo menos, un evento no plani-ficado del tipo ‘peor escenario’ sin impacto crítico en la carga.

Conectados a múltiples líneas de distribución eléctrica y de refrigeración con múltiples componentes redundantes (2 (N+1) signifi-ca 2 UPS con redundancia N+1).

La anterior información puede tenerse en cuenta, como referente para implementar acciones de mejoramiento en los centros de datos de las entidades o para especi-ficar características que se requieran en el caso de contratar servicios de alojamiento o colocación de servidores bajo el

23

esquema de contratación como servicio. Sin embargo, como ya se indicó, con la posibilidad de contar con estos espacios y capacidades bajo los acuerdos marco de precio, lo que resulta realmente importante será tener claras las necesidades de la entidad e identificar las oportunidades de obtención de las soluciones que mayor convengan a la institución.

2.7. Proyectos de oursourcing de Tecnologías de la Información Este tipo de proyectos corresponde a la contratación de servicios en materia de tecnologías de la información, cuya responsabilidad se transfiere a un tercero.

En el marco de la clasificación establecida al inicio de este numeral, estos proyectos corresponden a los de alta complejidad y riesgo, considerando las características de la relación contractual.

¿Qué es Outsourcing? Para entender bien el concepto de outsourcing, vale la pena establecer definiciones formales, tales como: OUTSOURCING: Es la transferencia a terceros de la

responsabilidad de proporcionar un servicio adaptado a las necesidades de una organización.

OUTSOURCING EN TECNOLOGÍAS DE INFORMACIÓN: Se define como la “cesión a una empresa externa de la gestión de los Sistemas de Información de una organización”.

¿Qué tipos existen? Los aspectos más importantes para especificar servicios para ser tercerizados, corresponden a la selección de empresas idóneas, con capacidad técnica, logística, financiera y operativa; el establecimiento de acuerdos de nivel de servicio que garanticen la satisfacción oportuna de la necesidad de la entidad; la comprensión de las necesidades de la entidad, y experiencia específica en los servicios por contratar por parte del proveedor8.

8 *** Enlaces de interés:Para ampliar el tema de los acuerdos marco de precio para suministrar los Servicios de Conectividad y Centro de Datos / Nube Privada, consulte el detalle del proceso, en: https://www.contratos.gov.co/consultas/detalleProceso.do?numConstancia=14-1-120521 Última fecha de consulta: 1/08/2014 *** *** Enlaces de interés:Para ampliar el tema de los acuerdos marco de precio para suministrar los Servicios Nube Pública, consulte el detalle del proceso, en: https://www.contratos.gov.co/consultas/detalleProceso.do?numConstancia=14-1-120568 Última fecha de consulta: 1/08/2014 *** *** Enlaces de interés:Para ampliar el tema de los acuerdos marco de precio para compraventa de Equipos Tecnológicos y Periféricos (cómputo, portátiles, todo en uno, computadores de

24

En el marco de las definiciones anteriores, hay muchos tipos de proyectos en los cuales se puede aplicar el concepto de outsourcing. Por ejemplo: Prestación de servicio de asistencia técnica en labores de

operación de Centros de Datos. Servicios integrales de desarrollo y mantenimiento de

aplicaciones. Servicios integrales de administración y operación delegada de

infraestructura. Servicio integral de mesa de ayuda y mantenimiento de

infraestructura. Justamente la alta complejidad y riesgo que representa entregar aspectos relacionados con la gestión de componentes de la operación de tecnologías de la información a terceros, motivó que aspectos como los servicios de nube pública y nube privada, mediante los cuales se tiene acceso a servicios basados en la nube bajo diferentes esquemas y condiciones, se hayan estructurado para disponerlos como acuerdos marco de precio.

2.8. Proyectos de soluciones integradas, “llave en mano” Este tipo de proyectos corresponde a aquellos en los cuales se combinan la adquisición u obtención de servicios relacionados con tecnologías de la información y las comunicaciones, con el objeto de ser empaquetados en una solución integrada o también conocida como “llave en mano”.

La definición del concepto “llave en mano”, se deriva de la conceptualización asociada al tipo del contrato que se obtiene, teniendo en cuenta que en virtud del contrato un contratista se obliga frente al cliente o en este caso, la entidad contratante a cambio de un precio, a concebir, construir y poner en funcionamiento una obra o proyecto determinado.

Desde la perspectiva de clasificaciones en materia de complejidad y riesgo, la combinación de múltiples elementos de la incorporación de aspectos tales como el diseño, e incluso la operación, determinan que éstos son de alta complejidad y alto riesgo.

escritorio, híbridos, tabletas, impresoras, escáneres, video proyectores, monitores, lectores biométricos, unidades ópticas, cámaras web, soportes de portátiles, replicadores de puertos y discos duros), consulte el detalle del proceso, en: https://www.contratos.gov.co/consultas/detalleProceso.do?numConstancia=14-1-122251 Última fecha de consulta: 1/08/2014 ***

25

El Ministerio de tecnologías de la información y las comunicaciones, como parte del Plan “Vive Digital 2010-2014”, ha ejecutado importantes proyectos orientados a la masificación del uso de internet en Colombia, que podrían clasificarse dentro de esta tipología.

Algunos ejemplos de este tipo de proyectos son:

Diseño, instalación, puesta en servicio, administración, operación, mantenimiento, promoción, uso y apropiación de las TIC en los Kioscos Vive Digital.

Diseño, instalación, puesta en servicio, administración, operación, mantenimiento, promoción, uso y apropiación de las TIC en los Puntos Vive Digital.

Diseño e instalación de aulas informáticas. Diseño e instalación de un Centro de Datos.

¿Qué involucra un proyecto de soluciones integradas como el proyecto kioscos Vive Digital del MinTIC?

Es importante recordar que un Kiosco Vive Digital (Fase II) son espacios ubicados en establecimientos y sedes educativas, donde los docentes y estudiantes de las zonas rurales y apartadas del país se benefician del servicio de conectividad a Internet, y en horario extracurricular, todos los habitantes de estas zonas, además pueden acceder a servicios de telefonía, alfabetizarse digitalmente, realizar trámites y servicios con el Estado y optimizar sus actividades económicas.

Para este proyecto, el MinTIC estableció dentro del alcance el diseño, instalación, puesta en servicio, administración, operación, mantenimiento de los Kioscos, a incluso contempla actividades relacionadas con la promoción, uso y apropiación de las TIC en estos sitios. Como se puede apreciar, son muchas las actividades incluidas dentro de este alcance y se incluyen tanto actividades técnicas como no técnicas.

Dentro de las actividades técnicas se establecen aspectos como el diseño y configuración de las redes, dotación de equipos de cómputo y de comunicaciones, su operación y mantenimiento. Mientras que en las no técnicas, contemplan aspectos como la dotación de mobiliario, marcación y ambientación de cada Kiosco conforme al manual de imagen definió para tal fin y la contratación del personal para la administración y operación, entre otros.

Teniendo en cuenta las actividades contratadas y aspectos como la distribución geográfica y volumen de los frentes de trabajo que se ejecutan paralelamente para un proyecto como éste, se hace imprescindible contar para su ejecución, con el acompañamiento de una interventoría que tenga su cargo de la verificación y

26

control de avance en las actividades a cargo del contratista, así como la evaluación técnica de la calidad de los bienes y servicios derivados del alcance del contrato, entre otros aspectos.

2.9. Otros Proyectos Teniendo en cuenta que no se pretende hacer un listado exhaustivo de la totalidad de los proyectos con componente informático, más allá de los tipos más relevantes que ya se especificaron, sólo bastaría referirnos brevemente a otros proyectos que necesiten adelantar las áreas de tecnología.

Este tipo de proyectos son:

• Arrendamiento de equipos de cómputo • Arrendamiento de licencias • Arrendamiento de unidades de potencia ininterrumpida (UPS) • Gestión de proyectos informáticos • Prestación de servicios de Capacitación}

En relación con los contratos de arrendamiento se les reconoce la ventaja de satisfacer las necesidades de carácter temporal que no impliquen adquisición de los respectivos elementos. Un aspecto importante para tener en cuenta en este tipo de servicios, es que se debe especificar que el mantenimiento preventivo y correctivo de los elementos, corra por cuenta del proveedor durante el plazo del contrato, lo cual se traduce en ahorros para la entidad. Este tipo de contratos también se podrán hacer por Acuerdos Marco de Precio.

En cuanto a la gestión de proyectos informáticos, cada vez es más común que las áreas de tecnología se apoyen en profesionales con experiencia en la gerencia de proyectos de tecnología informática, como recurso que apalanque el cumplimiento de los objetivos de las áreas de tecnología y apoyo técnico a directivos y profesionales relacionados con proyectos de TI.

Por último, la contratación de servicios de capacitación, pretende fortalecer las competencias, habilidades y destrezas del personal de la organización, como base para mejorar los productos y servicios del área de tecnología. En este sentido, es muy importante establecer un plan de capacitación que refleje las necesidades particulares de los servidores públicos del área, en relación directa con su perfil y funciones a cargo, para garantizar la coherencia, pertinencia y eficacia de la formación que se pretende brindar.

27

3. Importancia e Impacto de los proyectos informáticos 3.1. Introducción La ejecución de proyectos informáticos es de suma importancia y gran impacto para las organizaciones, ya que es difícil imaginar hoy en día, una organización que pueda gestionar grandes volúmenes de datos y operaciones sin el uso de tecnología informática.

La visión del apoyo estratégico de las Tecnologías de la Información y las Comunicaciones a la organización, no se detiene en la gestión de datos o altos volúmenes de información y sus operaciones.

Va más allá, debe dirigirse a la producción de sistemas que apalanquen los aspectos estratégicos del negocio, a la innovación, que además debe apoyar e introducir la difusión de la información y las comunicaciones, para lograr una transformación de la cultura institucional que facilite el cumplimiento de los objetivos misionales con total enfoque en el servicio y alto nivel de satisfacción de las necesidades y expectativas de clientes internos y en especial, de los ciudadanos.

3.2. Importancia de los proyectos informáticos El soporte angular de la importancia de los proyectos informáticos, radica en que los mismos se constituyen en instrumento para la gestión de datos e información misional, para el establecimiento de líneas de base que nos permitan identificar plenamente las condiciones actuales de las necesidades para satisfacer o problemas por resolver, a la vez que su alineamiento estratégico garantiza un aporte efectivo el cumplimiento de la misión y visión de la organización.

Los proyectos informáticos no deben entenderse como tareas operativas, recurrente o de carácter básico instrumental, sino como una decisión estratégica de la entidad para adelantar actividades que respondan a necesidades de sistematización o automatización de tareas u operaciones, mejoramiento de procesos de apoyo misionales, dinamización de procesos de evolución o acciones estratégicas para cumplir a cabalidad, la misión y superación de las expectativas del talento humano interno y de los ciudadanos.

Otro aspecto que marca la relevancia de los proyectos informáticos en las organizaciones de hoy, lo que constituye las actuales dimensiones de la sociedad a la cual nos dirigimos, la sociedad de la información y la sociedad del conocimiento. Estamos hablando de una sociedad que cada bez hace un mayor uso y utilización inteligente de las Tecnologías de la Información y las Comunicaciones y que por lo

28

tanto, demandan servicios ágiles, eficaces y oportunos, mediados por los mecanismos virtuales, a los cuales no pueden ser ajenas las entidades.

3.3. Impacto en las organizaciones (interno) Desde el punto de vista del impacto interno en las organizaciones, la implementación de proyectos informáticos debe pretender:

1. La gestión efectiva de datos e información que facilite el normal funcionamiento de la entidad.

2. La optimización de procedimientos internos con base en herramientas que automaticen su ejecución, y en consecuencia, reduzcan la carga operativa.

3. La implementación de sistemas de gestión documental que además de preservar la información institucional, sirva como instrumento para reducir el uso de papel en el Ministerio TIC.

4. El apoyo permanente y sistemático de cada uno de los procesos de apoyo

5. La consolidación de la cultura informática de la entidad.

Vale la pena anotar que un proyecto informático, puede apuntar a uno o más de los objetivos previamente señalados.

3.4. Impacto en el servicio (externo) Desde el punto de vista del impacto externo en las organizaciones, la implementación de proyectos informáticos debe pretender:

• La gestión efectiva de datos e información • La optimización de procedimientos que soportan trámites y servicios

prestados por el MinTIC, con soporte de herramientas que automaticen su ejecución, y en consecuencia, reduzcan la carga operativa.

• La implementación de aplicaciones y sistemas de gestión documental que agilicen y automaticen el trámite de solicitudes, quejas y reclamos.

• La reducción de costos operacionales del Ministerio TIC, derivados de la prestación de los servicios a su cargo.

• La disposición de herramientas que permitan una mejor gestión de las necesidades de los grupos de interés del Ministerio.

• La implementación de soluciones que permitan gestionar datos e información necesaria para fortalecer la planeación, formulación, desarrollo e implementación de las políticas públicas a cargo del Ministerio TIC.

29

• El apoyo a la ejecución de estrategias de servicio multicanal, es decir, por medio de canales presenciales (ventanillas, supermercados de servicios, etc.) y no presenciales (telefónico, kioscos de autoservicio, internet, soluciones móviles, etc.), con tecnología que facilite su interoperabilidad y trazabilidad.

En materia de implementación de proyectos informáticos con impacto externo, es un referente de obligatorio cumplimiento, el acatamiento de las disposiciones que haya dispuesto el Gobierno Nacional en el marco de la estrategia “Gobierno en Línea”, como instrumento para facilitar la relación del ciudadano con el Estado.

3.5. Beneficios y retos Mediante los proyectos informáticos, en especial aquellos que se materializan en la implementación de sistemas de información, el Ministerio TIC puede obtener beneficios dentro de los cuales se resaltan los siguientes:

• Generación de información y conocimiento sobre los ámbitos de competencia de la entidad, como soporte en la formulación de políticas públicas, planes, programas y proyectos.

• Provisión de mecanismos de modelamiento, proyección y análisis de acciones particulares a cargo de la entidad.

• Optimización de recursos y mayores niveles de eficiencia y eficacia. • Cumplimiento de requerimiento del Modelo Integrado de Gestión, en

materia de información. • Reducción en los tiempos de respuesta internos y externos. • Optimización de las comunicaciones internas y externas. • Optimización de productos y servicios al ciudadano. • Provisión de nuevos canales y medios de atención al ciudadano,

operadores y demás grupos de interés. • Visibilidad y transparencia en la gestión.

¿Cuáles son los retos de la Gestión de Proyectos Informáticos?

No obstante lo anterior, la implementación de proyectos informáticos tiene los siguientes retos:

• Lograr una articulación de carácter estratégico de las soluciones con componente tecnológico con la misión y visión del Ministerio TIC.

• Cumplir el objetivo de cada proyecto, teniendo en cuenta: El presupuesto previsto El alcance establecido El plazo otorgado

30

La gestión de sus riesgos inherentes La satisfacción de las expectativas de sus actores asociados.

• Lograr la participación activa de los usuarios, interesados, patrocinadores del proyecto, gestionando sus expectativas.

• Disponer y adoptar las tecnologías adecuadas para materializar soluciones efectivas a las necesidades del MinTIC.

• Romper barreras, paradigmas arraigados y la resistencia al cambio. • Impactar favorablemente los procesos y procedimientos asociados. • Garantizar la seguridad de la información. • Transformar la cultura organizacional.

4. Riesgos y gestión de riesgos 4.1. Riesgos en proyectos La ejecución de proyectos informáticos es de suma importancia y gran impacto para las organizaciones, ya que es difícil imaginar hoy en día, una organización que pueda gestionar grandes volúmenes de datos y operaciones sin el uso de la tecnología informática.

Los riesgos son eventos o condiciones inciertas que en el caso de ocurrir, tienen un efecto sobre un proyecto.

En este punto, es importante anotar que los efectos no son sólo negativos, también pueden ser positivos, pero en la mayoría de las ocasiones, el riesgo se asocia con una situación negativa. Un ejemplo de un riesgo positivo, es cuando un servicio o sistema de información tiene un éxito superior al inicialmente previsto y por lo tanto, la infraestructura dimensionada puede quedar rápidamente insuficiente para atender la demanda, en este caso, nadie puede negar lo positivo de tener una gran base de usuarios interesados en un determinado servicio por encima del impacto esperado.

Un riesgo puede ser catalogado como “conocido” o “desconocido””. Los primeros son aquellos que de alguna manera han sido identificados, analizados y en consecuencia, pueden ser gestionados para minimizar su probabilidad de ocurrencia o su impacto. Por su parte, los riesgos “desconocidos”, son aquellos que son más difícil prever y por lo tanto, administrar, debido que son eventos o condiciones que difícilmente se pueden advertir.

Por ejemplo: el atentado a la Torres gemelas que según blogs en internet indican que varias de las compañías que tenían sus sedes operacionales en ellas se quebraron, porque tenían oficinas alquiladas en la misma o incluso en la otra torre, algunas de ellas para guardar las copias de seguridad de la información.

31

¿Quién podía prever un atentado de tal naturaleza que hiciera desaparecer ambas torres? En verdad, no era fácilmente previsible.

4.1.1. La gestión de riesgos La gestión de riesgos en el marco de los proyectos, como lo sugiere la definición de la publicación Quantitative Risk Analysis for Project Management: A critical review (Galway, 2004), es el arte y la ciencia de identificar, analizar y responder a los riesgos durante la vida de un proyecto, con el propósito de lograr los objetivos del mismo.

Si se tiene en cuenta que los riesgos aumentan y disminuyen durante el proyecto, es claro que debemos monitorear permanentemente su estado, saber cuáles fueron resueltos y estar atentos para detectar los nuevos riesgos que puedan surgir.

La gestión de riesgos es un factor muy importante para garantizar el éxito de los proyectos informáticos, y aquí vale la pena traer a colación una frase de Tom Gilb que dice: “si usted no ataca los riesgos, los riesgos lo atacarán a usted”, en clara alusión a los problemas que se derivan de la inadecuada gestión de riesgos en proyectos de desarrollo de software que en muchas ocasiones, se traduce en sobrecostos en la ejecución de los proyectos9.

4.1.2. La importancia de la gestión de riesgos en los proyectos informáticos Uno de los aspectos que eleva la importancia de la gestión de riesgos en los proyectos informáticos, es precisamente las características que diferencian este tipo de proyectos con los de otras disciplinas.

Característica Proyectos en otras disciplinas Proyectos en TI

Propósito Definición clara y precisa Definiciones difusas (ejemplo: software

Alcance Fronteras y cobertura definidas Imprecisiones sobre cobertura de la solución

Paralelismo Definido en el mismo proyecto, trabajo especializado

Es difícil coordinar el trabajo en paralelo y garantizar el uso de estándares.

Interfases entre proyectos

Definidas con claridad en sus relaciones.

Algunas veces complejas por desconocimiento del alcance de las mismas.

9 Referencia: Ingeniero consultor en métricas, inspección y procesos devolución de software.

32

Dependencia de la tecnología

Depende del proyecto; en otras disciplinas, la evolución tecnológica se da a un ritmo menor.

Alta dependencia de la tecnología, la dinámica de la evolución es un reto.

Expectativas de los directivos y usuarios

Depende del proyecto. Son manejables en función de la claridad de los productos.

Son difíciles de manejar, por falta de claridad de los productos y de la tecnología. Muchas veces, se subestima el esfuerzo de la incorporación de tecnología.

Impacto acumulativo

Depende del proyecto, pocas veces genera un efecto colateral

Depende del proyecto, pero en ocasiones puede generar un efecto dominó.

Otra particularidad que tienen los proyectos informáticos, es que mientras los proyectos en otras áreas tienen un impacto menor, los proyectos informáticos más importantes tienen un alto impacto, la mayoría de las veces transversal a la entidad, e incluso fuera de ésta, cuando involucra soluciones integradas a sistemas de información externos o cuando por ejemplo se trata de servicios que hacen parte de una cadena de trámites.

En los siguientes temas de esta unidad, se tratarán en detalle, los problemas y riesgos en los proyectos informáticos, y la forma de enfrentarlos mediante un adecuado proceso de gestión.

4.2. Gestionado los Riesgos en los Proyectos Informáticos 4.2.1. Introducción Tal como se planteó en el tema anterior, el propósito de la gestión de riesgos es identificar, gestionar y mitigar continuamente los riesgos, tanto a nivel de organización como a nivel de los aspectos mismos del proyecto.

Como resultado de la implementación de un proceso de gestión de riesgos, se pretende:

Determinar el ámbito de la gestión de riesgos. Definir e implementar estrategias de gestión de riesgos Identificar riesgos en cada proyecto según la estrategia de gestión de

riesgos en particular, durante la vida del proyecto. Analizar los riesgos y determinar los prioritarios a los cuales se debe

asignar recursos para su tratamiento.

33

Seleccionar técnicas de monitoreo o seguimiento de los riesgos para determinar su cambio de estado y el progreso de las actividades de tratamiento

Tomar acciones pertinentes para corregir o evitar el impacto.

Teniendo en cuenta que el riesgo -en negativo- es un problema potencial que puede o no ocurrir, y que puede hacer que nuestro proyecto fracase, es fundamental, centrar la atención en acciones dirigidas a evitar o prevenir que un riesgo ocurra o en el caso de que ocurra, reducir el impacto que su ocurrencia pueda generar.

¿Cuáles son las estrategias de gestión de riesgos reactivas y las proactivas?

Uno de los principales aspectos en el marco de las estrategias de gestión de riesgos, es distinguir entre las que son reactivas y las que son proactivas

REACTIVAS: Se aplican a los efectos de la materialización, es decir, comprenden acciones tendientes a mitigar los efectos de situaciones que ya han ocurrido.

PROACTIVAS: Son aquellas que se contemplan antes de la ocurrencia de los riesgos y se dirigen principalmente a evitar o reducir la probabilidad de que tales riesgos se materialicen.

4.2.2. Identificación de riesgos En esta primera etapa, se pretende hacer un proceso de identificación que permita especificar las amenazas que pueden afectar el plan el proyecto.

Los riesgos según su ámbito, se pueden clasificar en tres categorías:

RIESGOS DEL PROYECTO: Son los riesgos que amenazan el plan del proyecto, la planificación temporal y sus costos. En esta categoría, caben todos aquellos riegos que general desviación de lo planeado o cuyo esfuerzo implique cambios en materia de recursos asignados, de carácter logístico, financiero u operacional.

RIESGOS DEL PRODUCTO: Son los riesgos que amenazan la calidad y la planificación relacionada con la operación del producto. En esta categoría, se concentran aquellos riesgos que pueden afectar las prácticas de desarrollo de los productos o servicios u en consecuencia, pueden afectar la calidad, así como la posibilidad de su implementación y puesta en operación, su duración o vida útil.

34

RIESGOS DEL NEGOCIO: Son los riesgos que amenazan la viabilidad de la entidad a cargo del proyecto. En esta categoría, se clasifican aquellos riesgos que pueden generar una afectación más allá del alcance del proyecto, es decir, aquellos que puedan poner en riesgo la continuidad de la entidad a cargo de su ejecución.

Para cada categoría indicada anteriormente, se puede establecer dos tipos de riesgo:

Riesgos genéricos: Son los riesgos que representan una amenaza potencial para todo tipo de proyectos.

Riesgos específicos: son los riesgos asociados específicamente al entorno o particularidades respecto de las especificaciones de la tecnología o el personal que requiere el proyecto.

A continuación, se presenta una estructura para identificar fuentes de riesgo, según su origen.

FUENTE DE RIESGO RIESGO

Riesgos asociados al cliente o usuario

Requerimientos o requisitos confusos o incompletos.

Ineficiencia, ineficacia en el cumplimiento de las responsabilidades por parte del cliente.

Insuficiente disponibilidad o conocimiento por parte del cliente, para proporcionar información precisa sobre los requerimientos o requisitos.

Insuficiente disponibilidad o conocimiento por parte del cliente, para adelantar los procesos de revisión de productos del proyecto.

Expectativas poco realistas por parte del cliente.

Restricciones contractuales que impliquen penalizaciones por incumplimiento de fechas, sin tener en cuenta posible demoras imputables al cliente.

Riesgos asociados al cronograma.

Tareas o hitos faltantes.

Duración inexacta de la métrica.

Estimaciones no precisas.

Un cronograma basado en cantidades exageradas de tiempo

35

extra para todo el equipo.

Riesgos asociados a los recursos.

Roles y/o responsabilidades NO claras.

Recursos NO disponibles.

Habilidades y/o conocimientos requeridos

NO satisfechos o inadecuados.

Equipo faltante o inadecuado.

Rotación del personal.

Riesgos asociados a la Experiencia.

Nueva Tecnología.

Improvisación por desconocimiento previo de las características de las soluciones por implementar.

Indebido manejo de situaciones

Conflictivas o problemáticas por falta de experiencia.

Riesgos asociados al Proceso de Administración de Proyectos.

Descomposición de Tareas (WBS) – una descomposición inadecuada falla al identificar todas las actividades que son parte del proyecto.

Métricas: estimaciones de tiempo y costo- las estimaciones agresivas o las desarrolladas con información insuficiente de tiempo, llevan a un riesgo mayor.

Fallas del Flujo de Trabajo: en la entrega, en la autorización de la terminación, no cumpliendo las fechas límite.

Falla de Aseguramiento de Calidad: proceso con fallas, carencia de la función de aseguramiento de calidad.

¿Qué debe contemplar la identificación?

Para identificar los riesgos, se debe partir de los conocidos o predecibles, elaborando un listado de comprobación de elementos de riesgo.

Para identificar los riesgos, se debe partir de los conocidos o predecibles, elaborando un listado de comprobación de elementos de riesgo.

36

Este listado se puede elaborar a partir de instrumentos ya existentes, tales como el listado de chequeo o comprobación de riesgos en proyectos similares o con la realización de un trabajo en grupo bajo la metodología de “lluvia de ideas”, con base en la cual se propongan aquellos aspectos que el grupo identifica como factor de riesgo, entre otros métodos. También resulta útil el desarrollo de entrevistas con actores clave del proyecto, que ayuden a identificar riesgos no identificados durante actividades previas de identificación.

La plena identificación de riesgos debe considerar riesgos que el equipo del proyecto puede controlar o influenciar. Por ejemplo: la distribución del equipo de trabajo en las diferentes tareas a cargo.

Los externos son los riesgos que van más allá del control o de la influencia del equipo del proyecto. Por ejemplo: cambios en la normatividad que afecten el contexto del proyecto y por ende, sus especificaciones.

4.2.3. Análisis de riesgos El análisis de riesgos consiste en adelantar un proceso de evaluación que permite determinar el grado de exposición del proyecto a cada riesgo previamente identificado. Este análisis se hace en términos cualitativos10 y cuantitativos11.

En el marco del análisis de riesgos, la probabilidad es en esencia, la expresión en términos porcentuales, de que ocurra un riesgo.

Ejemplo

Existe un 10% de probabilidad de que tengamos un daño que afecte el funcionamiento de la infraestructura que soporta el sistema. El impacto es el efecto de los riesgos sobre los objetivos del proyecto, en caso de que ocurra; puede calcularse en unidades de tiempo (para medir retraso), monto (para medir costo), o alcance (para medir complejidad), entre otros. Ejemplo: un fallo físico grave del servidor de datos, afectaría en diez semanas el plazo de ejecución del proyecto.

Con base en los aspectos anteriormente enunciados y para ejemplificar cómo se determina el nivel de exposición a riesgos, se calcula

10 El análisis cualitativo se emplea como fuente principal determinar la priorización de los riesgos identificados, teniendo como base la probabilidad de ocurrencia de cada riesgo y su impacto en el proyecto. 11 El análisis cuantitativo por su parte, evalúa el efecto de los riesgos y les asigna una calificación numérica. También puede estimar la magnitud de pérdida en términos económicos, determinando el costo asociado en el evento de que se materialice el respectivo riesgo.

37

multiplicando la probabilidad (10%), por el impacto del respectivo riesgo (diez semanas), así:

Riesgo por daño grave de la infraestructura que soporta el sistema (servidor de datos) = 0,10 x 10 = 1 semana

Tanto la estimación de la probabilidad de ocurrencia como de la magnitud de pérdida por la ocurrencia del riesgo, se hacen en forma subjetiva; sin embargo, existen varias técnicas que pueden ayudar a acotar la subjetividad tanto como sea posible.

Técnicas que pueden ayudar a acotar la subjetividad tanto como sea posible:

Juicio de expertos: Solicitar la estimación de personas familiarizadas con el proyecto o con experiencia en la gestión de este tipo de proyecto.

Utilizar el método Delphi: varios miembros de un grupo identifican riesgos y les asignan una probabilidad de ocurrencia y una magnitud de pérdida. Estas estimaciones son discutidas y refinadas por el grupo.

Caracterizar: Usar adjetivos (muy improbable) bastante improbable, improbable, probable, bastante probable, muy probable), y asignar un valor numérico a cada uno.

Se recomienda construir una matriz para asignar calificaciones de riesgo (muy bajo, bajo, moderado, alto y muy alto), a riesgos o condiciones con base en la combinación de escala de probabilidad e impacto. Los riesgos con alta probabilidad y alto impacto, probablemente requieran un análisis adicional, incluidas la cuantificación y una gestión de riesgos agresiva.

Una escala de la probabilidad de riesgos debe asignarse entre 0.0 (no existe probabilidad), y 1.0 (certeza), o porcentualmente entre el 0.0% y el 100%. Evaluar la probabilidad del riesgo puede ser difícil porque normalmente se utiliza el juicio basado en la experiencia que a menudo carece del beneficio de la información histórica. Se puede usar una escala ordinal que represente valores relativos de probabilidad desde muy improbable hasta casi seguro. En forma alternativa, las probabilidades específicas pueden ser asignadas, usando una escala general.

La escala de impactos de riesgos refleja la severidad de sus efectos en los objetivos del proyecto. El impacto puede ser ordinal o cardinal. Las escalas ordinales son simples valores ordenados por rango, como muy bajo, bajo, moderado, alto y muy alto. Las escalas cardinales asignan valores a estos impactos. El propósito de ambos enfoques, si el riesgo en cuestión ocurre, es asignar un valor relativo al impacto en los objetivos del proyecto. Escalas claramente definidas ya sean ordinales o cardinales, pueden ser desarrolladas, usando definiciones acordadas por la entidad.

38

La siguiente tabla es un ejemplo de evaluación de los impactos de riesgos por objetivos del proyecto. Ella ilustra su uso tanto para un enfoque ordinal como cardinal. Estas descripciones en escalas de impactos relativos, deberían ser preparadas por la organización antes de que el proyecto comience12.

EVALUACIÓN DEL IMPACTO DE RIESGO EN LOS OBJETIVOS PRINCIPALES DEL PROYECTO.

OBJETIVO DEL PROYECTO

MUY BAJO (0.05) BAJO (0.1) MODERADO

(0.2) ALTO (0.4)

MUY ALTO (0.8)

COSTO Incremento

insignificante del costo.

<5% de incremento en

el costo.

5-10 % de incremento en el

costo.

10-20 % de incremento en

el costo.

>20 % de incremento en el

costo.

TIEMPO Atraso

insignificante del tiempo.

Atraso en tiempo <5%.

Atraso general en el

proyecto 5-10%

Atraso general en el

proyecto 5-10%

El cronograma del proyecto se

atrasa >20 %

ALCANCE Disminución del alcance apenas

apreciable.

Áreas secundarias del

alcance son afectadas.

Áreas principales del alcance son

afectadas.

La reducción del alcance es

inaceptable para el cliente.

El producto final del proyecto es

totalmente inútil.

CALIDAD Disminución de

la calidad apenas apreciable.

Sólo aplicaciones

muy exigentes son afectadas.

La reducción de la calidad requiere

aprobación del cliente

La reducción de la calidad es

inaceptable para el cliente.

El producto final del proyecto es

totalmente inútil.

El impacto de los objetivos del proyecto puede ser evaluado en una escala desde "muy bajo" hasta "muy alto" o en una escala numérica. La escala numérica (cardinal), presentada en la tabla anterior, no es lineal e indica que la entidad desea especialmente evitar riesgos de impacto alto o muy alto.

4.2.4. 4.2.4 Priorización de riesgos La priorización de riesgos tiene como objetivo centrar los esfuerzos de la planificación en la respuesta a riesgos, de forma tal que se brinde algún tipo de tratamiento a los que más impacto pueden tener en el proyecto.

12 Es muy importante tener en cuenta que conforme a las exigencias existentes en materia de contratación estatal, los pliegos de condiciones o sus equivalentes, es decir, los documentos que soportan la realización de un proceso de selección de un contratista, deben incluir la estimación, tipificación y asignación de los riesgos previsibles involucrados en la contratación, incluso como parte del proceso de selección se celebran audiencias en las que se explica a los interesados en el proceso el alcance del estudio que la entidad haya dispuesto respecto de este análisis de riesgos.

39

En consideración a que por lo general, los proyectos tienen todo tipo de restricciones, no es posible garantizar una acción de tratamiento a todos los riesgos o puede ocurrir que una acción de tratamiento de un riesgo de un impacto relativamente bajo, resulte demasiado costosa como para que se tenga en cuenta. Por esta razón, es fundamental realizar la priorización.

Para hacer la priorización, se elabora una matriz que parte del listado de riesgos identificados, con información complementaria como la categoría de riesgo, la probabilidad, el impacto y la exposición.

RIESGO CATEGORÍA PROBABILIDAD IMPACTO EXPOSICIÓN

Cambio en las especi-ficaciones del producto.

Cliente 30% 8 semanas 2, 4 semanas

Aprobación de productos intermedios o informes tarda más de lo esperado.

Cliente 25% 5 semanas 1, 25 semanas

Falla grave en el servidor de datos.

Recursos (tecnología)

10% 10 semanas 1 semana

La idea es que el listado obtenido se ordene con base en el nivel de exposición e impacto de los riesgos, lo cual brinda orientación hacia dónde se debe centrar los esfuerzos de la planificación de la respuesta a riesgos.

4.2.5. Planificación de la respuesta a riesgos Un plan de respuesta a riesgos usualmente incluye:

Riesgos identificados, sus descripciones, aspecto del proyecto afectado, sus causas y efectos en los objetivos del proyecto.

Responsabilidades asignadas en cuanto a cada riesgo. Resultados del análisis de riesgos (probabilidad, impacto y exposición),

incluida su priorización. Planes de contingencia: Respuestas previstas para los riesgos que se hayan

considerado prioritarios y que serán planificados. Nivel de riesgo residual esperado después de que se aplique la respuesta

precisa. Acciones específicas para implementar la estrategia de respuesta a

cambios. Presupuesto y tiempos para la ejecución de las acciones de respuesta

40

4.2.6. Supervisión de riesgos La supervisión o monitorización de riesgos es fundamental, dado que concentra las actividades que permiten comprobar el progreso del control de un riesgo, así como identificar tempranamente nuevos riesgos.

El objetivo de esta supervisión es tomar decisiones de manera efectiva, plenamente documentadas y oportunas mediante la constante observación de los riesgos de los planes de mitigación que se hayan planteado para su tratamiento.

Planificar: se planifica cuando de conformidad con la revisión, se observan las modificaciones sustanciales en los riesgos encontrados (por ejemplo: se excede el valor del umbral de un riesgo), o aparecen nuevos riesgos, lo cual supone ajustar el plan inicialmente propuesto.

Cerrar el riesgo: se cierra el riego cuando se observa que la probabilidad del riesgo es inferior al valor del umbral o el riesgo se convierte en un problema cuya solución es viable en el plazo inmediato.

Invocar un plan de contingencia: se invoca un plan de contingencia cuando se da una circunstancia o situación denominada disparador, o urge ejecutar una acción inmediata para prevenir mayores impactos en la ejecución del proyecto.

Continuar con el plan actual: Se continúa con el plan actual, cuando no se requiere alguna acción adicional en consideración a que todo está sucediendo tal como estaba previsto.

¿A dónde se debe llegar luego de este análisis y supervisión?

De la revisión efectuada a los riesgos, así como de las acciones derivadas de las formas de proceder expuestas anteriormente, se debería llegar a:

Actualización de los riesgos identificados: en aspectos tales como probabilidad de ocurrencia, prioridad e impacto, ajustes a los planes de respuesta requeridos, etc.

Actualización de los planes de contingencia: en aspectos tales como el alcance de las acciones o la programación de su realización, responsables, etc.

Actualización de acciones preventivas y correctivas recomendaciones: en aspectos como programación de su realización, responsables, actividades adicionales requeridas por riesgos emergentes no identificados de forma previa o modificación de alcance de actividades existentes.

Actualización del análisis de riesgo: en aspectos tales como la matriz de probabilidades e impacto, con ocasión de las variaciones observadas en los riesgos.

41

Actualización del plan de proyecto: en el evento de que las actividades exijan la reprogramación de hitos o entregables.

El control es por lo tanto, un punto crucial en la toma de decisiones sobre el proyecto.

5. Riesgos en proyectos informáticos y recomendaciones de manejo 5.1. Riesgos comunes a todo tipo de proyecto informático Como hemos indicado, los riesgos son incidentes o situaciones que en un momento determinado, pueden afectar la ejecución de un proyecto o sus productos asociados.

Por lo tanto, partir del modelo de evaluación de las restricciones, como marco para la ejecución de un proyecto, y los problemas que en un momento determinado puedan afectar tales restricciones, resulta un punto de partida apropiado para identificar riesgos en la gestión de proyectos.

De conformidad con el cuerpo base de conocimientos sobre gestión de proyectos propuesto por el PMI, como parte del proceso de evolución que ha tenido el modelo de triple restricción (alcance, costo y tiempo), se ha propuesto una visión expandida de la múltiple restricción así:

A partir de estas restricciones, se desarrolla a continuación una descripción de los riesgos asociados a cada una de ellas y las recomendaciones respectivas, factores comunes a cualquier tipo de proyectos.

FUENTES DE RIESGO RIESGO Riesgos asociados al Requerimientos o requisitos confusos o incompletos.

42

cliente o usuario. Cambios frecuentes a los requerimientos o requisitos del proyecto durante la ejecución. Ineficiencia, ineficacia en el cumplimiento de las responsabilidades por parte del cliente. Insuficiente disponibilidad o conocimiento por parte del cliente, para proporcionar información precisa sobre los requerimientos o requisitos. Insuficiente disponibilidad o conocimiento por parte del cliente, para adelantar los procesos de revisión de productos del proyecto. Expectativas poco realistas por parte del cliente. Restricciones contractuales que impliquen penalizaciones por incumplimiento de fechas, sin tener en cuenta posible demoras imputables al cliente.

Riesgos asociados al cronograma.

Tareas o hitos faltantes. Duración inexacta de la métrica. Estimaciones no precisas. Un cronograma basado en cantidades exageradas de tiempo extra para todo el equipo.

Riesgos asociados a los recursos.

Roles y/o responsabilidades NO claras. Recursos NO disponibles. Habilidades y/o conocimientos requeridos NO satisfechos o inadecuados. Equipo faltante o inadecuado. Rotación del personal.

Riesgos asociados a la Experiencia.

Nueva Tecnología. Improvisación por desconocimiento previo de las características de las soluciones por implementar. Indebido manejo de situaciones conflictivas o problemáticas por falta de experiencia.

Riesgos asociados al Proceso de Administración de Proyectos.

Descomposición de Tareas (WBS) – una descomposición inadecuada falla al identificar todas las actividades que son parte del proyecto. Métricas: estimaciones de tiempo y costo- las estimaciones agresivas o las desarrolladas con información insuficiente de tiempo, llevan a un riesgo mayor. Fallas del Flujo de Trabajo: en la entrega, en la autorización de la terminación, no cumpliendo las fechas límite. Falla de Aseguramiento de Calidad: proceso con fallas.

En los siguientes numerales, se presentarán riesgos y recomendaciones específicamente relacionados con las tipologías de proyectos citadas en numerales

43

anteriores, y que se asocian de manera particular, con las actividades que se desarrollan en cada una de ellas.

5.2. Proyectos de Adquisición de proyectos de hardware, periféricos o dispositivos de comunicaciones Teniendo en cuenta que este tipo de proyectos, corresponde a la adquisición de elementos físicos, consistentes en hardware, periféricos o dispositivos de comunicaciones, éstos serían algunos posibles riesgos y sus recomendaciones:

RIESGO ASOCIADO RECOMENDACIONES Incumplimiento de la obligación legal de efectuar la adquisición de bienes o servicios incluidos en un Acuerdo Marco de Precio.

Adelantar como primer actividad previa al inicio del proceso de selección, la verificación de la posibilidad de adquirir el bien o servicio requerido mediante los acuerdos marco de precio que tenga publicados la Agencia Nacional de Contratación Pública - Colombia Compra Eficiente.

Características técnicas de los elementos por adquirir no se cumplen en la entrega.

Elaborar un listado de chequeo que permita verificar las especificaciones técnicas de los elementos entregados.

Solución parcialmente implementada por falta de conocimiento técnico sobre los elementos adquiridos y sus condiciones de instalación.

Establecer servicios conexos cuyo propósito sea la instalación y configuración de los elementos por adquirir.

Elementos adquiridos no se integran adecuadamente a las condiciones de la plataforma de la entidad.

Elaborar especificaciones que garanticen la total compatibilidad con la plataforma que exista en la entidad.

Desaprovechamiento de características técnicas de las soluciones adquiridas.

Incluir servicios conexos cuyo propósito sea optimizar el aprovechamiento de los elementos adquiridos. Esto puede derivar en servicios de optimización, así como transferencia de conocimiento a funcionarios de la entidad, sobre la tecnología adquirida.

Adquisición de elementos próximos a ser descontinuados o de tecnología que pueda ser categorizada como “obsoleta” en poco tiempo.

Establecer condiciones técnicas actualizadas para los equipos por adquirir, con características que faciliten su actualización.

44

Inclusión de partes o accesorios requeridos, no considerados al inicio del proyecto.

Determinación detallada de partes o accesorios requeridos para el adecuado funcionamiento del proyecto, desde la realización del estudio de mercado.

Condiciones técnicas no permiten la instalación de los elementos adquiridos.

Establecer de manera previa a la instalación, las condiciones de carácter técnico y logístico que se requieran para llevar a cabo la instalación de los elementos.

Mayores costos por servicios conexos no considerados al inicio del proyecto.

Detallar de manera adecuada, el alcance del proyecto y sus servicios conexos requeridos, obteniendo sus costos de manera desagregada desde el estudio de mercado.

Daños físicos de los equipos por defectos de fábrica.

Establecer condiciones de garantía que permitan obtener el arreglo o cambio del equipo, en caso de defectos de fábrica.

Configuración errada de los componentes físicos de los equipos.

Establecer condiciones de soporte que permitan solicitar ajustes o correcciones a la configuración efectuada por el proveedor.

Tiempos requeridos para procesos de importación no permiten cumplir a tiempo con el proyecto.

Incluir dentro del plazo de ejecución del proyecto, los tiempos requeridos para realizar el proceso de importación.

5.3. Proyectos de Desarrollo de aplicaciones de software a la medida, Mantenimiento (ajustes, mejoras y nuevas funcionalidades), Parametrización y adaptación de soluciones Teniendo en cuenta que este tipo de proyectos corresponde al desarrollo de aplicaciones o software a la medida, es decir, para atender necesidades particulares de la entidad, así como aquellas que tienen como objeto el mantenimiento a aplicaciones existentes cuyo propósito sea la realización de ajustes, mejoras o el desarrollo de nuevas funcionalidades que mejoren las condiciones del software actual, éstos serían algunos posibles riesgos y sus recomendaciones.

RIESGO ASOCIADO RECOMENDACIÓN El alcance del proyecto no está claramente definido.

Realizar actividades que permitan reducir la incertidumbre respecto del “tamaño del producto”, con aspectos que precisen en lo posible: número de programas, complejidad

45

de las transacciones/operaciones, puntos de entrada, reportes e informes, tamaño y modelo de datos, número de usuarios, y requerimientos de integración con otros aplicativos, entre otros. Cuando sea posible, elaborar o contratar de manera separada, las etapas de análisis y diseño, de la de desarrollo e implementación.

Funcionalidad de los aplicativos desarrollados o mantenidos no cumplen las expectativas del usuario.

Involucrar al usuario desde la construcción de las especifi-caciones. Emplear métodos formales de registro de las funcionalidades deseadas, debidamente avalados por los funcionarios competentes de la entidad. Aterrizar las expectativas, de manera que sean realistas en función de los recursos disponibles y el alcance posible de la solución.

Incorreciones del software desarrollado o ajustado no se reportan oportunamente.

Establecer con el usuario, un protocolo para las pruebas de los desarrollos o ajustes que se le hagan al software, con instrumentos que permitan registrar incorrecciones o incidentes en su uso. Garantizar la disponibilidad de tiempo necesaria para realizar pruebas exhaustivas. Disponer de insumos suficientes (datos de prueba), para hacer las pruebas con énfasis en las excepciones que el software debe controlar. Establecer un período suficiente de acompañamiento y de garantía para corregir posibles defectos en los aplicativo

Inadecuada comprensión de los aspectos que deben apoyar los aplicativos por desarrollar o ajustar.

Documentar de la manera más clara posible, los aspectos por apoyar con los aplicativos, incorporando ejemplos de las entradas, procesos y salidas, reglas del negocio, excepciones y condiciones especiales. Cuando sea posible, exigir dentro del equipo de proyecto del contratista, especialistas o expertos en los temas que sean alcance de la solución.

Cambio de personal afecta la entrega oportuna del proyecto.

• Confirmar que el equipo de trabajo recibe sus honorarios y en lo posible, vericar mecanismos de retención de talento humano asignado al proyecto.

• En lo posible, procurar que varios miembros del equipo

tengan conocimiento sobre los temas especícos a cargo de cada miembro.

• Centralizar y organizar en forma adecuada, la

documentación del proyecto. Establecer mecanismos

46

que faciliten la reducción de la curva de aprendizaje de nuevos miembros del equipo.

Incumplimiento derivado de cambios en las especificaciones.

Establecer un mecanismo de control de cambios que permita la evaluación conjunta de cambios solicitados y la adecuación de los mismos a las restricciones del proyecto.

Defectos en aspectos técnicos, de requisitos, de diseño o de código, debido a revisiones técnicas irregulares.

Realizar revisiones regulares de todos los aspectos del proyecto, implementar listados de chequeo estándar para validar requisitos funcionales y aspectos técnicos solicitados.

Aplicativos desarrollados sin considerar aspectos de integración con otras soluciones ya implementadas.

• Verificar que las condiciones de interacción con otras soluciones que existan, estén debidamente identificadas y especificadas.

• Determinar modelos apropiados de interacción o interoperabilidad, respetando las competencias y fronteras que deben reflejar cada componente de las soluciones involucradas.

Herramientas desarrolladas sin estándares.

Definir los estándares y demás aspectos que consideren referentes metodológicos que eleven la calidad del proceso de desarrollo del software y sus productos asociados.

5.4. Proyectos de Mantenimiento de infraestructura tecnológica Teniendo en cuenta que este tipo de proyectos, corresponde a la realización de procesos de mantenimiento que faciliten el adecuado funcionamiento y disponibilidad de los diferentes elementos que conforman la infraestructura tecnológica de las entidades, éstos serían algunos posibles riesgos y sus recomendaciones:

RIESGO RECOMENDACIÓN Características técnicas de los servicios por prestar, están incompletos o son imprecisos.

Elaborar una relación detallada de los servicios de mantenimiento que se pretende obtener, y especificar para cada uno de ellos, un alcance preciso, preferiblemente con los criterios de aceptación correspondientes.

Servicios prestados sin Idoneidad técnica.

• Establecer criterios que permitan contar con un proveedor con experiencia y con personal técnico capacitado.

• Exigir certificaciones técnicas y experiencia específica en los servicios requeridos.

Uso de repuestos no homologados por el fabricante ponen en riesgo los Elementos de infraestructura.

• Incorporar condiciones que establezcan la exigencia de disponer repuestos nuevos, homologados por el fabricante.

• Establecer condiciones de garantía de calidad sobre los repuestos.

47

Mayores costos por servicios conexos no considerados al inicio del proyecto.

Detallar de manera adecuada, el alcance del proyecto y sus servicios conexos requeridos, presentando sus costos en forma desagregada desde el estudio de mercado.

Problemas derivados de la Imprevisión de situaciones por las cuales no se pueda realizar los procesos de mantenimiento

• Definir expresamente en el contrato, el manejo para circunstancias como la necesidad de adquirir repuestos de difícil consecución, y repuestos o servicios no cotizados inicialmente.

• Implementar mecanismos que ofrezcan cierto grado de flexibilidad para asignar recursos

• del contrato a situaciones difíciles de prever, como por ejemplo: un monto global para

• soportar una “bolsa de repuestos”, que se ejecuta con base en valores unitarios previamente establecidos.

Procesos de mantenimiento obstaculizan las actividades de la entidad.

• Especificar los horarios (preferiblemente en horas no hábiles), en los cuales se puede realizar los procesos de mantenimiento.

• Definir medidas de contingencia, en el caso de que el proceso de mantenimiento genere algún inconveniente que afecte la disponibilidad de un servicio más allá del horario programado. Programar con la debida antelación, las actividades de mantenimiento de mayor impacto.

Como resultado de la intervención a equipos, se pierden partes o repuestos.

• Establecer un protocolo para las intervenciones a los equipos, que incluya procedimientos de control (incluido listado de chequeo), que permitan garantizar que los mismos quedan en las condiciones como inicialmente estaban antes de procesos de mantenimiento preventivo.

• De igual forma, en el caso de mantenimiento correctivo con suministro de repuestos, el protocolo debe permitir registrar las partes reemplazadas y que las mismas sean retiradas con la supervisión de la entidad.

5.5. Proyectos de seguridad informática Teniendo en cuenta que este tipo de proyectos corresponde a la provisión de bienes o contratación de servicios requeridos para mejorar las condiciones de seguridad de la información en la entidad, éstos serían algunos posibles riesgos y sus recomendaciones:

RIESGO ASOCIADO RECOMENDACIÓN Disponibilidad de servicios de la entidad se ve afectada por pruebas de vulnerabilidad o hacking ético.

• En un ambiente controlado, definir un protocolo para estas pruebas, preferiblemente diferente al de producción, para intentar ataques de mayor impacto. El ambiente debe replicar las mismas condiciones del original.

48

• Sacar copias de seguridad y configuración a todos los elementos involucrados, garantizando previamente que se pueden recuperar, antes de ejecutar pruebas de alto impacto en el ambiente real de producción.

• Planear y evaluar detenidamente, la intencionalidad y posibles efectos técnicos y funcionales, de cada prueba por realizar.

Servicios prestados sin idoneidad técnica.

• Establecer criterios que permitan contar con un proveedor con experiencia y con personal técnico capacitado.

• Exigir certificaciones técnicas y experiencia específica en los servicios requeridos.

Acciones de aseguramiento de componentes de la plataforma tecnológica parcialmente implementados, por falta de conocimiento técnico.

• Establecer servicios conexos13 cuyo propósito sea ejecutar acciones de aseguramiento, incluidos la instalación y configuración de parches, revisión de vulnerabilidades, y configuración de políticas, entre otros aspectos.

• Asegurar procesos de transferencia de conocimiento a funcionarios de la entidad para garantizar la continuidad de acciones de aseguramiento.

Elementos de hardware y software de seguridad adquiridos, no se integran adecuadamente a las condiciones de la plataforma de la entidad.

Elaborar especificaciones que garanticen la total compatibilidad con la plataforma que exista en la entidad.

Desaprovechamiento de características técnicas de las soluciones adquiridas.

Incluir servicios conexos cuyo propósito sea optimizar el aprovechamiento de los elementos adquiridos. Esto puede derivar en servicios de optimización, así como transferencia de conocimiento a funcionarios de la entidad sobre la tecnología adquirida.

Pérdida o fuga de información resultante de pruebas de penetración o explotación de vulnerabilidades.

Firmar un acuerdo de confidencialidad, que permita evitar pérdida o fuga de información.

Condiciones técnicas no permiten la Instalación de los elementos adquiridos.

Previo a la instalación, establecer las condiciones de carácter técnico y logístico que se requieran para llevar a cabo la instalación de los elementos.

Mayores costos por servicios conexos no considerados al inicio del proyecto.

Detallar de manera adecuada, el alcance del proyecto y sus servicios conexos requeridos, y presentar sus costos de manera desagregada desde el estudio de mercado.

13 Servicios conexos: son los servicios que no son el objeto principal del contrato, pero son complementarios o facilitan su cumplimiento.

49

5.6. Proyectos de adecuación de infraestructura para Centros de Datos, hosting o colocation de servidores, sistemas de control de acceso y videovigilancia Teniendo en cuenta que este tipo de proyectos corresponde a la realización de obras civiles, adquisición de elementos físicos y lógicos para garantizar una adecuada infraestructura de un sitio de procesamiento de datos, así como a sistemas complementarios que permitan el monitoreo y control físico y ambiental de sus instalaciones, éstos serían algunos posibles riesgos y sus recomendaciones:

RIESGO ASOCIADO RECOMENDACIÓN Calidad deficiente en obras civiles de adecuación ejecutadas.

• Solicitar acompañamiento en las intervenciones relacionadas con obras civiles, a la dependencia o persona que resulte idónea en la entidad para este propósito.

• Llevar un registro fotográfico que permita tener el “antes” y el “después” de la intervención.

Características técnicas de los elementos por adquirir (sistemas de control ambiental, control de incendios, control de acceso, etc.), no se cumplen en la entrega.

Elaborar un listado de chequeo que permita verificar las especificaciones técnicas de los elementos entregados.

Solución parcialmente implementada por falta de conocimiento técnico sobre los elementos adquiridos y sus condiciones de instalación

Establecer servicios conexos cuyo propósito sea la instalación y configuración de los elementos por adquirir.

Elementos adquiridos no se integran adecuadamente a las condiciones de la plataforma de la entidad

Elaborar especificaciones que garanticen la total compatibilidad con la plataforma que exista en la entidad.

Desaprovechamiento de características técnicas de las soluciones adquiridas

Incluir servicios conexos cuyo propósito sea optimizar el aprovechamiento de los elementos adquiridos. Esto puede derivar en servicios de optimización, así como transferencia de conocimiento a los servidores públicos del MinTIC sobre la tecnología adquirida.

Inclusión de partes o accesorios requeridos, no considerados al inicio del proyecto.

Determinación detallada de partes o accesorios que se requieran para el adecuado funcionamiento del proyecto, desde la realización del estudio de mercado.

Inclusión de partes o accesorios requeridos, no considerados al inicio del proyecto.

Previo a la instalación, establecer las condiciones de carácter técnico y logístico que se requieran para instalar los elementos.

Inclusión de partes o accesorios requeridos, no considerados al inicio del proyecto.

Detallar de manera adecuada, el alcance del proyecto y sus servicios conexos requeridos, y presentar sus costos de manera desagregada desde el estudio de mercado.

50

5.7. Proyectos de Outsourcing de Tecnologías de la Información Teniendo en cuenta que este tipo de proyectos corresponde a la contratación de servicios en materia de tecnologías de la información cuya responsabilidad se transfiere a un tercero, a continuación algunos posibles riesgos y sus recomendaciones:

RIESGO ASOCIADO RECOMENDACIÓN Incumplimiento de la obligación legal de adherirse a acuerdos marco de precio – Colombia compra eficiente.

Adelantar como primer actividad previa al inicio del proceso de selección, la verificación de la posibilidad de adquirir el bien o servicio requerido mediante los acuerdos marco de precio que tenga publicados la Agencia Nacional de Contratación Pública - Colombia Compra Eficiente.

El alcance del proyecto no está definido con claridad.

Realizar actividades que permitan reducir la incertidumbre respecto del alcance del proyecto, con aspectos que precisen en lo posible: responsabilidades de las partes, servicios para tercerizar, acuerdos de nivel de servicio, condiciones especiales por cumplir para prestar los servicios, equipos y personal técnico requeridos, entre otros.

Servicios tercerizados no cumplen las expectativas del usuario.

• Involucrar al usuario, desde la definición de las especifi-caciones para contratar los servicios por tercerizar.

• Definir conjuntamente con los usuarios, acuerdos de nivel de servicio que garanticen su satisfacción. Aterrizar las expectativas, de manera que sean realistas en función de los recursos disponibles y el alcance de la tercerización.

• Emplear métodos formales de obtención y evaluación de los indicadores relacionados con los acuerdos de nivel de servicio.

• Establecer consecuencias desde el punto de vista contractual, respecto del incumplimiento de metas relacionadas con los acuerdos de nivel de servicio.

Fallas o inconvenientes en los Servicios tercerizados no se reportan oportunamente.

• Establecer un protocolo para reportar incidentes relacionados con los servicios tercerizados.

• Garantizar la disponibilidad de tiempo que se requiera para evaluar la calidad de los productos y servicios tercerizados.

• Establecer un período suficiente de acompañamiento y de garantía para corregir posibles incidentes que se detecten.

Pérdida de control sobre el proceso tercerizado

Tomar medidas para mantener el control sobre el proceso tercerizado, en aspectos tales como: mecanismos para la

51

gestión de solicitudes, procesos y protocolos de control, calidad de los servicios prestados, indicadores relacionados con las metas establecidas por los acuerdos de nivel de servicio y mecanismos para el reporte de incidentes, entre otros.

Servicios prestados sin idoneidad técnica

Establecer criterios que permitan contar con un proveedor con experiencia y con personal técnico capacitado.

Daños o mal uso de los activos de la entidad, por parte del personal de la empresa a cargo de los servicios tercerizados.

Exigir certificaciones técnicas y experiencia específica en los servicios requeridos.

Desarrollo de dependencia total del proveedor de los servicios tercerizados e incapacidad para retomarlos en caso de alguna eventualidad

• Generar una base de conocimiento acerca del proyecto, soportada en documentación detallada con las actividades tercerizadas.

• Destinar recursos al seguimiento y control detallado de las actividades.

• Establecer un plan de transferencia de conocimiento con evaluación periódica.

Condiciones técnicas no permiten instalar los elementos adquiridos

Previo a la instalación, establecer las condiciones de carácter técnico y logístico que se requieran para llevar a cabo la instalación de los elementos.

Mayores costos por servicios conexos no considerados al inicio del proyecto.

Detallar de manera adecuada, el alcance del proyecto y sus servicios conexos requeridos, y presentar sus costos de manera desagregada desde el estudio de mercado.

5.8. Proyectos de soluciones integradas – “llave en mano” Teniendo en cuenta que de manera similar al anterior, se transfiere a un tercero la responsabilidad de la ejecución a un tercero, pero además se amplía la gama de actividades a su cargo, deben considerarse los riesgos y recomendaciones del numeral anterior y adicionalmente los siguientes:

RIESGO ASOCIADO RECOMENDACIÓN Complejidad de la verificación de actividades a ejecutar no permite garantizar la calidad de los bienes y servicios contratados

• Considerar -de manera previa a la contratación del proyecto- la posibilidad de contar con una interventoría especializada para verificar los aspectos inherentes a la adquisición de los bienes o servicios incluidos en el proyecto o solución integrada a contratar.

Mayores costos por incertidumbre sobre aspectos de alcance o de modelo de negocio relacionado con la solución integrada a contratar

• Adelantar o realizar un estudio de prefactibilidad que reduzcan los niveles de incertidumbre sobre aspectos de alcance o del modelo de negocio (si aplica) del proyecto a contratar.

Reclamaciones relacionadas con el restablecimiento del equilibrio

• Identificar previamente situaciones que puedan afectar condiciones establecidas con cargo al

52

económico del contrato por aspectos imputables a cambios en las condiciones

proyecto y hacer especificaciones particulares que permitan adelantar su gestión sin afectar los costos de su desarrollo.

• Incluir consideraciones respecto de la forma en que se gestionan los controles de cambios respecto a condiciones establecidas para la ejecución del proyecto.

5.9. Otros proyectos Teniendo en cuenta que en esta clasificación, caben otros tipos de proyectos no especificados en los numerales anteriores, éstos serían algunos posibles riesgos y sus recomendaciones:

RIESGO ASOCIADO RECOMENDACIÓN Elementos arrendados sufren daños por condiciones técnicas de las instalaciones (arrendamiento de equipos)

Verificar condiciones técnicas de las instalaciones antes de instalar los equipos entregados bajo la modalidad de arriendo. Establecer la posibilidad de que los elementos arrendados sean cubiertos por pólizas de seguros.

Elementos arrendados fallan o se Deterioran por falta de mantenimiento (arrendamiento de equipos)

Dentro del contrato de mantenimiento, establecer el mantenimiento preventivo y correctivo de los equipos, a todo costo (incluidos repuestos y mano de obra).

Profesionales o personal técnico Contratado no tiene las habilidades requeridas para cumplir el objeto del contrato (prestación de servicios)

Verificar referencias laborales y certificaciones de experiencia de la persona por contratar. En los casos en que sea posible, realizar pruebas técnicas.

Falta de insumos para realizar actividades a cargo de contratistas (prestación de servicios)

Identificar y disponer de manera oportuna, los insumos que los contratistas requieran para el cabal cumplimiento del objeto del contrato.

Demandas de carácter laboral (prestación de servicios)

Establecer medidas para evitar configurar situaciones en desarrollo del contrato que determinen subordinación y dependencia, así como continuidad del servicio.

Personas que no pueden ser beneficiadas con capacitación acceden a cursos contratados (capacitación)

Fijar un protocolo para la preinscripción, inscripción y legalización (si aplica) de procesos de exclusión en cursos contratados. Determinar si el tipo de capacitación que se va a contratar es objeto de la restricción legal existente, en relación con imposibilidad de impartir capacitación a personas diferentes a las que hacen parte de la planta de personal de la entidad, tales como personal provisional o contratistas de prestación de servicios.

53

Deficiente calidad en servicios de capacitación (capacitación)

Establecer condiciones para que la capacitación sea ofrecida por instituciones de reconocida trayectoria. Cuando sea posible, incluir especificaciones de certi-ficación para los respectivos temas o tecnologías sobre los cuales sea necesario capacitar.

5.10. Claves para desarrollar proyectos exitosos 5.10.1. Apoyo de la alta dirección Como hemos visto, los proyectos informáticos aún en aquellos casos que parecen ser de poco o mediana complejidad, muchas veces tienen un alto impacto en la entidad, ya sea porque son de carácter transversal, porque soportan servicios a terceros (en especial al ciudadano y otras entidades), o porque apoyan la toma de decisiones.

Es fundamental el acompañamiento y apoyo de la alta dirección para ejecutar este tipo de proyectos, en especial, cuando existen condiciones como la baja cultura informática, cuyas condiciones afectan la dinámica que se requiere para incorporar cambios y realizar una transformación organizacional.

Este tipo de apoyo se traduce en aspectos tales como orientación estratégica sobre los objetivos del proyecto, asignación de presupuesto requerido, generación de instrucciones a las diferentes áreas de la entidad sobre requerimientos del proyecto, y demás elementos que faciliten el cumplimiento de los objetivos del mismo.

5.10.2. Compromiso del usuario El usuario es un actor fundamental desde la concepción, hasta la posible apropiación de soluciones derivadas de la implementación de proyectos informáticos. Sin usuario, no hay proyecto.

En este sentido, es muy importante resaltar que los proyectos informáticos no son del área de sistemas, tecnología o informática del Ministerio TIC. En los resultados del proyecto, están las expectativas de poder resolver una necesidad o una problemática de impacto institucional, de mejorar la toma de decisiones, de optimizar recursos o de mejorar los servicios al ciudadano, entre otras. En realidad, son proyectos de cada uno de los usuarios que lo requieran.

Desafortunadamente, la visión de que los proyectos informáticos son del área de tecnología de la entidad, hace que muchas veces estas dependencias se perciban solas en la responsabilidad de sacar el proyecto adelante, razón por la cual es fundamental, generar una corresponsabilidad y compromiso absoluto de las áreas usuarias, mediante la definición de responsables funcionales que lideren el

54

proceso desde la concepción de la idea, hasta la puesta en operación definitiva del respectivo proyecto.

5.10.3. Claridad de los objetivos del proyecto Los proyectos tienen mayor posibilidad de ser exitosos, en la medida en que se tenga claridad respecto de sus objetivos. Un proyecto demanda muchos esfuerzos y recursos, generación de especificaciones, interminables reuniones, y un sin número de situaciones que sólo se ven justificadas, si la organización en conjunto, tiene claridad sobre para qué se está realizando el proyecto.

El “para qué” de un proyecto como soporte de su objetivo, debe ser el eje articulador que motive los esfuerzos de los diferentes actores que participan en el proyecto, y garantizar que a pesar de las dificultades o situaciones problemáticas típicas de cualquier proyecto, el mismo tenga continuidad hasta lograr sus propósitos.

5.10.4. Expectativas y alcances reales En la implementación de proyectos informáticos, se generan muchas expectativas. Esto se puede apreciar cuando se realiza cualquier lluvia de ideas en la cual inicialmente parece existir una gran motivación por contar con una solución para determinada necesidad o problema. Desafortunadamente, esa motivación parece reducirse en el preciso momento cuando es necesario que los responsables designados por las diferentes áreas, deban comprometerse con actividades concretas, como por ejemplo: la formalización de los requerimientos.

No obstante lo anterior, es necesario “aterrizar” las expectativas a las posibilidades reales que pueda ofrecer la solución, en el marco de sus restricciones de alcance, tiempo de ejecución y costo.

Lo anterior implica identificar las expectativas de la manera más clara y precisa que sea posible y “traducirlas” en especificaciones que permitan conformar un alcance para la solución.

Esta fase inicial se debe ir acotando en función del presupuesto disponible y la retroalimentación que se haga como posibles proveedores en el marco de las precotizaciones que se deben obtener para realizar el estudio de mercado.

En algunos casos, será necesario estructurar el proyecto por fases, de tal forma que se adelanten actividades agrupadas por etapas que sean distribuidas en el tiempo. Lo importante de ejecutar el proyecto con esta estrategia, es tener un norte orientado por la visión de la solución, pero cuyos frutos se van obteniendo

55

de manera estructurada, conforme con los productos y alcance que se definan para cada etapa.

En los casos en que la complejidad exija, deben hacerse estudios de prefactibilidad, de forma tal que se reduzca la incertidumbre respecto del alcance del proyecto.

5.10.5. Aspectos técnicos La falta de previsión de aspectos técnicos o restricciones de infraestructura en la entidad, pueden ser factores que terminen por ocasionar el fracaso del proyecto.

En este sentido, es necesario tener en cuenta los requerimientos de articulación de orden técnico que pueda tener la solución por implementar, así como los requisitos para su adecuada implementación. Es especialmente importante, procurar que el cronograma del proyecto no dependa de productos de otros procesos, proyectos o contratos que puedan en un momento determinado, limitar la disponibilidad de insumos requeridos.

En proyectos de desarrollo o mantenimiento de software, deberá tenerse en cuenta aspectos como:

Extensibilidad Desempeño Seguridad Facilidad de entendimiento Facilidad de modificación Portabilidad Escalabilidad Disponibilidad Confiabilidad Usabilidad Facilidad de construcción

Mientras que en la adquisición de hardware, se deberá tener en cuenta factores como:

Escalabilidad Desempeño Seguridad Facilidad de configuración Software utilitario

56

Metodologías formales y referentes

Es muy importante establecer metodologías y referentes generalmente aceptados, que puedan adoptarse como marco de ejecución de las actividades del respectivo proyecto.

Es oportuno resaltar la definición de hitos asociados a entregables del proyecto, y éstos a su vez, asociados a la forma de pago del respectivo contrato.

Emplear metodologías formales generalmente aceptadas, ofrece la ventaja de contar con entregables con contenidos cuya estructura reconoce el marcado y facilita la posibilidad de contar con listados de chequeo que permitan verificar condiciones de calidad de los productos entregados.

5.10.6. Estimaciones confiables La estimación es un proceso clave para determinar la cantidad de recursos que requiere un proyecto.

Aunque en la estimación, no se puede garantizar exactitud, existen características que pueden afectar su precisión, tales como:

Riesgos inherentes al proyecto Fiabilidad de la información usada Efectividad del proceso de estimación El proceso de estimación deberá realizarse en el nivel de detalle que

requiera el proyecto según los siguientes aspectos por considerar: La magnitud del proyecto Riesgo de las estimaciones inexactas Incertidumbre del proyecto.

Cuando alguno de estos aspectos es grande, su estimación debe considerar mayor detalle.

5.10.7. Personal capacitado e idóneo Es de suma importancia que el personal vinculado al proyecto, independiente de que sea propio o de un contratista, esté debidamente capacitado y cuente con las habilidades que les permitan ser idóneo en las tareas a su cargo.

Cuando se trate de personal propio, debe ser parte del proceso de asignación de las actividades, verificar las capacidades y habilidades requeridas para su ejecución o en su defecto, saber que en los casos cuando sea posible, el servidor público

57

tenga la capacidad de investigar para obtener información necesaria para realizar la actividad.

En lo referente a equipos de trabajo de contratistas, deberá incluirse como parte del proceso de selección, los requisitos de formación académica, experiencia específica e incluso, cuando así corresponda, la exigencia de certificaciones de la industria o formación técnica especializada.

5.10.8. Procesos de selección Adelantar un adecuado proceso de selección es un factor clave de éxito, para obtener, entre otros:

Acceso a la tecnología adecuada, de fabricantes con garantía directa de fábrica (equipos y software)

Soluciones a la medida de los requerimientos de la entidad, con metodologías y herramientas de aceptación mundial (consultorías de análisis, diseño e implementación de software).

Infraestructura adecuada para soportar el sistema de sistemas de información misionales y de apoyo (infraestructura y adecuaciones)

Habilidades y competencias en tecnología de punta, así como en sus procesos de apropiación (capacitación)

Sin duda alguna, las tecnologías de la información y comunicaciones, son cada vez más empleadas y los procesos de gestión de las entidades dependen en buena parte, de la disponibilidad de todo tipo de herramientas tecnológicas, sin las cuales no sería posible atender eficiente y eficazmente las necesidades de la ciudadanía ni los requerimientos como los efectuados por los organismos de control. En el contexto actual, una administración eficiente supone el aprovechamiento intensivo de las nuevas tecnologías, lo cual hace absolutamente indispensable la disposición de bienes y servicios informáticos, cuyos contratos se consigan de procesos de selección que permitan obtener excelentes productos o servicios.

En este punto es muy importante recordar, que antes de lanzar cualquier proceso de selección, debe verificarse si el bien o servicio a contratar se encuentra incluido dentro de los bienes o servicios ofrecidos dentro del alcance de acuerdos marco de precio celebrados por la Agencia Nacional de Contratación Pública - Colombia Compra Eficiente, dado que además de ser una obligación legal de adherirse al acuerdo cuando el bien o servicio que se requiere está incluido en alguno de ellos, también se tienen ventajas muy importantes como por ejemplo la obtención de lo requerido en tiempos muy inferiores a los que implica adelantar todo un proceso de selección, así como beneficiarse de la robustez de las especificaciones y

58

condiciones con las que se contratan estos servicios por parte de la Agencia, entre otros.

5.10.9. Sostenibilidad Por último, pero no menos importante, debe garantizarse la sostenibilidad de los resultados del proyecto, para lo cual debe considerarse aspectos como los siguientes:

Apropiación de los resultados del proyecto por parte de los usuarios: el convencimiento de los usuarios sobre los beneficios que les ofrece el proyecto, es un elemento que mitiga el riesgo de abandono de sus resultados.

Soporte: En la etapa de operación o entrada en producción de los proyectos, es fundamental contar con el soporte desde la perspectiva funcional y técnica, para que en el caso de incidentes o dificultades, el usuario sienta que tiene el acompañamiento requerido para superar los inconvenientes que se le puedan presentar.

Mantenimiento y actualización: Para garantizar la vigencia de la solución, es importante adelantar procesos de mantenimiento o actualizaciones. De esta forma, se garantiza que la solución tiene la posibilidad de adaptarse a las nuevas necesidades o requerimientos.

Transferencia de tecnología / Capacitación: La generación de capacidades y habilidades en el talento humano, en los aspectos técnicos y funcionales, permiten que los responsables de soporte y los usuarios respectivamente, puedan realizar las actividades a su cargo.

Identificación de las fases siguientes: Documentar las posibles etapas que en el futuro se puedan desarrollar para mejorar alcance, cobertura o características de las solución, constituye una oportunidad para asignar nuevos recursos para el proyecto y por lo tanto, garantizar su continuidad.

59