UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL
(UCI)
PROPUESTA DE UN MODELO PARA LA GESTIÓN DE LOS RIESGOS EN LOS
PROYECTOS DE DESARROLLO DE SISTEMAS SUBCONTRATADOS POR EL
DEPARTAMENTO DE INFORMÁTICA DEL CONAVI
LIC. MAURICIO DEL RÍO CALDERÓN
PROYECTO FINAL DE GRADUACIÓN PRESENTADO COMO REQUISITO
PARCIAL PARA OPTAR POR EL TÍTULO DE MASTER EN ADMINISTRACIÓN
DE PROYECTOS.
San José, Costa Rica
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL
(UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como
Requisito parcial para optar al grado de Master en Administración de Proyectos
__________________________
Fausto Fernández Martínez
PROFESOR TUTOR
_________________________
Ing. Mario López Soto, MAP
LECTOR No.1
__________________________
Ing. Yuri Kogan Schmuckler, MAP
LECTOR No.2
________________________
Lic. Mauricio del Río Calderón
DEDICATORIA
Dedico este proyecto a mi esposa Mª. Gabriela quien con su apoyo y paciencia siempre me alentó a seguir adelante.
RECONOCIMIENTOS
Agradezco a todas aquellas personas que hicieron posible que este proyecto concluyera de la mejor manera. A mi tutor, los lectores, compañeros de trabajo y Maestría. A todos, infinitas gracias por cada uno de sus aportes, los cuales fueron todos de mucha utilidad a
INDICE GENERAL
CAPITULO I: INTRODUCCION... 1
1.1 Antecedentes ... 1
1.2 Problemática ... 2
1.3 Justificación del Proyecto ... 4
1.4 Objetivos ... 4
1.4.1 Objetivo General ... 4
1.4.2 Objetivos Específicos ... 5
CAPITULO II: MARCO TEORICO ... 6
2.1 Marco Institucional... 6
2.2 Teoría ... 8
2.2.1 Teoría de Administración de Proyectos según el PMBOK ... 8
2.2.2 Ley de Contratación Administrativa ... 18
2.2.3 Tecnologías de la Información. ... 23
2.2.4 Desarrollo de Sistemas de Información ... 26
2.2.5 Tendencias en el software ... 32
2.2.6 Proveedores de servicios de SI ... 32
2.2.4 Software de Sistemas de información. ... 33
2.2.5 Gestión del riesgo en las tecnologías de la información. ... 36
CAPITULO III: MARCO METODOLOGICO ... 39
3.1 Categorías de fuentes de informacion: ... 39
3.1.1 Primarias: ... 39 3.1.2 Secundarias: ... 39 3.2 Investigacion documental ... 40 3.3 Métodos de Investigacion ... 40 3.3.1 Método analítico-sintético ... 40 3.4 Técnicas y Herramientas. ... 41
CAPITULO IV: DESARROLLO... 42
4.1 Situación Actual ... 42
4.1.1 Investigación de los Expedientes ... 42
4.1.2 Encuestas realizadas ... 44
4.2 Propuesta de acciones de mejora ... 79
4.3 Guía para la Gestión de Riesgos ... 82
CAPITULO V: CONCLUSIONES ... 112
CAPITULO VI: RECOMENDACIONES ... 114
BIBLIOGRAFIA ... 116 ANEXOS ... 117 Anexo N º 1 ... 118 Anexo Nº 2 ... 120 Anexo Nº 3 ... 122 Anexo Nº 4 ... 123 Anexo Nº 5 ... 124
INDICE DE CUADROS
Cuadro Nº 1 Técnicas y Herramientas utilizadas en el Proyecto Final de Graduación...41 Cuadro Nº 2 Cuadro de resumen de las contrataciones………....………..…42 Cuadro Nº 3 Acciones específicas para el objetivo de la calidad……….….…….80 Cuadro Nº 4 Acciones específicas para el objetivo de tiempo………..…….….81 Cuadro Nº 5 Acciones específicas para el objetivo de la satisfacción del usuario final. 81
INDICE DE FIGURAS
Figura Nº 1 Organigrama Institucional del Consejo Nacional de Vialidad………7 Figura Nº 2 Grupo de procesos que conforman el Plan de Gestión de Riesgo……….…14 Figura Nº 3 Interacción de procesos de un proyecto con los procesos de un Plan de Gestión deRiesgos ……….…….……..15 Figura Nº 4 Tipos de software de aplicaciones y sistemas………..…….…32
INDICE DE GRÁFICOS
Gráfico No. 1 Conocimiento de gestión del riesgo por parte del líder del
proyecto………... 45
Gráfico No. 2 Aplicación de una metodología para gestión de riesgos por parte del líder del proyecto……….. 46 Gráfico No. 3 Inclusión de tareas adicionales en el cronograma base del proyecto para la gestión de riesgos en el proyecto………..… 46 Gráfico No. 4 Comunicación planes de contingencia por parte de la jefatura…. 47 Gráfico No. 5 Existencia de estudio previo de riesgos asociados al proyecto.... 47 Gráfico No. 6 Existencia de cláusulas en el cartel en cuanto a estrategias relacionadas con los riesgos del proyecto……...………. 48 Gráfico No. 7 Tiempo consumido en la etapa de requerimientos para el proyecto liderado……….……….. 48 Gráfico No. 8 Tiempo requerido en la etapa de estudio de mercado para el proyecto liderado………... 49 Gráfico No. 9 Participación de los usuarios finales en la etapa de levantamiento de requerimientos……… 494 Gráfico No. 10 Revisión y aval de requerimientos del sistema por usuarios
finales……….. 50
Gráfico No. 11 Solicitud formal por parte de las jefaturas para dar inicio al proyecto…………... 50 Gráfico No. 12 Análisis de involucrados al iniciar con el proyecto……… 51 Gráfico No. 13 Evaluación y atención de los riesgos asociados al proyecto... 51 Gráfico No. 14 Comunicación entre las partes involucradas en el proyecto…. 52 Gráfico No. 15 Revisión de problemas en etapas anteriores a la ejecución….. 52 Gráfico No. 16 Obtención de los entregables en el plazo establecido……... 53 Gráfico No. 17 Entregables avalados por el usuario final mediante documento
firmado……….. ………. 53
Gráfico No. 18 Prioridad dada a los entregables devueltos por el usuario……. 54 Gráfico No. 19 Gestión del conocimiento de los riesgos presentados en la
etapa de ejecución y control del proyecto………. 54 Gráfico No. 20 Opinión por parte del líder en cuanto a la importancia de gestionar los riesgos en sus proyectos. ……… 55 Gráfico No. 21 Importancia del proyecto gestionado……….………. 55 Gráfico No. 22 Aplicación de conocimientos de gestión de proyectos para
cada proyecto……….……… 56
Gráfico No. 23 Conocimiento de gestión de riesgo por parte del líder del proyecto... 56 Gráfico No. 24 Aplicación de una metodología para la gestión de riesgos por parte del líder del proyecto...……… 57 Gráfico No. 25 Inclusión de tareas adicionales en el cronograma base del proyecto para la gestión de riesgos en el proyecto……….. 57 Gráfico No. 26 Comunicación planes contingencia por la jefatura……….... 58 Gráfico No. 27 Existencia de estudio previo de riesgos asociados al proyecto. 58 Gráfico No. 28 Existencia de cláusulas en el cartel en cuanto a estrategias relacionada con los riesgos del proyecto..……….… 59 Gráfico No. 29 Tiempo consumido en etapa de requerimientos para proyecto
liderado…..………. 59
Gráfico No. 30 Tiempo requerido en la etapa de estudio de mercado para el proyecto liderado. ………. 60 Gráfico No. 31 Participación de usuarios finales en etapa de levantamiento de
requerimientos……...……… 60
Gráfico No. 32 Revisión y aval de los requerimientos del sistema por los usuarios finales………...……… 61 Gráfico No. 33 Solicitud formal de jefaturas para iniciar proyecto……….... 61 Gráfico No. 34 Análisis de involucrados al iniciar con el proyecto……… 62 Gráfico No. 35 Evaluación de los riesgos asociados al proyecto y atención a
los mismos……….. 62
Gráfico No. 36 Comunicación entre las partes involucradas en el proyecto…… 63 Gráfico No. 37 Previsión en etapas anteriores de problemas presentados en la etapa de ejecución... 63 Gráfico No. 38 Obtención de los entregables en el plazo establecido……... 64
Gráfico No. 39 Aval de entregables por parte del usuario final mediante documento firmado…………... 64 Gráfico No. 40 Prioridad a los entregables devueltos por el usuario…... 65 Gráfico No. 41 : Gestión del conocimiento de los riesgos presentados en la etapa de ejecución y control del proyecto………. 65 Gráfico No. 42 Opinión por parte del líder en cuanto a la importancia de gestionar los riesgos en sus proyecto……… 66 Gráfico No. 43 Importancia del proyecto gestionado……….. 66 Gráfico No. 44 Aplicación de conocimientos de gestión de proyectos para cada uno de los proyectos……… 67 Gráfico No. 45 Consideración de la opinión del usuario final sobre los requerimientos del nuevo sistema…………..……… 67 Gráfico No. 46 Solicitud de firma de requerimientos para el nuevo sistema…... 68 Gráfico No. 47 Consideración de opinión por parte del Departamento de Informática... 68 Gráfico No. 48 Calificación por parte del usuario de las etapas del proyecto…. 69 Gráfico No. 49 Comunicación del usuario final con la empresa desarrolladora.. 69 Gráfico No. 50 Comunicación del usuario final y el Departamento de
Informática……….. 70
Gráfico No. 51 Tiempo que lleva utilizando el usuario final el sistema…………. 70 Gráfico No. 52 Beneficio del sistema en las labores del usuario... 71 Gráfico No. 53 Cumplimiento de expectativas del usuario final…………... 71 Gráfico No. 54 Calificación del sistema por parte del usuario final…...………… 72 Gráfico No. 55 Calificación por parte del usuario final al proceso de solicitud y corrección de errores y mejoras al sistema. ………. 72 Gráfico No. 56 Consideración de la opinión del usuario final sobre los requerimientos del nuevo sistema……….………. 73 Gráfico No. 57 Solicitud de firma de requerimientos para el nuevo sistema…... 73 Gráfico No. 58 Consideración de la opinión del usuario final por parte del Departamento de Informática……….. 74 Gráfico No. 59 Calificación por parte del usuario de las etapas del proyecto…. 74
Gráfico No. 60 Comunicación del usuario final con la empresa desarrolladora.. 75 Gráfico No. 61 Comunicación entre usuario final y Depto. Informática……….. 75 Gráfico No. 62 Tiempo que lleva utilizando el usuario final el sistema…………. 76 Gráfico No. 63 Beneficio del sistema en las labores del usuario…... 76 Gráfico No. 64 Cumplimiento de expectativas del sistema para el usuario final. 77 Gráfico No. 65 Calificación del sistema por parte del usuario final…...………… 77 Gráfico No. 66 Calificación del usuario final al proceso de solicitud y corrección de errores y mejoras al sistema. ………..….. 78
ABREVIATURAS
CONAVI - Siglas en español para Consejo Nacional de Vialidad.
CASE - Siglas en inglés para Ingeniería del Software Asistida por Computadora
(Computer Aided Software Engineering)
FODA - Siglas en español de fortalezas, oportunidades, debilidades y amenazas.
NIST – Siglas en inglés para Instituto Nacional de Estándares y Tecnología (National
Institute of Standards and Technology)
PMBOK - Siglas en inglés para Conocimientos Base para la Administración de Proyectos
(Project Management Body of Knowledge)
PMI - Siglas en inglés del Instituto de Administración de Proyectos (Project Management
Institute).
RAD - Siglas en inglés para diseño de aplicación rápida (Rapid Application Development)
RBS - Siglas en inglés de Estructura de Desglose del Riesgos (Risk Breakdown Structure)
RFP - Siglas en inglés para Solicitud para Respuesta (Request for Proposal)
RFQ - Siglas en inglés para Solicitud para Cotización (Request for Quotation,)
SAP - Siglas en inglés de Software para Negocios y Soluciones de Aplicaciones y
Servicios (Business Software Solutions Applications and Services)
SIGEPRO- Siglas en español para Sistema de Gestión de Proyectos.
RESUMEN EJECUTIVO
El Consejo Nacional de Vialidad (CONAVI) es una institución de tipo pública la cual tiene cerca de diez años de haber sido creada. Fue creada mediante la Ley 7798 y su labor básica es administrar contratos que buscan tanto crear como mantener la infraestructura vial (carreteras y puentes) que conforman la red vial nacional.
El CONAVI por si mismo no ejecuta los proyectos, pero si se encarga de gestionar contratos de obra llevados a cabo por terceros. De aquí la importancia de contar con sistemas de información robustos que permitan a las personas encargadas de dicha gestión poder realizar sus labores de manera correcta, ya que dichos contratos representan muchos miles de millones de colones.
El departamento de informática en cuyo lugar se desarrolló el siguiente trabajo también sigue dicha estrategia para llevar a cabo los sistemas de información que apoyan la gestión de los proyectos de obra pública. La mayoría de proyectos en informática obedecen a contratos por servicios de desarrollo de sistemas de información y compra de equipo de cómputo.
En los últimos años se han venido fortaleciendo distintas áreas del CONAVI con sistemas de información “a la medida”. Pero hasta ahora no se cuentan con herramientas en el departamento de informática que le permitan desarrollar una adecuada gestión del riesgo en los proyectos de desarrollo de sistemas de información que se contratan a empresas. Por ello existe la necesidad de abordar dicho faltante, y así dotar al personal encargado de la gestión de los contratos de desarrollo de sistemas de información de dicha herramienta.
Por lo tanto se tiene como objetivo principal de este trabajo contar con una guía metodológica para la gestión de los riesgos en los proyectos de desarrollo de sistemas subcontratados para el Departamento de Informática del CONAVI.
Para lograr esto se plantearon tres objetivos específicos, el primer objetivo es el de recopilar documentación de proyectos subcontratados de desarrollo de sistemas licitados en el pasado y que sean significativos para la Institución, esto para analizar sus resultados en cuanto a tiempo, calidad y satisfacción de los usuarios. El segundo objetivo es proponer acciones especificas para un mejoramiento de los proyectos analizados en los objetivos planteados y por último el tercer objetivo es desarrollar una guía para la gestión de riesgos para ser utilizado en los proyectos antes mencionados.
Las metodologías utilizadas para lograr completar de manera satisfactoría cada uno de los objetivos planteados fueron: la revisión exhaustiva de documentación relacionada con proyectos de desarrollo de sistemas de información que se contrataron y las entrevistas a encargados de proyectos y a usuarios finales quienes utilizan los sistemas estudiados. Todo con el fin de conocer como se lograron los objetivos planteados en dichos proyectos relacionados con el tiempo de ejecución, calidad y satisfacción del los usuarios finales.
Todo esto es importante para llevar a cabo recomendaciones basado en los resultados encontrados y a partir de esto poder elaborar una guía para la gestión de riesgos en base a la Guía de los Fundamentos de la Dirección de Proyectos (PMBOK) en su tercera edición y que se ajuste a las necesidades departamentales.
Los resultados hallados mediante la resolución del objetivo número uno evidenciaron un nivel de desconocimiento por parte de los líderes de proyecto de técnicas en la gestión de riesgos a la hora de llevar a cabo el seguimiento y control de los proyectos a su cargo. También se obtuvo información más en detalle de las características de cada uno de los proyectos en sus distintas etapas como por ejemplo el tiempo de ejecución, tipo de contratación y las horas que se invirtieron en su elaboración.
El objetivo número dos muestra acciones específicas que se recomienda sean tomados en consideración a la hora de contratar más etapas en dichos proyectos o para otros proyectos que se liciten en el futuro en el departamento.
Por último en el objetivo número tres se elaboró una propuesta de una guía para la gestión de los riesgos para proyectos; en dicha guía se presentaron los seis procesos que conforma la gestión de riesgos, presentado de una manera paso a paso que le permitan al equipo de gestión del riesgo llevar de manera sistemática dicha labor, en busca de una mejor gestión.
Se concluyó a partir del desarrollo del presente trabajo aspectos como la importancia de llevar a cabo un estudio profundo en el análisis de interesados en esta clase de proyectos, ya que intervienen muchos intereses y la cantidad de grupos que interaccionan hacen que la gestión del proyecto se dificulte en ausencia de procedimientos, información actualizada y una debida gestión de los riesgos.
Se destaca el esfuerzo por parte de cada uno de los líderes de proyecto para gestionar sus proyectos, tomando en cuenta la falta de herramientas y técnicas que se dio en el momento de las contrataciones.
Así mismo se recomendó a las jefaturas sobre la importancia de contar con una metodología en la gestión de riesgos en los proyectos de desarrollo de sistemas que se contratan.
Otra recomendación importante es normar los diferentes procesos que se vinculan con una contratación por servicios de desarrollo de sistemas, con el fin de facilitar las labores de los líderes de proyecto; ya que se evitaría cometer de manera reiterada errores en dicho proceso.
Se recomendó dotar a los líderes de proyectos con herramientas informáticas que les permitan gestionar sus proyectos.
CAPITULO I: INTRODUCCION
1.1 Antecedentes
La institución en donde se desarrollará el proyecto es el Consejo Nacional de Vialidad (CONAVI), actualmente sus oficinas centrales se encuentran ubicadas carretera a Sabanilla. Es una institución gubernamental que se creo en el año 1998 con la Ley 7798, la cual establece al CONAVI como un órgano con desconcentración máxima, adscrito al Ministerio de Obras Públicas y Transportes.
La visión del CONAVI es ser una entidad eficiente y oportuna en la administración de recursos, con alto compromiso de servicio y calidad, reconocida a nivel nacional e internacional, que promueve la incorporación de innovaciones tecnológicas para consolidar la Red Vial Nacional en términos adecuados de niveles de servicio y seguridad acordes con el desarrollo socioeconómico de Costa Rica.
La misión del CONAVI es ser una entidad pública especializada en infraestructura vial, comprometida con el bienestar y desarrollo de Costa Rica, capaz de asegurar la sostenibilidad de la Red Vial Nacional, a través de contratos y convenios con terceros para garantizar condiciones óptimas de operación, mediante un proceso de mejora continua y en armonía con el ambiente.
Los objetivos del CONAVI son:
Planear, programar, administrar, financiar, ejecutar y controlar la conservación y la construcción de la Red Vial Nacional, en concordancia con los programas que elabore la Dirección de Planificación del Ministerio de Obras Públicas y Trasportes. Administrar su patrimonio.
Ejecutar mediante contratos las obras, los suministros, y servicios requeridos para el proceso de conservación y construcción de la totalidad de la red vial nacional. Fiscalizar la ejecución correcta de los trabajos e incluso el control de la calidad. Promover la investigación, el desarrollo y la transferencia tecnológica en el campo
Celebrar contratos o prestar los servicios necesarios para el cumplimiento de sus objetivos y funciones.
El CONAVI obtiene su financiamiento del impuesto al combustible y de ingresos por concepto de peajes; dichos montos son destinados mayormente a realizar actividades de conservación, mantenimiento rutinario y periódico, mejoramiento y rehabilitación de la red vial nacional.
Por otro lado existen cuatro grandes programas presupuestarios y su estructura organizacional es un reflejo de dicha división.
Dentro de la estructura organizacional se encuentran departamentos tipo staff cuya función es el de asesorar a las diversas áreas que conforman la Institución. El departamento de Informática es uno de ellos, este se encuentra conformado por dos sub divisiones. Una es el sub-área de desarrollo de sistemas de información, en la cual laboran cuatro analistas de sistemas y el segundo es el sub-área de soporte técnico, en la cual laboran cuatro profesionales en computación. Ambas cuentan con un jefe, los cuales a su vez deben rendir cuentas al jefe del departamento.
1.2 Problemática
Uno de los aspectos más importantes dentro de la gestión de proyectos es la planeación. Es la etapa en la cual es necesario invertir la mayor cantidad de esfuerzo.
En el departamento de informática como en muchos otros departamentos, los proyectos que se llevan a cabo nacen a partir de una necesidad por parte de los usuarios tanto internos como externos al CONAVI.
El área de desarrollo de sistemas gestiona un número importante de proyectos anualmente, el nivel de complejidad varia de uno a otro y los encargados de llevarlo a cabo es un grupo de analistas de sistemas conocidos como jefes de proyecto, a quienes
se les asignan los proyectos; dependiendo de las cargas de trabajo, conocimientos, experiencia y aptitudes demostradas.
Informática divide los proyectos del área de desarrollo en tres tipos, los cuales son: desarrollos internos, desarrollos subcontratados y contrataciones de servicios.
Los desarrollos internos son todos aquellos sistemas de información desarrollados por recurso humano interno disponible en el área; se utilizan lenguajes de programación de dominio del analista-programador. La principal características de estos proyectos es el bajo nivel de complejidad que comprenden.
Para proyectos más grandes los cuales puede durar su ejecución un año o más, se utiliza la modalidad de subcontratación. Son desarrollos contratados los cuales se sacan a contratación para que una empresa los desarrolle a partir de las especificaciones técnicas publicadas en un cartel. Dichos proyectos obedecen a una necesidad de tipo organizacional en la cual se verán beneficiados muchos departamentos en el CONAVI.
Por último se encuentran los proyectos que requieren la contratación de un servicio o solución, no necesariamente por medio de la creación de un sistema de información. Un ejemplo de estos proyectos es la contratación de un escaneo masivo de documentación en la Institución. Estos proyectos también varían su nivel de complejidad y requieren una forma particular de ser gestionados.
Los proyectos subcontratados requieren especialmente de un mayor tiempo de planeación debido a su complejidad. En dicha etapa se levantan los requerimientos técnicos que le darán forma a la nueva aplicación. Los jefes de proyecto se enfocan de gran manera en dichos requerimientos y los tiempos que dicta la Ley de Contratación Administrativa son muy cortos y se requiere ejecutar los presupuestos, los cuales son de un año.
A la hora de valorar los riesgos de un proyecto cada jefe de proyecto en base a su experiencia mapea una serie de riesgos. Este análisis en algunos casos se realiza de
manera informal. En caso que dicho análisis no se lleve a cabo, tanto el líder de proyecto como sus jefes deberán tomar acciones para minimizar el impacto de los riesgos en el momento que empiezan a surgir a lo largo de la ejecución del proyecto.
1.3 Justificación del Proyecto
Por un lado al ser la planeación de un proyecto una de las etapas más importantes y por otro lado conociendo la realidad de los proyectos en el área de desarrollo de sistemas, es que se desea contar con una herramienta la cual permita de una manera esquematizada llevar a cabo la gestión de los riesgos en el proyecto.
Debido a esto se considera importante, primero que todo contar con dicha herramienta para luego ser aplicada desde el momento antes de iniciar el levantamiento de los requerimientos de un sistema nuevo; si se identifican correctamente los riesgos asociados al proyecto y luego se gestionan de manera sistemática, facilitaría la gestión del proyecto al jefe de proyecto y le permitiría ocupar su tiempo en otras tareas igualmente importantes.
1.4 Objetivos
A continuación se indican los objetivos que se desean abarcar a lo largo de la ejecución del presente proyecto.
1.4.1 Objetivo General:
Contar con una metodología para la gestión de los riesgos en los proyectos subcontratados de desarrollo de sistemas por el Departamento de Informática del CONAVI.
1.4.2 Objetivos Específicos:
1. Analizar los resultados en cuanto a tiempo, calidad y satisfacción de los usuarios de proyectos de desarrollo de sistemas subcontratados en el pasado, basado en la documentación de los mismos.
2. Proponer acciones especificas para un mejoramiento de los proyectos analizados en cuanto al tiempo, calidad y satisfacción de los usuarios.
3. Desarrollar una guía para la gestión de riesgos para ser utilizada en los proyectos de desarrollo de sistemas subcontratados.
CAPITULO II: MARCO TEORICO
2.1 Marco Institucional
El CONAVI es una institución de carácter público, la cual administra fondos provenientes en su mayor parte de los impuestos sobre la gasolina y el dinero que se recauda en los peajes ubicados en ciertas rutas nacionales.
Esta institución se encarga de gestionar proyectos de obra pública, los cuales buscan crear, mejorar y darle mantenimiento a las carreteras pertenecientes a la red vial nacional.
Actualmente el CONAVI cuenta con una estructura organizacional donde en su parte más alta se encuentra un Consejo de Administración cuya labor es la de tomar decisiones al más alto nivel administrativo, como se puede observar en la figura Nº 1.
Bajando en la estructura organizativa se encuentran departamentos de staff, administrativos y las unidades asesoras, estas últimas se encargan directamente de gestionar contratos de obra de infraestructura vial, estas son: la Dirección de Obras y la Dirección de Conservación Vial.
Consejo de Administración
Auditoría
Dirección Ejecutiva
Asesoría Legal Planeamiento y Control
Informática
Secretaría de Actas
Dirección de Obras Dirección de Conservación Vial
Dirección de
Ingeniería Dirección Administrativa-Financiera
Administración de
Peajes Pesos y Dimensiones
Figura Nº 1. Organigrama Institucional del Consejo Nacional de Vialidad (CONAVI, 2008)
La actual estructura del departamento de Informática del CONAVI es la siguiente:
1. Área de Servicios ó Soporte Técnico. 2. Área de Desarrollo de Sistemas.
Ambas cuentan con un jefe y adicionalmente existe un jefe de departamento que se encarga de velar que los objetivos del departamento a nivel macro sean alcanzados año tras año.
Actualmente laboran cuatro analisistas de sistemas en el área de Desarrollo de Sistemas y su rol es el de encargados de proyectos. Al igual que el CONAVI, el departamento de Informática gestiona en su mayoría proyectos subcontratados. Los sistemas de
información que cuenta el CONAVI son en su mayoría sistemas que fueron hechos a la medida por empresas especialistas en el área de desarrollo de aplicaciones.
Los sistemas de información más significativos que ha adquirido el CONAVI bajo la modalidad de subcontratación son el de Recursos Humanos y el Sistema de Gestión de Proyectos de Infraestructura Vial y Conservación Vial.
Se tiene planeado adquirir más sistemas por la vía de sub-contratación y que además todos se comuniquen entre si; con el fin de contar con un gran sistema tipo SAP y que le de soporte a los procesos que se llevan a cabo en el CONAVI.
2.2 Teoría
2.2.1 Teoría de Administración de Proyectos según el PMBOK:
2.2.1.1 ¿Qué es un proyecto?
Según la guía del PMBOK (PMI,2004) un proyecto es un esfuerzo temporal de elaboracion gradual que se lleva a cabo para crear un proyecto, servicio o resultado único. Temporal significa que cada proyecto tiene un comienzo definido y un final definido y elaboración gradual significa desarrollar en pasos e ir aumentando mediante incrementos.
2.2.1.2 Plan de gestión del proyecto:
El plan de gestión del proyecto describe cómo se va a usar el sistema de gestión de proyectos.
Es un documento formalmente aprobado que define como se ejecuta, supervisa y controla un proyecto. Puede ser resumido o detallado y estar compuesto por uno o más planes de gestión subsidiarios y otros documentos de planificación (PMI,2004).
El plan de gestión del proyecto contiene el plan de gestión del cronograma, el plan de gestión de costes, el plan de gestión del alcance del proyecto y el plan de gestión de riesgos, entre otros.
2.2.1.3 Sistema de gestión del proyecto:
El sistema de gestión de proyectos (PMI,2004) es el conjunto de herramientas, técnicas, metodologías, recursos y procedimientos utilizados para gestionar un proyecto. Puede ser formal o informal, y ayuda al director del proyecto a gestionar de forma eficaz un proyecto hasta su conclusión. El sistema es un conjunto de procesos y de las funciones de control correspondientes, que se consolidan y combinan en un todo funcional y unificado.
2.2.1.4 Plan de gestión del cronograma:
Proporciona orientación sobre el desarrollo y la planificación de las actividades del cronograma y del plan de gestión del alcance del proyecto; se utiliza para la estimación de recursos de las actividades (PMI,2004).
2.2.1.5 Plan de gestión de costes:
Establece los criterios para planificar, estructurar, estimar, preparar el presupuesto y controlar los costes del proyecto.
El esfuerzo de planificación de la gestión de costes (PMI,2004) tiene lugar al principio de la planificación del proyecto y establece el marco de cada uno de los procesos de gestión de costes, para que el rendimiento de los procesos sea eficiente y coordinado.
2.2.1.6 Control Integrado de Cambios:
Se aplica para asegurarse de que las acciones acordadas se implementen y supervisen como parte del proyecto en curso; revisa todas las solicitudes de cambio, aprueba los cambios y controla los cambios en los productos entregables y en los activos de los procesos de la organización (PMI,2004).
Actividades de gestión del cambio:
Identificar que debe producirse un cambio o que ya se ha producido.
Influir sobre los factores que podrían sortear el control integrado de cambios, de forma que solamente se implementen los cambios aprobados.
Revisar y aprobar los cambios solicitados.
Gestionar los cambios aprobados cuando y a medida que se produzcan, mediante la regulación del flujo de cambios solicitados.
Mantener la integridad de las líneas base habilitando sólo los cambios aprobados para su incorporación dentro de los productos o servicios del proyecto, y manteniendo actualizada la documentación de configuración y planificación relacionada.
Revisar y aprobar todas las acciones correctivas y preventivas recomendadas. Controlar y actualizar los requisitos del alcance, coste, presupuesto, cronograma y
calidad basándose en los cambios aprobados, mediante la coordinación de cambios durante todo el proyecto.
Documentar el impacto total de los cambios solicitados. Validar la reparación de defectos.
Controlar la calidad del proyecto según las normas, sobre la base de los informes de calidad.
2.2.1.7 Gestión del Riesgo:
Un riesgo de un proyecto (PMI,2004) es un evento o una condición incierta que, si se produce, tiene un efecto positivo o negativo sobre al menos un objetivo del proyecto,
como tiempo, coste, alcance o calidad. Un riesgo puede tener una o más causas y, si se produce, uno o más impactos. Las condiciones de riesgo pueden incluir aspectos del entorno del proyecto o de la organización que pueden contribuir al riesgo del proyecto, tales como prácticas deficientes de dirección de proyectos, la falta de sistemas de gestión integrados, múltiples proyectos concurrentes o la dependencia de participantes externos que no pueden ser controlados.
El riesgo del proyecto tiene su origen en la incertidumbre que está presente en todos los proyectos. Riesgos conocidos son aquellos que han sido identificados y analizados, y es posible planificar. Los riesgos desconocidos no pueden gestionarse de forma proactiva, y una respuesta prudente del equipo del proyecto puede ser asignar una contingencia general contra dichos riesgos, así como contra los riesgos conocidos para los cuales quizás no sea rentable o posible desarrollar respuestas proactivas.
Las organizaciones perciben los riesgos por su relación con las amenazas al éxito del proyecto o por las oportunidades de mejorar las posibilidades de éxito del proyecto. Los riesgos que son amenazas para el proyecto pueden ser aceptados si el riesgo está en equilibrio con el beneficio que puede ser obtenido al tomarlo.
Los riesgos que constituyen oportunidades, como la aceleración del trabajo que puede lograrse asignando personal adicional, pueden ser seguidos para beneficiar los objetivos del proyecto.
La Gestión de los Riesgos del Proyecto incluye los procesos relacionados con la planificación de la gestión de riesgos, la identificación y el análisis de los riesgos, las respuestas a los riesgos, y el seguimiento y control de riesgos de un proyecto. Los objetivos de la Gestión de los Riesgos del Proyecto son aumentar la probabilidad y el impacto de eventos positivos, y disminuir la probabilidad y el impacto de eventos adversos para los objetivos del proyecto. Los procesos de Gestión de los Riesgos del Proyecto incluyen (ver Figura No. 2):
Planificación de la Gestión de Riesgos: decide cómo enfocar, planificar y ejecutar las actividades de gestión de riesgos para un proyecto.
Identificación de Riesgos: determina qué riesgos pueden afectar al proyecto y documenta sus características.
Análisis Cualitativo de Riesgos: prioriza los riesgos para otros análisis o acciones posteriores, evaluando y combinando su probabilidad de ocurrencia y su impacto. Análisis Cuantitativo de Riesgos: analiza numéricamente el efecto de los riesgos
identificados en los objetivos generales del proyecto.
Planificación de la Respuesta a los Riesgos: desarrolla opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto.
Seguimiento y Control de Riesgos: realiza el seguimiento de los riesgos identificados, supervisa los riesgos residuales, identifica nuevos riesgos, ejecuta planes de respuesta a los riesgos y evalúa su efectividad durante todo el ciclo de vida del proyecto.
La Identificación de Riesgos determina qué riesgos pueden afectar al proyecto y documenta sus características. Entre las personas que participan en actividades de identificación de riesgos se pueden incluir, según corresponda, las siguientes: el director del proyecto, los miembros del equipo del proyecto, el equipo de gestión de riesgos (si se asigna uno), expertos en la materia ajenos al equipo del proyecto, clientes, usuarios finales, otros directores de proyectos, interesados y expertos en gestión de riesgos. Si bien estos miembros del personal son a menudo participantes clave de la identificación de riesgos, se debería fomentar la identificación de riesgos por parte de todo el personal del proyecto.
La Identificación de Riesgos es un proceso iterativo porque se pueden descubrir nuevos riesgos a medida que el proyecto avanza a lo largo de su ciclo de vida. La frecuencia de la iteración y quién participará en cada ciclo variará de un caso a otro. El equipo del proyecto debe participar en el proceso para poder desarrollar y mantener un sentido de pertenencia y responsabilidad por los riesgos y las acciones asociadas con la respuesta a los riesgos. Los interesados ajenos al equipo del proyecto pueden proporcionar información adicional sobre los objetivos. En algunas ocasiones, simplemente la identificación de un riesgo puede sugerir su respuesta, y esto debe registrarse para
realizar otros análisis y para su implementación en la planificación de la respuesta a los riesgos.
El registro de riesgos contiene información sobre riesgos del proyecto identificados que el equipo del proyecto tiene en cuenta al realizar estimaciones sobre las duraciones de las actividades y al ajustar dichas duraciones a los riesgos. El equipo del proyecto analiza la medida en que los efectos de los riesgos se incluyen en la estimación de la duración de la línea base para cada actividad del cronograma, especialmente aquellos riesgos con calificaciones de alta probabilidad o de alto impacto.
Figura Nº 3. Interacción de procesos de un proyecto con los procesos de un Plan de Gestión de Riesgos (PMBOK, 2004)
La Planificación de la Respuesta a los Riesgos es el proceso de desarrollar opciones y determinar acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Se realiza después de los procesos Análisis Cualitativo de Riesgos y Análisis Cuantitativo de Riesgos. Incluye la identificación y asignación de una o más
financiada. La Planificación de la Respuesta a los Riesgos aborda los riesgos en función de su prioridad, introduciendo recursos y actividades en el presupuesto, cronograma y plan de gestión del proyecto, según sea necesario.
Las respuestas a los riesgos planificadas deben ser congruentes con la importancia del riesgo, tener un coste efectivo en relación al desafío, ser aplicadas a su debido tiempo, ser realistas dentro del contexto del proyecto, estar acordadas por todas las partes implicadas, y a cargo de una persona responsable. A menudo, es necesario seleccionar la mejor respuesta a los riesgos entre varias opciones.
Los riesgos incluyen las amenazas y las oportunidades que pueden afectar al éxito del proyecto, y se discuten las respuestas para cada una de ellas.
Las respuestas a los riesgos planificadas que están incluidas en el plan de gestión del proyecto se ejecutan durante el ciclo de vida del proyecto, pero el trabajo del proyecto debe ser supervisado continuamente para detectar riesgos nuevos o que cambien.
El Seguimiento y Control de Riesgos es el proceso de identificar, analizar y planificar nuevos riesgos, realizar el seguimiento de los riesgos identificados y los que se encuentran en la lista de supervisión, volver a analizar los riesgos existentes, realizar el seguimiento de las condiciones que disparan los planes para contingencias, realizar el seguimiento de los riesgos residuales y revisar la ejecución de las respuestas a los riesgos mientras se evalúa su efectividad. El proceso Seguimiento y Control de Riesgos aplica técnicas, como el análisis de variación y de tendencias, que requieren el uso de datos de rendimiento generados durante la ejecución del proyecto. El proceso Seguimiento y Control de Riesgos, así como los demás procesos de gestión de riesgos, es un proceso continuo que se realiza durante la vida del proyecto. Otras finalidades del proceso Seguimiento y Control de Riesgos son determinar si:
Las asunciones del proyecto aún son válidas.
El riesgo, según fue evaluado, ha cambiado de su estado anterior, a través del análisis de tendencias.
Se están siguiendo políticas y procedimientos de gestión de riesgos correctos. Las reservas para contingencias de coste o cronograma deben modificarse para
alinearlas con los riesgos del proyecto.
El proceso Seguimiento y Control de Riesgos puede implicar tener que elegir estrategias alternativas, ejecutar un plan para contingencias o de reserva, adoptar acciones correctivas y modificar el plan de gestión del proyecto. El propietario de la respuesta a los riesgos informa periódicamente al director del proyecto acerca de la efectividad del plan, de cualquier efecto no anticipado y cualquier corrección sobre la marcha que sea necesaria para gestionar el riesgo correctamente. El proceso Seguimiento y Control de Riesgos también incluye la actualización de los activos de los procesos de la organización, incluidas las bases de datos de las lecciones aprendidas del proyecto y las plantillas de gestión de riesgos para beneficio de proyectos futuros.
2.2.1.8 Cierre del Proyecto:
El proceso Cerrar Proyecto (PMI,2004) supone realizar la parte de cierre del proyecto del plan de gestión del proyecto. En los proyectos de múltiples fases, el proceso Cerrar Proyecto cierra la parte del alcance del proyecto y las actividades relacionadas aplicables a una fase determinada. Este proceso incluye finalizar todas las actividades completadas a lo largo de todos los Grupos de Procesos de Dirección de Proyectos para cerrar formalmente el proyecto o una fase del proyecto, y transferir el proyecto completado o cancelado según corresponda. El proceso Cerrar Proyecto también establece los procedimientos para coordinar las actividades requeridas para verificar y documentar los productos entregables del proyecto, coordinar e interactuar para formalizar la aceptación de estos productos entregables por parte del cliente o del patrocinador, e investigar y documentar las razones por las cuales se realizaron ciertas acciones si un proyecto se da por finalizado antes de completarlo. Se desarrollan dos procedimientos para establecer las interacciones necesarias para realizar las actividades de cierre a lo largo de todo el proyecto o de una fase del proyecto:
Procedimiento de Cierre Administrativo. Este procedimiento describe en detalle todas las actividades, interacciones, roles y responsabilidades relacionados con los
miembros del equipo del proyecto y de los demás interesados involucrados en la ejecución del procedimiento de cierre administrativo del proyecto. Realizar el proceso de cierre administrativo también incluye las actividades integradas requeridas para recopilar los registros del proyecto, analizar el éxito o el fracaso del proyecto, reunir las lecciones aprendidas y archivar la información del proyecto, para su uso futuro por parte de la organización.
Procedimiento de Cierre del Contrato. Incluye todas las actividades e interacciones requeridas para establecer y cerrar todo acuerdo contractual establecido para el proyecto, y también para definir aquellas actividades relacionadas que respaldan el cierre administrativo formal del proyecto. Este procedimiento implica tanto la verificación del producto (todo el trabajo completado de forma correcta y satisfactoria) como el cierre administrativo (actualización de registros de contrato para reflejar los resultados finales y archivo de esa información para su uso futuro). Los términos y condiciones del contrato también pueden establecer especificaciones para el cierre del contrato, que deben ser parte de este procedimiento. La finalización anticipada de un contrato es un caso especial de cierre del contrato que podría suponer, por ejemplo, la incapacidad para entregar el producto, una desviación de presupuesto o la falta de los recursos requeridos.
2.2.2 Ley de Contratación Administrativa:
2.2.2.1 Descripción General:
La Ley de Contratación Administrativa (Asamblea Legislativa, 2007): en su Artículo 1º “regirá la actividad de contratación desplegada por los órganos del Poder Ejecutivo, Poder
Judicial, Poder Legislativo, Tribunal Supremo de Elecciones, Contraloría General de la República, Defensoría de los Habitantes, sector descentralizado territorial, entes públicos no estatales y empresas públicas.
Cuando se utilicen parcial o totalmente recursos públicos, la actividad contractual de todo tipo de personas físicas o jurídicas se someterá a los principios de esta Ley…”
2.2.2.2 Tipos de Contratación (Asamblea Legislativa, 2007)
a. Licitación pública:
Artículo 41: La licitación pública es el procedimiento de contratación obligatorio en los siguientes casos:
a. En los supuestos previstos en el artículo 27 de esta Ley.
b. En toda venta o enajenación de bienes, muebles o inmuebles, o en el arrendamiento de bienes públicos, salvo si se utiliza el procedimiento de remate.
c. En los procedimientos de concesión de instalaciones públicas
b. Licitación abreviada:
Artículo 45.—Estructura mínima. En la licitación abreviada, se invitará a participar a un mínimo de cinco proveedores del bien o servicio, acreditados en el registro correspondiente. La invitación se dirigirá a la dirección que indique el respectivo proveedor.
Si el número de proveedores para el objeto de la contratación es inferior a cinco, la administración deberá cursar invitación, mediante una publicación en el Diario Oficial. La administración también queda facultada para que curse invitación, mediante publicación en La Gaceta, cuando así lo estime conveniente para la satisfacción del interés público.
Por la naturaleza abreviada del procedimiento, la administración únicamente estudiará las ofertas de los proveedores que hayan sido invitados. Cuando medie publicación en La Gaceta, estudiará todas las ofertas presentadas.
El plazo para recibir ofertas no podrá ser menor inferior a cinco ni superior a veinte días hábiles, salvo en casos muy calificados en que la administración considere necesario ampliarlo hasta el máximo de diez días adicionales, para lo cual deberá dejar constancia en el expediente de las razones que justifican la ampliación.
El acto de adjudicación deberá dictarse dentro del plazo establecido en el cartel, el cual no podrá ser superior al doble del fijado para recibir ofertas. Vencido dicho plazo sin haberse dictado el acto de adjudicación, los oferentes tendrán derecho a dejar sin efecto su propuesta y a que se les devuelva la garantía de participación y sin que les resulte aplicable sanción alguna. Asimismo, los funcionarios responsables del no dictado oportuno del acto de adjudicación, estarán sujetos a las sanciones previstas en los artículos 96 y 96 bis de esta Ley, por incumplimiento general de plazos legales.
Para lo no previsto en esta sección, el procedimiento de licitación abreviada se regirá por las disposiciones de la presente Ley para la licitación pública, en la medida que sean compatibles con su naturaleza.(Así reformado mediante el artículo 1° de la ley N° 8511 del 16 de mayo del 2006).
Artículo 30.—Modificación del procedimiento en licitación infructuosa. Si se produce una licitación pública infructuosa, la administración podrá utilizar en el nuevo concurso el procedimiento de licitación abreviada.
Si una licitación abreviada resulta infructuosa, la administración podrá realizar una contratación directa.
En los casos anteriormente citados, deberá mediar autorización de la Contraloría General de la República, órgano que dispondrá de un término de diez días hábiles para resolver, previa valoración de las circunstancias que concurrieron para que el negocio resultara infructuoso.
En el caso de un remate infructuoso, la administración podrá aplicar hasta dos rebajas a la base fijada por el avalúo respectivo, hasta en un veinticinco por ciento (25%) cada vez. (Así reformado mediante el artículo 1° de la ley N° 8511 del 16 de mayo del 2006).
2.2.2.3 Sobre la adjudicación:
Artículo 42 bis.—Adjudicación. El acto de adjudicación deberá ser dictado dentro del plazo establecido en el cartel, que no podrá ser superior al doble del plazo fijado para recibir ofertas. Dicho plazo podrá ser prorrogado por un período igual y por una sola vez, mediante resolución motivada, en la cual se acrediten las razones de interés público que así lo justifiquen (Asamblea Legislativa, 2007).
Vencido el plazo señalado en el párrafo anterior sin haberse dictado el acto de adjudicación, los oferentes tendrán derecho a dejar sin efecto su propuesta, así como a que se les devuelva la garantía de participación, sin que les resulte aplicable sanción alguna. Asimismo, los funcionarios responsables del no dictado oportuno del acto de adjudicación, estarán sujetos a las sanciones previstas en los artículos 96 y 96 bis de esta Ley, por incumplimiento general de plazos legales.
Para los efectos de la readjudicación o declaratoria de desierto del concurso, derivadas de la anulación del acto de adjudicación, la administración dispondrá de un plazo de un mes, contado a partir del día siguiente a la fecha de la notificación de la resolución respectiva, plazo que podrá ser prorrogado por un mes adicional, en los casos debidamente justificados mediante resolución motivada que deberá constar en el expediente. Vencido este plazo, los funcionarios responsables del no dictado oportuno del acto de adjudicación, estarán igualmente sujetos a las sanciones previstas en los artículos 96 y 96 bis de esta Ley, por incumplimiento general de plazos legales. (Así adicionado mediante el artículo 3° de la ley N° 8511 del 16 de mayo del 2006).
2.2.2.4 Recursos:
Artículo 81.—Plazo y órganos competentes. Contra el cartel de la licitación pública y de la licitación abreviada, podrá interponerse recurso de objeción, dentro del primer tercio del plazo para presentar ofertas (Asamblea Legislativa, 2007):
El recurso se interpondrá ante la Contraloría General de la República, en los casos de licitación pública, y en los demás casos, ante la administración contratante. (Así reformado mediante el artículo 1° de la ley N° 8511 del 16 de mayo del 2006).
Artículo 82.- Legitimación y supuestos. Podrá interponer el recurso de objeción todo oferente potencial o su representante, cuando se considere que ha habido vicios de procedimiento, se ha incurrido en alguna violación de los principios fundamentales de la contratación o se ha quebrantado, de alguna forma, el ordenamiento regulador de la materia.
Además, estará legitimada para objetar el cartel o el pliego de condiciones, toda entidad legalmente constituida para velar por los intereses de la comunidad donde vaya a ejecutarse la contratación o sobre la cual surta efectos.
Artículo 83.- Resolución. El recurso de objeción deberá resolverse dentro de los diez días hábiles siguientes a su presentación.
Si no se resuelve dentro de este plazo, la objeción se tendrá por acogida favorablemente. Artículo 84.—Cobertura del recurso y órgano competente. En contra del acto de adjudicación podrá interponerse el recurso de apelación, en los siguientes casos:…
i) En las administraciones citadas en el inciso i), del artículo 27 de esta Ley, cuando el monto de la adjudicación impugnada sea igual o superior a los diez millones…
(Los límites económicos establecidos en los incisos del a) al j) fueron modificados por resolución R-CO-7 del 21 de febrero de 2007)
Para efectos de la aplicación de los límites anteriores, únicamente se tomará en consideración el monto impugnado. En el caso de licitaciones compuestas por varias líneas, se sumarán los montos adjudicados de las líneas que se impugnen. Si se trata de contratos continuados, se tomará en cuenta el monto adjudicado para el plazo inicial, sin considerar prórrogas eventuales. En licitaciones con cuantía inestimable cabrá el recurso de apelación. En los concursos promovidos de conformidad con lo previsto en el primer párrafo del artículo 1º de esta Ley, resultarán aplicables los límites establecidos en los anteriores incisos. En las adjudicaciones derivadas de autorizaciones basadas en razones de urgencia, no procederá recurso alguno.
El recurso deberá ser presentado ante la Contraloría General de la República, dentro de los diez días hábiles siguientes a la notificación del acto de adjudicación en los casos de licitación pública. Cuando se trate de licitaciones abreviadas o de concursos promovidos de conformidad con el segundo párrafo del artículo 1 de esta Ley, el recurso deberá presentarse dentro de los cinco días siguientes a la notificación del acto de adjudicación.
Los montos de apelación citados en este artículo serán ajustados de conformidad con los criterios establecidos en el artículo 27 de esta Ley.
(Así reformado mediante el artículo 1° de la ley N° 8511 del 16 de mayo del 2006).
2.2.3 Tecnologías de la Información.
2.2.3.1 Conceptos Básicos:
James A. O’Brien ofrece en su libro las siguientes definiciones:
a. Aplicaciones:
Usos de los sistemas de información para operaciones, administración y ventaja competitiva de una empresa, incluidos el comercio electrónico y la colaboración, utilizando Internet, intranets y extranets (O’Brien, 2001).
b. Desarrollo:
Formas en que los usuarios finales especialistas de información desarrollan soluciones de sistemas de información a problemas empresariales utilizando metodologías fundamentales de desarrollo y solución de problemas.
c. Administración:
Manejo efectivo y ético de los recursos y las estrategias empresariales implícitas en el uso de la tecnología de información en los niveles global, empresarial y de usuario final de una empresa.
d. Sistema:
Puede definirse simplemente como un grupo de elementos interrelacionados o que interactúan conformando un todo unificado.
2.2.3.2 Sistemas de Información:
a. Sistema de información:
Es un grupo de componentes interrelacionados que trabajan en conjunto hacia una meta común mediante la aceptación de entradas y generando salidas en un proceso de
transformación organizado (O’Brien, 2001). Este tipo de sistema (algunas veces llamado dinámico) tiene los tres componentes o funciones básicos de interacción:
Entrada: comprende la captura y el ensamblaje de elementos que entran al sistema para ser procesados, por ejemplo los datos.
Procesamiento: incluye procesos de transformación que convierten las entradas en salidas, por ejemplo cálculos matemáticos.
Salida: abarca la transferencia de elementos que han sido generados por un proceso de transformación hasta su destino final, por ejemplo productos terminados.
Un sistema de información es una combinación organizada de personas, hardware, software, redes de comunicaciones y recursos de datos que reúne, transforma y disemina información en una organización. Las personas han dependido de los sistemas de información para comunicarse entre si utilizando una variedad de mecanismos físicos (hardware), procedimientos e instrucciones de procesamiento de información (software), canales de comunicaciones (redes) y datos almacenados (recursos de datos) desde los albores de la civilización.
b. Usuario final:
Cualquiera que utilice un sistema de información o la información que genere. Usualmente este término se aplica a la mayor parte de las personas en una organización, a diferencia de las pocas personas que son especialistas en sistemas de información, como los analistas de sistemas o los programadores profesionales de computación.
Los sistemas de información deben sustentar las estrategias empresariales, los procesos y las estructuras empresariales y la cultura organizacional de una empresa.
El éxito de un sistema de información no debe medirse sólo por su eficiencia en términos de minimizar costos, tiempo y el uso de los recursos de información. El éxito también debe medirse por la efectividad de la tecnología de la información en el respaldo de las estrategias empresariales de una organización, facilitando sus procesos, intensificando sus estructuras y su cultura organizacional e incrementando el valor comercial de la empresa.
Los sistemas de información desempeñan tres papeles esenciales en cualquier tipo de organización:
Respaldar las operaciones empresariales. Respaldar la toma de decisiones gerenciales. Respaldar la ventaja competitiva estratégica.
c. Componentes de un sistema de información:
Un sistema de información depende de los recursos humanos (usuarios finales y especialistas en SI), hardware (maquinas, medios), software (programas y procedimientos), datos (bases de datos y de conocimiento) y redes (medios de comunicaciones y soporte de redes) para desempeñar actividades de entrada, procesamiento, salida almacenamiento y control que conviertan los recursos de datos en resultados de información.
d. Tipos de sistemas de información:
o Sistemas de apoyo a las operaciones:
Generan una variedad de productos de información para uso interno y externo, pero no hacen énfasis en la generación de los productos específicos de información que pueden ser utilizados de manera óptima por los gerentes. Consisten en procesar en forma eficiente las transacciones comerciales, respaldar las comunicaciones y actualizar las bases de datos corporativas. Se pueden subdividir en:
Sistemas de procesamiento de transacciones. Sistemas de control de procesos.
Sistemas de colaboración empresarial.
o Sistemas de apoyo gerencial:
Proporcionan la información y el respaldo necesarios para que los gerentes tomen decisiones efectivas. Las principales categorías son:
Sistemas de información gerencial. Sistemas de apoyo a las decisiones. Sistemas de información ejecutiva.
Existen también otras categorías de sistemas de información que pueden respaldar aplicaciones operacionales, gerenciales o estratégicas, entre las cuales están:
Sistemas expertos.
Sistemas de gerencia del conocimiento. Sistemas de información estratégica. Sistemas de información empresarial.
2.2.4 Desarrollo de Sistemas de Información:
2.2.4.1 El proceso de desarrollo de los sistemas:
El primer paso en el proceso de desarrollo de sistemas es la etapa de investigación de sistemas. Esta etapa puede abarcar la consideración de propuestas generadas por un proceso de planeación de sistemas de información, e incluye el estudio preliminar de soluciones propuestas con sistemas de información para problemas empresariales (O’Brien, 2001).
2.2.4.2 Estudios de factibilidad:
Consiste en un estudio preliminar que investiga las necesidades de información de usuarios potenciales y determina los requerimientos de recursos, los costos, los beneficios y la factibilidad de un proyecto propuesto (O’Brien, 2001). La meta de los estudios de factibilidad radica en evaluar sistemas alternativos y proponer los sistemas más factibles y deseables de desarrollo. La factibilidad de un sistema propuesto puede evaluarse en términos de cuatro categorías importantes:
Factibilidad organizacional: se centra en qué tan bien respalda un sistema de información propuesto los objetivos de la organización y su plan estratégico de sistemas de información. Por ejemplo, generalmente no se financian aquellos proyectos que no contribuyen directamente al logro de los objetivos estratégicos de la organización.
Factibilidad económica: tiene que ver con el hecho de si los ahorros esperados en costos, el incremento en los ingresos y en las utilidades, las reducciones en la inversión requerida y otros tipos de beneficios excederán los costos de desarrollar y operar un sistema propuesto. Por ejemplo, si un proyecto no puede cubrir sus costos de desarrollo, no será aprobado, a menos que sea ordenado por regulaciones gubernamentales o por otras consideraciones.
Factibilidad técnica: puede demostrarse si la empresa puede adquirir o desarrollar en el tiempo requerido el software y el hardware confiables capaces de satisfacer las necesidades de un sistema propuesto.
Factibilidad operacional: es la disposición y la capacidad de la gerencia, los empleados y los clientes, los proveedores y otros, para operar, utilizar y respaldar un sistema propuesto. Por ejemplo, si el software para un nuevo sistema es demasiado difícil de utilizar, es posible que los empleados cometan muchos errores y eviten su uso. De este modo, no se mostraría la factibilidad operacional.
o Análisis de costos/beneficios:
Si los costos y los beneficios pueden cuantificarse, estos se denominan tangibles; si no es así, reciben el nombre de intangibles. Ejemplos de costos tangibles son los costos de hardware y software, los salarios de los empleados y otros costos cuantificables necesarios para desarrollar e implementar una solución de SI. Los costos intangibles son difíciles de cuantificar; incluyen la pérdida de goodwill (buena voluntad) del cliente o la moral de los empleados, causadas por errores e interrupciones que surgen de la instalación de un nuevo sistema.
Los beneficios tangibles son resultados favorables, como la disminución en los costos de nómina generada por una reducción en personal o una disminución en los costos de tener
inventario, causados por una reducción en el inventario. Los beneficios intangibles son los mas difíciles de estimar. Tales beneficios como mejor servicio al cliente o información más rápida y exacta caen dentro de esta categoría. Los posibles costos tangibles e intangibles serian el opuesto de cada beneficio.
2.2.4.3 Análisis de los sistemas:
Se trata de un estudio a fondo de las necesidades de información de los usuarios finales, que genera los requerimientos funcionales que se emplean como la base para el diseño de un nuevo sistema de información (O’Brien, 2001).
Tradicionalmente, el análisis de sistema comprende un estudio detallado de:
Las necesidades de información de la organización y de usuarios finales.
Las actividades, los recursos y los productos de cualquier sistema de información actual.
Las capacidades de los sistemas de información que se requieren para satisfacer sus necesidades de información, y las de otros usuarios finales.
o Análisis organizacional:
Los miembros de un equipo de desarrollo deben saber algo sobre la organización, su estructura gerencial, su personal, sus actividades empresariales, los sistemas del entorno con los que debe tratar, y sus sistemas de información actuales. Alguien en el equipo debe saber esta información con mas detalle, con respecto a las unidades de negocio específicas o los grupos de trabajo de usuarios finales que se verán afectados por el sistema de información nuevo o mejorado que se esta proponiendo.
o Análisis del sistema actual:
Antes de diseñar un nuevo sistema, es importante estudiar el sistema que se mejorará remplazará (si existe). Se necesita analizar cómo este sistema utiliza los recursos de
hardware, software, redes y personal para convertir los recursos de datos –como datos sobre transacciones- en productos de información, como informes y presentaciones. Posteriormente, debe documentar como se logran las actividades de entrada, procesamiento, salida, almacenamiento y control de los sistemas de información.
o Análisis de los requerimientos funcionales:
Es posible que se requiera trabajar en equipo con analistas de sistemas y otros usuarios finales para determinar las necesidades específicas de información empresarial. Se debe tratar de determinar las capacidades de procesamiento de información requerida para cada actividad de sistemas (entrada, procesamiento, salida, almacenamiento, control), con el fin de satisfacer estas necesidades de información, la meta principal consiste en identificar qué debería hacerse, no cómo hacerlo.
Finalmente, se deben desarrollar requerimientos funcionales, que constituyen los requerimientos de información de usuarios finales que no estén ligados a los recursos de hardware, software, redes, datos y de personal que los usuarios finales actualmente utilizan o podrían utilizar en el nuevo sistema.
2.2.4.4 Diseño de los sistemas:
El análisis de sistemas describe lo que un sistema debería hacer para satisfacer las necesidades de información de los usuarios. El diseño de los sistemas especifica cómo logrará el sistema este objetivo. El diseño de sistemas consta de actividades de diseño que genera especificaciones de los sistemas que satisfacen los requerimientos funcionales desarrollados en la etapa de análisis de sistemas (O’Brien, 2001).
o Diseño de interfaz de usuario, de datos y procesos:
Diseño de interfaz de usuario: es el respaldo de las interacciones entre usuarios finales y sus aplicaciones que se basan en el computador. Los diseñadores se
concentran en el diseño de formas atractivas y eficientes de entrada y salida de usuarios. Es importante ser simple, ser claro y organizarlo en forma lógica.
Diseño de datos: se centra en el diseño de la estructura de bases de datos y archivos utilizados por un sistema de información propuesto. El producto del diseño de datos consiste en descripciones detalladas de los atributos o las características de las entidades (objetos, personas, lugares, eventos) sobre los cuales necesita mantener información el sistema de información propuesto; las relaciones que estas entidades tienen entre sí; los elementos de datos específicos (bases de datos, archivos, registros, etc.) que necesitan mantenerse para cada entidad rastreada por el sistema de información; las reglas de integridad que rigen la forma como cada elemento de dato es especificado y utilizado por el sistema de información.
Diseño de procesos: se centra en el diseño de recursos de software, es decir, los programas y procedimientos que necesita el sistema de información propuesto. Los diseñadores se centran en el desarrollo de especificaciones detalladas del software que tendrá que adquirirse o desarrollar mediante una programación a la medida para satisfacer las especificaciones de diseño de la interfaz de usuario y de datos, y los requerimientos funcionales desarrollados en la etapa de análisis. Debido al amplio uso de sistemas cliente/servidor, el diseño del proceso del software con frecuencia se expresa como una arquitectura de “tres niveles” de servicios de procesamiento:
Servicios de usuario. Servicios de aplicación. Servicios de datos.
2.2.4.5 Elaboración de prototipos:
Consiste en el desarrollo rápido y la prueba de modelos adecuados de nuevas aplicaciones en un proceso interactivo e iterativo que puede ser utilizado tanto por analistas de sistemas como por usuarios finales. La elaboración de prototipos hace que el proceso de desarrollo sea más rápido y más fácil para el analista de sistemas, en especial para proyectos donde los requerimientos del usuario final son difíciles de definir. Por tanto, la elaboración de prototipos algunas veces se denomina RAD. La elaboración de
