universidad de chile facultad de ciencias...

FELIPE ANDRES MUÑOZ GUERRA

PROFESOR GUÍA:

OSCAR BARROS VERA

MIEMBROS DE LA COMISIÓN:

EDUARDO CONTRERAS VILLABLANCA

CLAUDIO SALVATORE CONCHA

ERICK ZÚÑIGA ACUÑA

SANTIAGO DE CHILE

MAYO 2010

PLANIFICACIÓN, ASIGNACIÓN DE RECURSOS Y CONTROL DE

PROYECTOS DE LA DIVISIÓN GERENCIA DEL FONDO DE DESARROLLO DE LAS TELECOMUNICACIONES

PROYECTO DE GRADO PARA OPTAR AL GRADO DE MAGÌSTER EN INGENIERÌA DE NEGOCIOS CON TECNOLOGÌAS DE

INFORMACIÒN

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE INGENIERÍA INDUSTRIAL

RESUMEN DE LA MEMORIA PARA OPTAR AL GRADO DE MAGISTER DE INGENIERÍA DE NEGOCIOS CON TECNOLOGÍAS DE INFORMACIÓN POR: FELIPE A. MUÑOZ GUERRA FECHA: 3/05/2010 PROF. GUIA: Sr. OSCAR BARROS V.

“PLANIFICACIÓN, ASIGNACIÓN DE RECURSOS Y CONTROL DE

PROYECTOS DE LA DIVISIÓN GERENCIA DEL FONDO DE DESARROLLO DE LAS TELECOMUNICACIONES”

La complejidad cada vez mayor de los proyectos desarrollados en el área de

telecomunicaciones implica el uso de una gran cantidad de recursos, la coordinación de un número importante de individuos, el uso de tecnología de punta y la realización de numerosas y variadas actividades. Es por esta razón que la gestión debe estar fuertemente apoyada por metodologías y herramientas para la administración de proyectos que mejoren y faciliten por un lado la labor de manejo de los responsables de proyectos y, por otro lado, el desarrollo de las tareas por parte de los recursos especializados.

El objetivo del presente trabajo es diseñar una solución integral para la gestión de los

proyectos concursables generados por la División Gerencia del Fondo de Desarrollo de las Telecomunicaciones (DGFDT), que es la encargada de generar proyectos que busquen entregar un acceso universal, igualitario y no discriminatorio de la población a los servicios de telecomunicaciones.

El proyecto de rediseño está enfocado al estudio y la mejora de los procesos de

planificación de proyectos, asignación de recursos y control de tareas de la DGFDT, en la búsqueda de la eficiencia operacional y de la entrega de productos de mayor calidad.

Para lo anterior fue necesario desarrollar un prototipo funcional para la planificación y

control de proyectos, que apoye el manejo de proyectos por medio de una base de conocimientos sólida y del control del avance de cada tarea. Junto con esto el diseño de la solución toma en cuenta 2 estándares a nivel mundial para la administración de proyectos, como son las metodologías del PMI y el estándar CMMI, que son por demás complementarias.

En el diseño y desarrollo de la herramienta se utilizaron aplicaciones Open Source que

le dieran el carácter de una solución económica pero a su vez flexible para probables modificaciones o adaptaciones en diversas plataformas en caso de ser requerido.

El resultado final fue el diseño detallado de una solución que permite a grandes rasgos

planificar proyectos de telecomunicaciones, asignar recursos y realizar un seguimiento y control de estos proyectos dentro del ámbito de la DGFDT.

Se concluye que el trabajo desarrollado constituirá un aporte para la gestión de los

futuros proyectos de telecomunicaciones llevados a cabo por la DGFDT, entregando ahorros de esfuerzo, tiempo y costos en los diferentes procesos, entregando un apoyo directo a los encargados del manejo de los proyectos.

Dedicado a ti cosita mía

No dejes nunca de creer que todo es posible

Agradecimientos

Son tantas las personas que compartieron conmigo este proceso y a las que quisiera agradecer. Para todos aquellos que no menciono explícitamente va también mi más profundo agradecimiento.

Quisiera comenzar por agradecer a mis padres Verónica y Sergio, ya que gracias a ellos

me he convertido en la persona que soy y he podido conseguir con esfuerzo las metas que me he planteado. A mi hermana Javiera y a mi hermano Gabriel por estar siempre conmigo y alegrarme la vida cada vez que lo he necesitado.

Agradezco a toda mi familia, mis abuelas Pepa y Rita; mis abuelos Oscar y Gustavo; a

mis tías Lucía, Rita y Mallay; y a mis primos Gustavo, Jaime y Matías. Gracias a todos por ser un apoyo permanente y darme el ánimo de seguir adelante.

A Erick, porque más que un jefe ha sido un consejero y un amigo entregándome un apoyo esencial para mi desarrollo profesional y particularmente para la culminación de esta memoria.

A mis compañeros de trabajo y que más que eso han pasado a ser amigos, gracias por las demostraciones de afecto y de apoyo desde el primer día, haciéndome sentir inmediatamente acogido y entregándome consejos y ayuda día a día, por todo esto y más les estoy muy agradecido.

A mis amigos del magíster, por compartir junto conmigo esta gran experiencia de

desarrollo profesional y personal, gracias por su apoyo y ayuda durante todo este proceso. Agradezco al profesor Oscar Barros, que pese a su ajetreada agenda se dio el tiempo

para darme el consejo y apoyo necesarios para realizar con éxito este trabajo. De igual forma agradezco a Ana María por su apoyo en los temas administrativos así como en la motivación constante para que terminara con éxito el programa MBE.

Finalmente quiero agradecer a Margarita por adoptarme como a un hijo, entregándome

todo el cariño y apoyo, a Federico y Silvia, por recibirme desde el día uno con los brazos abiertos haciéndome sentir en casa y a las hermanas y hermanos de mi cosita por ser tan alegres y cariñosos conmigo, acercándome como parte de la familia.

.

Gracias a todos por su apoyo incondicional

I

Índice

Índice de Figuras V

Índice de Tablas VIII

Capítulo 1 Introducción 1

1.1. Motivación .................................................................................................................................. 1

1.2. Alcances ...................................................................................................................................... 3

1.3. Objetivo General ....................................................................................................................... 4

1.4. Objetivos Específicos................................................................................................................ 4 1.5. Situación Actual ......................................................................................................................... 5 1.6. Descripción del Informe ........................................................................................................... 7

Capítulo 2 La Organización 9

2.1. Subsecretaría de Telecomunicaciones ..................................................................................... 9 2.2. Fondo de Desarrollo de las Telecomunicaciones ............................................................... 11 2.3. División Gerencia del Fondo de Desarrollo de las Telecomunicaciones ........................ 12

2.3.2. Departamento de Ingeniería ..................................................................................... 14

2.4. Población Objetivo .................................................................................................................. 15

Capítulo 3 Modelo de Negocios 18

3.1. Producto .................................................................................................................................... 18 3.2. Clientes ...................................................................................................................................... 19 3.3. Propuesta de Valor .................................................................................................................. 20

3.3.1. Modelo de Negocios .................................................................................................. 20

3.3.2. Variables a Considerar ............................................................................................... 20

3.3.3. Beneficios Esperados ................................................................................................. 21

3.4. Análisis FODA ......................................................................................................................... 22 3.5. Factores Críticos de Éxito y Fracaso .................................................................................... 23 3.6. Cuantificación de Beneficios .................................................................................................. 23

II

3.7. Evaluación Financiera ............................................................................................................. 24 3.7.1. Costos Diseño y Desarrollo de un Proyecto tipo .................................................. 24

3.7.2. Costos del Desarrollo e Implementación de la Solución ..................................... 25

3.7.3. Flujo de Caja ............................................................................................................... 26

Capítulo 4 Marco Teórico 27

4.1. Proyectos de Instalación en Telecomunicaciones ............................................................... 27 4.1.1. Proyectos de Core (Núcleo) ..................................................................................... 27

4.1.2. Proyectos de Distribución ....................................................................................... 28

4.1.3. Proyectos de Acceso .................................................................................................. 29

4.1.4. Servicios Avanazados de Telecomunicaciones (NGN) ........................................ 31

4.1.5. Proyectos de Servicios de Valor Agregados ........................................................... 32

4.2. Tipificador de Proyectos de Instalación en el Area de Telecomunicaciones .................. 33 4.2.1. Familias de Proyectos ................................................................................................ 34

4.2.2. Criterios de Tipificación ............................................................................................ 38

4.3. Metodología PMI en la Gestión de Proyectos .................................................................... 41

4.3.1. Project Management (Dirección de Proyectos) ........................................................... 41 4.3.2. Progresos Metodológicos del Project Management .................................................... 41

4.4. Integración de Modelos para la Mejora de Procesos (CMMI) ......................................... 43

4.4.1. Niveles de Madurez y Capacidad ............................................................................. 44 4.4.2. Gestión de Proyectos ................................................................................................. 46

Capítulo 5 Metodología 48

5.1. Metodologia para el Diseño e Implementación de la Solución......................................... 48

5.1.1. Elementos de Diseño ................................................................................................ 49 5.1.2. Estructura del Diseño ................................................................................................ 61

5.2. Herramientas de Diseño e Implementación ........................................................................ 64 5.2.1. Framework Struts ....................................................................................................... 64 5.2.2. Herramienta para Modelado UML .......................................................................... 67 5.2.3. Plataforma del Servidor ............................................................................................. 67 5.2.4. Servidor de Aplicaciones J2EE ................................................................................ 67 5.2.5. Motor de Base de Datos ........................................................................................... 67 5.2.6. Aplicación para el Manejo de Cartas Gantt ............................................................ 67 5.2.7. Aplicación para la Formulación de Problemas de Programacion Lineal ........... 69 5.2.8. Aplicación para el Diseño y Ejecución de Flujos de Trabajo .............................. 69 5.2.9. Aplicación de Apoyo para Manejo de Contenidos................................................ 71 5.2.10. Configuración Definitiva de la Solución ................................................................. 73

Capítulo 6 Rediseño del Proceso de Negocios 74

6.1. Modelamiento del Rediseño de Procesos ............................................................................. 75

6.1.1. Gestión del Desarrollo de Proyectos ...................................................................... 77

6.1.2. Diseño Técnico, Construcción de Bases y Desarrollo de Concurso .................. 92

6.2. Proceso de Asignación de Técnicos .................................................................................... 103 6.2.1. Logica de Prioridad de Tareas ................................................................................ 103

6.2.2. Cálculo de Esfuerzo ................................................................................................. 103

III

6.2.3. Propuesta de Asignación de Recursos .................................................................. 103

6.3. Diseño de las Aplicaciones de Apoyo................................................................................. 106 6.3.1. Casos de Uso ............................................................................................................ 106

6.3.2. Diagramas de Secuencia y Secuencia Extendidos ............................................... 108 6.3.3. Modelo de Datos Físico .......................................................................................... 119

Capítulo 7 Construcción del Prototipo 122 7.1. Desarrollo del Prototipo para Planificación....................................................................... 122

7.1.1. Programación del Prototipo ................................................................................... 123

7.1.2. Estructura en XML de Carta Gantt en GanttProject ......................................... 125

7.2. Pantallas del Prototipo .......................................................................................................... 128

7.2.1. Ingreso de Proyectos ............................................................................................... 128

7.2.2. Plataforma para el Control de Proyectos ............................................................. 140

Capítulo 8 Implementación Organizacional 147

8.1. Gestión del Cambio ............................................................................................................... 147

8.2. Estrategia para la Gestión del Cambio ............................................................................... 151

8.3. Medición Evaluación y Cierre .............................................................................................. 153

Capítulo 9 Generalización 155

9.1. Aplicación del Framework.................................................................................................... 156

9.2. Construcción del Framework ............................................................................................... 158

9.3. Aplicación Particular ............................................................................................................. 160

Capítulo 10 Discusiones 161

10.1. Discusión “Planificación, Asignación de Recursos, Seguimiento y Control de Proyectos del Fondo de Desarrollo de las Telecomunicaciones” ................................................ 161

10.1.1. Planificación .............................................................................................................. 162

10.1.2. Asignación ................................................................................................................. 163

10.1.3. Control y Seguimiento ............................................................................................ 164 10.1.4. Diferencias con Soluciones Existentes ................................................................ 164

10.2. Discusión “Metodología PMI y Estándar CMMI” ........................................................... 167 10.2.1. Metodología PMI .................................................................................................... 167 10.2.2. Estándar CMMI ...................................................................................................... 169 10.2.3. Enfoques Alternativos ............................................................................................ 170

10.3. Discusión “Arquitectura de Procesos” ............................................................................... 170

10.4. Discusión “Prototipos de Planificación y Seguimiento Implementados” ..................... 171 10.4.1. Características Open Source ................................................................................... 172

10.4.2. Incorporación del Modelo de Tipificación ........................................................... 172

10.4.3. Conexión entre la Aplicación y GanttProject ..................................................... 173 10.4.4. Diseño de Pantallas e Interfaz de Usuario .......................................................... 174

IV

Capítulo 11 Conclusiones 175

11.1. Conclusiones Generales ........................................................................................................ 175

11.2. Limitaciones de la Solución .................................................................................................. 177

11.3. Recomendaciones Para Trabajos Futuros .......................................................................... 178

Referencias Bibliográficas 179

Acrónimos 183

Anexos 186 Anexo A: Procesos de Apoyo a Concursos ..................................................................................... 186

Anexo B: Ejemplos de Proyectos de la DGFDT ........................................................................... 189 Anexo C: Evolución de Proyectos Tipo de la DGFDT ................................................................ 196

Anexo D: Manual de Ususario Portal DGFDT.............................................................................. 200 Anexo E: Áreas de Conocimientos del PMI ................................................................................... 209 Anexo F: Gestión de Proyectos en el Estándar CMMI ................................................................. 214 Anexo G: Estándar BPMN ................................................................................................................ 221

Anexo H: Plataforma J2EE ............................................................................................................... 224

Anexo I: Tratamiento de Información XML .................................................................................. 228

V

Índice de Figuras

Figura 1 Estudios del Informe Chaos. 1 Figura 2 Descripcion del Proyecto de Memoria Desarrollado. 3 Figura 3 Hitos Principales hasta la Construcción de Bases. 6 Figura 4 Organigrama SUBTEL. 10 Figura 5 Organigrama División GFDT. 13 Figura 6 Componentes Principales del DI. 14 Figura 7 Secuencia de Actividades DI de un Proyecto Tipo. 14 Figura 8 Percepción de Cobertura Telefonía Móvil. 15 Figura 9 Penetración de Internet a Nivel Regional Rural. 16 Figura 10 Conexión de Internet a Nivel Nacional. 16 Figura 11 Acceso a TIC`s por Región. 17 Figura 12 Red de Núcleo. 28 Figura 13 Red xDSL. 29 Figura 14 Red WLAN. 30 Figura 15 Red UMTS. 31 Figura 16 Arquitectura Red NGN. 32 Figura 17 Proyectos de Instalación en Telecomunicaciones. 33 Figura 18 Red Backbone ATM. 36 Figura 19 Planta Externa. 36 Figura 20 Proyecto HFC. 37 Figura 21 Arquitectura IMS. 37 Figura 22 Progresos Metodológicos. 41 Figura 23 Mapa de Procesos del PMI. 42 Figura 24 Etapas de Evolución CMMI. 44 Figura 25 Áreas de Proceso para el Manejo Básico de Proyectos. 46 Figura 26 Áreas de Proceso para le Manejo Avanzado de Proyectos. 47 Figura 27 Metodología. 48 Figura 28 Áreas de Conocimiento del PMI a Considerar. 49 Figura 29 Elementos para la Planificación y Ejecución de Proyectos. 53 Figura 30 Elementos para el Monitoreo y Control de Proyectos. 53 Figura 31 Elementos para el diseño de Procesos. 58 Figura 32 Estructura Modular del Diseño de la Solución. 61 Figura 33 Relación de Elementos de Diseño con Módulo de Planificación. 62

VI

Figura 34 Relación de Elementos de Diseño con Módulo de Asignación. 63 Figura 35 Relación de Elementos de Diseño con Módulo de Seguimiento. 63 Figura 36 Funcionalidad Struts. 64 Figura 37 Funcionalidad Struts en Dealle. 65 Figura 38 Diagrama de Secuencia Struts. 66 Figura 39 Ejemplo de Herramienta GanttProject. 68 Figura 40 Patrón MVC de Joomla. 71 Figura 41 Arquitectura Joomla. 72 Figura 42 Resultados Obtenidos. 74 Figura 43 Macroprocesos. 75 Figura 44 Preparación y Ejecución de Concursos. 76 Figura 45 Gestión del Desarrollo de Proyectos. 77 Figura 46 Gestión y Planificación del Proyecto. 78 Figura 47 Elaboración de Cartera de Requerimientos. 79 Figura 48 Priorización. 80 Figura 49 Planificación de Tareas para el Diseño y Evaluación del Proyecto 81 Figura 50 Elaboración Ficha de Alcance y Obtención de Atributos. 82 Figura 51 Ingreso Nuevo Proyecto. 83 Figura 52 Definición de Tareas y Prioridades. 84 Figura 53 Decidir Asignación y Mejora Recurso. 85 Figura 54 Decidir Asignación Recursos. 86 Figura 55 Procesar Necesidades Tareas. 87 Figura 56 Obtener Lista Recursos Adecuados. 87 Figura 57 Asignar y dar Instrucciones a Recursos. 88 Figura 58 Determinar Esfuerzo por Tarea. 89 Figura 59 Asignar Recursos por Tareas. 90 Figura 60 Instrucciones Mejora Recurso. 90 Figura 61 Iniciar Ejecución del Proyecto. 91 Figura 62 Diseño Técnico, Construcción de Bases y Desarrollo de Concurso. 92 Figura 63 Diseño y Evaluación del Proyecto. 93 Figura 64 Obtención de Información de Entidades. 94 Figura 65 Diseño Técnico. 95 Figura 66 Justificación del Subsidio. 97 Figura 67 Bases. 98 Figura 68 Concurso. 100 Figura 69 Seguimiento. 102 Figura 70 Diagrama de Casos de Uso. 106 Figura 71 Diagrama de Secuencia de la Aplicación “Ingreso de Proyectos, Asignación y Control de Recursos”. 109 Figura 72 Diagrama de Secuencia “Ingreso de Nuevo Proyecto”. 110 Figura 73 Diagrama de Secuencia “Asignación de Prioridades”. 111 Figura 74 Diagrama de Secuencia “Obtención de Recursos Adecuados”. 112 Figura 75 Diagrama de Secuencia “Cálculo de Esfuerzo”. 113 Figura 76 Diagrama de Secuencia “Asignación Recursos a Tareas”. 114 Figura 77 Diagrama de Secuencia “Inicio Ejecución de Proyectos”. 115 Figura 78 Diagrama de Secuencia “Control Responsable”. 116 Figura 79 Diagrama de Secuencia “Control Jefe Proyectos”. 117 Figura 80 Diagrama de Secuencia “Control Técnico”. 118

VII

Figura 81 Diagrama de Clases Físicas. 119 Figura 82 Diagrama de Flujo Web del Prototipo. 123 Figura 83 Clases y Controladores del Prototipo. 124 Figura 84 Página de Inicio. 128 Figura 85 Ingreso de Nuevo Proyecto. 129 Figura 86 Selección de Criterios. 130 Figura 87 Estimación de la Cantidad de Recursos Requeridos. 131 Figura 88 Resumen. 132 Figura 89 Ingreso Exitoso. 133 Figura 90 Ver Proyectos Similares. 134 Figura 91 Cargar XML de Proyecto Similar. 135 Figura 92 Carta Gantt del Proyecto Similar 136 Figura 93 Buscar Proyectos Almacenados 137 Figura 94 Ver Proyectos Encontrados 138 Figura 95 Ver Lista de Proyectos Almacenados. 139 Figura 96 Página Principal Portal GFDT. 140 Figura 97 Menú de Gestión de Documentos. 141 Figura 98 Vista de Documentos Almacenados. 141 Figura 99 Menú Proyectos en Curso. 142 Figura 100 Ejemplo de Ver Tareas. 143 Figura 101 Ejemplo de Detalle de Tareas. 144 Figura 102 Ejemplo Editar Tareas. 145 Figura 103 Ejemplo de Gestor de Archivos. 146 Figura 104 Mapa de Poder. 150 Figura 105 Evolución Costos Procesos Diseño y Desarrollo Proyectos FDT. 154 Figura 106 Relaciones Estructura del Framework. 155 Figura 107 Framework Asignación de Recursos. 157 Figura 108 Diagrama de Clases Asignación. 158 Figura 109 Framework. 159 Figura 110 Diagramas de Clases de Control y Entity de la Aplicación. 160 Figura 111 Gestión Básica de Proyectos en las Etapas de Evolución del CMMI. 170 Figura 112 Procesos de Apoyo a Concursos. 186 Figura 113 Procesos de Ingreso, Manejo y Transferencia Recurso. 188 Figura 114 Gantt del Proyecto IDCI. 189 Figura 115 Gestión Documental (Downloads Home). 203 Figura 116 Gestión Documental. 205 Figura 117 Búsqueda de Documentos. 206 Figura 118 Cargar Documentos Paso 1. 206 Figura 119 Cargar Documentos Paso 2. 207 Figura 120 Cargar Documentos Paso 3. 207 Figura 121 Foro DGFDT. 208 Figura 122 Modelamiento de Procesos y Reglas de Negocio. 222 Figura 123 Uso de Símbolos de BPMN Seleccionados. 223 Figura 124 Relacion entre Capas y Framework J2EE. 225 Figura 125 Arquitectura Multi-capa con J2EE. 226

VIII

Índice de Tablas

Tabla 1 Análisis FODA. 22 Tabla 2 Costos del Proceso Pre-evaluación de la Solución Técnica. 24 Tabla 3 Costos del Proceso Diseño Técnico y Cálculo de Inversiones. 24 Tabla 4 Costos del Proceso Cálculo de Subsidio. 25 Tabla 5 Flujo de Caja. 26 Tabla 6 Característica Magnitud. 39 Tabla 7 Característica Naturaleza. 39 Tabla 8 Característica Tipo de Servicio. 40 Tabla 9 Elementos para la Planificación y Ejecución de Proyectos. 57 Tabla 10 Elementos para el diseño de Procesos. 61 Tabla 11 Características Generales de GanttProject. 68 Tabla 12 Beneficios de la Metodología PMI. 167 Tabla 13 Kilómetros de Tramos de Fibra Óptica por Región. 190 Tabla 14 Nivel de Cobertura del Proyecto por Región. 191 Tabla 15 Principales Hitos Proyecto IDCI. 191 Tabla 16 Cobertura del Proyecto Telefonía Móvil. 192 Tabla 17 Hitos Principales del Proyecto Telefonía Móvil. 193 Tabla 18 Tramos de Fibra Óptica por Localidad. 194 Tabla 19 Cobertura del Proyecto por Localidad. 194 Tabla 20 Hitos Principales Proyecto Localidades Intermedias Palena. 195 Tabla 21 Costos del Proceso de Estudio de Demanda Potencial IDCI I. 196 Tabla 22 Costos del Proceso Pre-evaluación de la Solución Técnica IDCI I. 196 Tabla 23 Costos del Proceso Diseño Técnico y Cálculo de Inversiones IDCI I. 197 Tabla 24 Costos del Proceso Cálculo de Subsidio IDCI I. 197 Tabla 25 Costos del Proceso de Estudio de Demanda Potencial Móviles II. 198 Tabla 26 Costos del Proceso Pre-evaluación de la Solución Técnica Móviles II. 198 Tabla 27 Costos del Proceso Diseño Técnico y Cálculo de Inversiones Móviles II. 198 Tabla 28 Costos del Proceso Cálculo de Subsidio Móviles II. 198 Tabla 29 Costos del Proceso Pre-evaluación de la Solución Técnica Rutas Antofagasta. 199 Tabla 30 Costos del Proceso Diseño Técnico y Cálculo de Inversiones Rutas Antofagasta. 199 Tabla 31 Costos del Proceso Cálculo de Subsidio Rutas Antofagasta. 199

1

Capítulo 1 Introducción 1.1 Motivación

En la actualidad dada la gran cantidad de proyectos en desarrollo en las diferentes ramas de la ingeniería, particularmente para el área de telecomunicaciones, y debido a la complejidad de estos en cuanto a la cantidad de recursos a utilizar, el número de tareas a desarrollar (y la duración de las mismas) y los altos costos asociados, motivan la búsqueda de una gestión eficiente de los proyectos como un factor muy importante a considerar por las empresas para llevar a adelante con éxito la planificación y ejecución de cada proyecto.

Existe un estudio que precisamente apunta a cuantificar qué tan eficiente es actualmente el

desarrollo y ejecución de proyectos en el mundo, el Informe Chaos o The Chaos Report [50], en el cual se entrega cada 2 años el escenario que enfrentan los proyectos en general, existiendo para ello una clasificación de los proyectos dependiendo si éstos fueron realizados dentro del tiempo y con el presupuesto planificado, o si los proyectos fueron efectivamente completados pero fuera de los plazos definidos, con un aumento de los costos propuestos, y probablemente con modificaciones en las características de ellos , o finalmente están aquellos proyectos que simplemente fueron cancelados durante su ejecución 1.

0%

10%

20%

30%

40%

50%

60%

Exitosos 26% 28% 34% 29% 35% 32%

Fallidos 28% 23% 15% 18% 19% 24%

Completados 46% 49% 51% 53% 46% 44%

1998 2000 2002 2004 2006 2009

Figura 1: Estudios del Informe Chaos2.

1 El estudio de The Chaos Report cubre más de 60000 proyectos. 2 El gráfico corresponde a los resultados del informe Chaos y que aparecen en Trends Report 2009.

2

Se puede apreciar que en el último estudio (año 2009) los proyectos que sobrepasaron los plazos y el presupuesto (Completados) y aquellos que fueron simplemente cancelados (Fallidos), suman el 68% de los proyectos realizados, lo que representa un potente indicador para motivar cada vez más al desarrollo de iniciativas que apunten a solucionar los problemas de planificación y gestión de los proyectos. En particular los proyectos de telecomunicaciones no son ajenos a estos problemas, y que se ven incrementados por las dificultades permanentes del desarrollo de nuevas tecnologías que incorporan variables de riesgo e incertidumbre en la implementación de nuevos proyectos.

Una estadística del mismo informe Chaos indica que para los proyectos TIC3 cerca del 44%

de los proyectos sobrepasa los plazos definidos inicialmente en casi la mitad del tiempo y el presupuesto inicial, mientras que un 24% fracasan y tan solo un 32% tienen éxito.

Es aquí donde toma fuerza la necesidad de buscar herramientas y metodologías que apoyen

el desarrollo de proyectos desde su inicio hasta su cierre, considerando en particular la información existente respecto a desarrollos anteriores de proyectos, que como se puede inferir de los resultados del informe Chaos, existe mucha información disponible.

Es por esta razón que una metodología que recoja los conocimientos y experiencia de

Proyectos de Telecomunicaciones previamente desarrollados determinando tanto sus aciertos como sus fallas puede permitir lograr el éxito del desarrollo futuro de estos proyectos.

Junto con esto es necesario considerar la condición de recurso escaso que se presenta irremediablemente en toda empresa debido a las variaciones que existen entre períodos de gran cantidad de desarrollo de proyectos y los de bajo desarrollo, con lo cual se tiene un número de recursos razonable que cubra correctamente ambos escenarios, de manera de no tener demasiado recurso ocioso, ni una falta de recursos excesiva. Con esto se tiene un número limitado de recursos que debe ser eficientemente utilizado de manera de optimizar el desarrollo de los distintos proyectos en los que se desempeña cada recurso.

De esta forma es esencial determinar una manera de asignar los recursos disponibles lo más óptimamente posible de acuerdo a características tanto del proyecto como del recurso mismo, como por ejemplo: especialidad y habilidades del recurso, nivel de experiencia, estado de ocupación (tanto actual como futuro), tareas a desarrollar, nivel de dificultad (o esfuerzo) de cada tarea, duración de cada tarea, etc.

Por otro lado es gran ayuda tener un control adecuado de cada proyecto que entregue un acceso expedito tanto a los jefes de proyecto, como al responsable general de proyectos, y a los recursos asignados a dichos proyectos, de manera tal que puedan interactuar entre ellos comunicando los grados de avance de cada tarea, o siendo avisados en caso de un atraso en alguna tarea, o de nuevos requerimientos del proyecto, entre otros. Esto permite la gestión integral de un proyecto con lo cual disminuye considerablemente la posibilidad de sorpresas desagradables durante su desarrollo, debido a demoras, problemas con los recursos, aumento excesivo de los costos, etc.

3 Tecnologías de Información y Comunicaciones

3

1.2 Alcances

El presente trabajo consiste en el rediseño de los procesos de “gestión del desarrollo de proyectos” y “diseño técnico, construcción de bases y desarrollo de concurso” para la División Gerencia del Fondo de Desarrollo de las Telecomunicaciones (DGFDT), área dependiente de SUBTEL4, y que en pocas palabras busca:

“Optimizar el manejo de recursos por medio de un sistema de planificación, asignación y gestión de recursos que simplifique el ingreso de nuevos proyectos de telecomunicaciones y la coordinación de recursos durante el desarrollo de dichos proyectos”.

La importancia de este trabajo de tesis radica en la idea de desarrollar un sistema eficiente capaz de apoyar tanto al responsable de proyectos como a los jefes de los proyectos respectivos y por ende mejorar la coordinación con los recursos encargados de llevar a cabo cada proyecto, logrando una disminución en los tiempos de planificación, diseño y evaluación de proyectos, construcción de bases, disminución de costos, entre otros.

El problema a resolver considera el mejorar el desarrollo de proyectos y que entregan como resultado final bases para concursos y qué es lo que ven los clientes, esto con el fin de optimizar los tiempos de ocupación de cada recurso, disminuir los costos de cada proyecto y concurso, etc. Lo anterior será resuelto por medio de la gestión integral de cada proyecto y de los proyectos en su conjunto, optimizando la asignación de recursos a cada proyecto, recuperando la información de aquellos anteriormente realizados y facilitando la gestión de cada proyecto en curso.

La solución propuesta administra los recursos de la mejor forma posible, generando una interacción entre todos los involucrados, desde los Técnicos, los Jefes de Proyectos, y por supuesto el Responsable de los proyectos.

Figura 2: Descripción del Proyecto Desarrollado

4 Subsecretaría de Telecomunicaciones de Chile

4

1.3 Objetivo General

El presente trabajo busca inicialmente identificar y rediseñar los procesos desarrollados al interior de la DGFDT particularmente en lo que respecta a la planificación e ingreso de proyectos y al control de tareas a lo largo del desarrollo de cada proyecto. Para esto es necesario recopilar y analizar toda la información relevante al manejo de proyectos, para lo cual se utilizará entre otras cosas un modelo tipificador de proyectos de instalación en el área de telecomunicaciones que permita efectuar una gestión del conocimiento histórico de proyectos con el fin de apoyar proyectos futuros, considerando también las metodologías y estándares existentes para el correcto manejo de proyectos, como son los entregados por el PMI5, por intermedio del PMBOK6, y el CMMI7.

Todo lo anterior con el fin de diseñar e implementar una solución integral para la gestión

de proyectos de telecomunicaciones de la DGFDT, que permita la utilización de la experiencia aplicada en proyectos anteriores, una asignación experta de recursos y un control exhaustivo del avance de cada tarea por parte de el (los) recurso(s) respectivo(s).

1.4 Objetivos Específicos

Identificar los procesos existentes en la DGFDT y potenciales rediseños.

Familiarizarse con los proyectos de telecomunicaciones desarrollados al interior de la DGFDT, y particularmente con las características de los proyectos definidos en el modelo tipificador y que corresponden a proyectos de Core, Distribución, Acceso, NGN8, e Infraestructura.

Facilitar la creación e ingreso de un nuevo proyecto de telecomunicaciones a la DGFDT por parte del responsable y de los jefes de proyectos.

Utilizar la información de proyectos de telecomunicaciones anteriores para simplificar el desarrollo de futuros proyectos. Todo esto con el fin de utilizar la información de problemas presentados y soluciones encontradas por los encargados de las tareas que conforman cada proyecto y reutilizarla en desarrollos futuros.

Optimizar la asignación de recursos a los distintos proyectos para evitar el “recurso ocioso”, maximizando la cantidad de proyectos desarrollados y minimizando los tiempos de implementación.

Desarrollar un prototipo funcional que permita poner a prueba el diseño realizado particularmente para los procesos de planificación y control de tareas.

5 Project Management Institute 6 Project Management Book Of Knowledge 7 Capability Maturity Model Integration 8 Next Generation Network o Redes de Nueva Generación.

5

1.5 Situación Actual

En la actualidad el proceso de planificación de proyectos, asignación de los recursos necesarios para llevar a cabo las diferentes tareas, y finalmente el control de las mismas, es manejado manualmente por el Jefe de Departamento de Ingeniería a través de una planilla Excel y de su experiencia y conocimiento de cada uno de los recursos de los que dispone.

Una vez que llegan los requerimientos y las instrucciones de la autoridad, éstos son

plasmados en una ficha de alcance que permite consolidar toda la información referente a la solicitud a abordar, y que dependiendo de su naturaleza y de las decisiones principalmente políticas, puede transformarse o no en un posible concurso.

Recogidos los aspectos principales de la solicitud, se toman las acciones necesarias, y que

pueden ir desde un estudio de factibilidad técnica y económica, hasta el desarrollo de un concurso que implica el diseño de una solución técnica, la evaluación económica del proyecto y un posterior cálculo de subsidio, la construcción de bases y el llamado a concurso, entre los puntos más destacables.

Es en el punto anterior donde se construye una carta Gantt de las tareas a realizar, siendo importante recalcar que no es hecha para todos los requerimientos sino para aquellos que desencadenan un concurso, la cual tiene como fechas principales las definidas inicialmente por la autoridad y el cliente (Subsecretario y CDT9), y que son principalmente:

La Publicación de las Bases del Concurso: Las bases son publicadas en la página web de Subtel, con la finalidad de que las empresas la estudien y, aquellas interesadas, entreguen una propuesta de acuerdo a lo estipulado en éstas.

Consultas y Respuestas: Período en el cual se reciben y responden todas las preguntas de las empresas que puedan estar interesadas en concursar y que tienen dudas respecto a algunos de los artículos o Anexos incorporados en las Bases del concurso.

Recepción de Propuestas y Acto de Apertura: Fecha límite para recibir las propuestas de las empresas interesadas en el concurso y acto oficial en el cual se abren públicamente las propuestas en presencia de las empresas postulantes, determinándose si cumplen con las exigencias administrativas y legales mínimas para postular.

Teniendo las fechas límite anteriores en consideración, particularmente la fecha de

publicación de las Bases, se definen ciertos hitos principales, con sus respectivas fechas de entrega, y que están dados por la interacción existente al interior de la DGFDT entre sus dos áreas principales:

9 Consejo de Desarrollo de las Telecomunicaciones

6

El Departamento de Ingeniería (DI)

La Unidad de Gestión de Proyectos (UGP)

Los hitos mencionados anteriormente constan de la entrega de información y documentos de un área a la otra, esto con el fin de llevar a cabo todo el proceso de diseño y evaluación del proyecto hasta llegar a la construcción de las Bases. Estos se muestran en la figura a continuación:

Figura 3: Hitos Principales hasta la Construcción de Bases

7

Es sobre estos hitos que se definen una serie de tareas más específicas tendientes a abordar cada uno de los subtemas que componen finalmente cada uno de entregables que considera el hito. La tarea particular de definir cuáles serán las tareas a desarrollar y que recursos serán los encargados de cumplirlas son tanto el Jefe del Departamento de Ingeniería, como el Coordinador de la Unidad de Gestión de Proyectos y está sujeta al conocimiento que tenga cada uno de ellos en los recursos de los que dispone y la experiencia de poder estimar cuánto podría tardar cada recurso designado en realizar una tarea determinada.

El conocimiento de los proyectos desarrollados, es decir, toda la experiencia adquirida

durante el desarrollo de cada proyecto, no queda completamente plasmado en los documentos realizados, esto pues está en el “kow how” de cada individuo, y no se cuenta con una gestión centralizada del conocimiento, perdiéndose de esta manera la valiosa oportunidad de rescatar toda esta experiencia y hacerla parte de la organización en su conjunto, transmitiéndola a los nuevos recursos que se integren a ésta, simplificando enormemente la tarea de preparación y aprovechamiento de los recursos.

1.6 Descripción del Informe

A modo de estructuración del presente documento se muestra a continuación una breve descripción de cada uno de los capítulos que conforman el trabajo realizado, incluyendo las ideas más relevantes en cada caso:

El Capítulo 1 describe las motivaciones para la realización del proyecto de tesis, nombrando los elementos principales de un manejo de proyectos donde caben por supuesto los de Telecomunicaciones. Se enuncian los objetivos generales y específicos del trabajo de tesis y la descripción general del documento realizado.

El Capítulo 2 muestra brevemente las características de la organización en la que se

subscribe el trabajo de tesis realizado. Se entrega un contexto que va desde el organismo central (SUBTEL) hasta la División y área inicial en la que será implementado el prototipo.

El Capítulo 3 trata del modelo de negocios definido para el presente proyecto, y que

permitirá entender como la solución propuesta debería abordar el problema en cuestión y apoyar de la mejor manera posible a la organización.

El Capítulo 4 considera los conceptos, teorías e información respecto a proyectos de instalación en el área de telecomunicaciones, describiéndose un método de tipificación para dichos proyectos. Junto con lo anterior se estudian las metodologías del PMI para el correcto manejo de proyectos y que son complementadas con el estándar CMMI que define entre otras cosas los factores a tomar en cuenta para un manejo óptimo.

8

El Capítulo 5 abarca la metodología empleada para el diseño e implementación de la solución propuesta. Se estructura la forma en la que se diseñará la solución, considerando en que medida aportan las metodologías, estándares y la teoría de procesos al diseño final y como se relacionan entre ellos. Además se describen las herramientas de diseño e implementación a utilizar.

En el Capítulo 6 se entregan los resultados obtenidos del rediseño de los procesos de negocio, describiéndose en detalle el modelamiento del rediseño de los procesos de la organización en que se enmarca la solución, también se describen las lógicas relevantes para el proceso de asignación de recursos, la descripción del diseño en UML10 de la herramienta.

En el Capítulo 7 se detalla el desarrollo del prototipo y la visualización gráfica de éste. El Capítulo 8 se refiere al proceso de implementación de la solución diseñada al interior de

la DGFDT, con todo lo que conlleva el cambio propuesto y que va desde la metodología de trabajo hasta un cambio de mentalidad de la organización respecto al aprovechamiento de herramientas y soluciones que buscan optimizar el desarrollo de sus procesos.

En el Capítulo 9 se describe la generalización de los procesos y la solución propuesta, con

la finalidad de construir un framework que permita desarrollar soluciones genéricas y a la vez particulares, para organizaciones distintas pero con problemáticas comunes y que puedan ser abordadas por este tipo de soluciones.

El Capítulo 10 detalla las discusiones respecto a solución entregada, y que considera desde el diseño de la arquitectura de procesos generada, los métodos y lógicas para la asignación de recursos, metodologías y estándares utilizados, el prototipo funcional desarrollado y la implementación dentro de la organización.

En el Capítulo 11 se efectúan las conclusiones obtenidas del trabajo realizado, en las que se consideran los resultados finales de la solución diseñada e implementada, así como el prototipo de la herramienta desarrollada, sus limitaciones y algunas recomendaciones para futuros trabajos que continúen con esta línea de investigación.

Los Anexos muestran una descripción más detallada de algunos de los temas tratados en el presente trabajo.

10 Unified Modeling Language o Lenguaje Unificado de Modelación

9

Capítulo 2 La Organización 2.1 SUBTEL

La Subsecretaría de Telecomunicaciones, SUBTEL, es un organismo dependiente del Ministerio de Transportes y Telecomunicaciones. Su trabajo está orientado a coordinar, promover, fomentar y desarrollar las telecomunicaciones en Chile, transformando a este sector en motor para el desarrollo económico y social del país.

Tiene como principales funciones proponer las políticas nacionales en materias de telecomunicaciones, de acuerdo a las directrices del Gobierno, ejercer la dirección y control de su puesta en práctica, supervisar a las empresas públicas y privadas del sector en el país, controlando el cumplimiento de las leyes, reglamentos y normas pertinentes.

La Política de Telecomunicaciones se apoya en los siguientes principios básicos:

Compromiso del Estado con el acceso universal, igualitario y no discriminatorio de la población a los servicios de telecomunicaciones, a través del ejercicio de su rol subsidiario como garantía para los sectores rurales, aislados y marginados.

Reconocimiento de la libertad de emprendimiento y de los privados como los agentes naturales de inversión en el sector.

Ejercicio activo del rol promotor del Estado en relación con la introducción de nuevas tecnologías, servicios y aplicaciones.

Reconocimiento de la fuerte globalización y exposición a los mercados mundiales que se enfrenta la economía y el pueblo chileno.

2.1.1 Misión

Ser un servicio público de excelencia que contribuya en forma decisiva y permanente al éxito de las políticas de gobierno, en el ámbito de las tecnologías de Información y Comunicación.

10

2.1.2 Visión

Promover el acceso equitativo a las tecnologías de información y comunicación, aumentar la competitividad del mercado y asegurar la debida protección de los usuarios de los servicios de telecomunicaciones, favoreciendo con ello una mayor igualdad de oportunidades, el desarrollo económico, social y cultural del país y el incremento de la calidad de vida de las chilenas y chilenos.

2.1.3 Objetivos Estratégicos

Los objetivos estratégicos de SUBTEL son:

1) Contribuir a masificar el acceso a las redes y servicios de telecomunicaciones a través

de la política de acceso universal permitiendo extender de manera equitativa el uso y la aplicación de las Tecnologías de Información y Comunicación en Chile.

2) Proteger los derechos de los usuarios, realizando las acciones de difusión necesarias que permitan el acceso libre e informado a los servicios de telecomunicaciones disponibles en el país, fiscalizando el cumplimiento de las normas, estándares y contratos para una correcta operación del mercado.

3) Crear, modificar, actualizar y simplificar el marco normativo necesario para que el sector Telecomunicaciones se desarrolle, aumentando el acceso a redes y servicios, en un ambiente de competencia, que fomente la introducción de nuevas tecnologías y servicios.

4) Fortalecer la gestión institucional, incorporando tecnología y nuevos sistemas de gestión que permitan implementar la mejora continua de los procesos, entregando los bienes y servicios en forma eficiente y oportuna de manera de brindar un servicio de calidad a los ciudadanos.

2.1.4 Organigrama

Figura 4: Organigrama SUBTEL

11

2.2 FDT

El FDT es un instrumento financiero del Gobierno de Chile que tiene por objeto promover el aumento de la cobertura de servicios de telecomunicaciones en áreas rurales o urbanas de bajos ingresos, con baja o nula disponibilidad de estos servicios debido a la inviabilidad económica de ser atendidas por parte de la industria nacional de telecomunicaciones. En términos legales, el Fondo de Desarrollo de las Telecomunicaciones se concretó el año 1994 tras la modificación y promulgación del Título IV de la Ley General de Telecomunicaciones, N° 18.168, con la que se crea el Fondo.

Junto con lo anterior, normativamente el FDT se encuentra regulado por el Reglamento

del Fondo de Desarrollo de las Telecomunicaciones. Junto con dicha normativa, también forma parte integrante de esta estructura jurídica la Ley de Presupuesto de la Nación, que establece el monto anual de recursos disponibles para el financiamiento de los subsidios.

EL FDT aborda el primer objetivo estratégico relacionado con la labor realizada por

SUBTEL. El FDT, no ejecuta directamente los proyectos que diseña, sino que los adjudica mediante

concursos públicos a las empresas e instituciones, que satisfacen las condiciones y obligaciones para con la comunidad y el Estado, de los servicios detallados en las bases de dichos concursos, aportando al adjudicatario los recursos necesarios para sostener estos esfuerzos en el tiempo.

El FDT representa un compromiso financiero compartido entre el Estado y las empresas

de Telecomunicaciones, las que optan a subsidios a cargo al presupuesto nacional. Por lo tanto, se puede decir que se trata de una forma de subsidio a la oferta de servicios.

2.2.1 Administración

El Fondo es administrado por el "Consejo de Desarrollo de las Telecomunicaciones", integrado por: a) El Ministro de Transportes y Telecomunicaciones, quien lo preside; b) Los Ministros de Economía, Fomento y Reconstrucción, de Hacienda y de Planificación y Cooperación, o sus representantes; c) Tres profesionales con experiencia en el área de telecomunicaciones y vinculados a las diversas regiones del país que son designados por el Presidente de la República; d) El Secretario Ejecutivo del Consejo es el Subsecretario de Telecomunicaciones, quien tendrá a su cargo las actas de las sesiones y la calidad de ministro de fe.

12

2.2.2 Marco Normativo Aplicable

El marco normativo del Fondo de Desarrollo de las Telecomunicaciones lo constituyen, principalmente:

1) Ley Nº19.724 del 25/04/2001. Reemplaza el título IV de la Ley General de

Telecomunicaciones.

2) Ley Nº19.302 del 09/03/1994. Introduce modificaciones a la Ley General de Telecomunicaciones.

3) Decreto Nº353 del 02/08/2001. Aprueba Reglamento del FDT.

4) La Ley de Presupuesto de la Nación. Que establece el monto del subsidio anual

para el FDT.

2.2.3 Procedimiento

La estructura de funcionamiento y recepción de requerimientos susceptibles de ser concursados por el FDT, se fundamenta en las solicitudes de servicios de telecomunicaciones que se reciben, a través de los Asesores Regionales de la División Gerencia del Fondo de Desarrollo de las Telecomunicaciones, ubicados en las 15 regiones del país. Dichos requerimientos o demandas de conectividad, son efectuados por concesionarios de servicios de telecomunicaciones, municipalidades, juntas de vecinos y otras organizaciones sociales y comunitarias o terceros, a partir de la cual se elabora la cartera de proyectos (requerimientos), que es evaluada técnica y socialmente por la División Gerencia FDT de SUBTEL, y a partir de la cual se elaboran las propuestas que se elevarán al Consejo de Desarrollo de las Telecomunicaciones (CDT) para, de ser aprobadas, pasar a formar parte de los proyectos subsidiables, y que serán llamados a concurso público durante el año siguiente.

2.3 DGFDT

La DGFDT, surge a principios del año 2008 a partir de un proceso de reestructuración realizado por el Subsecretario de Telecomunicaciones, con miras a concentrar en la forma de una sola división, a los distintos actores de SUBTEL que tenían injerencia en el diseño y coordinación de los proyectos subsidiables del Fondo de Desarrollo de las Telecomunicaciones.

Es así como desaparece la denominada División Acceso Universal a la Sociedad de la

Información (AUSI), para ser reemplazada por la División Gerencia Fondo de Desarrollo de las Telecomunicaciones. De esta forma, la nueva de División queda conformada por el Departamento de Ingeniería y la Unidad de Gestión de Proyectos.

Las distintas Divisiones de SUBTEL cumplen un rol activo en algunas de las actividades o

tareas ligadas al seguimiento y puesta en marcha de los concursos ejecutados por la División GFDT.

13

Las Divisiones de SUBTEL forman parte del proceso para la implementación de los

proyectos subsidiados por el Fondo, en las siguientes tareas:

División Jurídica: participa en la visación de las bases de los concursos realizadas por la División GFDT.

División Concesiones: es la División encargada de generar y tramitar los decretos de concesión y permisos para las empresas de telecomunicaciones, incluidas aquellas que hayan sido adjudicatarias de algún concurso público del FDT.

División Fiscalización: es la División encargada de realizar la recepción de obras de las empresas de telecomunicaciones, incluidas las obras realizadas por empresas adjudicatarias de concursos del FDT. Además, recibe los reclamos y denuncias por incumplimiento de obligaciones de prestación de servicio, tanto para las empresas de telecomunicaciones en general como para aquellas que presten servicio subsidiado a través del FDT.

División Política Regulatoria: es la División que entrega información relevante para la elaboración de los anexos técnicos para las bases de los concursos del FDT (ejemplo: disponibilidad de uso de espectro radioeléctrico)

División Administración y Finanzas: es la División encargada de gestionar los pagos de los subsidios a las empresas adjudicatarias de los concursos del FDT, de acuerdo a lo establecido en las bases de cada concurso.

2.3.1 Organigrama

Figura 5: Organigrama División GFDT

14

2.3.2 Departamento de Ingeniería

A continuación se muestran los componentes principales que conforman al DI, y que van desde a qué corresponde el equipo multidisciplinario y cuáles son las tareas más relevantes del las que se encarga el departamento en lo que respecta al diseño y evaluación de los proyectos que lleva a cabo la DGFDT:

Figura 6: Componentes Principales del DI

Tomando como referencia un proyecto estándar desarrollado por el departamento, es posible vislumbrar las siguientes actividades secuenciales y que cada una desencadena un resultado particular que es utilizado como insumo ya sea para la actividad siguiente como para una actividad que deberá ser desarrollada por la UGP la cual entregará un resultado que será utilizado nuevamente como insumo en este set de actividades (ver también Figura 3: Hitos Principales para la Construcción de Bases).

Figura 7: Secuencia de Actividades DI de un Proyecto Tipo

15

2.4 Población Objetivo

Tal y como se menciona en la descripción del FDT, la población objetivo corresponde a la

de zonas rurales o urbanas de bajos ingresos, y que precisamente por sus características (lejanía de las zonas urbanas, dificultades de acceso, alto costo de instalación, baja densidad poblacional, entre otras) requieren de proyectos de conectividad de telecomunicaciones que permitan mejorar en parte su calidad de vida. Pero para comprender estos segmentos es necesario contar con estudios que permitan explicar cuál es su comportamiento.

A continuación se muestran algunos resultados obtenidos de un trabajo realizado de

manera conjunta entre la Universidad de Chile y la GFDT en el marco del estudio “Evaluación económica y social de los proyectos de la cartera subsidiable de proyectos del FDT 2008” [32]:

2.3.1 Telefonía Móvil

El 88% de los hogares encuestados a nivel nacional declaran tener al menos 1 teléfono móvil.

Figura 8: Percepción de Cobertura Telefonía Móvil

En general, los clientes tienen una percepción positiva sobre el servicio de Telefonía Móvil, a nivel nacional el 82% declara tener cobertura “siempre”.

La zona del Norte Grande es la que presenta una peor percepción, donde el 25% de los

encuestados declara tuna percepción de tener cobertura “a veces” e incluso el 3% de los encuestados declara no tener cobertura nunca.

16

2.3.2 Acceso a Internet

Figura 9: Penetración de Internet a Nivel Regional Rural

Del total de familias encuestadas que declara poseer Internet en su hogar, la mayoría contrata un servicio a través de una empresa (siendo está opción la del 89% de los encuestados).

Figura 10: Conexión de Internet a Nivel Nacional

17

Se puede observar de la figura que el 86% de los hogares rurales, se caracterizan por no

contar con una conexión a internet en sus hogares. A nivel nacional, las personas que no cuentan con Internet en el hogar declaran no tener

un PC como primera razón con un 37,7% de las preferencias, seguido por la razón de encontrarlo un servicio caro.

2.3.3 Acceso a TIC`s

Figura 11: Acceso a TIC por Región.

De la figura se aprecia que la Telefonía Móvil es el servicio que alcanza los mayores niveles de penetración, superando el 80% en la ruralidad (a excepción de la Región de Magallanes cuya penetración es de 78%).

Tan sólo el 31% de los hogares a nivel nacional declara tener teléfono fijo en su hogar

versus la penetración observada para el caso de la telefonía móvil; por lo que se desprendería que el efecto de la sustitución del teléfono móvil por el teléfono fijo también es una realidad en la ruralidad.

De los hogares encuestados, sólo el 14% de ellos declara tener acceso a internet en su

hogar.

18

Capítulo 3 Modelo de Negocios

En el siguiente capítulo se analizaran las diferentes variables que componen el modelo de negocios propuesto, tomando en cuenta la búsqueda de mejorar y optimizar el diseño y evaluación de cada proyecto y por consecuencia la elaboración de las Bases de Concurso.

3.1 Producto

El producto final entregado a los clientes corresponde a las bases publicadas y sus modificaciones y que contempla:

- Comprende las Bases Publicadas subidas al sitio Web de SUBTEL y el llamado en el Diario Oficial los días 1 ó 15 de cada mes.

- El Informe de Respuesta a las Consultas formuladas a las Bases. Se realiza la publicación de las respuestas en la página Web de SUBTEL.

- En el caso de que las Respuestas a las Consultas impliquen una modificación sustancial

a las Bases, la Autoridad puede tomar la decisión de elaborar y publicar en la página Web de SUBTEL, un texto refundido. A su vez se publica un aviso de modificación de las Bases en el Diario Oficial.

- Asimismo, la Autoridad puede determinar cambios a las Bases con posterioridad a la publicación del informe de respuesta a las consultas, ante lo cual se publicará en el Diario Oficial y la publicación en el sitio Web de SUBTEL.

Para la construcción de las Bases de cada concurso se requiere de una serie de insumos que

son incorporados al proceso de elaboración de las mismas, proceso que se resume en la Figura 3: Hitos Principales de la Construcción de Bases.

19

3.2 Clientes

Para el producto anteriormente descrito se tienen los siguientes clientes directos:

- Gobiernos Regionales (GORES)

Entregan el listado de requerimientos a nivel regional

Generan un ranking de las localidades que son más prioritarias y que ayuda a construir, luego de otros filtros adicionales, el listado definitivo de localidades a beneficiar.

Entregan parte del subsidio a entregar en cada concurso.

- Consejo de Desarrollo de las Telecomunicaciones (CDT):

Aprueba la cartera de requerimientos a ser desarrollada

Aprueba los llamados a concurso que realizará el fondo a través de la División Gerencia del FDT.

Aprueba la adjudicación de los proyectos a las personas jurídicas que son recomendadas por la Comisión de Evaluación.

- Subsecretario de Telecomunicaciones

Corresponde al Secretario Ejecutivo del Consejo, quien tendrá a su cargo las actas de las sesiones y la calidad de ministro de fe.

- Otras Instituciones

Otras instituciones (públicas o privadas) que pueden solicitar el desarrollo de un proyecto en particular, y que con posterior evaluación de la autoridad puede ser o no llevado a cabo a través del FDT o vía una modalidad diferente.11

11 La modalidad puede corresponder a un traspaso de recursos hacia el FDT el cual posteriormente hace entrega de dichos recursos como un subsidio para el desarrollo del concurso.

20

3.3 Propuesta de Valor

3.3.1 Modelo de Negocios

Presentar una solución completa e integral que permita desarrollar diseños, evaluaciones de proyectos y la construcción de bases en forma rápida, eficiente, y cada vez con un mayor grado de consistencia y solidez, entregando de esta forma satisfacción a los clientes.

Para poder cumplir adecuadamente con lo estipulado en el diseño de la estrategia, es de vital importancia que el resultado de mayor eficiencia en el diseño y desarrollo de cada proyecto sea percibido por el cliente final, como la entrega de un producto de mayor calidad y con la confianza generada por un mayor grado de acercamiento al proceso de desarrollo de cada proyecto, de manera que el cliente realice un seguimiento y apoyo al proceso, y por otro lado, que la División pueda apoyar a los clientes más integralmente durante todo el proceso.

Asimismo, se desea avanzar más allá mediante el rediseño de parte de los procesos del cliente y que estén directamente relacionados con la solución ofrecida, y que en muchos casos resulta fundamental para que dicha solución entregue los resultados esperados por el cliente. Este esfuerzo se puede ver graficado en la figura 69 Seguimiento, que muestra la interacción existente entre las dos áreas de la DGFDT y el CDT, visualizando claramente los procesos que allí operan.

3.3.2 Variables a Considerar

La primera variable a considerar será la de tiempos de implementación, que va por supuesto de la mano con la búsqueda de eficiencia operacional. Para esto la entrega de un sistema integrador que planifique, asigne y gestione es insuficiente sin antes un rediseño a los procesos de gestión y desarrollo de la organización, en los que implica la creación de nuevas metodologías a seguir por parte de los técnicos y jefes de proyecto encargados de llevar a cabo los diferentes proyectos, en los que se deberá plantear entre otros el realizar anotaciones (reportes) diarias de todos aquellos aspectos que se hayan presentado durante la gestión y el desarrollo de éstos, tanto el surgimiento de problemas como las soluciones encontradas o propuestas (en caso de no poder ser aplicadas), y que sirvan de referencia para futuros proyectos.

También se deberá tener una especial preocupación por los tiempos definidos para cada tarea, para lo que será necesario establecer una medición de los tiempos de implementación para cada tarea y como estos varían de una implementación a otra, tratando de parcelar cada tarea lo mas que sea posible de modo de poder establecer tiempos de desarrollo lo mas fidedignos posibles, ya que si una tarea es muy específica y puntal es más fácil de determinar su duración que si fuese más general y poco acotada.

21

Es claro que esta variable implica el compromiso de todos los involucrados en los

procesos que van desde el ingreso de los requerimientos, pasando por el diseño y evaluación de proyectos hasta la elaboración de las Bases y parte del desarrollo del concurso, como lo son los Técnicos, los Jefes de Proyecto y el Responsable, ya que de lo contrario no se estarían dando una de las condiciones necesarias que propone el proyecto de rediseño.

Como consecuencia de lo anterior se considera la disminución de los tiempos de respuesta

para diversos requerimientos realizados por los clientes como una medida del grado de satisfacción de éstos.

Para lo anterior es necesario la comprensión por parte del cliente que se requiere un grado

de relación mayor en el proceso de diseño y desarrollo, y que permita hacer una evaluación de sus procesos, de manera que tengan la flexibilidad necesaria para permitir que estos sean readecuados al nuevo escenario que entrega la solución y que por ende tiene por objetivo que el producto ofrecido cumpla cabalmente con todos los requerimientos entregados por los clientes.

3.3.3 Beneficios Esperados

Los beneficios esperados una vez que el sistema este implementado son:

1. Aprovechar la información de proyectos anteriores para el desarrollo de futuros proyectos: Esto como apoyo a la planificación, debido a que tanto el responsable de proyectos como los jefes de proyectos, encargados del ingreso de nuevos requerimientos, definen las actividades, plazos (no los hitos finales sino los intermedios), y recursos a utilizar, entre otros, basándose en su criterio y experiencia, pero desaprovechando en muchos casos la información de una gran cantidad de proyectos ya realizados, por ejemplo, para el establecimiento de cartas Gantt de cada nuevo proyecto necesarias para tener las definiciones antes mencionadas.

2. Utilizar un conocimiento más acabado de las capacidades de cada recurso:

Y que es uno de los problemas más recurrentes en las organizaciones actualmente, es el poco conocimiento de las habilidades de sus recursos. Asignando a personal capacitado a tareas específicas, se podrán ejecutar tareas en menor tiempo y de buena calidad.

3. Disminución de tiempos de implementación, evitando “recurso ocioso”: Con la implementación de la solución, se pretende poder estimar de mejor forma los tiempos, lo que quiere decir que cada técnico podrá desarrollar las tareas más eficientemente, aprovechando mejor los tiempos.

22

3.4 Análisis FODA

A continuación se muestra un recuadro con un análisis FODA realizado con el fin de estudiar las posibilidades con que cuenta la GFDT, con el fin de tomarlas como referencia para el diseño de la solución propuesta:

Misión

Fortaleza

Buen momento económico del país para invertir en proyectos Tecnológicos

Proyectos Desarrollados Previamente y que sirven como Base para el desarrollo de futuros proyectos

Mejora y mayor precisión en la construcción de los Diseños y por consecuencia de las Bases producto de la experiencia obtenida

Debilidades

Falta de incentivos suficientes para que las empresas postulen a los Concursos

Focalización de los recursos inicialmente destinados al FDT, para otros fines “más prioritarios”

Postulación y adjudicación de concursos por parte de empresas carentes de un respaldo sólido que les permita implementar el Proyecto

Oportunidades

Recursos de calidad y con experiencia en Telecomunicaciones y en el desarrollo de concursos

Existe aún en Chile una brecha importante de acceso a redes de Telecomunicaciones que debe ser resuelta

Nuevos Proyectos Innovación Buscar nuevos potenciales proyectos aprovechando el buen momento económico y la búsqueda de metas a nivel país (OCDE12).

Aumento de satisfacción de clientes. Incorporar nuevas restricciones para la postulación a los concursos que mayor seguridad y certeza de su implementación final.

Amenazas

Todavía es escaso la cantidad de recursos Humanos y Económicos para innovación

Falta de Recursos especializados para ciertos proyectos.

Recursos Limitados

Desarrollo de capital humano.

Aumento de capacidad y productividad

Generar integración con el cliente rediseñando procesos de este, entregando un mejor servicio.

Optimizar el uso de los recursos por medio de nuevas metodologías, procesos y herramientas.

Tabla 1: Análisis FODA

12 Dado el reciente ingreso de Chile como país miembro de la Organización para la Cooperación y Desarrollo Económico (OCDE), es que se busca cumplir con los niveles exigidos en dicho organismo.

23

3.5 Factores Críticos de Éxito y Fracaso

Factores Críticos de Éxito

1. Necesidad mejorar el proceso de planificación de proyectos y asignación de recursos. 2. Predisposición para aceptar un cambio en la organización y los procesos. 3. Una correcta definición del mapa de poder.

Factores Críticos de Fracaso

1. No adopción del proyecto 2. Resultados peores de lo actual 3. Problemas o cambios importantes en la organización mientras se desarrolla el proyecto. 4. Imposibilidad de cambiar la forma de trabajar de técnicos y JP

3.6 Cuantificación de los Beneficios

Se estima que con la realización de este proyecto, las variables para cuantificar sus beneficios se van a ver reflejadas directamente en los tiempos y precisión de cada nueva planificación y asignaciones, e indirectamente en la disminución de tiempos durante el diseño y desarrollo de cada proyecto debido al apoyo entregado a los diferentes técnicos por el registro de problemas y soluciones.

Directos

1. Disminución de tiempos de planificación y mayor precisión en la definición de plazos y costos de las actividades a realizar.

2. Mayor precisión en la asignación de recursos

Indirectos

1. Aumento de los niveles de satisfacción de los clientes.

2. Disminución de los tiempos de desarrollo de los proyectos, lo que se traduce en una disminución en los costos.

24

3.7 Evaluación Financiera

Para entender cuál podría ser el impacto del proyecto desarrollado en la construcción de las Bases y por consecuencia en los Concursos, es que se tomará inicialmente el nivel de incidencia de la propuesta en las actividades desarrolladas por el DI, y que puede ser cuantificable analizando los costos involucrados en la realización de las actividades principales detalladas previamente.

A continuación se muestra la evaluación económica de incorporar la solución propuesta

dados los costos operativos de desarrollar un proyecto cualquiera, los costos de inversión necesarios para la implementación de la solución y el potencial ahorro que traería consigo.

3.7.1 Costos Diseño y Desarrollo de un Proyecto Tipo A continuación se muestran los costos de llevar a cabo un proyecto tipo13, particularmente

dentro de los procesos desarrollados por el DI:

Profesionales N° Horas x día Semanales Total Dedicado Sueldo bruto Sueldo Diario Valor H-H Costo Total H-H

Ingeniero Económico 8 40 120 $1.222.222 $61.111 $7.639 $916.667

Geógrafo 8 40 120 $940.000 $47.000 $5.875 $705.000

$1.621.667

Equipos N° Horas x día Semanales Total Dedicado Costo Equipo Vida Útil MesesDepreciación

mensualCosto

16 80 240 $495.000 36 $13.750 $20.625

Activo Fijo N° Horas x día Semanales Total DedicadoCosto Mensual

m2M2 utilizados Total Costo AF

16 80 240 $5.254 10 $52.544 $78.816

$99.441

$1.721.107

TOTAL H-H

TOTAL OPERATIVOS

TOTAL VALIDACION CARTERA

Tabla 2: Costos del Proceso Pre-evaluación de la Solución Técnica

Nª Ingenieros N° Horas x día Semanales Total Dedicado Sueldo bruto Sueldo Diario Valor H-H Costo Total H-H

6 8 40 120 $1.222.222 $61.111 $7.639 $5.499.999

Nª Equipos N° Horas x día Semanales Total Dedicado Costo Equipo Vida Útil MesesDepreciación

mensualCosto

6 8 40 120 $495.000 36 $13.750 $61.875



6 8 40 120 $5.254 10 $52.544 $236.447

$5.798.321TOTAL DISEÑO DE RED y CALCULO DE INVERSIONES

Tabla 3: Costos del Proceso Diseño Técnico y Cálculo de Inversiones

13 El proyecto considerado es de los emblemáticos desarrollados cada año, y que en este caso fue IDCI 2008, Infraestructura Digital para la Competitividad e Innovación 2008, proyectos que son de carácter nacional.

25


2 8 40 120 $1.222.222 $61.111 $7.639 $1.833.333


mensualCosto

2 8 40 120 $495.000 36 $13.750 $20.625



2 8 40 120 $5.254 10 $52.544 $78.816

$1.932.774TOTAL CÁLCULO DE SUBSIDIO

Tabla 4: Costos del Proceso Cálculo de Subsidio

3.7.2 Costos del Desarrollo e Implementación de la Solución

3.7.2.1 Inversión Inicial

Se considerará una inversión inicial por la compra de un servidor de aplicaciones y base de datos por un valor cercano a $400.000.

3.7.2.2 Equipo Requerido para el Proyecto

Primero es necesario explicitar que se considerará al Jefe del DI como apoyo para el proceso de implantación, contabilizando las horas que destine a validar el proyecto y encaminarlo de acuerdo a los objetivos buscados, ya que el costo real pasará por el tiempo que se destine tanto en el diseño, como en la implementación, y que en principio se considerara como un par de horas semanalmente para estos efectos.

Junto con lo anterior es necesario considerar que se emplearán un número de 320 HH del

ingeniero de negocios en el proceso de implementación del proyecto, que involucra desde el diseño, elaboración y la puesta en marcha. Y un número cercano a las 160 horas de trabajo de recurso que abarca los temas de programación y diseño.

En promedio se pueden entregar los siguientes valores:

1. Ingeniero de Negocios: $2.500.000 (correspondiente al costo de implementación

considerando 2 meses de trabajo).

2. Ingeniero de Sistemas: $600.000 (programación de la solución durante aprox. 1 mes).

3. Soporte: $120.000 (costo anual considerando que el sistema requerirá revisiones menores).

4. Jefe de DI: $ 700.000 (considerando 2 hrs. Semanales durante 2 meses).

26

3.7.3 Flujo de Caja

De acuerdo a las consideraciones antes mencionadas, se procederá a realizar un flujo de caja para el proyecto, el cual en una primera instancia considerará un efecto directo sobre una parte del proceso de desarrollo de los proyectos realizados por la DGFDT, en particular se analizará el efecto para los proyectos más grandes y emblemáticos como el caso de los proyectos IDCI.

Se considerarán por ende los resultados observados a la fecha para dichos proyectos y que

entre otras cosas contemplan los costos y tiempos mostrados en las tablas 2, 3 y 4. Junto con ello, se toma en consideración la realización de un promedio de 4 proyectos similares al proyecto tipo (si bien esto no es así el costo en uso de recursos por año se podría aproximar de esta forma), y una consecuente proyección debido entre otras cosas a la optimización en el uso de recursos a 5 y hasta 6 “proyectos anuales”, dando como resultado el flujo siguiente:

en miles de pesos

Periodos 0 1 2 3 4 5

Servidor de Aplicaciones y BD 600.000

Valor Hora Jefe de Proyecto 0,8 0,8 0,8 0,8 0,8

Valor Promedio Hora Técnico 0,4 0,4 0,4 0,4 0,4

Factor de Ahorro 15%

Promedio de Proyectos / Año 0 4 4 5 5 6

Costos Equipo de Proyectos 0 -37.808.808 -37.808.808 -47.261.010 -47.261.010 -56.713.212

Costo Proyecto -3.100.000 0 0 0 0

Costos de Mantención -120.000 -120.000 -120.000 -120.000 -120.000

Ahorros 0 5.671.321 5.671.321 7.089.152 7.089.152 8.506.982

Utilidad Antes de Impuestos 0 -41.028.808 -32.257.487 -40.291.859 -40.171.859 -48.206.230

Impuesto (17%) 0 -6.974.897 -5.483.773 -6.849.616 -6.829.216 -8.195.059

Utilidad Después de Impuestos 0 -41.028.808 -26.773.714 -33.442.243 -33.342.643 -40.011.171

Flujo de Caja Operacional con Proy 0 -35.357.487 -26.773.714 -33.442.243 -33.342.643 -40.011.171

Flujo de Caja Operacional sin Proy 0 -37.808.808 -31.381.311 -39.226.638 -39.226.638 -47.071.966

Inversión Fija -600.000 0 0 0 0 0

Valor Residual de los Activos 0 80.000 80.000 80.000 80.000 80.000

Flujo de Caja con Proyecto -600.000 -35.277.487 -26.693.714 -33.362.243 -33.262.643 -39.931.171

Flujo de Caja sin Proyecto 0 -37.808.808 -31.381.311 -39.226.638 -39.226.638 -47.071.966

Flujo de Ahorros -600.000 1.931.321 4.687.597 5.864.396 5.963.996 7.140.795

Tasa de Descuento Anual 18,0%

VPN 12.008.469

TIR 418%

Tabla 5: Flujo de Caja

27

Capítulo 4 Marco Teórico

En el capítulo siguiente se detalla cual es el soporte teórico detrás del proyecto de tesis realizado, que consideran las metodologías, teorías y estándares tanto para el manejo de proyectos como para la gestión del conocimiento de proyectos particulares de telecomunicaciones.

4.1 Proyectos de Instalación en Telecomunicaciones

Los proyectos de ingeniería contemplan una amplia gama de elementos que los describen y por ende se han establecido un sinnúmero de definiciones realizadas por diferentes autores que tratan de explicar el concepto de manera general, no existiendo todavía una definición que satisfaga a todos, dada la diversidad de áreas de ingeniería y la amplitud dentro de cada una de estas. En particular se utilizará la siguiente definición:

“Un proyecto es una empresa planificada que consiste en un conjunto de actividades

que se encuentran interrelacionadas y coordinadas, cuya razón es alcanzar objetivos específicos dentro de los límites que imponen un presupuesto y un lapso de tiempo previamente

definidos” [36]. En particular para el diseño y desarrollo de la herramienta se analizarán proyectos de

telecomunicaciones y mas específicamente se estudiarán proyectos de Instalación en Telecomunicaciones, para lo cual se utilizará como referencia la memoria de título de Ariel Muñoz T.14 que precisamente consideró este tema para construir un tipificador de este tipo de proyectos que entrega directrices para su planificación y ejecución.

A continuación se detallan los proyectos de instalación considerados en el modelo de

tipificación final [33]:

4.1.1 Proyectos de Core (Núcleo)

Corresponden a proyectos encargados de establecer los sistemas de interconectividad primarios encargados de encausar el tráfico lo más rápidamente posible hacia los servicios adecuados. En general dicho tráfico va y viene desde servicios comunes a una gran cantidad de usuarios, como es el caso de los servicios globales o corporativos.

Como ejemplos se tienen los diseños de redes Backbone ATM, IP, IP/MPLS, entre

otras. Estos son desarrollados en su gran mayoría en Fibra Óptica.

14 Tipificación y Metodología para Proyectos de Instalación en al Área de las Telecomunicaciones.

28

Figura 12: Red de Núcleo15

4.1.2 Proyectos de Distribución

La idea central de este tipo de proyectos está en el diseño de un sistema que permita la difusión de la red hacia los puntos de demanda de ésta.

Estos proyectos contemplan una serie de funciones entre las que se encuentran:

1. Funcionar como punto de concentración para ingresar a dispositivos de capa de acceso.

2. Permitir el enrutamiento de tráfico entregando acceso a los grupos de trabajo.

3. Segmentación de la red en múltiples dominios de difusión.

4. Brindar seguridad y filtrado.

Como ejemplos se tienen proyectos de planta externa (que considera toda la infraestructura de cableado, instalaciones y equipos dispuestos fuera de los edificios de planta interna hasta el Terminal de distribución) de una organización y proyectos de MMOO16 y ATM.

15 La red de núcleo es la que se aprecia enmarcada en azul. 16 Redes de Microondas

29

4.1.3 Proyectos de Acceso

Constituyen los proyectos en los que finalmente se establece el acceso al cliente o usuario final, y son por ende muy relevantes debiendo considerar factores tanto técnicos como geográficos.

Se consideran 2 tipos de tecnologías de acceso: las cableadas (par trenzado, cable

coaxial, FO, red eléctrica) y las inalámbricas (señales de radio, WiFi, WiMax, GSM, UMTS, etc.)

4.1.3.1 Proyectos de Acceso Cableado

Se definen como aquellos proyectos de acceso que utilizan medios de transporte físicos para el envió de datos (Cable Coaxial, UTP, FTP o Fibra Óptica), en este caso estamos hablando de una tecnología de acceso guiado.

Como ejemplos de estos proyectos se tienen: Fibra Óptica (FTTx17), Redes HFC (Cable) y xDSL18.

Figura 13: Red xDSL

4.1.3.2 Proyectos de Redes Inalámbricas

A diferencia de los anteriores, este tipo de proyectos emplea como medio el aire y la utilización de antenas para la transmisión de datos. Una clasificación de las redes inalámbricas [35] entrega las siguientes 3 variantes:

17 Considera las siguientes tecnologías: Fiber to the Home (FTTH), Fiber to the Curb (FTTC) y Fiber to the Building (FTTB). 18 Algunas de las tecnologías que considera son: Digital Subscriber Line (DSL), Symmetric Digital Subscriber Line (SDSL), Asymmetric Digital Subscriber Line (ADSL), entre otras.

30

Redes Inalámbricas Personales:

En este tipo de redes se pueden considerar por un lado, las típicas redes de intercambio

mediante infrarrojos, pero que son limitadas debido a su corto alcance, baja velocidad y a la necesidad de que no existan obstáculos que entre los dispositivos. Por otro lado se tiene la comunicación vía Bluetooth que es un estándar utilizado entre dispositivos de uso personal y que como principales limitaciones presentan las incompatibilidades entre dispositivos de diferentes fabricantes.

Redes Inalámbricas 802.11:

Este tipo de redes correspondientes a un estándar de protocolo de comunicación del IEEE definen la utilización de los niveles inferiores del modelo OSI (capa física y de enlace), y en la que existen 3 variantes principales:

1. 802.11a19 2. 802.11b20 3. 802.11g21

Figura 14: Red WLAN

19

Hasta 54 Mbps en el rango de 5 Ghz 20

Hasta 11 Mbps en el rango de 2,4 Ghz 21

Hasta 54 Mbps en el rango de 2,4 Ghz

31

Redes Inalámbricas de Consumo:

Considera 2 tipos de redes, por un lado las redes CDMA (estándar de telefonía móvil estadounidense) y GSM (estándar de telefonía móvil europeo y asiático), que son los estándares que usa la telefonía móvil empleados alrededor de todo el mundo en sus diferentes variantes, existiendo actualmente redes móviles 3G como UMTS que son sucesoras de GSM.

Figura 15: Red UMTS

Por otro lado están las redes 802.16 que pretenden complementar a las anteriores

estableciendo redes inalámbricas metropolitanas (MAN) en la banda de entre los 2 y los 11 Ghz.

4.1.4 Servicios Avanzados de Telecomunicaciones (NGN)

Es necesario declarar inicialmente que si bien este tipo de proyectos no son desarrollados al interior de la DGFDT, si son relevantes para efectos de la construcción del modelo tipificador.

Este tipo redes a diferencia de la tradicional PSTN, red de telefonía pública conmutada,

está enfocada hacia la tecnología de paquetes (IP) para el transporte de información. Entregan multiservicio capaz de manejar voz, datos y video, algo que las redes tradicionales no eran capaces de realizar [20].

Las redes NGN presentan el plano de control (señalización y control) separado del

plano de transporte y conmutación/ruteo, con interfaces abiertos entre transporte, el control y las aplicaciones.

Este proceso de cambio ha permitido que las nuevas redes presenten cada vez más flexibilidad tanto para su construcción como para la oferta de servicios, así como reducciones importantes en los costos y simplificando también la operación y mantención traduciéndose en una reducción en los costos OPEX.

32

Todo esto ha permitido que se puedan ofrecer servicios integrados bajo una misma red,

y que van desde los servicios de audio, hasta video, TV, radio, Internet y telefonía (fija y móvil). Dentro de esta línea se tiene el IMS22 que forma parte del núcleo de la arquitectura de las nuevas redes NGN y que son capaces servicios multimedia fijos y móviles. Pretende servir para todo tipo de servicios, tanto actuales como futuros que se puedan prestar por Internet, permitiendo que los operadores e ISP puedan controlar y facturar cada uno de sus servicios.

Figura 16: Arquitectura Red NGN

4.1.5 Proyectos de Servicios de Valor Agregado

Este tipo de proyectos están dirigidos a la prestación de servicios que pueden ser entregados por medio de la utilización de las redes actualmente disponibles23, y que no involucran necesariamente un gasto en infraestructura. Como ejemplo de estos proyectos se encuentran los proveedores de Internet (ISP), de voz sobre IP, TV sobre IP, etc.

Si bien este tipo de proyectos al igual que los de NGN, tampoco son el foco de lo

desarrollado por la DGFDT, son relevantes para efectos del modelo tipificador analizado.

22 IP Multimedia Subsystem 23 Redes tanto físicas (de cableado) como redes inalámbricas.

33

4.2 Tipificador de Proyectos de Instalación en el Área de Telecomunicaciones

Este será el modelo utilizado para la clasificación de proyectos dentro de la solución diseñada y que permitirá tener un repositorio de proyectos realizados sobre los cuales poder tomar como referencia para la planificación de futuros proyectos, y que por supuesto tendrán claras similitudes dependiendo de la tipificación a la que pertenezcan.

El modelo corresponde a la clasificación de proyectos de instalación en telecomunicaciones para poder identificar proyectos que se puedan estandarizar24, con la finalidad de poder realizar un análisis profundo en estas actividades.

Para lo anterior fue necesario determinar los criterios relevantes de este tipo de proyectos, para lo cual se recopiló información de proyectos reales, informes, libros técnicos, trabajos de memoria, etc., y que permitió identificar y especificar clases o familias de proyectos, todo esto fue realizado por el ingeniero eléctrico Ariel Muñoz T. en su trabajo de título [33].

Se utilizó la metodología del PMI como base para la construcción del tipificador, junto con información de una serie de proyectos de instalación.

El resultado de esto fue la creación de un modelo para poder clasificar un proyecto de acuerdo a criterios y parámetros comunes, mediante la utilización de ciertas herramientas como: diccionario de actividad, diagramas de flujo de procesos, metodología PMI, áreas de conocimiento, entre otros. Dentro de los parámetros que pueden definir a un proyecto están: la inversión, los tiempos, la complejidad, la innovación, la tecnología, etc.

En particular se tomó los proyectos de instalación en telecomunicaciones por la relevancia y necesidad de entregar guías o patrones para disminuir la tendencia de atraso y cancelación de dichos proyectos.

Figura 17: Proyectos de Instalación en Telecomunicaciones

24 La estandarización es posible cuando los proyectos cumplen con características típicas, como costos no muy altos o bajos, no excesiva complejidad ni cantidad de recursos asignados, etc.

34

4.2.1 Familias de Proyectos

Considerando el estudio y trabajo realizado, fue propuesta la clasificación de proyectos por intermedio de la identificación de familias de acuerdo a características como: Magnitud (si son proyectos simples o más complejos a nivel de gestión), Naturaleza (dadas las diferencias existentes en las metodologías para el desarrollo de proyectos que parten desde 0, proyectos de mejoramiento o de ampliación) y Tipo de Servicio (de acuerdo al modelo de jerarquización de redes y/o servicio al que se enfoca el proyecto).

4.2.1.1 Tipificación I: Magnitud

Tomando como base las metodologías de manejo de proyectos del PMI se definió esta primera tipificación, que dependiendo del nivel de complejidad, tamaño, costos, entre otros criterios, se definirán 3 tipos de proyectos:

Proyectos Pequeños o Simples

Se caracterizan por tener un costo no superior a US$ 1M, una duración no superior a

los 2 años, presentan baja complejidad, una metodología simple y generalmente existe un solo participante.

Proyectos Estándar

Poseen costos en el rango de US$ 1M a US$ 2M., con duraciones desde un par de meses hasta 2 años plazo, tienen un cierto grado de complejidad y comúnmente existen entre 2 y 5 participantes.

Proyectos Grandes o Singulares

Tienen costos superiores a los US$ 2M, con duraciones desde 2 a 4 años plazo, son los que presentan la mayor complejidad tanto de gestión como de tecnología, y pueden existir más de 5 participantes.

4.2.1.2 Tipificación II: Naturaleza

Esta tipificación considera el tipo de naturaleza del proyecto en cuestión y que depende de si se trata de un proyecto que parte desde cero, un proyecto al que se le deba extender su capacidad (infraestructura, equipos, etc.), o un proyecto de mejoramiento de la infraestructura, tecnología existente, etc.

35

Proyectos de Apertura y Construcción

Se caracterizan por ser creados de cero, razón por la cual no disponen en su inicio de recursos ni de infraestructura. Buscan dotar de un sistema de telecomunicaciones a una demanda desprovista totalmente de este servicio.

Algunos de los criterios que los definen son: planificación, obras físicas de infraestructura, obras de tipo administrativo, entre otros.

Proyectos de Mejoramiento

Tiene como característica aumentar la eficiencia sobre algún parámetro del modelo

(tráfico, costos, calidad de servicio, demanda), buscando mejorar la calidad del servicio y/o disminuir las pérdidas físicas y comerciales. Para lograr lo anterior deben realizar variadas acciones, algunas de las cuales implican obras físicas de infraestructura y otras de tipo administrativo. Este tipo de proyectos no son normalmente abordados por la DGFDT.

Los proyectos más típicos de este tipo son: upgrades de software, migraciones, etc.

Proyectos de Ampliación

En este tipo de proyectos se aumentan las prestaciones de servicios debido a una extensión o ampliación de la infraestructura, equipos y cableados existentes, buscando un incremento de la oferta máxima del sistema de telecomunicaciones para hacer frente al crecimiento de la demanda, para lo cual se debe invertir en proyectos de distribución, dependiendo de donde se ubique el cuello de botella del sistema.

Los proyectos más típicos de este tipo son: construcción de redes de distribución y conexiones domiciliarias.

4.2.1.3 Tipificación III: Tipo de Servicio

Por último se identificaron los proyectos estandarizables según el modelo de jerarquización de redes y/o negocio (servicio) [33], que se ven a continuación:

Proyectos de Core

Algunos ejemplos son: Backbone ATM, IP, IP/MPLS, FFOO

36

Figura 18: Red Backbone ATM

Proyectos de Distribución Algunos ejemplos son: Implementación de Nodos, Planta Externa, Redes MMOO.

Figura 19: Planta Externa

Proyectos de Acceso

Según el medio físico algunos ejemplos son: Cableado: xDSL, FTTx, HFC. Inalámbricos: accesos WLAN, redes móviles.

37

Figura 20: Proyecto HFC

Proyectos de Plataformas de Servicios de Valor Agregado Algunos ejemplos son: Plataforma de E-learning, Proveedor de Servicios de Internet

(ISP). También se consideran 2 tipos de proyectos más, que si bien pueden ser desarrollados

por las empresas que se adjudican cierto tipo de concursos, no caben estrictamente dentro de los proyectos desarrollados por el FDT, y que se detallan a continuación:

Proyectos NGN

Algunos ejemplos son: IMS, IPTV, ToIP, etc.

Figura 21: Arquitectura IMS

Proyectos de Infraestructura Algunos ejemplos son: proyectos de infraestructura común de Telecomunicaciones

(ICT), planta externa, etc.

38

4.2.2 Criterios de Tipificación

El modelo antes mencionado define 4 tipos de criterios de decisión: Estratégicos (13)25, Tácticos (7), Operacionales (7) y de Ejecución (3), que se describen a continuación:

Estratégicos

Se definen como aquellos que determinan las capacidades del sistema y la secuencia de

actividades a llevar a cabo durante el proyecto. Por ejemplo: Cobertura, Tamaño, Alcance, etc.

Tácticos

Se definen como aquellos que determinan las modificaciones o requerimientos proyectados en infraestructura una vez que se ha completado el proyecto. Por ejemplo: Escalabilidad, Integración, Precios, etc.

Operacionales

Se definen como aquellos que determinan las funciones o recursos solicitados por el sistema para su correcto funcionamiento. Por ejemplo: Interoperabilidad, Administrabilidad, Confiabilidad, etc.

Ejecución

Se definen como aquellos que determinan los recursos o funciones necesarios para la correcta ejecución del proyecto. Por ejemplo: Normativas y Restricciones, Infraestructura y Cantidad de Recursos.

El detalle considerando los criterios asociados a cada familia y por consiguiente a cada tipificación se muestra en las siguientes tablas:

25

Constituye la cantidad de criterios asociados a cada tipo de criterio de decisión.

39

MAGNITUD

Magnitud

Alcance

Complejidad

Costos

Innovación

Nivel Tecnológico

Pequeños

Estandarizables

Singulares Plazos del Proyecto

Tamaño

CRITERIOS

Tabla 6: Característica Magnitud

NATURALEZA CRITERIOS

Cantidad de Recursos Requeridos

Disponibilidad

Alcance

Integración

Interoperabilidad

Migración

Alcance

Escalabilidad

Cobertura

Calidad de Servicio

Seguridad

Cantidad de Recursos Requeridos

Infraestructura

Apertura y Construcción

Mejoramiento

Ampliación

Naturaleza

Plazos del Proyecto

Costos-CAPEX

Infraestructura

Normativas y Restricciones

Tabla 7: Característica Naturaleza

40

TIPO DE SERVICIO CRITERIOS

Disponibilidad

Ancho de Banda

Seguridad

Alcance

Calidad de Servicio

Integración

Nivel Tecnológico

Interoperabilidad

Complejidad

Innovación

Infraestructura

Disponibilidad

Medio Ambiente

Normativas y Restricciones

Costos Capex

Costos-CAPEX

Legalizaciones de Obras

Infraestructura

Plazos

Ancho de Banda

Disponibilidad de Servicio

Nivel Tecnológico

Innovación

Legalizaciones de Obras

Seguridad y Control

Calidad de Servicio

Medio Ambiente

Costos Opex

Estructura de Precios

Flexibilidad

Complejidad

Innovación

Conocimiento de la Tecnología

Integración

Nivel Tecnológico

Alcance

Migración

Interoperabilidad

Ancho de Banda

Servicios

Costos Opex

Nivel Tecnológico

Innovación

Complejidad

Conocimiento de la Tecnología

Ancho de Banda

Servicios

Medio Ambiente

Integración

Estructura de Precios

NGN

Servicios de Valor Agregado

Tipo de Servicio

Core

Distribución

Acceso Cableado

Redes Inalámbricas

Tabla 8: Característica Tipo de Servicio

41

4.3 Metodología PMI en la Gestión de Proyectos

Para la elaboración de la solución y rediseño de los procesos de la DGFDT, se utilizarán metodologías y estándares definidos y ampliamente utilizados para el manejo de proyectos, y que permitan definir la forma y el fondo de una gestión óptima. Una de ellas es la metodología del PMI26 [37].

4.3.1 Project Management (Dirección de Proyectos)

Se considerarán los conceptos definidos por el Instituto de Manejo de Proyectos PMI, que es el organismo pionero en el desarrollo de la moderna concepción del “Manejo de Proyectos” o “Project Management”, cuya acción está apoyada en una teoría de carácter sistémico, sistemático y consolidado, llamado a orientar el manejo de las variadas tareas requeridas para la exitosa conducción de un proyecto. Dentro de los marcos de referencia considerados están el grupo de procesos de la dirección de proyectos y las áreas de conocimiento, que son descritas en detalle en el PMBOK (Project Management Body of Knowledge) [40].

Figura 22: Progresos Metodológicos

4.3.2 Progresos Metodológicos del Project Management Considera por un lado al grupo de procesos de la dirección de proyectos y las 9 áreas de conocimiento definidas por el PMI como se puede ver en la figura 22, a continuación se detallan ambos casos:

26 El Instituto de Manejo de Proyectos recoge las mejores prácticas de una cantidad de organizaciones que actualmente alcanza las 260.00 organizaciones en más de 171 países.

42

4.3.2.1 Grupos de Procesos de la Dirección de Proyectos

1. Inicio: Esta etapa la forman procesos que ayudan a facilitar la autorización formal para

poder iniciar un nuevo proyecto o una fase del mismo. Los procesos de iniciación, por lo general, se realizan fuera del ámbito de control del proyecto por la organización o por los procesos del programa o del portafolio.

2. Planeación: En esta etapa se planifican las tareas o actividades a realizar para el

desarrollo del proyecto. Los procesos de planificación están encargados del desarrollo del plan de gestión del proyecto, y también identifican, definen y maduran el alcance, el costo y planifican las actividades del proyecto que se realizan dentro del proyecto.

3. Ejecución: Esta etapa está formada por los procesos utilizados para completar el

trabajo definido en el plan de gestión del proyecto a fin de cumplir con los requisitos del proyecto. Esta etapa implica coordinar personas y recursos, así como integrar y realizar las actividades del proyecto, y abordar el alcance definido en el enunciado del alcance del proyecto e implementar los cambios aprobados.

4. Control y Monitoreo: Esta etapa está compuesta de aquellos procesos realizados para

observar la ejecución del proyecto de forma que se puedan identificar los posibles problemas oportunamente y adoptar las acciones correctivas, cuando sea necesario, para controlar la ejecución del proyecto. La etapa de control y monitoreo se integra y está presente durante todo el proyecto.

5. Cierre: Es la etapa que incluye los procesos utilizados para finalizar formalmente todas las actividades de un proyecto o de una fase de un proyecto, entregar el producto terminado a terceros o cerrar un proyecto cancelado. Este grupo de procesos, una vez completado, verifica que los procesos definidos se completan dentro de todos los grupos de procesos para cerrar el proyecto o una fase del proyecto, según corresponda, y establece formalmente que se ha finalizado un proyecto o fase del proyecto.

Figura 23: Mapa de Procesos del PMI

43

4.3.2.2 Áreas de Conocimiento

Las áreas del conocimiento de la metodología PMI están integradas por 8 conjuntos de

habilidades que representan las experiencias en el desarrollo de proyectos. Además de los 8 conjuntos de habilidades, se adiciona un noveno conjunto denominado integración, con lo cual se completa el mapa del conocimiento proporcionando una metodología bastante amplia en los aspectos a optimizar en un proyecto.

El listado de las áreas de conocimiento se puede ver a continuación:

Gestión del Tiempo

Gestión de los Costos y Recursos

Gestión de la Calidad

Gestión de las Comunicaciones

Gestión de los Riesgos

Gestión de las Adquisiciones

Gestión del Alcance

Gestión de la Integración

4.4 Integración de Modelos para la Mejora de Procesos (CMMI)

Junto a las metodologías del PMI se utilizará también el estándar denominado “ Capability Maturity Model Integration” el cual fue desarrollado inicialmente por el departamento de defensa de Estados Unidos debido a lo muchos problemas que tenía con el software que encargaba desarrollar a otras empresas, donde los presupuestos se disparaban y los plazos se extendían constantemente.

Este estándar servirá de apoyo a las metodologías utilizadas del PMI, siendo ambas muy compatibles, existiendo experiencias anteriores de su uso conjunto, y ayudando a establecer una base sólida para el correcto manejo de proyectos y la utilización de buenas prácticas.

Cabe señalar que el CMMI es precisamente la integración de varios modelos entre los

que se cuentan: CMMI-SW, dedicada al software; CMMI-SE, para ingeniería de sistemas; CMMI-SE/SW/IPPD, para el desarrollo de productos y que será el considerado para este caso; y CMMI-SE/SW/IPPD/SS para la gestión de proveedores. [47]

44

1 2 3 4 5Nivel de Madurez Área de Procesos

Su

bp

roce

so

s S

ele

ccio

na

do

s

Innovación Organizacional

Despliege del análisis causal y resolutivo

Funcionamiento de los procesos en la Organización

Manejo Cuantitativo de Proyectos

Desarrollo de Requerimientos

Soluciones Técnicas Integración de Productos

Verificación Validación Manejo

Integral de Proyectos +IPPD Manejo de

Riesgo

Manejo de Requerimientos

Planificación de Proyectos

Seguimiento y Control de Proyectos

Manejo de Proveedores

Calidad de Productos y Procesos

4

3

2

Cuantitativamente

Gestionado

Optimizado

Definido

Repetible

Inicial

5

Su

bp

roce

so

s S

ele

ccio

na

do

s

4.4.1 Niveles de Madurez y Capacidad

El modelo de evolución de la capacidad de gestión de procesos, CMMI es un modelo de organización que describe 5 etapas evolutivas (niveles) de administración de los procesos de una organización.

El pensamiento detrás del modelo CMM, fue pensado originalmente para el desarrollo

de software, y sostiene que una organización debe ser capaz de absorber y llevar a cabo sus aplicaciones de software. El modelo también proporciona los pasos y las actividades específicas que ayudan a una organización a pasar de un nivel al siguiente.

Las 5 etapas del modelo de evolución de la capacidad de la organización se pueden ver en la figura siguiente:

Figura 24: Etapas de Evolución del CMMI.

La explicación más en detalle de cada uno de los niveles de madurez se puede ver aquí:

1. Inicial o Nivel 1 CMM – CMMI: Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en las fechas definidas, los encargados deben quedarse durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto y el desarrollo del proyecto es completamente desestructurado.

2. Repetible o Nivel 2 CMM – CMMI: Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.

45

Los procesos que son necesarios implantar para alcanzar este nivel son:

Gestión de requisitos

Planificación de proyectos

Seguimiento y Control de proyectos

Gestión de proveedores

3. Definido o Nivel 3 CMM – CMMI: Alcanzar este nivel significa que la forma de desarrollar proyectos (gestión e ingeniería) está definida. Por definida quiere decir que está establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.


Desarrollo de requisitos

Integración del producto

Verificación

Validación

Desarrollo y mejora de los procesos de la organización

Definición de los procesos de la organización

Gestión de riesgos

Análisis y resolución de toma de decisiones

La mayoría de las empresas que llegan al nivel 3 paran aquí, ya que es un nivel que

proporciona muchos beneficios y no ven la necesidad de ir más allá porque tienen cubiertas la mayoría de sus necesidades.

4. Cuantitativamente Gestionado o Nivel 4 CMM – CMMI: Los proyectos usan objetivos de fácil medición para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.

Los procesos que hay que implantar para alcanzar este nivel son:

Gestión cuantitativa de proyectos

Mejora de los procesos de la organización

5. Optimizado o Nivel 5 CMM – CMMI: Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica.

46


Innovación organizacional

Análisis y resolución de las causas

4.4.2 Gestión de Proyectos

Para el caso de la gestión de proyectos, se propone seguir las siguientes estructuras, y que están precisamente alineadas con los niveles de madurez antes mencionados.

La primera estructura corresponde a las áreas de proceso en las cuales se realizará un

manejo básico de proyectos, y que comprende el monitoreo y control de proyectos (PMC), la planificación de proyectos (PP) y el manejo de proveedores (SAM). Junto con esto se considera también la interacción de estos procesos con las áreas de ingeniería y soporte que llevarán a cabo los productos y servicios, así como los proveedores que entregarán los materiales necesarios.

Un esquema de las áreas de proceso antes mencionadas es el siguiente:

Figura 25: Áreas de Proceso para el Manejo Básico de Proyectos

47

La segunda estructura corresponde a las áreas de proceso en las cuales se realizará un

manejo avanzado de proyectos, y que comprende la gestión cuantitativa de proyectos (QPM), la gestión del riesgo (RSKM) y la gestión integral de proyectos (IPM + IPPD). Por supuesto se considera también la interacción de estos procesos con las áreas de procesos del manejo básico de proyectos así como con las áreas de ingeniería y soporte que llevarán a cabo los productos y servicios, y las áreas de manejo de procesos.

El esquema de las áreas de proceso antes mencionadas es:

Figura 26: Áreas de Proceso para el Manejo Avanzado de Proyectos

48

Capítulo 5 Metodología

5.1 Metodología para el Diseño e Implementación de la Solución

En esta sección se definen los lineamientos principales respecto a como se utilizarán los conceptos y teorías de procesos, proyectos y manejo de proyectos para la estructuración de una solución que permita planificar uno o varios proyectos de Telecomunicaciones en el marco de los proyectos desarrollados por la DGFDT, tomando en consideración todos los posibles factores que pueden llegar a incidir en dichos proyectos, de manera de tenerlos claramente identificados y poder anticiparse a posibles errores o situaciones de riesgo para el o los proyectos. Junto con esto se debe considerar la formulación de una solución que sumado al proceso de planificación, entregue una asignación de recursos de manera óptima, tomando en cuenta todos los proyectos en ejecución y con la flexibilidad necesaria para efectuar modificaciones en caso de aparecer posibles eventualidades que requieran asignaciones particulares. Por último se definirán los criterios de diseño para estructurar en forma general los procesos y flujos de trabajo relacionados con la ejecución y el control de los proyectos desarrollado y que dependen de los actores involucrados en cada proyecto.

La metodología de trabajo a seguir queda graficado en la figura siguiente:

Figura 27: Metodología

49

5.1.1 Elementos de Diseño

Para comenzar el diseño de la solución se consideran los elementos más relevantes de la metodología del PMI y el estándar del CMMI para el manejo de proyectos, y se analizará cuales de estos elementos deben estar presentes en la solución propuesta, de manera que sean un aporte efectivo. En particular se utilizan, dentro del grupo de procesos de la dirección de proyectos del PMI, los siguientes grupos: planificación, ejecución y control y monitoreo. Estos procesos son coincidentes con los que plantea el CMMI en sus áreas de proceso para el manejo básico de proyectos y de los cuales serán considerados: la planificación de proyectos (PP) y el monitoreo y control de proyectos (PMC).

Dentro del conjunto de las 9 áreas de conocimiento definidas por el PMI, se consideran solo algunas como las más relevantes para el diseño, marcadas en azul en la figura, donde los procesos que se considerarán para el manejo de la herramienta de gestión serán: gestión de alcance, gestión del tiempo, gestión de costos y recursos y gestión de calidad.

Figura 28: Áreas de Conocimiento del PMI a Considerar.

Como se explicará más adelante el proceso de gestión de calidad estará relacionado con

las políticas desarrolladas y los objetivos planteados en cuanto a la consecución de estos una vez terminado el proyecto, razón por la cual aparecerá en la mayoría de los procesos considerados.

Como un apoyo al proceso de planificación de proyectos, es que es utilizado el Modelo Tipificador de Proyectos de Instalación de Telecomunicaciones de manera tal que permita la construcción de una base de conocimiento de este tipo de proyectos, permitiendo utilizar dicha información al momento de planificar un nuevo proyecto o también durante el proceso de ejecución, ya que se entregará información de problemas y fallas producidos durante el desarrollo de las tareas que conforman a él o los proyectos y por supuesto de las soluciones encontradas. Esta información es incorporada por los propios involucrados en el desarrollo de dichas tareas de forma que pueda ser utilizada por ellos mismos en el futuro o por nuevos actores encargados de estas tareas.

50

Se consideran sólo algunos de los criterios definidos en el modelo, particularmente

aquellos más relevantes y que entreguen una cierta objetividad que permita asociarles un valor numérico que luego diferencie a cada uno de los proyectos que los posean dentro de las familias de proyectos definidas, por ejemplo en la tipificación de Magnitud, para un criterio de costos > US$2M el proyecto pertenecerá a la familia de Proyectos Singulares o Grandes.

De esta forma se utilizan para el diseño de la solución los siguientes criterios de cada

uno de las tipos de criterios definidas en el modelo:

Estratégicos De los 13 criterios definidos en el modelo de tipificación se utilizan 8 de ellos ya que

éstos cumplen con los requisitos mencionados. A continuación se describe cada uno de los criterios seleccionados:

Plazos: Este criterio determinará las fechas definidas para la realización del proyecto. Será considerado como un atributo obligatorio de cada uno de los proyectos al momento de ingresar el nuevo proyecto al sistema. Con las fechas de inicio y fin definidas se podrá calcular también la duración en días que tendrá el proyecto, incorporándolo como un atributo más.

Costos CAPEX: Este criterio está asociado a los costos de inversión que se llevarán a cabo para cada proyecto, lo que fija los límites de gasto en los que se incurrirá. Se definirá en un rango de 1 a 10, con valores enteros, que luego podrán ser ponderados por los valores reales de inversión en los proyectos de telecomunicaciones desarrollados por la GFDT de acuerdo a los límites máximos y mínimos existentes.

Nivel Tecnológico: De acuerdo a la tecnología disponible en el transporte de los datos en los servicios que entrega cada proyecto, se definirán 4 tipos y que serán almacenados como valores numéricos enteros del 1 al 4 correspondientes a cada tipo:

Baja (1): Uso de tecnología ya aplicada Media (2): Uso de tecnología conocida Avanzada (3): Uso de nueva tecnología Súper Avanzada (4): Uso de tecnología en desarrollo

Calidad de Servicio (QoS): Criterio dado por la garantía de transmitir una cierta cantidad de datos en un tiempo definido.

Se definirán 3 niveles de calidad de servicio: Bajo (1), Medio (2) y Alto (3). Un ejemplo claro de esto está en la diferencia entre proyectos de Backhaul por Fibra

Óptica v/s Backhaul Satelital.

51

Alcance: De acuerdo al nivel de profundidad de cada proyecto, se divide en 3 tipos y que serán almacenados como valores numéricos enteros del 1 al 3 correspondientes a cada tipo:

Ensamble (1): Construir un componente único. Sistema (2): Construir un conjunto complejo de elementos interactivos y sub-sistemas unidos con funciones independientes Arreglo (3): Construir un conjunto grande de sistemas

Cobertura: Este criterio está relacionado con la presencia que tendrá el proyecto en el mercado y los servicios disponibles local, comunal, zonal o regionalmente. Será asociado a valores enteros en el rango de 1 a 10.

VAN: Este criterio corresponde al indicador de la evaluación de proyectos que permite calcular el valor presente de un determinado número de flujos de caja futuros. Será asociado a valores enteros en el rango de 1 a 10, valores que a su vez podrán ser ponderados por un rango real de valores presentes existente actualmente.

Migración: Este criterio está asociado al cambio o adopción de nuevas tecnologías como desarrollo del proyecto. Se le asignarán valores de 1, si no hay migración y 2 si la hay.

Tácticos De los 7 criterios definidos en el modelo de tipificación se utilizan 4 de ellos y que se

describirán a continuación:

Escalabilidad: Este criterio esta relacionado con las necesidades de ampliar la cobertura o la cantidad de recursos. Se le asignarán los valores numéricos 1 si no es escalable, 2 si es escalable en cobertura, 3 si es escalable en recursos.

Integración: Este criterio se entiende como la capacidad de unificar los servicios simplificando la administración y acceso a los recursos. Será asociado a valores enteros en el rango de 1 a 10

Ancho de Banda: Están relacionados con las necesidades de ancho de banda del proyecto.

52

Será asociado a valores enteros en el rango de 1 a 10, éstos a su vez están relacionados con una cantidad de información transmitida por unidad de tiempo (Mbps)

Seguridad: Tiene relación con la protección de los datos o servicios del proyecto. Podrá definirse un rango de seguridad con valores enteros de 1 a 10.

Operacionales De los 7 criterios definidos en el modelo de tipificación se utilizan 4 de ellos y que se

describirán a continuación:

Interoperabilidad: Define la capacidad de operar transparentemente con los recursos existentes en el proyecto. Se definirá un rango de valores enteros de 1 a 10.

Disponibilidad: Tiene relación con cuan disponible está la operación del servicio entregado por el proyecto. Se definirá un rango de valores enteros de 1 a 10.

Costos-OPEX: Es el criterio asociado a los costos operacionales de cada proyecto, y que define entre otras cosas los límites de recursos. Se definirá un rango de valores enteros de 1 a 10, que puede ser ponderado posteriormente por valores de costo reales.

Ejecución

Se consideran los 3 criterios definidos para este caso en el modelo de tipificación y que se describirán a continuación:

Normativas: Tanto las normativas como restricciones existentes, ya sean permisos municipales, regionales o legales, serán incorporados a los proyectos como un atributo adicional. En él se adjuntarán él o los archivos correspondientes a los permisos requeridos por el proyecto.

Cantidad de Recursos: Este criterio esta asociado al número de recursos necesarios para llevar a cabo el proyecto. Será considerado como un atributo de cada proyecto y que podrá ser definido tanto para el número de técnicos como para el número de jefes de proyecto.

Infraestructura: Criterio relacionado con el nivel de obras civiles requeridas por el proyecto. Se definirá un rango de valores enteros de 1 a 10.

53

Una vez definidos los criterios del modelo de tipificación a utilizar, se analizan las

relaciones entre las metodologías y los procesos entregados por el PMI y el CMMI respectivamente. En las figuras 29 y 30 se aprecian los elementos relevantes aportados por los procesos PP y PMC, por el modelo de tipificación y por el PMI, y que serán utilizados en el diseño y que serán detallados a continuación:

Figura 29: Elementos para la Planificación y Ejecución de Proyectos

Figura 30: Elementos para el Monitoreo y Control de Proyectos

54

5.1.1.1. Duración

Inicialmente será definido por el responsable de proyectos fechas de inicio y término que entreguen una visión global de los plazos de cada proyecto, los que por supuesto están o no sujetos a modificación dependiendo del tipo de proyecto, el cliente, etc.

Pero para obtener tiempos mucho más precisos es necesario detallar las duraciones de cada tarea a realizar, conociendo los porcentajes de avance de cada tarea de manera de determinar efectivamente si un proyecto está cumpliendo los plazos establecidos, y si no es así, que tan atrasado está y en que tareas específicas, con el fin de apoyar dichas tareas y encausar el proyecto.

Para lograr lo anterior se requiere definir diagramas de descomposición funcional o

WBS, que permitan conocer en detalle los tiempos de cada tarea y sus grados de avance. Existen herramientas como el software comercial WBS Chart Pro que permite definir estos diagramas, pero dado que se desea entregar una solución completa que permita además entregar cartas Gantt de cada proyecto, es que se utilizará la funcionalidad que entrega GanttProject y que entre otras cosas permite tener una descomposición de cada tarea considerando el nombre de la tarea, la duración, el porcentaje de progreso, los recursos asignados, las tareas de las que depende la tarea en cuestión, etc.

5.1.1.2. Atributos de Productos y Tareas

Como se detalló anteriormente, se utiliza el modelo de tipificación para determinar un conjunto de criterios que serán asignados a cada uno de los proyectos a realizar. Estos criterios dependerán de los tipos de familias de proyectos a los que sea clasificado cada proyecto por el responsable, y que tendrán asignados valores estimados de acuerdo a lo definido por el propio responsable de acuerdo su experiencia, y que por supuesto serán validados al final del proyecto de manera que sea almacenado en un historial de proyectos con información fidedigna y que pueda ser utilizada en el corto plazo para el desarrollo de nuevos proyectos y que coincidan con los ya registrados.

5.1.1.3. Ciclo de Vida

Está considerado desde el momento de la estructuración de los procesos que apoyarán

la solución a desarrollar y que fueron diseñados considerando los grupos de procesos de la dirección de proyectos del PMI y que establecen un ciclo de vida para los proyectos.

5.1.1.4. Esfuerzo y Costo

Estas estimaciones serán realizadas utilizando como punto central la información histórica de proyectos previamente realizados.

55

Para el caso del esfuerzo será incluido como atributo a cada una de las tareas a realizar

en los distintos proyectos que se implementen. Este atributo será de tipo numérico de manera tal que al ser ponderado por el atributo de habilidad perteneciente a cada uno de los recursos, entregará como resultado el número de horas que dicho recurso deberá emplear para realizar y completar dicha tarea.

Por otro lado se define un costo para cada recurso de una cierta cantidad de UM/hr27, que dependerá del tipo de recurso (conocimientos, experiencia, entre otros) y de si es o no de planta, ya que serlo tiene un costo un costo muy inferior al de un recurso externo. Todo esto es utilizado en un modelo de asignación diseñado utilizando la teoría de problemas de programación lineal, y que entregará entre otras cosas, el costo total de cada proyecto dependiendo de las condiciones impuestas de tiempos límite, presupuesto, etc.

Ambos atributos serán explicados en mayor detalle en el capítulo 6 en la sección de proceso de asignación de técnicos.

5.1.1.5. Presupuesto y Calendario

Apoyado por el repositorio histórico de proyectos sumado a la herramienta GanttProject y al modelo de asignación, permite establecer escenarios que ayuden a definir con una visión más global, cuáles deberán ser los presupuestos y las fechas de inicio y término de los proyectos a implementar.

5.1.1.6. Plan para Manejo de Datos

De lo explicado anteriormente se utiliza el modelo de tipificación para efectuar una efectiva clasificación y almacenamiento de los proyectos, de modo de simplificar su uso futuro en la planificación de nuevos proyectos. Junto con esto se apoyará una metodología que apunte al registro de los principales problemas que hayan surgido durante la realización de cada tarea, con lo cual se tendrá finalmente una base de conocimientos que permita entregar solucionas a problemas que han aparecido previamente teniendo claro en que tareas se suscitaron y cuales fueron los procedimientos utilizados para solucionarlos.

5.1.1.7. Plan para manejo de Recursos

Se diseña un modelo de asignación que entregue como resultado las asignaciones de recursos a las distintas tareas pertenecientes a los proyectos en un período de tiempo previamente definido. Esta asignación dirá qué recurso será asignado a que tarea en que tiempo, donde la unidad de tiempo podrá ser una hora, medio día o un día, dependiendo de la precisión y el detalle que se quiera obtener.

27 Unidades Monetarias / hora

56

Pero antes de utilizar el modelo, se aplica un filtro a los recursos de manera de obtener

listas de recursos que estén capacitados para realizar las tareas de los proyectos a implementar, y que dependerá tanto de la especialidad requerida por la tarea, colocada como un atributo en cada tarea, y de la especialidad de cada recurso, que aparece también como un atributo en cada recurso.

5.1.1.8. Habilidades y Conocimientos Requeridos

Se emplean tanto como atributos de las tareas como de los recursos. Y se utilizan tanto en la elaboración del filtro que entregue el listado de recursos que están capacitados para realizar las tareas de los proyectos a implementar, como en el modelo de asignación y que permitan establecer condiciones que determinen que recursos pueden o no ser asignados a que tareas.

5.1.1.9. Parámetros de Monitoreo

Algunos de los parámetros que podrán ser observados son los tiempos de ejecución por intermedio de los porcentajes de avance. También se podrá analizar los costos incurridos (que están también relacionados con el tiempo de desarrollo), entre otros.

5.1.1.10. Monitoreo de Compromisos

Como consecuencia de lo anterior se irán comparando los resultados del seguimiento con lo establecido inicialmente en el plan del proyecto y que está relacionado directamente con los compromisos efectuados con el cliente.

5.1.1.11. Manejo de Datos Monitoreo

Este subproceso corresponde al apoyo que debe efectuarse para mantener actualizados los datos, incorporados en la planificación, durante la ejecución del proyecto y compararlos constantemente en caso de que se requiera efectuar algún tipo de acción.

5.1.1.12. Estado de Avance

Se estimula a los recursos encargados de desarrollar cada una de las tareas, a que actualicen permanentemente el nivel de avance de cada tarea de forma tal de poder utilizar esta información en el monitoreo y control de los proyectos.

57

5.1.1.13. Análisis de Problemas

Se tiene como apoyo para el análisis de problemas, la base de conocimiento de proyectos y tareas previamente realizadas y que entregan entre otras cosas soluciones a problemas ya presentados. Por supuesto en caso de no existir antecedentes se deberá efectuar análisis y estudio del problema y que una vez solucionado deberá ser registrada la solución encontrada, sumándola al repositorio ya existente. Estos registros pueden ser almacenados directamente en cada tarea utilizando GanttProject, y que luego será almacenada junto con el proyecto y cada tarea en un repositorio del sistema.

5.1.1.14. Toma y Manejo de Acciones Correctivas

Una vez finalizado el proyecto se podrá hacer un recuento de los problemas y soluciones encontradas, así como de las medidas que se deberán tomar a futuro en la planificación de proyectos similares para evitar que se produzcan nuevamente dichos problemas. Esta información quedará almacenada donde corresponda, ya sea en la(s) tarea(s) donde surgió el problema o como información del proyecto en su conjunto. El resumen de los elementos de diseño para los procesos de planificación y ejecución de proyectos y para los de monitoreo y control de proyectos se puede ver en la tabla 9 a continuación:

Elementos de Planificación y Ejecución Elementos de Monitoreo y Control

Duración Atributos de Productos y Tareas Ciclo de Vida Esfuerzo y Costo Presupuesto y Calendario Manejo de Datos Recursos Habilidades y Conocimientos Requeridos

Parámetros de Monitoreo Compromisos Manejo de Datos Estado de Avance Análisis de Problemas Toma de Acciones Correctivas Manejo de Acciones Correctivas

Tabla 9: Elementos para la Planificación y Ejecución de Proyectos

Sumado a los elementos anteriores se aprovecha la arquitectura de macroprocesos para

estructurar los procesos de manera coherente de forma que se generen relaciones entre ellos que permitan explicar y visualizar el funcionamiento de la solución y como ésta incide en los procesos de la organización. De los procesos detallados en la arquitectura se indaga y profundiza en el desarrollo del Macroproceso 1, también llamado cadena de valor, el cual considera precisamente los procesos relacionados con la “Preparación y Ejecución de Concursos”, y que serán detallados en el capítulo 6.

58

Complementando el diseño de Macroprocesos se tienen los procesos definidos en las

áreas de de proceso para el manejo avanzado de proyectos del CMMI, y de las cuales se decide optar por la gestión cuantitativa de proyectos (QPM) y por la gestión integral de proyectos (IPM + IPPD). Estos aportan con elementos que refuerzan el diseño realizado de manera de poder efectuar una gestión más completa, y que tal como se detalla en las etapas de evolución del CMMI, tendrán por objetivo elevar el manejo de proyectos de la empresa a niveles más avanzados, como Definido o Cuantitativamente Gestionado.

A continuación se puede ver una figura que muestra dichos elementos:

Figura 31: Elementos para el diseño de Procesos

5.1.1.15. Establecer Objetivos

Está considerado por supuesto como parte fundamental para el desarrollo de un proyecto, y a lo cual tanto el Responsable de Proyectos como los Jefes de Proyectos estarán destinados. Es aquí donde la solución entrega el apoyo necesario para mantener dichos objetivos definidos inicialmente así como el correcto funcionamiento de los procesos.

59

5.1.1.16. Componer el Proceso Definido

Desde el punto de vista de poder planificar correctamente un proyecto definiendo detalladamente cada tarea a realizar, es que se utilizará la información histórica de proyectos para determinar que tareas deberán realizarse para la implementación de un proyecto dado, de forma tal que si se determina que dicho proyecto es similar en cuanto a los tipos de familia a los que pertenecen y a los criterios y valores que estos poseen, podrá utilizarse en principio como una guía el listado de tareas del proyecto similar y quizás la carta Gantt de este utilizando algunas duraciones y costos.

5.1.1.17. Manejo del Funcionamiento

Constituye una composición de lo anteriormente mencionado, en donde se considera un monitoreo de los objetivos del proyecto, tanto de calidad como del funcionamiento de los procesos, junto con poder identificar las acciones correctivas respectivas a cada tarea o proyecto.

5.1.1.18. Establecer los Procesos Definidos del Proyecto

De acuerdo a lo establecido para el manejo de tareas en cada proyecto y que por intermedio de una descomposición detallada de las tareas a realizar, es que se efectúa la mantención de los procesos definidos del proyecto, desde su inicio y planificación hasta el cierre del proyecto.

5.1.1.19. Internalizar los Planes

Se incorporan en los procesos definidos para el diseño de la solución y por ende en la solución misma, los planes correspondientes al desarrollo del proyecto, pero también se considera la información de planes estratégicos de la empresa en caso de que sea necesario tomarlos en cuenta, como por ejemplo en la calidad de los proyectos entregados, ya que de existir planes que busquen posicionar a la empresa como la proveedora de productos y servicios de alta calidad es probable que se deban emplear más recursos en el desarrollo de los proyectos.

5.1.1.20. Gestionar el Proyecto Utilizando los Planes Internalizados

Una vez definidos los planes que afectarán al proyecto sumados a los planes y procesos propios del proyecto, se procederá a gestionar el proyecto de manera de efectuar tanto la asignación como el monitoreo y control de los recursos tomando los planes y procesos en consideración.

60

5.1.1.21. Contribuir a los Procesos Activos de la Organización

Es precisamente lo que se desea lograr mediante el diseño de procesos en la arquitectura de macroprocesos que se profundiza posteriormente en el capitulo 6.

5.1.1.22. Establecer la Visión Compartida del Proyecto

Desde el punto de vista de un buen manejo de proyectos y de la gestión del cambio que requiere implementar la solución propuesta, es que se debe establecer una visión que sea asimilada por todos los actores involucrados con el proyecto, y que apoya la obtención de los objetivos planteados.

5.1.1.23. Establecer la Estructura del Equipo Integrado

Esta estructura depende de las tareas que compongan cada proyecto, debido al atributo de especialidad que poseen y que establece qué recursos están capacitados para desarrollar dichas tareas. Con esto se puede definir una estructura para cada proyecto que diga cuales deben ser los tipos de recursos que deben integrar el proyecto, considerando también la cantidad de recursos.

5.1.1.24. Asignar Requerimientos a los Equipos Integrados

Como se explicó en el plan de recursos, se diseña un modelo que permita la asignación de recursos a cada una de las tareas de los proyectos a implementar, y que es donde se efectuará tanto la creación definitiva de los equipos de cada proyecto como el establecimiento de cuales serán las tareas que ejecutarán los miembros de cada equipo.

5.1.1.25. Asegurar la Colaboración entre los Equipos

Por último, se fomenta la comunicación entre los miembros de cada equipo por medio de una solución que sea accesible por todos los actores, como lo es una solución de tipo Web y que permite que estos puedan entregar sus avances, registros y establecer peticiones desde diversas ubicaciones, entregando mayor flexibilidad y facilitando el trabajo de los ejecutores.

El resumen de los elementos para el diseño de procesos se puede ver en la tabla 10 a continuación:

61

Elementos de Gestión Cuantitativa

Elementos de Procesos Definidos

Elementos de Principios IPPD

Establecer Objetivos Componer el Proceso Definido Manejo del Funcionamiento del Proyecto

Internalizar los Planes Establecer los Procesos de Definidos del Proyecto Gestionar el Proyecto Utilizando los Planes Internalizados Contribuir a los Procesos Activos de la Organización

Establecer la Visión Compartida del Proyecto Establecer la Estructura del Equipo Integrado Asignar Requerimientos a los Equipos Integrados Asegurar la Colaboración entre los Equipos

Tabla 10: Elementos para el Diseño de Procesos

5.1.2 Estructura del Diseño Una vez establecidos los elementos a considerar, y que se ha detallado el cómo inciden en el diseño de la solución, se establece la estructura general de diseño que explica la modularidad de la herramienta, como se puede ver en la siguiente figura:

Figura 32: Estructura Modular del Diseño de la Solución

De la figura 32 se desprende que son diseñados 3 módulos principales, los cuales

consideran los elementos fundamentales para efectuar un correcto manejo de proyectos y que fueron definidos en la sección anterior.

En particular se definen las relaciones que existirán entre cada uno de los módulos definidos y los elementos de diseño considerados.

62

Para la planificación se incorporan todos aquellos elementos que permiten definir una

metodología que apoye de manera efectiva el ingreso de nuevos proyectos, considerando el nombre de cada proyecto, un código identificador, los plazos, las tareas o actividades que lo conforman, las características y criterios asociados a cada tipo de proyecto de acuerdo al modelo de tipificación y a la estimación de los recursos a utilizar.

De los elementos de diseño anteriormente descritos, son considerados para la

planificación los que se muestran en la figura siguiente:

Figura 33: Relación de Elementos de Diseño con Módulo de Planificación En la figura 33 se aprecian elementos particulares del módulo de planificación y que se

ven de color azul, por otro lado existen 5 elementos comunes a todos los módulos y que se ven de color blanco.

En el caso de la asignación de recursos, se toman los elementos de diseño que se

consideran para la formulación del modelo de asignación a diseñar, de forma que tome en cuenta la información más relevante de los recursos y proyectos, particularmente de las tareas que componen dichos proyectos, como por ejemplo: prioridad de proyectos y tareas; dependencia de tareas; duración; dificultad; especialidad y habilidades de recursos; presupuesto.

De los elementos de diseño anteriormente descritos, son considerados para la asignación los que se muestran en la figura 34:

63

Figura 34: Relación de Elementos de Diseño con Módulo de Asignación

Finalmente para el seguimiento y control de proyectos, los elementos de diseño son utilizados para definir como apoyar y estructurar los flujos de trabajo para el desarrollo de las tareas que conforman un proyecto. Estos flujos son particulares para cada caso pero es posible definir elementos generales comunes y que serán considerados para el seguimiento como se muestran en la figura 35:

Figura 35: Relación de Elementos de Diseño con Módulo de Seguimiento

64

5.2 Herramientas de Diseño e Implementación

Una vez definida la metodología a seguir se procede a la búsqueda y selección de las distintas herramientas que permitan realizar tanto el diseño lógico y físico de la solución, de manera que permitan la construcción de un prototipo funcional que plasme el diseño realizado.

5.2.1 Framework Struts

Para la implementación del prototipo es utilizado el estándar para el desarrollo de aplicaciones Web llamado Struts [48], que trata de simplificar la implementación de una arquitectura siguiendo el patrón MVC28, el que separa la gestión del Workflow29 de la aplicación, del modelo de objetos de negocio y de la interfaz.

El controlador del patrón MVC esta encargado de redirigir o asignar una aplicación a

cada petición; debe poseer algún tipo de mapa de correspondencias entre peticiones y respuestas que se les asignan.

Una vez realizadas las operaciones necesarias el flujo vuelve al controlador y este devuelve los resultados a una vista asignada.

La funcionalidad de Struts en aplicaciones Web se puede ver a continuación:

Figura 36: Funcionalidad Struts

28 Model-View-Controller 29 Flujo de Trabajo

65

El navegador genera una solicitud que es atendida por el controlador, que se encarga de

analizar la solicitud, seguir la configuración que se le ha programado en su XML y llamar al Action correspondiente pasándole los parámetros enviados. El Action instanciará y/o utilizará los objetos de negocio para concretar la tarea. Según el resultado que retorne el Action, el controlador derivará la generación de interfaz a una o más JSP´s, las cuales podrán consultar los objetos del modelo para mostrar información de los mismos.

El funcionamiento en detalle se ve a continuación:

Figura 37: Funcionalidad Struts en Detalle El controlador posee la funcionalidad involucrada desde que un usuario genera un

pedido HTTP, hasta que se genera la interfaz de respuesta. Entremedio, llamará a los objetos de negocio del modelo para que resuelvan funcionalidad propia de la lógica de negocio y según el resultado de la misma, ejecutara la jsp que deba generar la interfaz resultante.

Struts incluye un Servlet que a partir de la configuración de struts-config.xml recibe las solicitudes del usuario, llama al Action Bean que corresponda y, según los que este retorne, ejecuta una JSP.

La clase Action por su parte tiene por objetivo procesar una solicitud, y devolver un objeto ActionForward que identifica donde se debería reenviar el control para proporcionar la respuesta apropiada.

66

El diagrama a continuación describe el flujo en más detalle:

Figura 38: Diagrama de Secuencia Struts

El Usuario (User) hace clic sobre un link en una página html.

El controlador del Servlet recibe la petición, busca la información de mapeo en struts-config.xml, y rutea hacia un Action.

Action hace un llamado a un servicio (Service) de modelo de capas.

Service hace un llamado a la capa de datos (Data), base de datos, y se devuelven los datos solicitados.

Service los devuelve al Action.

Action los envía hacia una fuente visual (página JSP).

Servlet busca la información de mapeo por la fuente requerida y la envía hacia la página JSP apropiada.

El archivo JSP es invocado y enviado al browser como HTML.

Se le presenta al Usuario la nueva página HTML en un browser Web.

67

5.2.2 Herramienta para Modelado UML

Existen múltiples herramientas par trabajar con UML [27], tanto comerciales como open source30, considerando que se trabaja con el estándar Struts, se utiliza entonces la plataforma comercial de Red Hat Developer Studio, que es una herramienta bastante completa para el diseño y creación de aplicaciones Java.

5.2.3 Plataforma del Servidor

Una de las particularidades de J2EE es que al estar basado en Java, puede ser ejecutado en cualquier plataforma, por lo cual se podrá elegir tanto una plataforma Windows como una plataforma Linux que sea open source, y que también puede ser utilizada para uso comercial.

5.2.4 Servidor de Aplicaciones J2EE

Para el servidor se elige también un desarrollo de tipo open source, encontrando como opción interesante a JBOSS que está muy difundido y es muy estable y que es posible utilizarlo también en aplicaciones comerciales, y dado que esta escrito en Java, corre perfectamente tanto

bajo Windows como en Linux.

5.2.5 Motor de Base de Datos

Se considera a MySQL como la opción para la base de datos debido a que también es open source y es ampliamente la más utilizada en aplicaciones Web.

Considerando que al utilizar Struts la capa de base de datos queda abstraída por este framework, es posible en un futuro migrar a otro motor de bases de datos de ser necesario, sin tener que cambiar el modelo de la aplicación.

MySQL puede correr bajo plataformas Windows o Linux, en caso que se quiera trabajar sobre una u otra.

5.2.6 Aplicación para el Manejo de Cartas Gantt

De las herramientas actualmente disponibles en el mercado se analizan los elementos de los que disponen para la gestión de proyectos, actividades y tareas, y de qué elementos carecen de forma que se requiera la incorporación de aplicaciones mas completas.

Como resultado de la búsqueda se tiene que la herramienta GanttProject cumple con

los requisitos necesarios para conformar la herramienta final. A continuación se describirán algunas de sus características principales [28].

30 Es precisamente la característica de código abierto la que se privilegiará por fines docentes para el diseño de la herramienta.

68

Ganttproject es una aplicación completamente escrita en Java que permite manejar

proyectos utilizando como interfaz diagramas gantt, permitiendo descomponer los proyectos en tareas, mostrar dependencias y manejar recursos.

Para la creación de tareas permite organizarlas por grupos o categorías de forma de generar jerarquías, para posteriormente definir relaciones de dependencia entre ellas.

Dentro de las funciones básicas esta la de asignar a cada tarea su duración, el porcentaje completado, fechas de inicio y término, prioridades, notas explicatorios, entre otros.

Los recursos sobre los que trabaja son RRHH, asignando los roles dentro del proyecto y sus formas de contacto.

Posee también la posibilidad de generar un diagrama Pert, que es una herramienta cuantitativa de planificación y control, lo que permite a los administradores contar con un modelo de optimización que entregue la solución óptima de una secuencia de actividades en el tiempo, que deben realizarse para finalizar el plan de acción. También permite al administrador programar un proyecto por adelantado y a la vez calcular el tiempo necesario para completarlo.

Finalmente permite exportar el trabajo como imagen (JPG, PNG) o como XML, y que es lo que ayudará en definitiva para establecer la conexión con la herramienta.

Plataforma Estado Comercial Lenguaje Archivos

Linux, Windows GNU General Java Public License

Java XML, JPG, HTML, etc.

Tabla 11: Características Generales de GanttProject

Un ejemplo de carta gantt de un proyecto se puede ver en la figura a continuación:

Figura 39: Ejemplo de Herramienta GanttProject

69

5.2.7 Aplicación para la Formulación de Problemas de Programación Lineal

Se propone como herramienta de modelamiento y formulación del problema de programación lineal, al Sistema General de Modelación Algebraica, GAMS, que es un lenguaje soportado por un paquete informático, que permite el modelado, análisis y resolución de diversos problemas de optimización independiente del método de resolución asociado al mismo [30].

Inicialmente el manejo y comprensión de sus estructuras, requiere de un cierto

esfuerzo, pero que una vez manejadas se dispone de una herramienta potente para el manejo y resolución de problemas de programación matemática.

Los elementos más relevantes de GAMS se destacan a continuación:

1. Su capacidad para resolver problemas pequeños (docenas de variables y restricciones) y

grandes problemas (miles de variables y restricciones) escribiendo básicamente el mismo programa. Dispone de una forma compacta y eficiente para escribir bloques de ecuaciones similares sin más que escribir “una de ellas”.

2. Se separa la definición del modelo de la técnica de resolución. El usuario de GAMS

formula el modelo consistentemente, y una vez expresado en notación GAMS, uno de los programas disponibles se encarga de generar la solución. Como resultado, el usuario se centra en el modelado, sin ser perturbado por los problemas técnicos de los algoritmos de resolución. Esto hace posible un proceso de modelado muy sencillo y agradable.

3. Prácticamente reproduce la descripción del problema de programación matemática.

Como resultado, el código GAMS es casi auto-explicativo para los lectores que tengan una mínima formación en optimización.

4. Suministra también mecanismos que permiten resolver colecciones de problemas de

optimización estructurados, tales como los de técnicas de descomposición.

5.2.8 Aplicación para el Diseño y Ejecución de Flujos de Trabajo (Workflow)

Se consideran 2 herramientas para estos efectos, una para el diseño de flujos de trabajo y otra como motor que sobre un servidor permita ejecutar estos flujos permanentemente. Inicialmente se describirá el lenguaje sobre el cual trabajan estas herramientas y que está relacionado con los diseños de procesos aplicados para la solución propuesta.

70

5.2.8.1. BPEL

Lenguaje de ejecución de procesos de negocio (o BPEL con su sigla en ingles), corresponde a un lenguaje para orquestación escrito en XML, que describe la lógica de la interacción entre “servicios Web” de un proceso de negocio [23].

Entre otras cosas, permite especificar formalmente procesos de negocio y protocolos de interacción, así como ayuda a minimizar la brecha entre el negocio y la tecnología.

Dentro de las definiciones que tiene BPEL es posible ver entre otras cosas: flujos de control; variables; ejecución concurrente; entradas y salidas; manejo de transacciones y manejo de errores.

A través de un documento XML BPEL, un analista de negocio es capaz de representar la lógica asociada y los elementos con los que se verá relacionado. Estos elementos serán servicios Web y la lógica el proceso BPEL.

A modo de ejemplo, si se tiene un flujo de negocio determinado con una entrada A y una salida Z, éste se podría componer de muchos procesos internos que se lanzarían dependiendo de valores y respuestas anteriores. BPEL sería el encargado de orquestar todo el proceso ordenando qué proceso ejecutar (servicio Web) y en qué momento.

5.2.8.2. ActiveBPEL El motor ActiveBPEL Engine es un ambiente de ejecución en tiempo real, bajo la licencia GPL (open source) y escrito en Java, y que es capaz de leer y ejecutar definiciones de procesos BPEL. Por ejemplo, cuando un mensaje entrante gatilla un inicio de actividad, el motor crea una nueva instancia de proceso y comienza a correr. El motor se encarga de la persistencia, mensajes, alarmas y otros detalles de ejecución. El motor ActiveBPEL corre sobre cualquier contenedor de servlets, como por ejemplo, Apache Tomcat o JBOSS. Junto con lo anterior se tiene un diseñador visual para BPEL llamado ActiveBPEL Designer, que es un entorno de desarrollo especializado en la generación visual de modelos de orquestación que utilizan BPEL. Está basada en la plataforma Eclipse, y aunque no es de código abierto, es una herramienta gratuita. Está optimizada para el uso con servidores de orquestación BPEL de la propia compañía (ActiveBPEL Engine).

71

5.2.9 Aplicación de Apoyo para Manejo de Contenidos

Como una forma de incentivar la utilización de la solución propuesta al interior de la División, es que fue considerada la incorporación de un sistema de manejo de contenidos (CMS) que permitiera crear una interfaz amena y con información de interés para la organización.

Es así como se consideró implementar una plataforma lo suficientemente amplia como para incorporar diversas herramientas que permitiesen apoyar el trabajo realizado simplificando la forma de realizar dichas actividades. De esta manera es que luego de hacer un estudio de las

plataformas existentes fue que se consideró el sistema de gestión de contenidos (CMS31

) llamado Joomla.

Este sistema, al igual como todas las herramientas utilizadas para este proyecto, es de

código abierto y fue programada mayoritariamente en PHP bajo una licencia GPL, teniendo como requisitos una base de datos como lo es MySQL y de un servidor como HTTP Apache.

Figura 40: Patrón MVC de Joomla

Como se ve en la figura anterior, la arquitectura del sistema sigue el patrón MVC que fue explicado anteriormente.

De la figura 41 se puede ver que Joomla posee una arquitectura de 3 capas y que se

detallan a continuación:

La primera capa corresponde al nivel de Framework, y consiste en librerías y plugins.

La segunda es la capa de aplicación y conformada por distintas clases de aplicación. Actualmente existen 3 aplicaciones que vienen incorporadas: JInstalación, JAdministrador y JSitio. Cada aplicación actúa como un controlador principal de la página.

31 Content Management System

72

La 3era capa es el nivel de extensiones. Este nivel es donde todos los componentes, módulos y lógica de templates son ejecutados y mantenidos.

Figura 41: Arquitectura Joomla

Algunas de las descripciones relevantes de la conformación de la arquitectura son: EXTENSIONES Una extensión corresponde a un paquete que extiende de cierta manera la instalación

(funcionalidad) de Joomla. Componente Un componente es una de las extensiones más grandes y complejas de todas, pueden

entenderse como pequeñas aplicaciones. Un componente se compone de 2 partes principales, una de administrador y la otra del sitio. Los componentes utilizan la mayor parte de la página pues estos son manejados por un ítem del menú donde cada uno de ellos acciona un componente.

Módulo Los módulos son extensiones compactas y flexibles, y que algunas veces están linkeadas a

componentes, como es el caso del módulo de las “últimas noticias” que está asociado al componente de contenido y que muestra links a los más actualizados ítems de contenido.

Plugin Es como si fuera una extensión de Joomla, siendo en esencia controladores de eventos y

proveen rutinas que son asociadas con eventos accionadores de Joomla. Template Corresponde a un tipo de extensión de Joomla que cambia la forma en que se ve el sitio.

Es básicamente el diseño del sitio web. Los templates poseen ciertos campos en los que los componentes y los módulos serán

desplegados.

73

5.2.10 Configuración Definitiva de la Solución

Plataforma de Desarrollo

J2EE

Herramientas de Modelado

Modelado Clases y Casos de Uso: IBM Racional 6.0

Modelado Diagramas: Enterprise Architect 7.1

Entorno de Desarrollo

RedHat Developer Studio Beta 2

Eclipse 3.3.0 v2007

Plataforma de Servidor

SO Servidor: Linux (Ubuntu)

Servidor de aplicaciones J2EE: Apache Tomcat 5.5

Motor de base de datos: MySQL 5.0.22

Herramienta para Administración MySQL

EasyPHP 2.0

Herramienta de Manejo de Cartas Gantt

GanttProject 2.0.4

Herramienta para Formulación de PPL

GAMS Integrated Development Environment

Herramienta de Diseño y Ejecución de Flujos de Trabajo

ActiveBPELDesigner

ActiveBPELEngine

Sistema para el Manejo de Contenidos

Joomla

74

Capítulo 6 Rediseño del Proceso de Negocios En el presente capítulo se detalla el trabajo de modelamiento de los procesos observados al interior de la DGFDT, así como el rediseño realizado. En particular se revisará y rediseñará el proceso de asignación de recursos a los diferentes proyectos y tareas, y se explicará cuál es la lógica diseñada para estos efectos. Por último se describe en detalle el diseño de las aplicaciones de apoyo para el rediseño de procesos propuesto.

Inicialmente se explica cual es la estructuración de la arquitectura de procesos para el rediseño de la solución planteada en el marco de los proyectos desarrollados al interior de la DGFDT. El objetivo es establecer como incide la solución en los distintos procesos y a su vez qué elementos aporta cada uno de ellos al diseño de la solución.

En el punto 6.2 se explica el diseño del modelo de asignación de recursos explicando cuales son atributos más relevantes a considerar.

En el punto 6.3 se desarrolla el diseño de la herramienta de software que representa

uno de los resultados de la solución establecida, y en los que se estipula en detalle cual será la funcionalidad deseada, la arquitectura lógica y física, y posteriormente en el capítulo 7 se muestra el prototipo como resultado de este diseño.

Figura 42: Resultados Obtenidos

75

6.1 Modelamiento del Rediseño de Procesos

A continuación se detallarán cada uno de los procesos considerados para el desarrollo del proyecto y que fueron modelados usando la notación IDEF0 utilizando la herramienta iGrafx [28].

La estructura de estos procesos y subprocesos fue diseñada siguiendo inicialmente lo observado al interior de la DGFDT al comienzo del trabajo de tesis, añadiendo los rediseños necesarios para mejorar los procesos de asignación de recursos, planificación, ingreso y gestión de proyectos, entre otros.

El Macroproceso analizado, como se puede ver en la siguiente figura, será la Macro 1, “Preparación y Ejecución de Concursos”, de la cual se describirán cada uno de los subprocesos relevantes para el proyecto realizado.

Figura 43: Macroprocesos Como se puede ver en la figura la Macro 1 tiene varias entradas y salidas relevantes,

entre las que se pueden ver: El ingreso de los planes estratégicos de la Subsecretaría de Telecomunicaciones, representados por los planes de proyectos, también el de las nuevas capacidades que representan por ejemplo, mejoras en los productos y servicios desarrollados, y el de insumos y recursos externos.

76

Por otro lado, se tendrán salidas como los productos o servicios entregados a los

clientes, como son las Bases a Publicar de los Concursos o en su defecto el Texto Refundido, así como las necesidades ya sean de recursos o insumos, o simplemente la salida de información de procesos pertenecientes a la gestión y que apunta a la mejora o rediseño de éstos.

Observando los procesos de la macro 1, que corresponde a uno de los macroprocesos

más importantes, ya que representa la cadena de valor de la DGFDT, considerando desde el ingreso de los requerimientos por parte de los clientes (GORES, autoridades u otras instituciones), la obtención principalmente de información por parte de los proveedores, la gestión del desarrollo de los diferentes proyectos y la elaboración de un diseño técnico junto con la construcción de bases para el desarrollo posterior de un concurso.

En particular y como se puede ver en la figura a continuación, los procesos relevantes consideran la gestión del desarrollo de proyectos y la construcción de Bases, dentro de los cuales se encuentra entre otros, la gestión y planificación de proyectos, la asignación de recursos, que serán los puntos más importantes a considerar y que serán detallados en los puntos siguientes. El control de las diferentes tareas a realizar será considerado a lo largo del proceso de Diseño Técnico, Construcción de Bases y Desarrollo de Concurso.

Figura 44: Preparación y Ejecución de Concursos

77

6.1.1 Gestión del Desarrollo de Proyectos

Corresponde a un proceso perteneciente a la Macro 1, y que es el encargado del proceso de como llevar a cabo cada proyecto a ser realizado, y que básicamente considera el ingreso de requerimientos para un nuevo proyecto, la incorporación de nuevas soluciones o productos y servicios, y parte de la información de la planificación de la DGFDT.

En este proceso se considera un subproceso encargado de definir cuales y como se llevarán a cabo las nuevas soluciones y servicios a desarrollar, entregando las instrucciones generadas al proceso de gestión y planificación de cada proyecto, que es el proceso al cual daremos mayor importancia y que es precisamente el núcleo del rediseño, que tal como dice su nombre será donde se generen las planificaciones de cada uno de los proyectos a desarrollar por la DGFDT, y que consideran desde el ingreso de nuevos proyectos, las selección de los proyectos a implementar, la asignación de recurso y el inicio de la ejecución de proyectos, entre sus principales funciones.

Figura 45: Gestión del Desarrollo de Proyectos

78

6.1.1.1 Gestión y Planificación del Proyecto

Entrando en el detalle de este proceso, éste comienza por la instrucción de la

Autoridad con respecto a la realización de un concurso, indicando el tipo de proyecto y las entidades a las que se beneficiará, con lo cual se elabora la carta Gantt por concurso.

La decisión de elaborar una cartera de requerimientos depende del tipo de proyecto y las entidades beneficiadas. La Autoridad puede definir no realizar cartera de requerimientos. En ese caso los requerimientos pasan directamente al diseño y evaluación del proyecto.

Hasta el mes de junio de cada año se recepcionan las solicitudes de provisión de

servicios de telecomunicaciones para los concursos del año siguiente, lo que no impide que se incorporen requerimientos dentro del desarrollo del procedimiento, de acuerdo a la decisión de la Autoridad, según se observa en los flujos de los procesos mostrados más adelante.

Figura 46: Gestión y Planificación del Proyecto

79

6.1.1.1.1 Elaboración de Cartera de Requerimientos

Primero que todo es necesario explicar los conceptos que están detrás del siguiente proceso:

Entidades: Unidad territorial o funcional mínima para la definición de requerimientos de servicios de telecomunicaciones y la correspondiente ejecución de concursos. Cartera de Requerimientos: Listado de entidades, confeccionado a partir de los requerimientos efectuados por distintas instituciones públicas, privadas y la ciudadanía, que presentan necesidad de provisión de servicios de telecomunicaciones que se enmarcan en los criterios de focalización de la DGFDT. Requerimientos: Documento que hace referencia al maestro de las entidades filtrado que contiene al menos: información política administrativa, coordenadas, presencia de servicio de Telecomunicaciones (Voz y/o Datos), servicios Básicos (Electricidad), Información Demográfica (Población y/o hogares).

Figura 47: Elaboración de Cartera de Requerimientos

Una vez definidos los criterios para la cartera de requerimientos, ésta se elabora

siguiendo los pasos siguientes: a) Se recopilan los requerimientos no considerados en los concursos de años

anteriores y los requerimientos del año en curso de acuerdo a solicitudes efectuadas por diferentes vías, por ejemplo: requerimientos de instituciones públicas, autoridades, ciudadanía en general.

b) La autoridad determina los criterios para la elaboración de la cartera de

requerimientos, estableciendo los tipos de solicitudes y algunas condiciones para considerar ciertas entidades en los concursos a realizar el presente año.

80

c) Con los criterios anteriores, se conforma la cartera de requerimientos del año en

curso.

d) Una vez aprobada la cartera de requerimientos filtrada del año en curso, se determina la necesidad de realizar una priorización de los proyectos. En caso de no ser necesario priorizar esta cartera, se envía al DI para la elaboración de la ficha de alcance.

e) La cartera de requerimientos filtrada podrá ser devuelta por el DI si es que no

cumple con los requerimientos mínimos especificados. f) En caso de ser necesario la priorización, se prosigue según las actividades descritas

a continuación.

6.1.1.1.2 Priorización

Una vez decidida la necesidad de realizar una priorización en la cartera de proyectos, se procede de acuerdo a lo mostrado en la figura 48:

Figura 48: Priorización32

Primero se definen los criterios de priorización de acuerdo a las instrucciones de la autoridad. Por ejemplo: priorizar aquellas entidades que cuenten con servicio eléctrico o un número de habitantes suficiente.

32 La decisión de realizar una priorización de entidades depende del tipo de concurso y de los recursos presupuestarios existentes.

81

En caso de que existieran nuevos requerimientos, éstos se incorporan a la cartera a ser

priorizada.

Se envía un oficio de solicitud de priorización a los gobiernos regionales para que realicen la priorización de los requerimientos presentados de acuerdo de los criterios definidos.

Los asesores regionales apoyan el proceso de priorización de los gobiernos regionales, a

través de la entrega de información y explicación del procedimiento de priorización. Se reciben las priorizaciones solicitadas y se revisa que la información se encuentra en

las condiciones requeridas. Se realiza una sistematización de la información que considera la búsqueda y

recopilación de mayores antecedentes que no aparecen en el oficio de priorización. Lo anterior se realiza con trabajo de apoyo de los asesores regionales.

Con la información sistematizada se genera la cartera de requerimientos del año t (en

curso) priorizada, que constituye un insumo para el proceso de Planificación de Tareas para el Diseño y Evaluación del Proyecto.

La Cartera de requerimientos priorizada podrá ser devuelta por el DI si es que no

cumple con los requerimientos mínimos especificados.

6.1.1.1.3 Planificación de Tareas para el Diseño y Evaluación del Proyecto

Es a partir de este proceso que comienzan a incorporase modificaciones a la estructura actual o rediseño de procesos.

Figura 49: Planificación de Tareas para el Diseño y Evaluación del Proyecto

82

En particular se analiza la manera en que se canalizan los requerimientos desde que

ingresan, ya sea como cartera o requerimientos directos, hasta que son tomados por los diferentes recursos, los cuales llevan a cabo las diferentes tareas tendientes a diseñar y evaluar un proyecto de telecomunicaciones, y que puede ir desde la construcción de un Backbone de fibra óptica, hasta una red de acceso de última milla inalámbrico en cualquiera de las últimas

tecnologías disponibles33

. El detalle de cada uno de los 4 procesos mostrados en la figura 49 será detallado en los

puntos que vienen a continuación.

6.1.1.1.3.1 Elaboración Ficha de Alcance y Obtención de Atributos

Para la realización de cada concurso la autoridad entrega los lineamientos que definen el tipo de concurso a realizar, el presupuesto y los plazos. A partir de estas directrices y recibiéndose la cartera o los requerimientos directos se elabora la ficha de alcance.

Figura 50: Elaboración Ficha de Alcance y Obtención de Atributos

El contenido de la ficha de alcance es validado por la autoridad y puede ser modificado

a lo largo del proceso. Esta ficha es un documento que contiene al menos los siguientes ítems de cada

proyecto: requerimientos iniciales, alcances del proyecto, objetivos, resultados esperados, plan de actividades principales, equipo de trabajo, hitos relevantes.

Una vez definida la ficha de alcance se procederá con el ingreso de un nuevo proyecto,

y que es uno de los procesos incorporados en este rediseño. Ello, se describe a continuación.

33 Es importante recalcar que si bien los diseños se realizan considerando una tecnología en particular (WiMAX, UMTS, etc.), lo que se exige en las Bases de cada concurso no son las tecnologías, sino los estándares de calidad mínimos con los que deberá operar la empresa que se adjudique el concurso.

83

6.1.1.1.3.1.1 Ingreso de Nuevo Proyecto

En las figuras siguientes se muestra el diagrama de pistas para el ingreso de un nuevo

proyecto y que considera la incorporación de los atributos relevantes del proyecto (código, nombre, fecha inicio y término) y de atributos que permitan categorizar al proyecto considerando las características siguientes: Magnitud (pequeño, estándar y grande), Naturaleza (apertura, mejoramiento y ampliación) y Tipo de Servicio (Core, Distribución, NGN, etc.). Junto con lo anterior, cada proyecto tendrá una serie de criterios asociados a estas características y que permitirán definir mas en detalle una clasificación que permita a futuro compararlo con otros proyectos realizados y por ende poder utilizar esta información en futuros proyectos.

Figura 51: Ingreso Nuevo Proyecto

84

6.1.1.1.3.2 Definición de Tareas y Prioridades

Se considera la selección de los proyectos a implementar en un período definido de tiempo, y que por supuesto no hayan sido ejecutados, incorporándoles un nivel de prioridad tanto a los proyectos como a sus tareas, que permitirá posteriormente realizar una asignación experta que considere este atributo, optimizando el uso de recursos.

Figura 52: Definición de Tareas y Prioridades La definición de prioridad de proyectos y tareas determina cuál es el grado de

relevancia que tendrán dentro de la cartera de proyectos y tareas de la empresa, y que en principio estará definida como un valor asociado a cada uno dentro de una escala de -10 a 10, donde el numero más negativo (o el menor en el caso de los positivos) es el de mayor importancia.

La labor de definir cuál será la prioridad en cada caso, dependerá del criterio tanto del

Jefe de División, en el caso de los proyectos, como del Jefe de Departamento, en el caso de las tareas particulares que deba desarrollar el DI.

85

6.1.1.1.3.3 Decidir Asignación y Mejora Recurso

Este proceso considera el subproceso necesario para la asignación del recurso a cada proyecto, y mas específicamente a cada tarea dentro de dicho proyecto, uno encargado de decidir la aplicación de incentivos a los recursos y un último subproceso encargado de decidir la capacitación del recurso en caso de ser requerido.

Figura 53: Decidir Asignación y Mejora Recurso

Se puede ver que el más relevante corresponde al primero, “Decidir Asignación

Recursos” y que dadas las tareas y requerimientos a implementar, entre otros, entregará las asignaciones de los distintos recursos a cada una de las tareas a implementar. Este proceso esta dividido a su vez en 2 subprocesos: “Procesar Necesidades Tareas” y “Asignar y dar Instrucciones a Recursos”, que serán explicados a continuación.

86

6.1.1.1.3.3.1 Decidir Asignación Recursos

Antes de llegar a la asignación misma de recursos se diseña un pequeño filtro que entregue un listado de los recursos capacitados para realizar las tareas encomendadas, esto es, que del total de recursos disponibles se tomen aquellos que cumplen por lo menos con la especialidad requerida por alguna de las tareas, por supuesto que en principio se dará que dada la cantidad de tareas (debido a la cantidad de proyectos) a resolver serán elegidos casi o la totalidad de los recursos existentes, pero pudiera darse el caso que no fuese así.

Figura 54: Decidir Asignación Recursos

El proceso de asignación por otro lado, recibe esta lista junto a las tareas a implementar y sus prioridades, y se encarga de efectuar la asignación, así como de generar instrucciones de capacitación o mejora a los recursos en caso de ser requerido por una tarea determinada. A continuación se analizarán ambos procesos.

6.1.1.1.3.3.1.1 Procesar Necesidades Tareas

El primero de estos subprocesos considera la obtención de los requerimientos y especificaciones de cada proyecto de forma tal de utilizar dicha información (características, duraciones y criterios) para de esta manera determinar una lista preliminar de recursos que cumplen con los requisitos de los proyectos esto de acuerdo a la especialidad de dichos recursos, enviándose esta lista con los posibles candidatos al subproceso de “asignar y dar instrucciones a recursos” que es donde se encuentra el modelo de asignación.

87

Figura 55: Procesar Necesidades Tareas

El proceso de “obtener la lista de recursos” considera la utilización de la especialidad y

habilidad de los recursos, y que realizando una comparación con lo solicitado por cada tarea, es posible si el recurso cumple con los requisitos de al menos una tarea, que es lo básico para poder pertenecer a la lista de recursos a asignar.

Figura 56: Obtener Lista Recursos Adecuados

88

6.1.1.1.3.3.1.2 Asignar y dar Instrucciones a Recursos

En este subproceso final, se asigna y da instrucciones al cada recurso de acuerdo a la lógica que aparece en los 3 subprocesos que lo conforman, y que son: “Determinar Esfuerzo por Tarea”, “Asignar Recursos por Tareas” e “Instrucciones Mejora Recurso”.

Figura 57: Asignar y dar Instrucciones a Recursos

En los 2 primeros procesos está lo central del sistema de asignación, y donde en el

primero se determina el nivel de esfuerzo que se requiere para realizar una tarea determinada por parte de un recurso ideal. Esta información es dirigida junto a las de tareas y prioridades y a la lista preliminar de recursos y es entregada al segundo proceso que es donde se encuentra la lógica y será realizado finalmente la asignación de recursos.

A continuación se detallan cada uno de estos 3 procesos.

89

Determinar Esfuerzo por Tarea

En determinar el esfuerzo por tarea, se tiene que se analizan las características con las cuales se está definiendo el proyecto, y que son: Magnitud, Naturaleza y Tipo de Servicio. Una vez hecho esto, se obtienen los criterios asociados a este proyecto y que lo describen mas en detalle, y que mediante los cuales se determinará el nivel de esfuerzo que se deberá realizar para llevar acabo dicha tarea y que será un atributo numérico que ponderado por el atributo de habilidad de cada recurso, se obtendrá el nivel de esfuerzo medido en cantidad de horas que dicho recurso deberá utilizar para desarrollar la tarea.

Figura 58: Determinar Esfuerzo por Tarea

Asignar Recursos por Tareas

Luego, utilizando el atributo de esfuerzo, sumado a la lista preliminar de recursos a asignar, en la que se incluyen los atributos de cada recurso (especialidad, habilidad, entre otros) mas la información de tareas a realizar y prioridades, proveniente de los otros procesos, y que será utilizada en un modelo de programación lineal para determinar cuales serán los recursos a asignar a las distintas tareas que conforman el proyecto a desarrollar. El detalle del modelo será explicado mas adelante.

90

Figura 59: Asignar Recursos por Tareas

Instrucciones Mejora Recurso

Finalmente se le da las instrucciones de mejora a los recursos en caso que requieran de capacitación para la o las tareas que vayan a realizar.

Figura 60: Instrucciones Mejora Recurso

91

Finalmente y para los procesos de “Decidir Asignación y Mejora Recurso” se deja de

manifiesto la opción (ya que por el momento no será considerando dentro del sistema final a implementar) de aplicar incentivos o beneficios a los recursos de acuerdo a su nivel de desempeño dentro de cada proyecto (ver figura 53), con la finalidad de potenciar aun más el desarrollo de proyectos dentro de la empresa; y también estará considerada la opción de realizar la capacitación del recurso de acuerdo al tipo de ámbito que abarca el proyecto y a la(s) tarea(s) especifica(s) que deberá llevar a cabo dicho recurso, y que estará dado por la información proveniente del mensaje de “Instrucción Mejora Recurso” que determina si requieren capacitación o no.

6.1.1.1.3.4 Iniciar Ejecución del Proyecto

En este último proceso de “Planificación de Tareas para el Diseño y Evaluación del Proyecto” (ver figura 49) se considera la selección por parte del responsable de los proyectos (Jefe de División), de todos los proyectos que se desee iniciar su ejecución, y que implica el informar a los recursos asignados a estos proyectos, cuales serán las tareas que deban desarrollar, cuales serán los tiempos de entrega y requerimientos entre otros.

Es necesario aclarar que tanto el Jefe del DI como el Coordinador de la UGP pueden ser a su vez responsables por la parte del proyecto que les toca manejar, apoyando así al Jefe de División en las distintas actividades a realizar, razón por la cual para este caso se les entrega la doble calidad de responsables y jefes de proyecto, y que es visualizada de esta forma por el sistema.

Por último serán informados tanto los jefes de proyecto como los recursos asignados, dando inicio al proceso de “Diseño Técnico, Construcción de Bases y Desarrollo de Concurso” que considera seguimiento de cada una de las tareas de acuerdo al tipo de recurso técnico involucrado y también se considerará el proceso de control que lleva a cabo el responsable de proyectos y que es el que finalmente se encarga de la buena implementación de la totalidad de los proyectos.

Figura 61: Iniciar Ejecución del Proyecto

92

6.1.2 Diseño Técnico, Construcción de Bases y Desarrollo de Concurso

Este es el proceso principal que se desarrolla al interior de la DGFDT y que considera como subprocesos más relevantes los mostrados en la figura 62:

Figura 62: Diseño Técnico, Construcción de Bases y Desarrollo de Concurso

El flujo parte con el Diseño y Evaluación de Proyectos, proceso realizado principalmente por el DI con el apoyo de la UGP en el tema de la caracterización de entidades y que será detallado en el proceso respectivo.

El trabajo de apoyo de bases consiste en la disposición de recursos del DI para la

revisión y redacción de las bases de acuerdo de los requerimientos de la UGP. El resultado de este apoyo se visualiza en la entrega de los anexos técnicos que serán incorporados a las Bases y que una vez revisada, constituirá las Bases a Publicar.

Los procesos posteriores son desarrollados principalmente por la UGP, donde se

presenta el apoyo del DI, si así lo estima conveniente el CDT, en la evaluación técnica de la(s) propuesta(s) entregada(s), esto en el proceso de Seguimiento.

93

6.1.2.1 Diseño y Evaluación del Proyecto

Como primer proceso de “Diseño y Evaluación del Proyecto”, está el de

“Preevaluación de la Solución Técnica y Obtención del Universo de Entidades”, en el cual utilizando los criterios definidos por la autoridad, se trabaja en la creación del universo de entidades, considerando las posibles soluciones tecnológicas a implementar e información relevante.

Figura 63: Diseño y Evaluación del Proyecto

94

6.1.2.1.1 Obtención de Información de Entidades

Antes de entrar en el detalle del proceso, es necesario clarificar ciertos términos: Ficha de Caracterización: Formulario usado para el registro de características relevantes de las entidades. Maestro de Entidades: Documento que hace referencia al maestro de las entidades que contienen a lo menos: información política administrativa, coordenadas, presencia de servicio de Telecomunicaciones (Voz y/o Datos), servicios Básicos (Electricidad), Información Demográfica (Población y/o hogares).

Verificación de la Información: Acción por la cual se determina si la información con la que se cuenta en un determinado momento para una entidad es suficiente para la evaluación del proyecto. Con la ficha de alcance definida, se actualiza el universo de entidades en función de la

preevaluación de la solución técnica. La actualización consiste en solicitar información a distintas instituciones y revisar las fichas de caracterización disponibles de procesos anteriores.

Se verifica la información recopilada, de acuerdo a las características relevantes de cada

entidad para el desarrollo del proyecto. En caso de que para una entidad se requiera mayor información o presente errores u observaciones, se solicita a la UGP, mediante correo, los antecedentes que se requieren de acuerdo a criterios establecidos por el DI.

Figura 64: Obtención de Información de Entidades

95

Una vez recepcionada las fichas de caracterización de la UGP, se vuelve a sistematizar

la información en el maestro de entidades, se verifica nuevamente según el punto anterior y de estar conforme, se genera el universo de entidades caracterizadas, y que corresponde al conjunto de entidades de interés para el proyecto con características relevantes para éste.

De esta forma se caracterizan todas las entidades de interés para el proyecto.

6.1.2.1.2 Diseño Técnico

Una vez obtenido el universo de entidades caracterizadas y las nuevas entidades se realiza el diseño técnico del proyecto.

Figura 65: Diseño Técnico

Algunas definiciones relevantes para este proceso se muestran a continuación: Solución Tecnológica: Tecnologías óptimas seleccionadas para la evaluación del proyecto bajo el modelo de empresa eficiente.

Diálogo Empresas: Instancia de retroalimentación que se realiza con las empresas firmantes del acuerdo público-privado para la conectividad digital, en donde éstas hacen observaciones al proyecto evaluado.

96

Servicio Básico: Servicio de telecomunicaciones que se define como obligatorio para la oferta comercial de la compañía adjudicataria del concurso.

Zona de Servicio Obligatoria: Área o punto geográfico en donde se exigirá la prestación del servicio básico

Estándares de Calidad: Conjunto de especificaciones técnicas que determinan las condiciones de satisfacción para la prestación de un servicio de telecomunicaciones. Inversiones: Conjunto de costos en infraestructura calculados para el proyecto evaluado. Red: Red de Telecomunicaciones que cumple con lo establecido en la Ficha de Alcance. Entidades beneficiadas: Entidades que estarán dentro de la zona de servicio exigible, para las cuales se prestará el servicio básico según las bases del Concurso. Informes Técnicos: Documento que contiene al menos: la solución tecnológica, el diseño de la red eficiente, la zona de cobertura exigible y el cálculo de inversiones.

Las entradas al diseño técnico son: la ficha de alcance, el universo de entidades caracterizadas, la información recopilada de los proveedores de equipos y el servicio básico a exigir. Además de Instrucciones de la Autoridad.

Se evalúa la solución tecnológica y el servicio básico a exigir dentro del concurso. De

acuerdo a lo anterior, se definen los estándares de calidad adecuados para la evaluación del proyecto.

Con la solución tecnológica y servicio básico revisado y aprobado, se diseña la red

estableciendo la zona de servicio obligatorio. Una vez aprobados y revisados los puntos anteriores, se realiza el cálculo de

inversiones necesarias para llevar a cabo el proyecto. Las inversiones se ajustarán de ser necesario cada vez que se disponga de nueva información del proyecto.

Las fases anteriores pueden sufrir modificaciones posteriores de haber solicitud de

incorporación de nuevas entidades o instrucciones de la autoridad. Con toda la información generada, revisada y aprobada en las actividades anteriores, se

elaboran los informes técnicos y el listado de entidades beneficiadas, que contiene como mínimo el Id y el nombre de la entidad, para la elaboración de las bases

En caso de haber diálogo con empresas, se envían los informes técnicos validados para

difundir la información.

97

6.1.2.1.3 Justificación del Subsidio

Con el cálculo de las inversiones y definido el conjunto de entidades beneficiadas, se estima el subsidio a entregar y que es necesario para que el proyecto sea sustentable bajo el modelo de empresa eficiente (VAN=0). Éste es calculado de acuerdo a la evaluación económica y/o social del proyecto.

Las definiciones relevantes para el proceso se mencionan a continuación:

Evaluación económica: flujo de caja privado que justifica el subsidio que contiene: ingresos, demanda, costos, inversiones, consideraciones contables y el marco presupuestario vigente. Evaluación social: El flujo de caja social que justifica los beneficios y costos sociales del proyecto. Subsidio: Cálculo del monto estimado para la realización del proyecto bajo un modelo de empresa eficiente.

.

Figura 66: Justificación del Subsidio

En caso de que la autoridad decida externalizar la evaluación económica, se debe controlar las actividades como contraparte técnica (de acuerdo al convenio suscrito con el proveedor) y aprobar conforme el producto entregado de acuerdo a los Términos de Referencia.

98

De no externalizar la evaluación económica, el equipo de analistas económicos del DI

evalúa económicamente el proyecto. De decidir la autoridad que no se requiere una evaluación social, se estima el monto del

subsidio sólo con la evaluación económica. De ser necesario una evaluación social del proyecto, la Autoridad debe decidir si se

externaliza o no. En caso de externalizarla, se debe controlar el procedimiento de la misma forma con que fue realizado para la evaluación económica.

En caso de no externalizar la evaluación social, el DI evalúa socialmente el proyecto. Finalmente, con la evaluación económica y social se realiza el cálculo del monto

propuesto de subsidio. Las evaluaciones económica y social deberán ajustarse cada vez que se disponga de

nueva información del proyecto.

6.1.2.2 Bases Como entrega final de los procesos del DI, y de acuerdo a los requerimientos del

Coordinador de la UGP, se elabora un informe que contiene la información relevante del proyecto para la elaboración de bases.

Figura 67: Bases

99

Las definiciones relevantes para el presente proceso son:

Bases Generales34: Documento, incluidos sus respectivos anexos, que contiene las disposiciones generales aplicables a ciertos concursos públicos y a los proyectos que se asignen con motivo del mismo. Bases Específicas: Documento, incluidos sus respectivos anexos, que contiene el conjunto de disposiciones y procedimientos que complementan lo establecido en las Bases Generales y que fijan los términos, condiciones y alcances de aplicación exclusiva a un determinado proyecto y a su proceso de asignación y ejecución, atendiendo a sus características particulares. Consulta Pública: Instancia de revisión y comentarios al borrador de bases específicas, por parte de las empresas que conforman el acuerdo público-privado para la conectividad digital. Informe para Concurso: Documento, cuyo objetivo es informar al público en general de las características del concurso, cuenta con una introducción del mecanismo del concurso, alcances, entidades beneficiadas al menos y las particularidades socio-económicas y técnicas que se definan para el mismo.

Los pasos necesarios para la elaboración de las bases se describen a continuación:

a) Con las Fichas de Alcance y el Informe de Elaboración de Bases, se elaboran las Bases

Específicas. Luego que estas bases son aprobadas por el Jefe de División, se envían para su visación procediendo según la letra e). En caso de requerirse consulta pública, se envían para la aprobación del Jefe de la División con la posterior realización de la consulta pública a las empresas.

b) En la consulta pública participan empresas que pertenecen al rubro de las

telecomunicaciones y que participaron en el diálogo con empresas.

c) Las bases se corrigen de acuerdo a las observaciones o comentarios que se realicen en la consulta pública.

d) Las bases corregidas son llevadas a visación por la División Jurídica (no se envían los

anexos técnicos) o por la Autoridad según corresponda. Si no son visadas, las bases observadas vuelven a ser corregidas y enviadas a su visación.

e) Una vez visadas las bases vuelven a la UGP y junto con los anexos técnicos son

validadas por el Jefe de la División y enviadas a la Autoridad para su aprobación final. Si estas no son aprobadas o es necesario incorporar cambios, son enviadas nuevamente a la UGP para su corrección.

34 El proceso de la elaboración de las Bases Generales se realiza a lo menos una vez al año siguiendo el mismo proceso que para las Bases Específicas, y son publicadas en el primer llamado a concurso del año. Luego, las bases generales se incorporan como insumo a cada llamado a concurso que se realice en el año.

100

f) Si existen modificaciones a las bases deben ser nuevamente visadas y proceder según la

letra d).

g) Finalmente, con las bases visadas se prepara la publicación de las bases que deben contener los anexos técnicos elaborados por el DI.

h) Se preparan las bases a publicar y de ser necesario el informe para concurso.

i) Una vez aprobadas las Bases por la Autoridad según la letra e), se envía un extracto a

los Representantes del CDT, quienes en la sesión respectiva autorizan o no el llamado a Concurso. Si se autoriza, se envían las bases a publicar. Si no se autoriza el llamado a Concurso, el Subsecretario de Telecomunicaciones toma la decisión de las acciones a seguir.

6.1.2.3 Concurso35

Con la aprobación del llamado a concurso por parte del CDT se procede a realizar el concurso como se muestra en la figura 68:

Figura 68: Concurso

Los términos relevantes de este proceso son:

Texto Refundido: Documento, incluidos sus respectivos anexos, que contiene las respectivas Bases Generales o Específicas, más las modificaciones y/o información adicional provenientes del Informe a las Respuestas a las Consultas, o de modificaciones posteriores a éste determinadas por la autoridad y publicadas en el Diario Oficial.

35 Corresponde al proceso regulado por medio del cual se publican las bases y se recepcionan las propuestas para el acto de apertura.

101

Bases Publicadas y sus modificaciones: Corresponde al Producto Final del Proceso e incluye los siguientes registros: Bases Publicadas, Respuestas a observaciones y Publicación en el Diario Oficial.

Los pasos necesarios para la realización del concurso se describen a continuación:

a) El CDT autoriza el llamado a Concurso y se publica en página web de SUBTEL el Acta de Sesión del CDT respectiva en cuanto ésta se haya suscrito por todos los consejeros presentes en la respectiva sesión. b) Se publican las Bases Específicas y Generales, en la página web de la Subsecretaría de Telecomunicaciones (SUBTEL) (www.subtel.cl). El conjunto de Bases constituyen el registro “Bases publicadas”. Además se publica el llamado a concurso en el Diario Oficial los días 1 o 15 de cada mes. c) De acuerdo a cronograma de las Bases Específicas, se recepcionan las consultas a las Bases vía correo electrónico hasta la fecha de cierre establecida. d) Se elabora un borrador con las respuestas a las consultas realizadas, el que debe ser visado por la Autoridad o División Jurídica. Si hay observaciones se modifica el borrador hasta que sea aprobado. e) Una vez aprobado el borrador de respuesta, se realiza la publicación de las respuestas en la página web de SUBTEL, de acuerdo a la fecha establecida en el cronograma de las Bases. f) En el caso de que las Respuestas a las Consultas impliquen una modificación sustancial a las Bases, la Autoridad puede tomar la decisión de elaborar y publicar en la página web de SUBTEL, un texto refundido con la modificación correspondiente. A su vez se publica un aviso de modificación de las Bases en el Diario Oficial. Asimismo, la Autoridad puede determinar cambios a las Bases con posterioridad a la publicación del informe de respuesta a las consultas, ante lo cual se publicará en el Diario Oficial un inserto dando cuenta de la(s) modificación(es) respectiva(s), pudiendo además determinar la publicación en el sitio web de SUBTEL de un texto refundido con la(s) modificación(es) correspondiente(s). h) Posteriormente, se recepcionan las propuestas, en caso de existir, según las condiciones y fecha establecida en las Bases Específicas. i) El Coordinador de la UGP comunica al presidente de la comisión de apertura el resultado de la recepción de propuestas. j) En caso de recepcionarse propuestas, éstas se guardarán cerradas a la espera del acto de apertura. Estas propuestas son propiedad del CDT y la información contenida en ella es confidencial. k) La DGFDT prepara el acto de apertura de propuestas, de acuerdo a lo solicitado por la Autoridad.

102

6.1.2.4 Seguimiento

Este último de los procesos analizados, y corresponde a la fase de recepción de las propuestas (en el caso de que las hayan) entregadas por las empresas postulantes al concurso. Una vez recepcionadas, se realiza el acto de apertura con la participación de las empresas postulantes, en el cual se procede a la apertura de los sobres que contienen los elementos legales y administrativos que son requisito indispensable para la postulación al concurso. En caso de que alguna de las empresas postulantes no cumplan con cualquiera de los requisitos mínimos exigidos podrá, de acuerdo a lo definido finalmente por el CDT, quedar fuera del proceso de evaluación y por ende del concurso.

Figura 69: Seguimiento

Con la o las propuestas que cumplieron los requisitos iniciales, se procede a realizar las evaluaciones tanto técnicas como financieras del proyecto. Este tarea es realizada por una comisión de evaluación especialmente designada por el CDT, la cual en casi la totalidad de los casos es integrada por miembros de la DGFDT (DI y UGP), aunque podría no ser así si el CDT así lo definiera.

Una vez finalizado el proceso de evaluación, y para las empresas que cumplieron con

todo lo solicitado en las bases, incluidos los anexos técnicos, se define (en el caso que haya más de un postulante) de acuerdo a una tabla de puntaje 36cual será la empresa adjudicataria.

36 Para mayor detalle respecto al proceso de adjudicación remitirse a reglamento del FDT [43].

103

6.2 Proceso de Asignación de Técnicos37

En esta sección se describen los criterios iniciales que deberán ser considerados para el desarrollo futuro de un prototipo de asignación de recursos que pueda ser incorporado a la solución en su conjunto. Esto con el fin de establecer elementos para generar una correcta asignación, entre los que se encuentran: especialidad y habilidades; nivel de experiencia; dependencia de tareas; prioridad de tareas; dificultad de tareas (Esfuerzo); costo de recursos y presupuesto.

6.2.1 Lógica de Prioridad de Tareas

En principio, la determinación de la prioridad de cada tarea, así como la de cada proyecto, está definida por el criterio del responsable, el cual luego de visualizar todos los proyectos (y tareas) a implementar en un plazo definido de tiempo, podrá asignar las prioridades correspondientes, de acuerdo a criterios como el tamaño, costos, plazos, etc.

6.2.2 Cálculo de Esfuerzo

Para el caso del esfuerzo, se obtiene este atributo de las tareas similares encontradas en el historial de proyectos (y tareas). De esta forma el esfuerzo asignado estará abalado por la experiencia ganada durante la realización de un número importante de proyectos, y corresponderá a un atributo numérico obtenido de un promedio de los tiempos que ha tardado en realizar una tarea particular, eliminado los tiempos perdidos en factores externos, lo que deja como resultado un número de horas mínimo en el cual se podría dejar realizada dicha tarea, es decir, si la realizara un recurso ideal y sin pérdidas de tiempo adicional.

6.2.3 Propuesta de Asignación de Recursos

Luego de evaluar varias opciones de posible asignación, se deja propuesto para un

trabajo posterior, el desarrollo de un modelo de asignación que implica el planteamiento de un Problema de Programación Lineal (PPL), con la búsqueda de minimizar el costo total de los proyectos a implementar, sujeto a una serie de restricciones, de dependencia de tareas, presupuesto, prioridad, entre otras.

En los puntos siguientes se muestran las consideraciones tomadas que debería

considerar la futura formulación del problema.

37 Dentro del concepto de técnico se incorporan los siguientes perfiles: ingeniero de proyectos, analistas económicos y geógrafos.

104

6.2.3.1 Consideraciones

Se desea diseñar una solución capaz de asignar recursos, dentro de un período de n meses, a un conjunto de proyectos de telecomunicaciones. Cada proyecto cuenta con un conjunto de j tareas, donde cada tarea tiene los siguientes atributos:

1. Especialidad: Qué tipo de recursos pueden ejecutar dicha tarea, y que se pueden definir como desde el punto de vista del tipo de servicio de dicha tarea, por ejemplo: Core (Backbone F.O., MMOO), Distribución (Backhaul), Acceso Cableado, entre otras.

2. Dependencia: Orden existente entre cada tarea dentro de un proyecto, una tarea no

puede ser realizada sin que la tarea de la cual depende no a sido realizada.

3. Esfuerzo: Atributo numérico definido del nivel de trabajo que requiere una cierta tarea para ser realizada por un recurso ideal, de forma tal que al ser ponderado por un atributo del recurso destinado (la habilidad), entrega el número de horas que debe destinar dicho recurso al desarrollo de la tarea. (Ejemplo: Esfuerzo de la tarea j (Ej) es 5 y el recurso tiene habilidad (HRij) de 2, entonces al dicho recurso le toma 10 hrs. realizar dicha tarea).

Cada tarea y cada proyecto poseen un tipo de prioridad (por ejemplo -10 más prioritario y +10 menos prioritario), y dadas 2 tareas (o proyectos) a ser realizados en un mismo periodo de tiempo (o en los que se produzcan traslape de tareas), se asignaran los recursos a la tarea (proyecto) de mayor prioridad.

Cada recurso posee una o más especialidades que lo facultan para realizar un tipo de tarea determinada, y dispone diariamente de un cierto número de horas diarias para realizar dicha tarea.

Junto con esto, posee un nivel de habilidad asociada a la especialidad de dicho recurso, por defecto es 1, esta habilidad ponderada por el esfuerzo de la tarea entrega el número de horas en que la tarea será realizada por el recurso.

Por supuesto si el número de horas de que dispone el recurso es menor al número de horas de la tarea que le fue asignada, entonces el recurso deberá ser asignado a dicha tarea para un número de días que cumpla con la cantidad de horas que requiere dicha tarea.

Junto con lo anterior, cada recurso tiene un costo asociado medido en $/hr, existiendo 2 tipos de costo dependiendo de si el recurso es de planta o externo, y que son costos fijos y costos variables de forma tal que siempre se privilegiará la utilización de recursos de planta por sobre los externos, ya que serán claramente más caros.

105

Cada proyecto tiene un cierto grado de holgura (h) medido en hrs. y que permite ajustar

los tiempos de cada tarea en caso de retrasos, y que por supuesto es parte de lo que se quiere evitar.

El objetivo final será minimizar el costo de los proyectos dentro del periodo de n

meses, sujeto a las restricciones anteriores y al hecho de que se debe aprovechar la totalidad de los recursos disponibles para evitar el recurso ocioso, es decir, diariamente cada recurso debe tener asignado una tarea a realizar, y para evitar que se produzcan días en los que un recurso quede con horas de “ocio” se realizara una asignación por horas, es decir, se vera hora a hora si el recurso tiene o no asignada una tarea determinada, disminuyendo aún más la posibilidad de “tiempos muertos”.

6.2.3.2 Modelo Propuesto

De las consideraciones anteriores se deja propuesta la creación de un modelo de programación lineal38 [12] que considere variables de decisión y restricciones, de acuerdo a todos los elementos definidos previamente y particularmente aquellos detallados en el Capítulo 5, tanto en los elementos como la estructura de diseño.

Se propone este tipo de modelo pues en una primera aproximación permite abordar esta problemática de manera particular y con un grado de precisión suficiente toda vez que las restricciones impuestas consideren la mayor cantidad de aspectos relevantes del proceso de asignación de recursos en cuestión.

38 Corresponde a un procedimiento o algoritmo matemático mediante el cual se resuelve un problema indeterminado. Este será formulado a través de ecuaciones lineales de manera de optimizar, ya sea minimizando o maximizando, una función objetivo también lineal, de forma tal que las variables de dicha función estén sujetas a una serie de restricciones expresadas mediante un sistema de inecuaciones.

106

6.3 Diseño de las Aplicaciones de Apoyo 6.3.1 Casos de Uso 6.3.1.1 Diagrama de Casos de Uso

El diagrama de casos de uso considera la presencia de 4 actores relevantes y que fueron también mencionados durante la descripción de los procesos a realizar y que son: Responsable, Jefe Proyecto, Técnico y Sistema.

Es necesario recordar que como se explicó en la parte del rediseño de procesos (Iniciar

Ejecución del Proyecto), tanto el Jefe del DI como el Coordinador de la UGP pueden ser a su vez responsables por la parte del proyecto que les toca manejar, apoyando así al Jefe de División en las distintas actividades a realizar, razón por la cual para este caso se les entrega la doble calidad de responsables y jefes de proyecto.

Junto con lo anterior, los casos de uso diseñados toman desde el ingreso de nuevos

proyectos hasta el control y seguimiento de tareas. A continuación se muestra el diagrama de casos de uso que muestra las relaciones entre estos y los actores antes mencionados:

Figura 70: Diagrama de Casos de Uso

107

A continuación se detallarán cada uno de los casos de uso ilustrados en el diagrama

anterior.

6.3.1.2 Detalle de los Casos de Uso 1. Ingreso Proyectos

Toma en cuenta el ingreso de los datos de cada nuevo proyecto a implementar, y de su posterior almacenamiento en un repositorio de proyectos.

2. Ingreso Tareas

Durante el ingreso de un nuevo proyecto se podrán extraer las tareas que componen

dicho proyecto y que estarán almacenadas en un repositorio diferente del de proyectos, pero teniendo siempre la conexión al proyecto al que pertenecen. 3. Ver Proyectos Similares

Tiene relación directa con el caso de uso anterior, ya que es mediante esta

funcionalidad que es posible obtener las tareas que componen a un nuevo proyecto, siempre cuando este haya tenido un proyecto similar del cual poder extraer la información de tareas necesaria para la implementación del proyecto. 4. Ver Proyectos Almacenados

Permite ver simplemente aquellos proyectos del repositorio de proyectos que hayan sido realizados con posterioridad o aquellos que estén en desarrollo.

5. Asignación Tareas

Es de gran relevancia ya que constituye el proceso de incorporación de recursos a cada una de las tareas a implementar de manera óptima, es decir, incrementando el uso de recursos de manera de disminuir los tiempos ociosos, aumentando la productividad. También llamado asignación de recursos a tareas, contempla la búsqueda de proyectos y por ende tareas a implementar, junto con la utilización de los recursos disponibles, y el ingreso de recursos nuevos o de apoyo, que serán utilizados en un modelo de asignación que entregue como resultado las asignaciones de los distintos recursos a cada una de las tareas, y que por último se les notifica de dicha asignación por medio de un mensaje por una vía de comunicación como el correo electrónico.

6. Buscar Proyectos a Implementar

Utilizando una búsqueda similar a la de los proyectos almacenados, salvo que considera que el estado del proyecto deba estar en “Ejecución”, este caso de uso forma parte del proceso de asignación.

108

7. Ver Recursos Disponibles

Permite realizar la búsqueda de recursos disponibles desde el repositorio de recursos,

junto con lo cual se determinará inicialmente cuales son adecuados para realizar las tareas encomendadas, y que por ende entrega solamente los recursos que estén capacitados. También se considerará su capacitación en caso de ser necesario. 8. Ingreso Recursos

Forma parte del proceso de asignación de manera que permite la incorporación de nuevos recursos (Técnicos o Jefes de Proyectos) y que son ingresados al repositorio correspondiente para ser posteriormente incorporados al proceso de asignación. 9. Envío Mensaje Asignación Recurso

Una vez realizada la asignación, se envía un mensaje destinado a cada recurso asignado, informándole de su tarea a realizar y de todos aquellos aspectos que esta implica, como el tiempo estimado, requerimientos, consideraciones iniciales, etc., de manera de introducirlo en su nueva tarea. 10. Control de Tareas

Una vez que se ha realizado la asignación de recursos, y que posteriormente se ha iniciado la ejecución de los proyectos, se ejecuta el control y seguimiento de las tareas. Por un lado se tiene que el responsable se encarga del manejo global de los proyectos corroborando que se cumplan los plazos y requerimientos generales, dando instrucciones a los distintos Jefes de Proyectos. El Jefe de Proyectos sigue la implementación de cada una de las tareas de manera tal que cada uno de los técnicos involucrados reciba las instrucciones de implementación. Finalmente cada técnico registra sus avances diarios en el sistema y envía peticiones a su Jefe de Proyectos en caso de requerirlo.

11. Registro de Tareas

Es precisamente el registro de incidencias, problemas y soluciones generadas diariamente durante el desarrollo de una tarea, y que tiene por finalidad entregar dicha información a futuras implementaciones en las que se puede requerir el uso de estos registros.

6.3.2 Diagramas de Secuencia

Se muestra en la figura siguiente el diagrama de secuencia que abarca en forma general a la aplicación de “ingreso de proyectos, asignación y control de recursos”, de manera tal de entregar una visión macro de los procesos llevados a cabo.

109

Figura 71: Diagrama de Secuencia de la Aplicación “Ingreso de Proyectos, Asignación y Control de Recursos”

110

Figura 72: Diagrama de Secuencia “Ingreso de Nuevo Proyecto”

111

El diagrama anterior detalla la secuencia de ingreso de cada nuevo proyecto al sistema,

de forma tal de permitir su clasificación inmediata de acuerdo a las características y criterios definidos para el proyecto ingresado. Junto con ello se buscan los proyectos más parecidos al proyecto que se está ingresando (en cuanto a características y criterios), procediendo a ver las cartas Gantt de cada proyecto similar, y una vez elegido el más adecuado, se procederá a guardar dicha información contenida en la Gantt, y que se encuentra en un archivo XML, de manera que se almacene tanto el XML (con las modificaciones respectivas para ajustarlo al nuevo proyecto) como las tareas que contiene en un repositorio de tareas, por medio de la extracción de los datos de cada tarea utilizando ciertas reglas y una lógica de traducción.

Una vez que se hayan ingresado todos aquellos proyectos que estén destinados a ser implementados en el corto plazo, probablemente un periodo no mayor a 6 meses, se procederá a realizar la asignación de recursos a todos aquellos proyectos a implementar. Es aquí donde el responsable selecciona dichos proyectos de una lista de nuevos proyectos proveniente del repositorio de proyectos, luego el controlador realiza la búsqueda de las tareas pertenecientes a cada proyecto y las envía a la lógica de prioridad para que se definan las prioridades de cada una de las tareas así como de sus respectivos proyectos.

Figura 73: Diagrama de Secuencia “Asignación de Prioridades”

112

Finalmente las prioridades asignadas son mostradas al responsable que se encarga de

modificarlas o no de acuerdo a su criterio, para luego ser incorporadas como un atributo de cada tarea y Proyecto.

Luego de priorizados los proyectos y sus tareas, se realiza una preselección de los recursos que serán posteriormente asignados a cada una de las tareas de los proyectos a implementar. Esta preselección considera en forma simple el descartar todos aquellos recursos que no posean ninguna de las especialidades requeridas por los proyectos y por ende por las tareas a realizar, y que se realiza comparando la especialidad de cada recurso con el atributo de especialidad incorporado en cada una de las tareas de los proyectos.

Figura 74: Diagrama de Secuencia “Obtención de Recursos Adecuados”

Con la preselección de recursos realizada, se ejecuta el cálculo del esfuerzo de cada tarea a ser realizada, y que estará medido por un valor numérico que al ser ponderado por el valor del atributo de habilidad de cada recurso, determinará el número de horas que requerirá el recurso para llevar a cabo la tarea encomendada.

113

Para asignar el esfuerzo a cada nueva tarea a desarrollar, se buscará en el repositorio de

tareas (proyectos) aquellas tareas que coinciden con las nuevas tareas, y que poseen ya el atributo de esfuerzo, y que ha sido validado por la práctica en el desarrollo de proyectos a lo largo del tiempo.

La búsqueda será realizada utilizando las características y criterios asociados a cada una

de las tareas (y proyectos), de manera de determinar con exactitud la similitud de la tarea encontrada con el de la tarea a la que se le asignará el esfuerzo.

Figura 75: Diagrama de Secuencia “Cálculo de Esfuerzo”

Para finalizar el proceso de asignación de recursos, se tiene la secuencia que permite asignar los recursos a cada una de las tareas, esto por medio de la utilización de una lógica de asignación que utilizando la información previamente recopilada (lista de recursos adecuados, información de tareas y prioridades, presupuestos, entre otros), entrega una asignación de recursos a cada tarea de cada uno de los proyectos a implementar, optimizando el uso de estos recursos de manera de disminuir los “tiempos muertos”.

El resultado se ingresa al sistema y se entrega al responsable que será el encargado de

evaluar la asignación realizada y si es necesario hacer algunas modificaciones. Junto con esto, se entrega la información dirigida a la mejora y capacitación de los

recursos en caso de ser necesario dados los requerimientos de ciertas tareas.

114

Figura 76: Diagrama de Secuencia “Asignación Recursos a Tareas”

115

Con los recursos ya asignados, solo resta dar inicio a la ejecución de cada uno de los

proyectos, labor que será realizada también por el responsable de proyectos, el cual seleccionará los proyectos a ejecutar, dando paso a que cambie su atributo de estado en el repositorio de proyectos, pasando a estar en “Ejecución”. Luego se consultará cuales son los recursos asignados a las tareas de los proyectos a ejecutar y se les enviarán mensajes que les notifique de sus nuevas asignaciones y que también podría incluir información relevante respecto a dichas tareas.

Figura 77: Diagrama de Secuencia “Inicio Ejecución de Proyectos”

Una vez que se ha dado inicio a la ejecución de los proyectos, se da inicio simultáneamente a los procesos de seguimiento y control de proyectos y tareas, por parte de cada uno de los actores existentes.

En principio y como coordinador global del estado de los proyectos, se tiene al responsable, el cual supervisa cada uno de los proyectos en ejecución, analizando problemas importantes y que no puedan ser resueltos por los jefes de proyectos, controlando los tiempos, y si lo requiere, enviando mensajes a los jefes de proyecto o incluso a los técnicos.

El responsable podrá ir modificando datos que fueron guardados en cada proyecto y pudieron ser inexactos dada la nueva información de la que se dispone, esto con el fin de tener un repositorio de proyectos actualizados y con información fidedigna que pueda ser usada en la implementación de futuros proyectos.

116

Figura 78: Diagrama de Secuencia “Control Responsable”

En el caso del control realizado por el jefe de proyecto, éste podrá hacer un seguimiento a cada proyecto que tenga a su cargo, observando el estado de avance de cada tarea en dichos proyectos.

Podrá también modificar las prioridades y criterios definidos a cada tarea, siempre con la autorización previa del responsable, pudiendo también realizar peticiones de reasignación de técnicos de una tarea a otra, si así lo estima conveniente.

117

Figura 79: Diagrama de Secuencia “Control Jefe Proyectos”

Finalmente cada técnico notificará del estado de avance de la tarea que desarrolla, y

enviará mensajes de petición a su jefe de proyecto en caso de tener solicitudes particulares, y que lo ayuden a desarrollar la tarea en cuestión, como se ve en la figura 80:

118

Figura 80: Diagrama de Secuencia “Control Técnico”

Como se aprecia en la figura, el técnico respectivo envía la información del estado de avance de la tarea desarrollada, incorporando además información relevante como es el caso de documentos o archivos que acrediten el estado de avance y comentarios respecto de los problemas que fueron apareciendo y que medidas fueron tomadas al respecto.

119

6.3.3 Modelo de Datos Físicos En los puntos siguientes se detallará la arquitectura física de la solución, es decir, como se almacenarán la información en la base de datos, y todas las relaciones existentes entre los datos, de manera de construir una base de conocimiento efectiva para la solución.

6.3.3.1 Diagrama de Clases Físicas

En la siguiente figura se puede ver el diagrama de clases físicas o modelo de datos, donde se detallan cada una de las entidades relacionadas a la planificación y manejo de proyectos, así como a la asignación y manejo de recursos.

Figura 81: Diagrama de Clases Físicas

120

6.3.3.2 Detalle de las Clases Físicas A continuación se detallarán cada una de las clases físicas o entidades mostradas en la figura 81:

1. Proyecto: Es la clase encargada de almacenar los proyectos implementados, y estará

relacionada con varias entidades que por medio de códigos identificadores o id, le asocien listas de entidades relacionadas como ListaJefeProyectos, ListaTecnicos, ListadeTareas, ListaCaracterísticas, entre otras. Tendrá como atributos principales un código o id, un nombre y las fechas de inicio y término o fin. A su vez tendrá una serie de métodos que permitan escribir u obtener dichos atributos.

2. ListaProyectos: Es la entidad que contiene listas de id de proyectos que están

relacionadas con los jefes de proyecto, es decir, entrega la lista de proyectos que tiene asignado un determinado jefe de proyectos.

3. JefeProyectos: Corresponde a la entidad que almacena el id, el nombre y la

información relevante de los jefes de proyecto a ser utilizada.

4. ListaJefeProyectos: Esta entidad contiene listas de id de jefes de proyectos que están relacionadas con los proyectos, es decir, la lista de jefes de proyecto que fueron asignados a un determinado proyecto.

5. Tecnico: Corresponde a la entidad que almacena el id, el nombre y la información

relevante de los técnicos a ser utilizada.

6. ListaTecnicos: Esta entidad contiene listas de id de técnicos que están relacionadas con los proyectos, es decir, la lista de técnicos que fueron asignados a un determinado proyecto.

7. Tarea: Es la entidad encargada de almacenar las tareas de los proyectos

implementados, y que están relacionados con ellos por intermedio de un id en la lista de tareas. Posee una serie de atributos entre los que se cuentan un id, la duración, el esfuerzo, la especialidad y la dependencia. Posee a su vez métodos que permitan escribir u obtener dichos atributos.

8. ListadeTareas: Esta entidad contiene listas de id de las tareas que pertenecen a cada

uno de los proyectos, es decir, la lista de tareas que forman parte de un determinado proyecto.

9. Caracteristica: Almacena los nombres de las características de cada proyecto

relacionadas con los tipos de familias de proyectos, y que son para el caso de la familia Magnitud: Pequeño, Estándar y Grande. Para el caso de la familia Naturaleza: Apertura, Mejoramiento y Ampliación.

121

Y para el caso de la familia Tipo de Servicio: Core, Distribución, Acceso, NGN, Servicios de Valor Agregado e Infraestructura.

10. ListaCaracteristicas: Contiene listas de id de las características correspondientes a

cada uno de los proyectos, es decir, la lista de las características que permiten identificar un proyecto.

11. TipoCaracteristica: Almacena los nombres de los tipos de características generales de

los proyectos y que están definidas por los tipos de familias de proyectos definidas en el modelo de tipificación y que son: Magnitud, Naturaleza y Tipo de Servicio.

12. Criterio: Corresponde a la entidad que almacena los nombres y los valores asociados a

los criterios definidos para cada tipo de proyecto, los cuales también fueron definidos en el modelo de tipificación, y que permiten establecer los elementos más relevantes para cada proyecto dependiendo de los tipos de familia a los cuales pertenezcan.

13. ListaCriterios: Contiene listas de id de los criterios correspondientes a cada proyecto,

es decir, la lista de los criterios con sus valores respectivos que permiten definir un proyecto en detalle.

122

Capítulo 7 Construcción del Prototipo 7.1 Desarrollo del Prototipo para Planificación

El desarrollo del prototipo considerará en una primera instancia el ingreso de nuevos proyectos a ser implementados por la empresa y la búsqueda de los proyectos almacenados en el repositorio de proyectos.

En mayor detalle permite clasificar a cada nuevo proyecto de acuerdo a ciertas características y criterios, permite buscar proyectos similares al que se esta ingresando de acuerdo a la clasificación entregada, y también permite a modo de prueba incorporar recursos a cada proyecto, dependiendo de la especialidad que poseen (y que debe coincidir con las que requiere el proyecto).

Finalmente se procederá a generar una gantt del proyecto, por medio de la creación de

un XML estructurado de acuerdo a lo requerido por la herramienta GanttProject.

El XML será generado sólo cuando no exista un proyecto similar que pueda ser utilizado, ya que en este caso se utilizará la gantt guardada en dicho proyecto similar, aprovechando la información de tareas y recursos, que en ella aparezcan.

Junto con esto se implementará una plataforma de manejo de contenidos (estilo

intranet) que permita entre otras cosas: manejo centralizado de la documentación, publicación de información relevante para la División, incorporación de links a sitios de interés (SUBTEL, páginas de noticias de telecomunicaciones, sitios de gobierno para la búsqueda de normativas relevantes para el trabajo realizado, etc.).

Junto con lo anterior, se incorporará a la plataforma (a modo de prueba y con la

finalidad de hacer pruebas a la lógica diseñada y a la vez hacer una gestión del cambio previo a una futura implementación) una aplicación que permite el control de tareas bajo la lógica planteada en este trabajo, y que será mostrada y descrita en el punto 7.2 Pantallas del Prototipo.

123

7.1.1 Programación del Prototipo

Primero que todo se crea un proyecto en Red Hat Developer Studio [49], con la característica que sea un proyecto de tipo Struts (Struts Project), luego se le da la ubicación donde correrá la aplicación desde un Web browser (por ejemplo: http://localhost:8080/prototipo/), la aplicación se encontrará en un contenedor de Servlets de Jboss.

Una vez creado el proyecto, aparecerán una serie de carpetas y librerías pertenecientes al proyecto en blanco, en particular se abrirá la carpeta WebContent/Web-INF, y se abrirá el archivo struts-config.xml, que será donde estará el diagrama de flujo Web de la aplicación así como la fuente principal de ella.

Luego se procederá a crear cada uno de los Action, Global Forward, Páginas JSP y FormBean (correspondientes a los controladores), que serán utilizados por la aplicación.

Con el diagrama de flujo realizado se procede a generar el código java correspondiente a cada una de las clases creadas, este procedimiento es realizado automáticamente por Red Hat, de forma que se crean las estructuras básicas o “cáscaras” que serán completadas luego con código dispuesto para cada uno de ellos.

El diagrama de flujo Web diseñado para el prototipo se puede ver a continuación:

Figura 82: Diagrama de Flujo Web del Prototipo

http://localhost:8080/prototipo/

124

Luego de generado el código Java, se procede a revisarlo y modificarlo en cada uno de

los Actions.java y Forms.java creados en el paquete “sample” de la carpeta WebContent/Web-INF/classes.

Además se crea un nuevo paquete llamado “prototipo” el cual contiene cada una de las

clases relevantes para la aplicación y que han sido en parte detalladas anteriormente. Los 2 paquetes se pueden ver a continuación:

Figura 83: Clases y Controladores del Prototipo Una vez que se establece el ingreso de proyectos y su almacenamiento en el repositorio

de proyectos, y que considera también repositorios para cada clase, como característica, criterio, técnico, jefe de proyecto, etc., se procede a interactuar con los archivos XML pertenecientes a proyectos similares almacenados o en caso de no existir un proyecto similar fue necesario crear uno que pudiese ser interpretado por la herramienta GanttProject como un proyecto definido con tareas y recursos.

Para esto fue necesario analizar los archivos XML que son utilizados por la herramienta, de forma de determinar cual es la estructura que utilizan, de manera tal de poder leerlos y extraer información, así como poder reproducirlos y crear Gantt´s de proyectos automáticamente por medio de la información ingresada en el sistema al crear un nuevo proyecto.

En el punto siguiente se muestra la estructura típica de XML que utiliza GanttProject para guardar un proyecto determinado.

125

7.1.2 Estructura en XML de Carta Gantt en GanttProject Primero se puede ver los datos iniciales del proyecto, como el nombre, la organización

a la que pertenece, la fecha inicial, entre otros:

<?xml version="1.0" encoding="UTF-8" ?> <project name="Proyecto Red Acceso Inalambrico 1" company="GFDT" webLink="" view-date="2005-12-26" view-index="0" gantt-divider-location="307" resource-divider-location="411" version="2.0"> <description /> <view zooming-state="default:6" /> 

Luego se puede apreciar el calendario y la definición utilizada para los días.

<calendars> <day-types> <day-type id="0" /> <day-type id="1" /> <calendar id="1" name="default"> <default-week sun="1" mon="0" tue="0" wed="0" thu="0" fri="0" sat="1" /> <overriden-day-types /> <days /> </calendar> </day-types> </calendars>

Las propiedades de que poseerán las tareas se pueden ver a continuación, en donde

existen 10 tipos de propiedades que son: tipo, prioridad, información, nombre, fecha de inicio, fecha de fin, duración, completitud, coordinador y predecesores (o dependencia).

Claramente estos tipos de propinadas son coincidentes con todo lo antes mencionado, y la forma en que se tratará la asignación de recursos a tareas considerando cada uno de estos atributos.

<tasks color="#99ccff"> <taskproperties> <taskproperty id="tpd0" name="type" type="default" valuetype="icon" /> <taskproperty id="tpd1" name="priority" type="default" valuetype="icon" /> <taskproperty id="tpd2" name="info" type="default" valuetype="icon" /> <taskproperty id="tpd3" name="name" type="default" valuetype="text" /> <taskproperty id="tpd4" name="begindate" type="default" valuetype="date" /> <taskproperty id="tpd5" name="enddate" type="default" valuetype="date" /> <taskproperty id="tpd6" name="duration" type="default" valuetype="int" /> <taskproperty id="tpd7" name="completion" type="default" valuetype="int" /> <taskproperty id="tpd8" name="coordinator" type="default" valuetype="text" /> <taskproperty id="tpd9" name="predecessorsr" type="default"valuetype="text"/>

126

</taskproperties>

Una vez definidas las propiedades se crean cada una de las tareas que se llevarán a cabo en el proyecto, y que están definidas por un id, el nombre, y las demás propiedades en caso de ser utilizadas.

<task id="0" name="Tar_1" color="#99ccff" meeting="false" start="2005-12-27" duration="6" complete="100" priority="1" expand="true" /> <task id="1" name="Tar_2" color="#99ccff" meeting="false" start="2006-01-02" duration="15" complete="86" priority="1" expand="true" /> <task id="2" name="Tar_3" color="#99ccff" meeting="false" start="2005-12-26" duration="31" complete="89" priority="1" expand="true" /> </tasks>

Por otro lado se crean los recursos a ser utilizados en el proyecto, definiéndolos por un

id, el nombre, la función que cumplirán, y una forma de contacto (fono). <resources> <resource id="7" name="Recurso 1" function="Default:0" contacts="" phone="4213440" /> <resource id="8" name="Recurso 2" function="Default:1" contacts="" phone="4213534" /> <resource id="9" name="Recurso 3" function="Default:0" contacts="" phone="4213597" /> </resources>

Una vez creados, serán asignados a cada una de las tareas existentes en el proyecto de manera de definir por medio del los id de cada tarea y cada recurso, cual tarea será realizada por que recurso, que función llevará a cabo, y si dicho recurso es o no responsable de dicha tarea, donde por supuesto dicha responsabilidad siempre recaerá sobre el jefe de dicho proyecto.

<allocations> <allocation task-id="0" resource-id="8" function="Default:1" responsible="true" load="100.0"

/> <allocation task-id="0" resource-id="7" function="Default:0" responsible="false" load="100.0"

/> <allocation task-id="1" resource-id="8" function="Default:1" responsible="true" load="100.0"



/> <allocation task-id="2" resource-id="7" function="Default:0" responsible="true" load="100.0"

/> </allocations>

127

Finalmente se consideran las características que poseerán las columnas de tareas que se

despliegan en el visor de Gantt´s de la herramienta, y que considerarán los tiempos de inicio y fin de una tarea, así como el nombre de dicha tarea. <taskdisplaycolumns> <displaycolumn property-id="tpd3" order="0" width="75" /> <displaycolumn property-id="tpd4" order="1" width="75" /> <displaycolumn property-id="tpd5" order="2" width="75" /> </taskdisplaycolumns> <previous /> <roles roleset-name="Default" /> </project>

Una vez hecho el análisis de la estructura de XML requerida, se procede a crear un generador de XML básico que considere la información ingresada en la creación de cada nuevo proyecto y que no sea posible encontrar un proyecto similar del cual obtener mayor información respecto a las tareas a realizar: String codigoXML; Para (cada proyecto existente) {

codigoXML=<?xml version="1.0" encoding="UTF-8"?><project name="Proyecto Prueba" company="GFDT" webLink="" view-date="Fecha Proyecto" view-index="0" gantt-divider-location="307" resource-divider-location="411" version="2.0"> () codigoXML= codigoXML+ <tasks>;

Para (cada tarea existente en el proyecto) {

codigoXML= codigoXML+( <task id="ID Tarea" name="Tarea N" color="#99ccff" meeting="false" start="Fecha de Inicio" duration="duración tareas" complete="completitud" priority="prioridad" expand="true"/>); } codigoXML= codigoXML+ </tasks>; codigoXML= codigoXML+ <resource>

Para (cada recurso existente en el proyecto) {

codigoXML= codigoXML+<resource id="Id Recurso" name="Nombre Recurso" function="Función" contacts="" phone="Teléfono Recurso"/> } codigoXML= codigoXML+ </resources>; codigoXML= codigoXML+ </project>;

128

7.2 Pantallas del Prototipo

Para cumplir con el objetivo de este punto se busca mostrar las 2 partes del prototipo realizadas, y que son por un lado la del ingreso de proyectos, con su consecuente clasificación y posterior búsqueda, y por otro lado la del control de tareas. Pero como se explicó anteriormente, ésta fue realizada a través de la implementación de una plataforma de manejo de contenidos en un servidor local (similar a una intranet), sobre la cual se incorporó una aplicación de control de tareas acorde a lo diseñado en este trabajo.

7.2.1 Ingreso de Proyectos

En esta parte se muestran las pantallas que constituyen la parte del prototipo desarrollado que tiene por objetivo el ingreso de nuevos proyectos y la búsqueda de proyectos anteriores.

7.2.1.1 Inicio

La primera pantalla corresponde a la página de inicio y se puede ver a continuación:

Figura 84: Página de Inicio

Tiene 3 botones de acceso, dados por las funciones principales del prototipo, que son

el ingreso de un nuevo proyecto, el de buscar proyectos y el de ver el listado de proyectos.

129

7.2.1.2 Ingreso de Nuevo Proyecto

Se procede al ingreso de los datos relevantes de cada nuevo proyecto, desde el código asociado al proyecto en la empresa, el nombre y las fechas de inicio y fin. Junto con esto se establece una clasificación del proyecto (realizada por el responsable) de acuerdo a 3 características relevantes: magnitud, naturaleza y tipo de servicio.

Para el caso de la magnitud se tienen definido 3 tipos, que son pequeño, estándar y

grande, dependiendo principalmente del nivel de costos que representa el proyecto, pero que en realidad esta definido por 7 criterios (alcance, costos, complejidad, plazos, etc.), y que aparecerán en la pagina de selección de criterios, en la cual se podrá definir el valor asignado a estos criterios.

El tipo de servicio considera los tipos de proyectos o de servicios prestadas y que son

proyectos de Core, Distribución, Acceso Cableado, Redes Inalámbricas, NGN y Servicios de Valor Agregado. La selección de uno de estos tipos entregará un criterio que permitirá seleccionar la versión utilizada en la solución.

Finalmente la naturaleza permite determinar si el proyecto es de apertura (o de una

implementación desde cero), de mejoramiento y de ampliación (nuevas servicios o proyectos a la base instalada).

Figura 85: Ingreso de Nuevo Proyecto

130

7.2.1.3 Selección de Criterios y Estimación de la Cantidad de Recursos

Una vez seleccionadas las características de los proyectos, se despliegan los criterios asociados a la selección de tipos de características realizada.

Posteriormente, se seleccionan aquellos criterios que se consideren más relevantes para el proyecto y a cada criterio “con ticket” se le dará un valor en un rango del 1 al 10 de acuerdo al valor que debería poseer, y que será ponderado por un rango de valores asociado a cada criterio, por ejemplo para el caso de los costos serán valores en $ o $US, entre un valor mínimo y máximo de presupuesto.

Figura 86: Selección de Criterios

Junto con lo anterior, se solicita una estimación de la cantidad de recursos y de jefes de proyectos requeridos, esto si bien es para tener una idea de una incorporación inicial de recursos al proyecto, la asignación definitiva considerará la totalidad de recursos disponibles, y todos aquellos proyectos a implementar, de forma tal que la asignación optimice el uso de los recursos.

131

Figura 87: Estimación de la Cantidad de Recursos Requeridos

132

7.2.1.4 Resumen del Proyecto

A continuación se muestra un resumen de la información del proyecto ingresada hasta el momento. Aparece también la asignación preliminar que se comentó anteriormente, y que incorpora técnicos y jefes de proyecto, de acuerdo a la especialidad que posean, y que esta por supuesto coincida con la del proyecto, reflejada en el tipo de servicio entregado.

Figura 88: Resumen Ingreso de Proyecto

133

7.2.1.5 Ingreso Exitoso

En esta página simplemente se confirmará el ingreso del proyecto de manera correcta, recordando el código del proyecto ingresado, y solicitando la búsqueda de proyectos similares con el fin de obtener las tareas a realizar y toda aquella información relevante para el desarrollo del proyecto.

Figura 89: Ingreso Exitoso del Proyecto

134

7.2.1.6 Ver Proyectos Similares

Una vez solicitada la búsqueda, se entregan los proyectos que más concuerden con el proyecto ingresado, por medio de la comparación de los criterios pertenecientes a cada proyecto con los del nuevo proyecto. Estos serán desplegados aquí y se podrá ver la carta gantt de cada uno de ellos, de forma de que el responsable determine finalmente que gantt tomará como referencia para la nueva implementación.

Junto con esto, existe la opción de visualizar todos los proyectos realizados anteriormente, y que por alguna razón deseen ser analizados por el responsable antes de guardar la gantt con las tareas a realizar. Esta opción es la misma que entrega el botón en la página inicial o home, y se añade como un apoyo.

En caso de no existir algún proyecto que reúna las condiciones mínimas de similitud, se

procederá a generar una gantt básica con los datos del proyecto ya ingresados, y que deberá ser modificada por el responsable incorporando los nombres de las tareas y sus duraciones, entre otros datos.

El archivo que se genera es de tipo XML, y debe ser cargado a la herramienta

GanttProject, para su posterior visualización y modificación.

Figura 90: Ver Proyectos Similares

135

7.2.1.7 Cargar XML de Proyecto Similar

Finalmente se da la opción de guardar la gantt (en formato de archivo XML), en la ubicación que estime conveniente el responsable, para luego poder verlo por intermedio de GanttProject, y que en caso de ser el elegido, poder modificarlo de acuerdo a los nuevos requerimientos.

Si bien este procedimiento se ha dejado preliminarmente en forma manual, se desea que quede de forma automática, de manera de simplificar el procedimiento y que sea más atractivo para el usuario.

Figura 91: Cargar XML de Proyecto Similar

136

7.2.1.8 Carta Gantt A continuación se guarda el archivo XML y se carga en la herramienta GanttProject que fuera anteriormente abierta por intermedio del botón “Launch” que se puede ver en la figura 90. Con el archivo cargado se puede ver la carta gantt respectiva como se ve en la figura siguiente:

Figura 92: Carta Gantt del Proyecto Similar

Aquí es posible realizar todas las modificaciones pertinentes que adapten al proyecto ingresado, que una vez adaptado podrá ser guardado y almacenado en la base de datos de proyectos en el atributo de carta gantt del proyecto ingresado.

137

7.2.1.9 Buscar Proyectos En caso de que se requiera buscar cierto tipo de proyectos, será posible realizarlo especificando los tipos de características de los proyectos solicitados, como se puede ver en la figura 93.

Figura 93: Buscar Proyectos Almacenados

138

7.2.1.10 Proyectos Encontrados

Luego, los proyectos encontrados se muestran en una tabla, especificándose a que tipo de familias pertenecen:

Figura 94: Ver Proyectos Encontrados

Es posible formular un a nueva búsqueda simplemente utilizando el botón de “nueva búsqueda” que se ubica inmediatamente bajo la tabla.

139

7.2.1.11 Ver Proyectos Almacenados

Por último, existe la posibilidad de ver los proyectos anteriormente realizados, y sea desde la página de inicio o desde la de proyectos similares.

Figura 95: Ver Lista de Proyectos Almacenados

140

7.2.2 Plataforma para el Control de Proyectos

Se muestran las pantallas de la plataforma implementada, la cual como se aprecia en la figura 96 existen una serie de aplicaciones adicionales a las funciones principales del diseño propuesto con la finalidad de simplificar la gestión del cambio que implica que los usuarios se acostumbren a utilizar este tipo de herramientas en sus actividades diarias.

Figura 96: Página Principal Portal GFDT

141

7.2.2.1 Gestión de Documentos

Parte de los problemas existentes al interior de la División GFDT, era la descentralización

de la información, la cual era manejada por distintos individuos, y que si bien se realizaron intentos por contar con un único repositorio, la dificultad para acceder a los diversos contenidos de archivos y documentación continuó siendo un problema.

Como se aprecia en la figura siguiente, se incorporó en la plataforma un sistema de manejo

de documentos 39al que se le llamó “Gestión Documental” y que permite simplificar la tarea de manejar la documentación generada y que sea relevante para la División GFDT, así como toda aquella información que requiere de un fácil acceso por parte de todos los profesionales. El sistema en cuestión se conecta a la base de datos MySQL de la plataforma realizando la carga y descarga de archivos de manera simple y rápida, junto con permitir búsquedas simples y avanzadas dependiendo de los requerimientos de cada usuario.

Figura 97: Menú de Gestión de Documentos

Se puede ver que se definió una estructura de acuerdo al tipo de información almacenada y a qué áreas de la División corresponden. La figura 98 muestra un ejemplo de una subcarpeta dentro de la categoría principal “Departamento de Ingeniería”.

Figura 98: Vista de Documentos Almacenados

39 El sistema mencionado corresponde a una aplicación desarrollada especialmente para plataformas Joomla denominada Docman. Ver Manual de Usuario en Anexo D.

142

7.2.2.2 Control de Tareas

Como se ha explicado a lo largo del presente informe, una de las partes centrales del

trabajo de rediseño y de la incorporación de herramientas de apoyo a los diferentes procesos estaba la implementación de un sistema para el control y seguimiento de tareas que permitiese tanto al responsable como a los jefes de proyecto estar al tanto del avance de las diferentes tareas que constituyen cada proyecto y por ende del avance mismo del proyecto, y por otro lado de apoyar a los recursos técnicos encargados de realizar cada tarea particular de manera que puedan informar a tiempo los diferentes avances, así como problemáticas enfrentadas y soluciones encontradas en cada tarea y que puedan ser útiles para resolver los futuros problemas que se presenten en nuevos proyectos.

Es así como se incorporó a la plataforma un sistema de manejo de proyectos que permite realizar la gran mayoría de las funciones diseñadas para estos efectos, y que van desde la notificación vía correo electrónico a los recursos técnicos que han sido asignados a las diferentes tareas de un proyecto, la notificación al responsable y los jefes de proyecto de los diferentes avances de cada tarea así como la interacción vía comentarios y archivos y documentos asociados a las tareas en cuestión, la generación de alertas en el caso de la expiración de fechas de entrega, entre otros.

La figura a continuación muestra la pantalla de acceso al sistema y que permite al usuario

seleccionar los proyectos a los cuales pertenece (espacios de trabajo) y la o las tareas a las que ha sido asignado. El resumen de tareas que aparecen al inicio corresponde a aquellas que no han sido completadas y que por ende requieren una atención particular por parte de los recursos asignados.

Figura 99: Menú Proyectos en Curso

143

A continuación se puede apreciar un ejemplo del detalle de tareas dentro de un proyecto,

en el cual se puede ver las diferentes tareas y los recursos asociados a las mismas, definiéndose también (dependiendo de la tarea) un ID, un nivel de prioridad, un nivel de avance o progreso y un plazo de entrega (tempo límite) que define en parte las características de cada tarea.

Figura 100: Ejemplo de Ver Tareas

Para los casos del responsable y los jefes de proyectos, podrán realizar búsquedas de tareas dependiendo de 3 variables principales:

A quién fue asignada

El nivel de avance : completa o incompleta

La prioridad definida: Muy Alta, Alta, Media, Baja y No definido

144

En la figura se muestra la interacción que tiene el jefe de proyectos con el recurso

asignado para una tarea en particular. Junto con esto se puede ver él o los documentos o archivos adjuntos a la tarea que dan cuenta efectivamente del estado de avance presentado, teniendo la posibilidad de definir un breve comentario al lado de cada documento especificando si es un documento definitivo o simplemente una versión preliminar.

Figura 101: Ejemplo de Detalle de Tareas

145

Para la modificación de las características de cada tarea es que se presenta la pantalla

siguiente y que permite desde definir el nombre de la tarea hasta definir el recurso asignado a ella y que dependiendo de cada jefe de proyecto pueden ser o no reasignados a otras tareas.

Figura 102: Ejemplo Editar Tareas

146

Finalmente se muestran todos los archivos y documentos asociados a las tareas para un

determinado proyecto, de manera tal que se puede ver unificadamente todas las entregas realizadas para la completitud de un proyecto.

Como se puede ver en la figura, cada recurso puede subir un documento incorporando

una breve descripción que permita rápidamente conocer su contenido, mostrándose además la fecha en la que fue subido al sistema.

Se entrega también la posibilidad de realizar búsquedas rápidas por medio de un buscador.

Figura 103: Ejemplo de Gestor de Archivos

147

Capítulo 8 Implementación Organizacional 8.1 Gestión del Cambio

El modelo de cambio utilizado para desarrollar el proceso de cambio fue la estrategia para lograr eficacia en los cambios de Schwartz y que considera lo siguiente:

“Conducir efectivamente los procesos de cambio recomendando determinadas políticas o

comportamientos que, según su experiencia como consultor, puede contribuir al logro de mejores resultados y que son aplicables a cualquier circunstancia o modelo que se adopte para la conducción del cambio”.

El objetivo principal se dirige a la utilización de determinadas prácticas que faciliten que

los cambios se conviertan en hábitos, para lograr su interiorización efectiva en las organizaciones. La idea es utilizarlo puesto que en los cambios, las personas, y los grupos necesitan desarrollar un sentido de pertenencia y propiedad, e involucrarse activamente en la planificación de los cambios, o sólo se tendrá un acuerdo pasivo.

Existen ocho comportamientos que fueron analizados y que se presentan a continuación:

8.1.1 Comunicación Eficaz

Debe existir comunicación: antes, durante y después de los cambios. Las vías principales que recomienda son:

Distribuir informes o descripciones escritas de los cambios

Realizar con regularidad reuniones de pequeños y grandes grupos.

Utilizar oradores que se destaquen en transmitir una visión efectiva

Seleccionar líderes para las tareas, que sean positivos y optimistas, y que comuniquen con claridad, precisión y regularidad lo que se está haciendo.

Utilizar buenas habilidades de comunicación en todo momento durante los cambios.

Ser empáticos

Asegurarse de ser francos y directos

148

8.1.2 Involucrar al personal y estimular la participación

La participación facilita la reducción de la resistencia a los cambios

Desarrollar un sentido de pertenencia y propiedad de los mismos

Motivar a los involucrados para que funcionen los cambios.

8.1.3 Permitir que la gente se “despida” (de lo viejo)

Las personas necesitan “dejar de lamentar” el viejo sistema, o la forma familiar de hacer las cosas, y hace falta tiempo y oportunidad para desligarse del pasado.

Se pueden, identificar sistemas, métodos, normas, formas y calidad de liderazgo a utilizar en el futuro.

8.1.4 Suministrar capacitación en nuevos valores y comportamientos

Es importante tener disponible y aplicar sistemáticamente autoevaluación, capacitación y

desarrollo, para todos los involucrados en los cambios. Las vías principales para ello son las siguientes:

Planificar por anticipado y asignar los recursos necesarios para capacitar personas.

Suministrar informaciones acerca de cómo y por qué se desarrollará la capacitación.

Incorporar y explicar, en la capacitación, nuevos valores y comportamientos.

Evaluar el estilo, formato y objetivo de las necesidades formales e informales de capacitación.

8.1.5 Sintonizar emocionalmente

Escoger personas para hablar acerca de los cambios y ayudar a que se comprenda que los cambios son irreversibles, y que ellos pueden influir.

149

8.1.6 Suministrar retroalimentación (Feedback)

Son factores clave: el suministro de retroalimentación y de informaciones. Las vías principales que recomienda son:

Desarrollar reuniones de equipos de trabajos.

Mantener entrevistas informales, de persona a persona.

Utilizar revisiones de desempeños y evaluaciones para reforzar los cambios.

Desarrollar encuestas y utilizar grupos de sensibilización.

8.1.7 Establecer sistema de retribuciones

Las personas tienden a motivarse y a comportarse de las formas en que perciban que les conducirán a resultados deseables.

Formas de retribución tales como: promociones, reconocimientos, sistema salarial, asignación de puestos, necesitan examinarse cuidadosamente para que apoyen la dirección de la transición.

8.1.8 Desarrollar nuevas normas grupales y una nueva declaración de misión

Resulta fundamental suministrar un sentido de dirección, con una imagen clara de cuán

bien se ajusta la organización y los equipos. Cómo establecer la misión:

Determinar quiénes son los clientes del grupo.

Preguntar, ¿Cuál es el campo de actividades de mi responsabilidad?

Determinar las partes de la misión o meta de la organización o departamento

Asegurarse de conocer las normas de grupos, escuchar y observar cómo actúan las personas entre sí, a fin de cumplir sus trabajos.

150

8.2 Estrategia para la Gestión del Cambio

8.2.1 Mapa de Poder

A continuación se muestra el mapa de poder, para poder llevar a cabo el proyecto:

Figura 104: Mapa de Poder

Como se aprecia en la figura, los actores relevantes y que entregan un valioso apoyo para

la realización e implementación del proyecto son por un lado el jefe de división que estuvo muy a favor de ordenar y estructurar los procesos al interior de la DGFDT de manera de poder detectar focos de posible mejora en estos. Junto con esto mostró gran interés en la implementación de una plataforma que permitiese la centralización y manejo de la documentación al interior de la División.

Pero sin duda fue el Jefe de Departamento de Ingeniería el motor fundamental para llevar

a cabo la implementación, mostrando su gran interés y entrega de apoyo desde el proceso de identificación y rediseño de los procesos, hasta la implementación de la plataforma y en particular con lo que respecta al sistema de control de tareas, siéndole de particular ayuda para el seguimiento de tareas e interacción con los recursos a su cargo.

Por último fueron los mismos integrantes del equipo técnico que brindaron todo su apoyo

y motivación para el uso de las herramientas entregadas, aportando con comentarios de posibles mejoras que ayudaran a potenciar el sistema.

151

8.2.2 Plan de Gestión del Cambio

Primero se definieron las narrativas y los pasos a seguir para poder realizar el proceso de cambio: • Responsable (Jefe de División): 1. Le permitirá tener una visión mucho más clara desde el proceso de ingresar un nuevo proyecto, ya que podrá apoyarse en información de proyectos anteriores mientras lo hace (por ejemplo para la definición de tareas y la generación de cartas Gantt). 2. Podrá establecer una asignación de recursos técnicos a proyectos si así lo estima conveniente o simplemente asignar a los jefes de proyecto y apoyarse en estos para asignar a los diversos recursos. 3. Junto con los 2 puntos anteriores y por medio del proceso de control y seguimiento, podrá apoyar de mejor forma al Jefe de Departamento de Ingeniería y al Coordinador de la UGP en sus requerimientos y en la solución de problemas. • Jefe de Proyecto (Jefe Departamento de Ingeniería): 1. Le permitirá tener un canal más fluido tanto con el responsable o Jefe de División, como con el equipo técnico que tiene en los proyectos asignados. 2. Podrá establecer una asignación de recursos técnicos avanzada que considere variables como las habilidades de los recursos, el esfuerzo requerido para cada tarea y las prioridades definidas para éstas, los plazos definidos, entre otros, lo que le permitirá tener un apoyo importante a dicha gestión que actualmente desarrolla simplemente por medio de una hoja en Excel. 3. Podrá determinar más claramente los tiempos de implementación, conociendo los plazos que tienen asignados los recursos a las diversas tareas. • Técnico (Ingeniero o Geógrafo): 1. Podrá tener claro cuáles serán sus asignaciones diarias y semanales, existiendo siempre la posibilidad de reasignaciones pero que serán determinadas con claridad. 2. Podrá utilizar información valiosa durante la realización de la tarea, ya que podrá tener acceso a historiales de eventos y soluciones dispuestos para tanto para la tarea que está ejecutando como para un gran número de tareas ya implementadas.

Se define una estrategia compartida por los diferentes actores involucrados en el proyecto.

152

8.2.2.1 Razones de Negocio La razón de negocio para ejecutar el cambio fue aumentar la eficiencia operacional de la

empresa de manera de realizar la implementación de proyectos lo más óptimamente posible.

Los principales beneficios que se destacaron en la gestión del cambio son:

1. Reducción de los tiempos de implementación y por ende de los tiempos de entrega al cliente.

2. Mejor uso de la información de proyectos disponible tanto en el ingreso de nuevos proyectos como durante la implementación.

3. Mejor toma de decisiones durante proceso de asignación.

4. Soluciones de mejor calidad en un menor tiempo, en particular en lo que respecta a los Diseños y Evaluaciones de Proyectos.

En lo que respecta a los riesgos, efectivamente se reduce la posibilidad que existan diferencias entre los plazos iniciales y reales en el proceso de planificación.

8.2.2.2 Liderazgo Comprometido

El líder del cambio está representado por el jefe de departamento de ingeniería, el cual es por demás de los más beneficiados, razón por la cual es el más interesado en que se lleve a cabo el proyecto.

Fueron asignados recursos de ambas áreas de la DGFDT, esto es del DI y de la UGP, que

tuvieron como tarea apoyar en el proceso de identificación y rediseño de procesos, tarea que junto con lo anterior tuvo como último objetivo buscar la certificación ISO 9001:2008 para los procesos realizados por la División.

Por supuesto el líder aceptó y comprendió el riesgo que significaba embarcarse en el

cambio que debió ser realizado y las implicancias de este.

8.2.2.3 Individuos Afectados por el Cambio

Respecto a los Costos/Beneficios para el equipo técnico producidos por el cambio, es posible decir que:

Los principales costos estarán relacionados con el trabajo preliminar de cambiar ciertas metodologías desarrolladas hasta el momento (ingreso y clasificación de los proyectos, asignación de los recursos, y el registro de problemas y soluciones, principalmente).

153

Mientras que los beneficios fueron mencionados en las narrativas propuestas para cada actor involucrado.

Finalmente es posible afirmar que los afectados comprendieron las motivaciones del

cambio y actuaron a favor del mismo razón que se justifica también de las narrativas generadas para cada uno de los actores involucrados y se desprende que cada uno de ellos tuvo una motivación asociada a este cambio, razón por la cual estuvieron a favor del proceso de cambio.

8.3 Medición de Evaluación y Cierre

Existen al interior de la División una serie de indicadores de gestión que tienen como principal objetivo el poder medir de manera efectiva la satisfacción de los clientes, pero estos indicadores han sido modificados y re-implementados paralelamente al proceso de implementación de este proyecto, razón por la cual en principio no era posible utilizarlos para medir el nivel de impacto.

Fue así como se consideró la medición de la evolución de 2 tipos de proyectos

particulares, y que comprendían por un lado proyectos para la entrega de servicios de telefonía móvil a zonas rurales en ciertas regiones del país, y por otro proyectos para la entrega de servicios de transmisión de datos (internet) a grandes números de localidades rurales a nivel nacional. La idea es que para cada tipo de proyecto se tiene como muestra un proyecto antes y después de la implementación de la solución, razón por la cual arrojaría una métrica razonable respecto al nivel de impacto de esta propuesta en los proyectos desarrollados y en la DGFDT en su conjunto.

En esta evaluación se toma en cuenta los puntos de vista del aprendizaje y gestión del

conocimiento de los proyectos anteriores, así como las mejoras operativas en cuanto a la planificación y control de tareas de cada nuevo proyecto. Los resultados directos de la medición realizada van en la línea de potenciales variaciones en los costos y tiempos de diseño y desarrollo de cada proyecto y que a su vez tienen como objetivo la construcción exitosa de cada concurso.

En principio es posible decir que tanto la solución como el prototipo implementado

fueron incorporados paulatinamente a partir de octubre del año 2009, teniendo como primeros usuarios a los encargados del manejo documental de la DGFDT, los cuales comenzaron cargando en la base de datos de la plataforma todos aquellos documentos oficiales más relevantes de cada proyecto y que posteriormente serían utilizados por todos los integrantes de la división como parte del trabajo de más largo aliento respecto de la gestión del conocimiento. Junto a lo anterior, el Jefe del DI aprovechó la oportunidad de realizar el seguimiento a diferentes tareas del proyecto IDCI 2009, facilitando tanto su labor de control, como motivando al resto del departamento a que utilizara la plataforma (6 Ingenieros de Diseño, 2 Analistas Económicos y 2 Geógrafos).

154

Posteriormente, se comenzaron a incorporar los nuevos proyectos a desarrollar y que

requerían de un uso más significativo de recursos de manera dando cabida directa al uso del prototipo.

Como se mencionó anteriormente, es posible realizar una comparación a grandes rasgos

de la evolución en el desarrollo de 2 tipos de proyectos particulares y que fueron desarrollados antes y después de la implementación de la solución. Estos corresponden a los proyectos de IDCI 40 e IDCI II, para el caso de los proyectos de servicios de transmisión de datos y Telefonía Móvil II y Rutas de Antofagasta, para los proyectos que entregan telefonía móvil. Cada par de proyectos posee características similares entre sí que los hacen comparables. El detalle de estos proyectos así como de la evolución de los costos operacionales se puede ver en el Anexo C.

Tomando en consideración los mismos procesos analizados en el capítulo 3

particularmente en el punto 3.7 (Evaluación Financiera) y que permiten evaluar el impacto más directo de la solución en los costos operativos de diseñar un proyecto. Los resultados obtenidos se ven en la figura a continuación:

$ 14.897.745

$ 9.452.202

$ 3.472.863

$ 1.862.218

$ 0

$ 2.000.000

$ 4.000.000

$ 6.000.000

$ 8.000.000

$ 10.000.000

$ 12.000.000

$ 14.000.000

$ 16.000.000

IDCI I IDCI II MOVILES II RUTAS

Transmisión de Datos Telefonía Móvil

COSTOS DE DISEÑO Y DESARROLLO

Figura 105: Evolución Costos Procesos Diseño y Desarrollo Proyectos Tipo del FDT Sumado a todo lo anterior, es posible rescatar la positiva percepción y aceptación de la

solución entregada, tanto así que el trabajo de modelamiento y rediseño de procesos derivó posteriormente en un proceso de certificación de calidad ISO 9001:2008, y que fue exitosamente llevado a cabo al interior de la DGFDT, teniendo como apoyo directo para esta certificación a la solución y herramientas implementadas lo cual constituyó una potente justificación para el uso y aprovechamiento de las soluciones incorporadas.

40

Infraestructura Digital para la Competitividad e Innovación.

155

Capítulo 9 Generalización

En el presente capítulo se describirá la generalización al proceso de rediseño propuesto, de manera tal que pueda ser extendido a otro tipo de procesos similares perteneciendo posiblemente a ámbitos muy diversos.

De esta forma por medio de la construcción de un framework, es posible identificar una

serie de estructuras y elementos en común e individualizando aquellas que son específicas para cada caso, con lo cual es posible obtener soluciones genéricas adaptables a problemáticas particulares.

Es así como la composición de un framework está dada por un set de clases comunes

entre sí, y que no son específicas a casos particulares, junto con una o más clases que si deberán ser particularizadas a cada caso.

En la figura siguiente se muestran las etapas principales para la construcción de un

framework particularmente la relación entre el desarrollo realizado y la estructura del framework y que está definido por medio del patrón y la lógica de negocios genérico para un dominio dado.

Figura 106: Relaciones Estructura del Framework

156

De la figura anterior es posible describir las siguientes etapas:

Análisis del Dominio: Se descubren requisitos del dominio y los posibles requerimientos futuros a partir de estudio de los patrones de procesos de negocio.

Para completar los requerimientos sirven las experiencias previamente publicadas, los sistemas de software existentes, las experiencias personales y los estándares considerados.

Fase del Diseño del Framework: Define las abstracciones de éste. Se modelan las clases comunes y especificas, permitiendo la flexibilidad propuesta en el análisis del dominio esbozado en líneas generales.

Fase de Instanciación: Las clases del framework son implementadas, generando un software del sistema aplicado a un caso particular.

9.1 Aplicación del Framework

Los procesos de asignación de recursos y control de tareas para el desarrollo de un proyecto al interior de la DGFDT, son posible de generalizar a la asignación de recursos y control de tareas de cualquier tipo de proyecto dentro de cualquier tipo de empresa u organización considerada. Esto es así puesto la génesis sobre la que se basan estos procesos en cada caso son iguales, esto es, el principio de una asignación de recursos puede ser utilizado tanto para asignar consultores de una empresa de software a un proyecto, como para asignar técnicos de instalación de una empresa de TV Cable. De igual manera los principios que sustentan el control y seguimiento de tareas de los proyectos de la DGFDT pueden ser utilizados para el control de tareas de una consultora de proyectos mineros.

Es entonces que se necesita la construcción de frameworks tomando en cuenta que las

estructuras y lógicas generales es posible utilizarlas para muchos casos específicos. Sumado a lo anterior, en vista que el modelo de patrones de diseño permite una especificación de la lógica de negocios, bastaría simplemente con definir estas lógicas particulares para lograr un sistema específico a las necesidades del negocio. Todo esto simplifica cualquier otro tipo de desarrollo y se transforma en una potente solución a múltiples problemáticas.

En la figura a continuación se muestra el diagrama del framework para la Asignación de

Recursos:

157

Figura 107: Framework Asignación de Recursos

De la figura se aprecian las siguientes clases que se detallan a continuación:

Asignación de Recursos: Corresponde a la clase en la que se aplica la lógica particular asociada al negocio. Para los casos particulares se requiere analizar específicamente las funciones de las clases Prioridad, Tareas y Recursos, y que como se aprecia son específicos para cada clase, en este caso para la de Asignación de Recursos para Diseño y Desarrollo de Proyectos. Prioridad: Es una clase entity que contiene la información de las prioridades que son asignadas a cada proyecto y a cada tarea dentro de dichos proyectos (de esta forma se tiene que las tareas con mayor prioridad provienen de los proyectos con más alta prioridad). La prioridad definida estará dada de acuerdo al criterio que defina ya sea el responsable o los jefes de proyecto respectivos. Tareas: Esta clase entrega toda la información asociada con las tareas en desarrollo y también con aquellas pertenecientes a proyectos previamente realizados, dado que pueden entregar valiosa información para futuros proyectos. Asociada a cada tarea es posible encontrar comentarios, archivos y documentos adjuntos, tiempo de realización y recursos participantes como las principales características. Los elementos más relevantes para cada tarea y que precisamente permiten realizar el proceso de asignación son: la especialidad, la dependencia (entre tareas) y el esfuerzo. Para mayor detalle revisar las consideraciones del punto 6.2 Proceso de Asignación de Técnicos.

158

Recurso: Representa a los diferentes recursos participantes de cada proyecto y que poseen una serie de características que los definen y que son esenciales para el proceso de asignación, como son: las habilidades, la especialidad y la experiencia.

9.2 Construcción del Framework

De acuerdo a lo discutido anteriormente, y de acuerdo a las clases mostradas en las figuras siguientes se construye el framework:

Figura 108: Diagrama de Clases Asignación

De acuerdo a la estructura de clases que se aprecia en la figura anterior, se puede generalizar el desarrollo de un sistema para la asignación de recursos de la forma siguiente:

Clases de Control

Asignación de Recursos: esta clase ejecuta las lógicas de negocio relacionadas con la asignación de los recursos a los proyectos y tareas para cada caso.

Clases Entity

Recurso: Contiene las características de cada recurso y que permiten llevar a cabo las lógicas de asignación. Particularmente las habilidades, especialidad y experiencia.

159

Prioridad: Se almacena la información de prioridades de proyectos y tareas. Podrá variar entre valores enteros dentro del rango de -10 a 10.

Tarea: Guarda toda la información relevante de cada tarea. En lo que respecta directamente a la asignación incluye la especialidad, la dependencia y el esfuerzo.

Con todo lo anterior se construye el siguiente framework:

Figura 109: Framework

160

9.3 Aplicación Particular Tomando en consideración el modelo planteado en los puntos anteriores y con el objeto

de comprobar el grado de aplicación del framework, se muestra a continuación una propuesta para el desarrollo de un sistema de asignación de consultores en una empresa de software, de manera que para cada nueva solución solicitada a la empresa, se distribuyan las tareas y se asigne a los consultores de acuerdo a la carga total de trabajo existente, optimizando así el uso de los recursos.

A continuación se muestra la aplicación del framework para este caso particular:

Figura 110: Diagrama de Clases de Control y Entity de la Aplicación De la figura anterior es posible ver que la estructura propuesta en el framework no se ve

modificada mayormente, implicando simplemente una especificación de los parámetros definidos en las clases entity para ajustarse este caso particular, con lo cual éstos serán los que en definitiva muestren las diferencias entre un caso y otro.

161

Capítulo 10 Discusiones En el presente capítulo se efectúan los análisis de los resultados obtenidos de la solución propuesta en cuanto a los alcances y aportes realizados, así como los problemas y dificultades encontrados durante el diseño y desarrollo de la solución.

10.1 Discusión “Planificación, Asignación de Recursos y Control de Proyectos del Fondo de Desarrollo de las Telecomunicaciones” En esta sección se discutirá sobre todos aquellos elementos considerados para el diseño de la solución, se analizará la metodología desarrollada en el capítulo 5 así como parte de los resultados obtenidos en el diseño y desarrollo de la solución, y tal como se plantea en el titulo de esta discusión serán analizados como piezas centrales la planificación de proyectos, la asignación de recursos a dichos proyectos y finalmente el control y seguimiento de los mismos durante el desarrollo de cada proyecto. Es prudente recalcar que existe una variada gama de alternativas tecnológicas que atacan los temas de manejo de proyectos, es así como existen diferentes teorías, metodologías, estándares, entre otros, que abordan este tema entregando una visión sobre como realizar un buen manejo y que implicancias tiene esto dentro de la organización. Particularmente para el caso de proyectos del Fondo de Desarrollo de las Telecomunicaciones es posible comprender que se requiere de un esfuerzo importante en definir correctamente cuales deben ser los pasos a seguir para llevar a cabo un proyecto de esta índole, debido a la gran cantidad de requerimientos de todas partes del país y a la aparición de nuevas tecnologías cada vez más rápidamente, con lo cual es fundamental tener ciertas estructuras sobre las cuales poder tomar decisiones antes de llevar a cabo un nuevo proyecto que implique hacer uso de nuevas y mejores tecnologías. Cuando se habla de tener un buen manejo o de realizar “buenas prácticas”, no es a la ligera, ya que efectivamente es lo que hace la diferencia al momento de realizar una actividad, y que si la llevamos a un caso general, se tiene que para un gran número de actividades realizadas por un gran número de individuos, existe una enorme cantidad de factores de riesgo que perjudiquen el desarrollo de cada actividad y por ende del trabajo en su conjunto, más aún cuando las actividades no son independientes entre sí sino que están íntimamente relacionadas, como ocurre en la gran mayoría de los proyectos.

162

Como parte elemental para poder comprender estos proyectos, que tipos existen, como

se llevan a cabo, qué elementos los caracterizan, cuanto duran, etc., fue tomado en consideración el modelo de tipificación para proyectos de instalación en telecomunicaciones realizado por Ariel Muñoz T., el cual analizó una serie de proyectos de instalación en telecomunicaciones, en particular considerando la clasificación de los proyectos por tipo de funcionalidad entregada por Ferrer Durá el año 2003 y utilizando el modelo de jerarquización de redes de Cisco, extrapolándolo al caso de proyectos de instalación en telecomunicaciones. La base de conocimiento sobre la cual se pretende establecer un apoyo efectivo al manejo de proyectos, tanto en la planificación como durante el control y seguimiento de recursos, se estructura sobre el modelo antes mencionado, ya que permite definir con precisión un proyecto de instalación en el área de telecomunicaciones, que cubre a los proyectos desarrollados por la DGDFT, con lo que se logra una correcta clasificación de estos que pueda ser utilizada para obtener información relevante de proyectos anteriormente realizados de manera simple y precisa.

10.1.1 Planificación De acuerdo a la American Management Assocation, la planificación “consiste en determinar lo que se debe hacer, cómo se debe hacer, que acción debe tomarse, quien es responsable de ella y por qué”. Para otros autores “el futuro no hay que preverlo, hay que crearlo. El objetivo de la planificación debiera ser diseñar un futuro deseable e inventar el camino para conseguirlo”. La planificación juega un rol de gran relevancia en la obtención y administración de compromisos confiables entre los participantes de un proyecto, a distintos niveles. Es una función dinámica, que debe actualizarse permanentemente debido a que corresponde a tomar decisiones anticipadas respecto de un futuro que no se conoce en forma perfecta.

La planificación es por cierto una de las etapas más relevantes de un proyecto, puesto que involucra todas aquellas proyecciones que se hagan para determinar los tiempos requeridos, los recursos a utilizar, la tecnología involucrada, entre otros, y que finalmente impacta en el costo en el que se incurrirá durante el desarrollo de éste, de forma tal que si es mal planificado puede desembocar en un aumento de tiempo y costos suficientemente grandes como para producir el fracaso del proyecto, lo que por demás se da con bastante frecuencia41.

Como parte fundamental de este proceso se tomó en consideración los conceptos obtenidos de la metodología y estándares del PMI y CMMI respectivamente. Estos fueron analizados en profundidad con lo que fue posible determinar una serie de elementos que permiten definir con claridad un proceso de planificación de proyectos y tomando en consideración por supuesto que se desea manejar proyectos del FDT siguiendo los objetivos planteados al inicio de este trabajo.

41 Ver Motivación, Capítulo 1.

163

Los elementos de diseño recogieron todos aquellas características presentes en un proyecto y que deben ser consideradas durante la planificación, como por ejemplo: duración, ciclo de vida, esfuerzo y costo, recursos, etc. Cada uno de ellos fue detallado para explicar como influye dentro del diseño de la solución, y como se relaciona con otros elementos de diseño.

Un aspecto importante que se tomó en cuenta para el diseño y desarrollo y que impacta especialmente durante la planificación, es el de la definición de tareas o actividades a ser realizadas durante un proyecto, y que considera cual es la dependencia entre estas tareas, cuanto tiempo requiere realizarlas, qué recursos necesitan, entre otros, y que se ve finalmente reflejada en la construcción de una carta gantt que detalla todo lo que debe ser realizado durante la implementación del proyecto.

Para ello se decidió aprovechar la base de conocimiento construida con los proyectos de telecomunicaciones y el modelo de tipificación, con lo cual se logró que para cada nuevo proyecto a planificar fuese posible obtener proyectos de características similares y que pudiesen entregarle al nuevo proyecto la base de las tareas a realizar, tiempos, costos, etc. de manera que el responsable encargado de la planificación sólo tenga que realizar cambios menores a la planificación ya realizada, y de la cual ya se tiene por supuesto una cierta experiencia del trabajo realizado lo que fortalece aún más la planificación del nuevo proyecto.

10.1.2 Asignación Actualmente, no es posible desarrollar proyectos con tecnologías de avanzada y personal calificado, haciendo uso de procesos obsoletos de dirección y manejo de proyectos. Una decisión inoportuna o mal planificada pone en peligro el cumplimiento de los objetivos y resultados del trabajo desarrollado por los integrantes del proyecto. Las empresas generalmente disponen de personal calificado y potentes sistemas informáticos montados sobre sus redes de computadoras, que hacen factible el manejo de proyectos haciendo uso de las nuevas tecnologías de la informática y las comunicaciones, con el objetivo de garantizar el balance adecuado entre el sistema de dirección y el nivel tecnológico alcanzado en los procesos productivos o de los servicios entregados. La asignación de recursos dentro del manejo de proyectos constituye uno de los problemas más importantes por su incidencia, principalmente en la duración y los costos del proyecto.

Junto a lo anterior, se hace muy necesario el uso de las TIC como apoyo a la asignación de los recursos en los proyectos, con el objetivo de obtener la información necesaria para efectuar de manera óptima y con la mayor precisión posible dicho proceso.

164

Por otro lado, cuando la asignación se realiza mediante un procedimiento manual se

hace más difícil la reducción del tiempo con la asignación de nuevos recursos, pero cuando se ejecuta mediante un sistema informático, es posible realizar determinados cálculos que faciliten los análisis y la toma de decisiones, teniendo presente la ruta crítica, el costo y la disponibilidad de recursos.

Es posible encontrar muchas similitudes en los procesos de asignación para distintos

tipos de proyectos de ingeniería. Es por eso que se tomaron todos aquellos elementos comunes y fueron definidos como elementos a considerar para un potencial modelo de asignación.

10.1.3 Control y Seguimiento Por un lado, el seguimiento corresponde a la obtención y análisis de la información sobre el desempeño hasta el momento en que se realiza el control, utilizando como base de referencia y comparación la planificación. De esta forma es posible identificar variaciones en el plan, y proyectar el desempeño futuro del proyecto. Por otro lado, el control se refiere a tomar acciones en base a la información entregada por el seguimiento, es decir, actuar sobre los factores que generan las variaciones. El poder controlar efectivamente los proyectos es un elemento muy relevante para entregar una administración proactiva.

Todo lo anterior determinará las formas de implementación de los proyectos, lo que por ende impacta en el cómo estos serán seguidos y controlados.

Para esto se diseñaron los flujos acorde a los procesos actualmente realizados en la DGFDT para llevar a cabo un proyecto, los cuales fueron diseñados tanto en la arquitectura de macroprocesos, estando relacionados con los procesos de planificación y asignación, como en los diagramas de secuencia, los que detallan claramente como los diferentes actores llevan a cabo estos procesos y de que forma interactúan con las tecnologías utilizadas (bases de datos, paginas Web, controladores, etc.).

10.1.4 Diferencias con Soluciones Existentes Existen numerosas soluciones que buscan apoyar integralmente el manejo de proyectos, las cuales están formadas en muchos casos no de un solo sistema sino varios sistemas y plataformas que se comunican entre sí entregando todo tipo de funcionalidades y que a su vez apoyan a otras áreas de negocio. Estas soluciones no sólo se preocupan por entregar las herramientas necesarias a los involucrados en cada proyecto para que estos puedan implementarlo correctamente, sino que toman en cuenta al cliente y como entregarle a él un producto o servicio de la mayor calidad, haciéndolo parte del proceso de planificación e implementación del proyecto.

165

A continuación se mencionan algunas de las soluciones encontradas:

10.1.4.1. AuraPortal

Es una solución de gestión de proyectos que considera para ello 4 elementos fundamentales [8]:

BPM (Gestión de Procesos) con Reglas de Negocio

Intranet/Extranet con Workflow

Gestión documental sobre MS SharePoint42

Portales para Comercio Electrónico y Página Web

Soporta todo el ciclo de gestión de los proyectos definido como: configuración, planificación, ejecución, seguimiento y medición de los resultados.

Configuración

Se fijarán los objetivos, se definirán los recursos que deben intervenir (personal, equipo, etc.), se establecerán previsiones de costes y tiempos y se le dotará de toda la información necesaria para su realización.

Planificación

Podrá establecerse una planificación del desarrollo de un proyecto tan amplio y detallado como se desee. Las fases de desarrollo y las tareas a realizar se determinarán siempre en función del nivel de control que se quiera obtener sobre las actividades y recursos que van a intervenir.

Ejecución

Se incrementa de forma natural el éxito de los proyectos gracias al control y la información. Permite automatizar todas las etapas y el flujo de trabajo de los proyectos, desde su creación hasta su conclusión.

Seguimiento y Medición de los Resultados

Permite análisis inmediatos de la marcha de los proyectos de forma automática y al día, comparando datos previstos frente a realizados, permitiendo el análisis de la ejecución del proyecto.

42 Sistema que permite la colaboración entre usuarios e integrar las aplicaciones de escritorio como MS Office, MS Project, entre otras. Posee diversas herramientas de control de contenidos.

166

10.1.4.2. IFS Applications

Es un conjunto de soluciones enfocadas especialmente para el sector de las telecomunicaciones, que ofrece soporte a nivel mundial a operadores de telefonía tanto fija como móvil, compañías de radiodifusión, ISP’s y empresas de construcción y mantenimiento de redes. [22]

Aspectos diferenciales de IFS son entre otros, su funcionalidad específica para el

sector, su experiencia contrastable y una arquitectura basada en componentes que permite precios ajustados, implementación gradual paso a paso y facilidad de integración con aplicaciones de terceros.

Con IFS se seleccionan e implementan solamente el conjunto de componentes de negocio que sean necesarios y se añade nueva funcionalidad de acuerdo al incremento de necesidades.

En particular para la gestión de proyectos, la solución de IFS controla y da visibilidad a la ejecución y el progreso de cada proyecto. Soporta la obra en curso o la instalación de equipamientos, el reporte de situación y el seguimiento de las actividades de proyecto así como la introducción de datos de tiempo, gastos de viaje o cualquier otro tipo de costes.

10.1.4.3. Project Management de SAP Business One

Esta solución se enmarca dentro de las soluciones verticales que entrega SBO43 [44] y que corresponden a soluciones internacionales complementarias a SBO y que han sido adaptadas a las necesidades locales.

Project Management es una solución de gran alcance para las industrias de servicio inmersas en grandes proyectos y está diseñada para adaptarse a diferentes tipos de clientes. Se integra rápidamente en las operaciones diarias. Es una solución fácil de utilizar con un corto período de implementación, para que el usuario pueda aprovechar rápidamente las ventajas de su implementación.

Ofrece una amplia gama de características y de funciones, proporcionando todas las herramientas necesarias para la gerencia acertada de los proyectos, incluyendo el planning, la gerencia de recursos, el análisis, la facturación y el cálculo de los proyectos múltiples, servicios, la gestión del tiempo de los empleados así como los costos de los traslados.

43

SAP Business One.

167

10.2 Discusión “Metodología PMI y Estándar CMMI”

El entorno actual de desarrollo de proyectos a nivel mundial, presenta condiciones de cambio acelerado permanente, lo que genera por supuesto constante incertidumbre, la aparición cada vez más rápido de competencia, ciclos de vida menores de productos, tecnología accesible a cada vez más individuos, menores tiempos de producción, recursos limitados, mayor grado de complejidad de los desarrollos, mayores niveles de innovación, y necesidad de mayor eficiencia operacional, etc.

Todo lo anterior motiva a buscar cada vez con mayor fuerza metodologías para el

manejo o administración de proyectos que permitan entre otras cosas realizar más trabajo con menor cantidad de recursos en menor tiempo, mantener un mejor control de los cambios, incrementar la calidad de los productos y servicios entregados, e incrementar la rentabilidad del negocio, entre otros.

Los proyectos de telecomunicaciones y en particular los del FDT no son ajenos a esta

problemática, dadas la complejidad que estos presentan en cuanto a las tecnologías aplicadas, la cantidad de recursos requeridos, la competencia permanente entre las empresas del sector, las regulaciones existentes, etc. Es por esta razón que la entrega de metodologías para el manejo de proyectos como apoyo al desarrollo de los mismos, es sumamente relevante.

A continuación se discutirá sobre los 2 estándares utilizados para el desarrollo de la

solución.

10.2.1 Metodología PMI La metodología PMI entrega una serie de beneficios enfocados a la administración de proyectos, los cuales se mencionan en la siguiente tabla:

Eficiencia Operacional Integración Oportunidades

Asignación de Recursos Plazos Costos y Presupuesto Identificación de Riesgos

Planificación Control y Seguimiento Desarrollos Paralelos Aprovechar Conocimiento

Mayor Rentabilidad Aumento Calidad de Productos y Servicios Satisfacción del Cliente

Tabla 12: Beneficios de la Metodología PMI

Los beneficios aquí mencionados son precisamente los que motivan a utilizar esta

metodología para el diseño de la solución, ya que considera los elementos suficientes para el correcto manejo de proyectos.

168

Pese a ello, existen también desventajas en la aplicación de esta metodología y que se

pueden ver a continuación:

Se requiere de una mayor inversión

Puede generar conflictos dentro de la organización

Requiere que parte del tiempo de trabajo sea utilizado en la generación de documentos.

Toma un tiempo no menor ajustar la correcta aplicación de la metodología.

Requiere que exista flexibilidad por parte de los individuos.

Entre otras.

Pese a lo anterior, se optó por seguir el diseño utilizando loe elementos entregados por esta metodología, para los cuales se consideró lo siguiente:

Gestión del Tiempo: Fue contemplado que gracias a la correcta definición de las tareas, su secuenciación y una precisa estimación de los recursos requeridos para realizarlas (para lo que fue considerado un atributo de esfuerzo de tareas), es posible evitar grandes variaciones entre lo planificado y el resultado final del proyecto. Para esto se requiere de una base de conocimiento sólida formada por un número importante de proyectos.

Gestión de los Costos y Recursos: Como una forma de determinar con mayor precisión los costos a incurrir durante los proyectos y particularmente como apoyo al proceso de asignación, es que se requiere nuevamente de un número importante de proyectos que permitan realizar buenas estimaciones de costos, y que se traducirá en entregarle al cliente un presupuesto más preciso y evitar sorpresas desagradables al cierre del proyecto.

Gestión de las Comunicaciones: Se planteó precisamente como consideración para el diseño de los flujos de trabajo (Workflows), ya que es una necesidad que los actores relevantes puedan conocer permanentemente el estado de los proyectos, así como que la información de problemas y soluciones quede documentado para el desarrollo de futuros proyectos.

Gestión del Alcance: Esta relacionado directamente con las tareas o actividades típicas de los proyectos de telecomunicaciones, de forma tal que estarán consideradas en los proyectos ingresados, particularmente en las cartas gantt de cada uno de los proyectos del FDT.

169

Gestión de la Integración: Se consideró a nivel general como el área encargada principalmente de la supervisión de los procesos definidos en la arquitectura de procesos y de documentar los criterios definidos para los proyectos desarrollados.

No fueron consideradas las gestiones de riesgo ni de adquisiciones, no porque no sean

relevantes, ya que son de vital importancia y es necesario tenerlos muy presente para llevar un buen manejo de proyectos, sino que para efectos de la solución propuesta y la herramienta desarrollada, no fue necesario considerarlos. Su utilización quedará propuesta para futuros trabajos en los cuales será necesario profundizar en dichos temas.

10.2.2 Estándar CMMI Poniendo en el contexto de las etapas de evolución del CMMI es posible ver que el manejo de proyectos corresponde al primer paso y uno de los más difíciles para una organización en llevar a cabo para mejorar sus procesos:

Figura 111: Gestión Básica de Proyectos en las Etapas de Evolución del CMMI

Las consideraciones básicas para el manejo de proyectos, de acuerdo a lo definido en este estándar, entregaron 3 fases principales y que son: el establecimiento de las estimaciones, el desarrollo de un plan, y la obtención de los compromisos con el plan. Las 2 primeras fases fueron las consideradas para el diseño de la solución y que coincide con lo establecido por el PMI en las áreas de gestión de tiempo, costos, recursos y alcance. Por otro lado los compromisos con el plan deberán ser tratados tomando en consideración los compromisos que serán requeridos para una eventual implementación de la solución propuesta en una empresa de telecomunicaciones.

170

10.2.3 Enfoques Alternativos

Las metodologías y estándares utilizados para el desarrollo del trabajo de tesis han sido probados como formas efectivas de abordar el manejo de proyectos así como todo aquello asociado a la gestión de éstos, pero claramente éstos no son los únicos existentes.

Basado en los sistemas de gestión de una conocida empresa automotriz japonesa a

nivel mundial, Lean Project Delivery o Entrega de Proyectos sin Pérdidas, es un enfoque de Lean Construction o Construcción sin Pérdidas que busca el mejoramiento del desempeño durante la fase de ejecución de proyectos, cubriendo además un conjunto de funciones para los procesos administrativos de las organizaciones, enfoque que ha tomado cada vez mayor fuerza.

LPD ha sido diseñado considerando los sistemas de reducción de pérdidas y que

agregan valor sistemáticamente en el proceso de manufactura, también llamado Lean Production o Producción sin Pérdidas [3].

El aumento en la aplicación de LPD ha logrado que las prácticas de este se propaguen verticalmente en la cadena de valor, incorporando una nueva mirada en el diseño, abastecimiento y contratación de recursos en los proyectos

Sumado a este enfoque aparece un sistema de planificación y administración, que

muestra cabalmente la introducción de LC en la fase de ejecución de proyectos, llamado Last Planner System. La aplicación de LPS en diversos proyectos ha dado prueba de mejoras en ámbitos como: los costos, los tiempos, la calidad y la seguridad.

Precisamente el comienzo de LPS está dado por las críticas a las metodologías del PMI

particularmente en el área de la construcción.

10.3 Discusión “Arquitectura de Procesos” La estandarización de procesos de negocios por intermedio de los PPN busca sintetizar el conocimiento empírico y la experiencia de procesos de negocios en estructuras sin una formalización clara, es decir, que no tienen una descripción formal respecto de los elementos que conforman dichas estructuras. Esto busca evitar que existan dificultades en la aplicación de patrones para el modelamiento de procesos y que también se encuentran presentes en una serie de otros estándares SCOR, eTOM, FEA, etc. Algunos de los problemas principales que logra resolver este estándar, a diferencia de los otros, son:

1. No hay una sola interpretación, por parte de los diseñadores, de los elementos de las estructuras, lo que produce problemas de aplicación, pues es es poco directa la asociación con elementos de un proceso real. Esto no pasa en la ingeniería tradicional, donde las estructuras estándares tienen elementos simples de identificar, como redes, cables, conexiones, etc.

171

2. La mayoría de los modelos genéricos no explicitan aspectos fundamentales de la

gestión de negocios, tales como coordinación, centralización o descentralización y el rol de la tecnología en las actividades del proceso, lo cual hace que las opciones de rediseño desde el punto de vista de gestión, no estén claras.

3. Por ende los modelos no explicitan una gran cantidad de conocimiento tácito del

proceso, lo cual dificulta su uso práctico y perjudica la calidad de los rediseños basados en ellos.

Con todo lo anterior, se tiene un patrón que permite modelar adecuadamente los

procesos que formarán parte de la solución para el manejo de proyectos de instalación de telecomunicaciones, considerando todos los elementos de diseño mencionados en la metodología, de manera de definir la arquitectura sobre la cual se regirán los procesos que conforman la solución y que consideran a grandes rasgos la planificación, la asignación de recursos y el seguimiento y control de los proyectos.

Por último es posible comentar que la ayuda que entrega la modelación de los procesos

junto con el estudio de la solución facilita de manera considerable el posterior diseño de ésta, ya que se obtiene una comprensión más acabada de cual es el funcionamiento de una organización y por ende cuales son sus falencias con el fin de elaborar herramientas que se ajusten a sus necesidades.

10.4 Discusión “Prototipos de Planificación y Seguimiento Implementados”

Como parte de los resultados obtenidos durante el desarrollo de este proyecto es que se desarrolló un prototipo que pudiese ejemplificar en una primera aproximación cómo debería ser la herramienta de gestión diseñada, cómo será la interacción de los usuarios con ella, cuales funcionalidades serán utilizadas y cuál deberá ser el diseño de las pantallas de manera que haga más amigable su uso.

A continuación se discutirán los puntos más significativos en el desarrollo del prototipo

y que corresponden a las características de código abierto de la aplicación, a cómo fue incorporado el modelo de tipificación siguiendo el diseño previo, las características de conexión de la aplicación Web con GanttProject y el diseño de la interfaz para facilitar la tarea al usuario.

172

10.4.1. Características Open Source Fue necesario realizar el desarrollo del prototipo en un lenguaje open source como lo

es Java, esto debido al carácter docente del proyecto de tesis y porque son precisamente las aplicaciones de este tipo las que están comenzando a tener mayor relevancia ya no sólo a nivel académico sino también a nivel corporativo, y porque también permite que futuros memoristas puedan trabajar sobre la herramienta desarrollada, añadiéndole funcionalidad para construir una aplicación más robusta y con más capacidades o simplemente utilizando algunos de sus bloques funcionales para la realización de nuevas aplicaciones.

Fue también posible lograr que la mayoría de las herramientas con las cuales se trabajó

para el desarrollo del prototipo fueran de código abierto, como es el caso de la base de datos MySQL, el administrador de esta base de datos EasyPHP, el entorno de desarrollo basado en Eclipse llamado Red Hat Developer Studio y JBOSS que es un servidor de aplicaciones J2EE totalmente de código abierto e implementado en Java. Junto con ello la plataforma de manejo de contenidos Joomla, así como las aplicaciones incorporadas para el manejo de documentos y control de tareas, también son de código abierto, con lo cual se entrega una solución completamente flexible y modular, capaz de ser modificada fácilmente para futuras mejoras.

Por supuesto la herramienta que permite la creación y despliegue de cartas gantt

llamada GanttProject, con la cual fue necesario realizar la interconexión con la aplicación Web desarrollada, también es una herramienta open source, razón por la cual se obtiene una aplicación completamente de código abierto, flexible y sujeta a futuras modificaciones.

10.4.2. Incorporación del Modelo de Tipificación

Para el desarrollo de la aplicación fue necesario considerar todos los elementos

utilizados en el diseño de la solución, y en particular los elementos entregados por el modelo de tipificación de proyectos de instalación de telecomunicaciones, del cual se obtuvo la base para desarrollar el repositorio de proyectos de telecomunicaciones y que conforman la base de conocimiento de la herramienta. La estructura de la base de datos se puede ver en el diagrama de clases físicas de la arquitectura de diseño de la solución en el capítulo 6.

Los proyectos ingresados debieron seguir algunas de las características correspondientes a las familias de proyectos definidas en el modelo de tipificación, así como los criterios y los valores de éstos que son asociados a cada uno de los proyectos que ingresa a la base de datos, es así como se tiene diferentes tipos de proyectos de Core, Distribución, Acceso Cableado, Redes Inalámbricas y NGN.

Junto con lo anterior se consideró el uso de algunos proyectos tipo de la GDFT para

poder determinar las tareas y actividades a realizar por cada uno de ellos, las dependencias existentes entre ellos y los recursos requeridos, de manera de generar cartas gantt que se ajusten a los proyectos implementados actualmente.

173

Es necesario aclarar que dado que la herramienta basa su precisión en la calidad de la

base de conocimiento de la que disponga, los resultados obtenidos de parte de la aplicación al momento de buscar proyectos similares al proyecto ingresado serán en principio imprecisos, puesto que la base se irá poblando poco a poco de la información de los proyectos que se irán realizando y de aquellos proyectos previamente desarrollados y con los que se cuente la información necesaria.

10.4.3. Conexión entre la Aplicación y GanttProject La opción de poder interconectar la aplicación Web desarrollada en Java con la herramienta de manejo de diagramas gantt, GanttProject, fue posible gracias a el manejo de lenguaje XML, el cual permitió por un lado almacenar los proyectos en la base de datos utilizando este formato, y por otro lado permitiendo crear proyectos nuevos de base utilizando.

Al comienzo la información ingresada (nombre de proyecto, código, fechas, recursos) permitirá obtener una carta Gantt inicial y que luego pueda ser modificada incorporando las tareas o actividades propias de los proyectos en cuestión.

El lenguaje XML (aunque en realidad no es considerado un lenguaje si no como una manera de definir lenguajes para distintas necesidades) permite de manera sencilla intercambiar información estructurada entre diferentes plataformas, como bases de datos, editores de texto, hojas de cálculo, y como en este caso aplicaciones en principio diferentes. La estructura en XML de una carta gantt creada en GanttProject se puede ver en la sección de desarrollo del prototipo en el capítulo 7, al igual que la estructura de una gantt básica.

Es también interesante comentar que GanttProject es perfectamente compatible con

MsProject, y que fue probado exportando proyectos a ambas aplicaciones, y que a su vez Project permite también el manejo de diagramas gantt por intermedio de XML, lo que facilitaría la futura adopción de MsProject como herramienta de manejo de cartas gantt dando más flexibilidad a la aplicación. Pese a lo anterior existe todavía un paso manual en el cual se requiere abrir GanttProject para luego introducir manualmente el archivo XML correspondiente a la carta Gantt del proyecto, pues no ha sido posible ejecutar directamente el archivo de manera que sea abierto inmediatamente por la herramienta.

174

10.4.4. Diseño de Pantallas e Interfaz de Usuario

Finalmente, el diseño estipulado para la aplicación desarrollada consideró factores de

utilidad para los usuarios, para lo cual fue necesario observar diseños de otras aplicaciones existentes estudiando que configuraciones son las que entregan una mejor interfaz.

Como resultado se obtuvieron diseños simples pero a la vez agradables a los usuarios, con funcionalidad que dieran cuenta de toda la información relevante

Inicialmente se diseñaron 12 páginas Web en las cuales aparecen reflejados los

diferentes pasos tanto del ingreso de nuevos proyectos como de la búsqueda de proyectos almacenados, de manera que en cada uno de ellos se definió una estructura simple y ordenada para el despliegue de la información utilizando principalmente tablas.

Un punto importante fue el diseño de una página de resumen antes de almacenar el

proyecto en la base de datos desplegando toda la información seleccionada para el proyecto nuevo ingresado, y que resulta muy útil para verificar que la información es la correcta y disminuir la cantidad de proyectos mal ingresados.

Luego, una vez implementada la plataforma de manejo de contenidos, se procedió a

diseñar un variado número de páginas que mostraran todas las funcionalidades puestas a disposición de los usuarios de forma simple y rápida. Para mayor detalle ver Anexo D.

Por último es necesario comentar que dada la forma en la cual fue construida la

aplicación, es posible modificar el diseño de las páginas de manera relativamente sencilla, ya que se está considerada la separación de la parte lógica de la interfaz en la permanente búsqueda de flexibilidad y modularidad de los desarrollos.

175

Capítulo 11 Conclusiones En este capítulo se dan a conocer las conclusiones finales del trabajo realizado y se detalla el cumplimiento de los objetivos planteados, los principales problemas generados durante el desarrollo del trabajo y cuales deberían ser los caminos a seguir para continuar en esta misma línea.

11.1 Conclusiones Generales

Por medio de este trabajo de tesis, fue posible desarrollar una solución capaz de facilitar el manejo de proyectos de la GFDT, aprovechando la información existente de proyectos anteriormente realizados y construyendo una base de conocimiento efectiva en base a un modelo de tipificación para proyectos de instalación de telecomunicaciones previamente desarrollados.

La solución diseñada aplica metodologías, estándares y estructuras de procesos, de

manera de utilizar los elementos necesarios para poder apoyar de manera efectiva 3 de los procesos más relevantes en la administración de proyectos y que son: la planificación, la asignación de recursos y el seguimiento y control de tareas o actividades.

Para lo anterior fue necesario efectuar una exhaustiva investigación respecto de toda la

información existente en cuanto a dirección de proyectos se refiere, y que incluye estándares en diferentes ámbitos y áreas de la ingeniería, teorías nuevas o ya existentes respecto a las “buenas prácticas” en los proyectos, o la búsqueda de modelos que entregaran guías sobre como es efectuado el procedimiento de asignación de recursos actualmente.

Fue así como se realizó un estudio de la metodología para la dirección de proyectos del

Instituto de Manejo de Proyectos (PMI), la cual fue también utilizada para el diseño del modelo de tipificación y que fue una de las razones por las que se decidió utilizarla. Esta metodología presenta por un lado varias ventajas en cuanto a una mayor eficiencia operacional (asignación de recursos, determinación de los plazos y costos, etc.), mayor integración (mejor planificación, control y seguimiento, etc.) y la generación de mejores oportunidades (principalmente por una mayor rentabilidad).

176

A su vez, la metodología del PMI presenta diversas desventajas en cuanto a requerir

una mayor inversión, una disminución de la productividad generada en principio por la poca flexibilidad que pueden tener los individuos al considerar “todos” los elementos entregados por la metodología, el requerir tiempos de ajuste o para la generación de documentos, entre otros.

Junto a la metodología anterior fue considerado el estándar CMMI cuyo objetivo está

relacionado con la creación de guías de evaluación y mejora de los procesos de desarrollo y mantenimiento de sistemas y productos de tanto de software (por intermedio de su división CMM-SW) como de ingeniería (por intermedio de su división SE- CMM). Su propósito es distinto, ya que a diferencia del PMI, el CMMI entrega una visión de mejora de procesos en una organización y que puede tomar como referencia el PMBOK para administrar los proyectos orientados a mejorar la capacidad y madurez de los proceso involucrados en el desarrollo de proyectos.

Los aportes de ambos modelos fueron utilizados en la construcción de una arquitectura

de procesos en base a los patrones de proceso de negocios (PPN), lo que permitió en definitiva diseñar la solución en una estructura bien definida tomando en consideración todos los elementos necesarios para realizar el correcto manejo de proyectos de telecomunicaciones del FDT.

Es necesario recalcar que gracias a los PPN fue posible poder plasmar todos aquellos

conceptos y elementos de diseño obtenidos de la metodología PMI y del estándar CMMI, pues permite generar una estructura de procesos bien definida donde establecer e incorporar cada uno de los nuevos criterios al interior de la organización y particularmente en lo que respecta a la planificación y gestión de los proyectos.

En cuanto a los objetivos planteados, se entrega mediante la solución, un apoyo al

proceso de planificación de forma de proporcionarle a él o los responsables de ingresar los proyectos, información histórica que pueda ser aprovechada para la planificación de los nuevos proyectos. Ejemplo de esto son las cartas gantt de todos aquellos proyectos que tengan características similares a los nuevos proyectos ingresados, en cuanto a la familia de proyectos a la cual pertenecen y a los criterios (y valores) que tienen asignados.

Fue posible también incorporar como apoyo al desarrollo de los proyectos, el diseño de

los procesos encargados de entregar la información de problemas y soluciones a los recursos ejecutores de las tareas, de forma que puedan hacer uso de esta información que en la mayoría de los casos queda solamente en aquellos que realizaron las tareas anteriormente, y no en un repositorio formalmente establecido.

Adicionalmente, se definieron los elementos más relevantes para el diseño y desarrollo

de un futuro modelo de asignación de recursos técnicos encargados de la implementación de cada uno de los proyectos planificados, de manera de tomar en consideración las variables necesarias para optimizar el manejo del proyecto, disminuyendo los tiempos de “recurso ocioso” y por ende de los costos.

177

Al igual que en el caso de la entrega de información de problemas, el proceso de

seguimiento y control de tareas fue logrado por intermedio de la plataforma y particularmente a través de la herramienta de control de tareas, de forma tal que se pudo definir parte importante de cómo debería ser su desarrollo, incluyendo qué herramientas deberían ser utilizadas en dicho caso. Fue así como la herramienta sirvió de prototipo para implementar los flujos de trabajo (Workflows) de un proyecto a desarrollar, realizando entre otras cosas: envío de alertas, manteniendo actualizada las tareas y avances de los proyectos, y estableciendo la comunicación efectiva entre los actores involucrados en cada proyecto.

Respecto de la capacidad de la solución propuesta, en cuanto a la metodología de

diseño de la solución y los modelos sobre los cuales está basada, es posible decir que es aplicable no sólo a proyectos de telecomunicaciones como los desarrollados por el FDT, sino cualquier otro tipo de proyectos de ingeniería, dadas las características del modelo tipificador de proyectos de instalación de telecomunicaciones, que permite incorporar nuevos tipos de proyectos a las familias de proyectos, considerando nuevos criterios que estén asociados a ellos.

Junto con ésto, los diseños de los procesos de planificación, asignación, seguimiento y

control de proyectos de instalación de telecomunicaciones dejan abierta la posibilidad de poder ser aplicados a otro tipo de proyectos de ingeniería (ver Capítulo 9), dada la flexibilidad del diseño realizado y que queda plasmado también en el prototipo de planificación desarrollado, el cual fue construido con la modularidad necesaria para poder incorporar nuevos elementos de clasificación, esto es, nuevas familias de proyectos (Magnitud, Naturaleza, Tipo de Servicio), nuevos tipos de familias (Pequeños, Singulares, Apertura, Mejoramiento, Core, NGN, etc.) y nuevos criterios asociados (Plazos, Costos, Tamaño, Migración, Ancho de Banda, etc.).

Finalmente, cabe destacar el aporte realizado por este trabajo, el cual permitiría apoyar

el desarrollo de futuros proyectos de telecomunicaciones, tanto en la GFDT como en otras organizaciones, entregándoles a los responsables de éstos, las herramientas para simplificar, y hacer con mayor precisión los procesos de planificación, asignación de recursos, seguimiento y control de proyectos. Todo esto entregará como beneficios más tangibles la reducción en los tiempos de implementación y por ende de entrega de los proyectos, el ahorro de costos en el uso de los recursos y en una mejor utilización de los recursos en general.

11.2 Limitaciones de la Solución

De acuerdo a lo descrito en este trabajo de tesis, existen limitaciones para los resultados obtenidos y que están explicadas a continuación:

Es necesario incluir un número importante de proyectos de telecomunicaciones de forma que los resultados entregados por el prototipo de planificación sean efectivamente los esperados, puesto que de lo contrario se le entregará el responsable un proyecto que puede no ser muy similar al proyecto que está planificando.

178

La solución y el prototipo en particular, pese a que poseen un variado número de funciones, carecen de la funcionalidad entregada por otras herramientas existentes en el mercado y que en muchos casos se asocian con otras para formar una gran plataforma de administración. Esto por supuesto es superable incorporando nuevos módulos de funcionalidad y que es posible gracias a las características de modularidad y flexibilidad de la solución.

Las limitaciones que presenta el modelo de tipificación de proyectos de telecomunicaciones son a su vez traspasados a esta herramienta, aunque existe eso si la flexibilidad necesaria para incorporar nuevos tipos de proyectos y actualizar la solución.

Se utilizaron consideraciones generales en algunos puntos de los procesos diseñados, debido a que implicaba extender en demasía el trabajo realizado y que pueden ser perfectamente abordados en un futuro trabajo de tesis.

11.3 Recomendaciones para Trabajos Futuros

A continuación se mencionan algunas recomendaciones para futuros trabajos realizados siguiendo esta línea de estudio:

Tomar como punto de partida los resultados obtenidos con la solución diseñada e incorporarle elementos de los proyectos de telecomunicaciones, como nuevos proyectos y nuevos flujos de trabajo, con actividades específicas a cada tipo de proyecto, de manera de entregar una mayor precisión a cada uno de los procesos diseñados.

Ampliar el prototipo diseñado incorporando un modelo de asignación de recursos, de acuerdo a los criterios definidos y programándolo por ejemplo como un PPL. Además será necesario pasarlo a lenguaje Java o compatible con éste, de manera de crear una aplicación que interactúe con el prototipo.

Desarrollar el motor específico con los flujos de trabajo de los proyectos del FDT a desarrollar, considerando el diseño ya realizado en este trabajo e incorporar las aplicaciones ya diseñadas conformando una completa herramienta para el manejo de proyectos.

Incluir otros tipos de proyectos de telecomunicaciones que amplíen la herramienta, y que dependerá por supuesto de los proyectos llevados a cabo por la GFDT, como son los nuevos desarrollos en tecnologías como 3G, LTE, etc.

Buscar nuevas metodologías o estándares entreguen nuevos enfoques para abordar los problemas del manejo de proyectos, como lo son el LPD y el LPS, que introducen nuevas prácticas fundamentadas principalmente en desarrollos productivos.

179

Referencias Bibliográficas

1. ALARCÓN, L. F. 2008. Planificación la base Fundamental. Curso: Administración de Proyectos. Clase 2. La clase R ejecutiva. El Mercurio. Chile.

2. ALARCÓN, L. F. 2008. Seguimiento y Control del Proyecto. Curso: Administración

de Proyectos. Clase 6. La clase R ejecutiva. El Mercurio. Chile.

3. ALARCÓN, L. F. 2008. Un Nuevo Enfoque: Lean Project Delivery. Curso: Administración de Proyectos. Clase 10. La clase R ejecutiva. El Mercurio. Chile.

4. ALDANA V., A. L. 2002. Planificación, Diseño y Utilización de Herramientas de

Ayuda a la Toma de Decisiones en Tiempo Real. Jornadas sobre sistemas de ayuda a la decisión ante problemas hidráulicos e hidrológicos en tiempo real.

5. AMBRIZ, R. 2002. Tendencias y Mejores Prácticas Globales de la Administración de

Proyectos en TI. Universidad Nacional de Costa Rica. 6. ANDRADE B., C., 2005. Diseño de un Sistema de Administración y Control de

Proyectos de Telecomunicaciones. Memoria para optar al Título de Ingeniero Civil Industrial. Santiago, Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas.

7. ASENTTI. 2006. Tendencias. Competitividad en IT para el Negocio. PMI –PMBOK.

<http://www.cepra.com.mx/asentti_v2/documentos/sinopsis/tendencia_pmi_150207.pdf>

8. AURAPORTAL. Soluciones de Gestión de Proyectos con AuraPortal.

<http://www.comunicacionaura.com/AuraPortal/Emails/GAP/E_GAP_SolGestionProyectos.htm>.

9. BARROS V., O. 2004. Ingeniería e – Business, Ingeniería de negocios para la

economía digital. J.C. SAEZ editor.

http://www.cepra.com.mx/asentti_v2/documentos/sinopsis/tendencia_pmi_150207.pdf

http://www.cepra.com.mx/asentti_v2/documentos/sinopsis/tendencia_pmi_150207.pdf

http://www.comunicacionaura.com/AuraPortal/Emails/GAP/E_GAP_SolGestionProyectos.htm

http://www.comunicacionaura.com/AuraPortal/Emails/GAP/E_GAP_SolGestionProyectos.htm

180

10. BARROS V., O. 2008. Diseño Integrado de Negocios, Procesos y Aplicaciones TI.

Santiago, Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas, Departamento de Ingeniería Industrial.

11. BENGOA G., A. 2000. Sistema de Gestión y Control de Proyectos, GESPRO.

Fundación Tekniker.

12. CASTILLO, E., CONEJO, A., PEDREGAL, P., GARCÍA, R., ALGUACIL, N. 2002. Formulación y Resolución de Modelos de Programación Matemática en Ingeniería y Ciencia.

13. CERDA E., M. A. 2007. Diseño de un Curso para la Gestión/Tipificación de

Proyectos en Telecomunicaciones. Memoria para optar al Título de Ingeniero Civil Electricista. Santiago, Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas.

14. DELGADO V., R., MONTES DE OCA R., M. 2006. Estrategias para la asignación de

recursos en la Dirección Integrada por Proyectos apoyada por las Tecnologías de la Informática y las Comunicaciones.

15. DELGADO V., R., VEREZ G., M. A. 2003. La Dirección Integrada por Proyectos.

Apoyada por las Tecnologías de la Informática y las Comunicaciones en el Marco del Perfeccionamiento Empresarial. Libro de texto. Editado por CETA. ISPJAE. Cuba.

16. DESMOND, C. L. 2003. “Project Management for Telecommunications Managers”.

Kuwler Academic Publishers.

17. DIAGNÓSTICO DIVISIÓN GERENCIA DEL FONDO DE DESARROLLO DE LAS TELECOMUNICACIONES. 2009. Estudios, Asesorías y Capacitación Altoya Ltda.

18. ECKEL B. “Thinking in Java, The Definitive Introduction to Object-Oriented

Programming in the Language of The World-Wide-Web”. 3rd Edition.

19. FICHA DE ANTECEDENTES DEL PROGRAMA INFORMACIÓN COMPLEMENTARIA. 2009. División Gerencia del Fondo de Desarrollo de las Telecomunicaciones, SUBTEL.

20. GONZALEZ S., O. 2006. Concepto y Arquitectura de las redes NGN. UIT / BDT

Seminario regional sobre Costes y Tarifas para los países miembros del Grupo TAL.

21. HIDALGO Z., R. 2004.Rediseño del Proceso y Diseño e Implementación de APLICACION E-Business para la Asignación de Técnicos. Proyecto de Grado para Optar al Grado de Magíster Mención Ingeniería de Negocios. Santiago, Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas.

22. IFS APPLICATIONS. Diseñado para la Industria de Telecomunicaciones. España.

< http://www.ifsworld.com/es/industries/telecommunications/details.asp >

http://www.ifsworld.com/es/industries/telecommunications/details.asp

181

23. IT KNOWLEDGE EXCHANGE

< http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1172072,00.html > 24. JBOSS SERVER MANAGER REFERENCE GUIDE. Version 2.0.0 GA. Copyright

© 2007 Red Hat. < www.jboss.org/docs >

25. LAWRENCE P., L. 2000. Critical Chain Project Management. Artech House, Inc.

26. LEY GENERAL DE TELECOMUNICACIONES, Nº 18.168, Título IV, modificado por la Ley 19.724, 2001.

27. LONGA F., A. 2007. Modelado UML y Generación de Código. Extracto de Memoria

de Título. Valparaíso, Universidad Técnica Federico Santa María.

28. MANUAL DEL USUARIO DE IGRAFX. 2006. Corel Corporation.

29. MANUAL DE USUARIO GANTTPROJECT 2.0.6 30. MARÍN A., J. I. 2000. Introducción al Lenguaje GAMS.

31. Material docente sobre gestión y control de proyectos. Programa de capacitación

BID/ILPES. SERIE Manuales. CEPAL.

32. MINUTA ENCUESTA ÁREAS RURALES. 2009. Departamento de Ingeniería, División Gerencia del Fondo de Desarrollo de las Telecomunicaciones, SUBTEL.

33. MUÑOZ T., A. O. 2007. Tipificación y Metodología para Proyectos de Instalación en

al Área de las Telecomunicaciones. Memoria para optar al Título de Ingeniero Civil Electricista. Santiago, Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas.

34. NAVARRO F., J. C. Apuntes del Curso IN77J “Orientación a Objetos para el e -

Business”. Santiago, Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas.

35. OTXOA G., A. 2003. Guía Wireless para Todos. Articulo [en línea] <http://www.cuantolibro.com/libro/22234/Guia-Wireless-Para-Todos.html>.

36. PARODI, C. 2001. El lenguaje de los proyectos, en Gerencia social. Diseño,

monitoreo y evaluación de proyectos sociales. Lima-Perú: Universidad del Pacífico.

37. PMI-PROJECT MANAGEMENT INSTITUTE. Newton Square, PA, USA, [en línea] <http://www.pmi.org>

38. POBLETE G., M. A. 2007. Rediseño de Procesos con Apoyo de TIC para Empresas

Pequeñas y Medianas de Servicios Profesionales. Proyecto de Grado para Optar al Grado de Magíster Mención Ingeniería de Negocios. Santiago, Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas.

http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1172072,00.html

http://www.jboss.org/docs

http://www.cuantolibro.com/libro/22234/Guia-Wireless-Para-Todos.html

http://www.pmi.org/

182

39. PROJECT MANAGEMENT INSTITUTE. 2001. Practice Standard for Work

Breakdown Structure.

40. PROJECT MANAGEMENT INSTITUTE. 2004. A Guide to Project Management Body of Knowledge 3th edition, PMBok Guide, USA, PMI Communications.

41. RAMIREZ C., Z.2005. Las Ontologías como Herramienta en la Gestión del

Conocimiento. La Habana, Universidad de la Habana, Departamento de Bibliotecología y Ciencia de la Información.

42. RECKER, J. 2008. BPMN Modelling – Who, Where, How and Why. BP Trends.

43. REGLAMENTO DEL FONDO DE DESARROLLO DE LAS

TELECOMUNICACIONES. 2001. Subsecretaría de Telecomunicaciones, Ministerio de Transportes y Telecomunicaciones. Decreto Nº 353.

44. SAP BUSINESS ONE. Soluciones Verticales. ProjectManagement – Gestión de

Proyectos. Sistec Tecnología y Sistemas. Bilbao. España. < http://sap.sistects.es/maripro.html >.

45. SCOTT R., J. H. 2007. Rediseño del Proceso de Evaluación Comercial a las Ventas y

Seguimiento de Contratos de Telefónica Chile. Proyecto de Grado para Optar al Grado de Magíster Mención Ingeniería de Negocios. Santiago, Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas.

46. SERRANO V., E. 2004. Eclipse Tutorial. 47. SOFTWARE ENGINEERING INSTITUTE. 2006. CMMI for Development,

Version 1.2, USA, Carnegie Mellon.

48. STRUTS FRAMEWORK INTRODUCTION.2006. <http://www.exadel.com/tutorial/struts/5.2/guess/strutsintro.html>.

49. STRUTS VISUAL TUTORIALS.2006.

<http://www.exadel.com/tutorial/struts/5.2/guess/strutstutorial.html>. 50. THE CHAOS REPORT. Éxito de los Proyectos. Chaos Studies, The Standish Group

International, Inc. 2009

51. TORRES P., K. 2004. Diseño de un Sistema de Administración de Proyectos del Instituto Nacional de Estadísticas. Memoria para optar al Título de Ingeniero Civil Industrial. Santiago, Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas.

52. TRENDS REPORT. 2008. The Trends in IT Value. The Standish Group

International, Inc.

http://sap.sistects.es/maripro.html

http://www.exadel.com/tutorial/struts/5.2/guess/strutsintro.html

http://www.exadel.com/tutorial/struts/5.2/guess/strutstutorial.html

183

Acrónimos

3G: The 3rd Generation A ATM: Asynchronous Transfer Mode B BPEL: Business Process Execution Language BPM: Business Process Management BPMN: Business Process Modelling Notation C CAPEX: Capital Expenditure CDMA: Code Division Multiple Access CDT : Consejo de Desarrollo de las Telecomunicaciones CMMI: Capability Maturity Model Integration CMMI-SE: Capability Maturity Model Integration for Systems Engineering CMMI-SW: Capability Maturity Model Integration for Software Engineering D DI: Departamento de Ingeniería E eTOM: enhanced Telecom Operations Map F FDT: Fondo de Desarrollo de las Telecomunicaciones FEA: Federal Enterprise Architecture FO: Fiber Optics FTP: File Transfer Protocol FTTx: Fiber to the (home, Curb, Building) G GAMS: General Algebraic Modelling System

184

Gb: Gigabit GFDT: Gerencia del Fondo de Desarrollo de las Telecomunicaciones GGSN: Gateway GPRS Support Node GHz: Gigahertz GPRS: General Packet Radio Service GPS: Global Positioning System GSM: Global System for Mobile communications H HFC: Hybrid Fibre Coaxial HTTP: Hyper Text Transfer Protocol I ICT: Infraestructura Común de Telecomunicaciones IDEF0: Integration Definition for Function Modelling 0 IEEE: Institute of Electrical and Electronics Engineers IMS: IP Multimedia Subsystem IP: Internet Protocol IPM: Integrated Project Management IPPD: Integrated Process and Products Development IPTV: Internet Protocol Television ISDN: Integrated Services Digital Network ISP: Internet Service Provider J JSP: Java Server Pages JPG: Joint Photographic Experts Group L LAN: Local Area Network LPD: Lean Project Delivery LPS: Last Planner System LTE: Long Term Evolution M MAN: Metropolitan Area Network Mbps: Megabits por segundo MMOO: Microondas MPLS: Multi Protocol Label Switching MSC: Mobile services Switching Centre MVC: Model-View-Controller N NGN: Next-Generation Network O OPEX: Operational Expenditure OSI: Open Systems Interconnection

185

P PERT: Program Evaluation and Review Technique PMBoK: Project Management Body of Knowledge PMC: Project Monitoring and Control PMI: Project Management Institute PP: Project Planning PPN: Patrones de Procesos de Negocios PSTN: Public Switched Telephone Network Q QAM: Quadrature Amplitude Modulation QoS: Quality of Service QPM: Quantitative Project Management QPSK: Quadrature Phase Shift Keying R RNC: Radio Network Controller RSKM: Risk Management RRHH: Recursos Humanos S SAM: Supplier Agreement Management SCOR: Supply-Chain Operations Reference SGSN: Serving GPRS Support Node T TI: Tecnologías de la Información TIC: Tecnologías de la Información y Comunicaciones ToIP: Telephone over IP U UGP: Unidad de Gestión de Proyectos UML: Unified Modelling Language UMTS: Universal Mobile Telecommunications System UTP: Unshielded Twisted Pair W WBS: Work Breakdown Structure WiFi: Wireless Fidelity WiMax: Worldwide Interoperability for Microwave Access WLAN: Wireless Local Area Network X xDSL: Digital Subscriber Line XML: Extensible Markup Language

186

Anexos

Anexo A: Procesos de Apoyo a Concursos

Siguiendo en la línea de la arquitectura de procesos diseñada, se mostrará a continuación la “Macro 4” también llamada “Procesos de Apoyo a Concursos” y que considera todos aquellos procesos y subprocesos encargados de la incorporación de nuevos recursos (humanos o materiales) a la organización, de forma que sean administrados tomando en consideración las necesidades e información de los otros macroprocesos: planificación; desarrollo de nuevos productos y/o servicios; y de preparación y ejecución de concursos. La arquitectura general fue ilustrada anteriormente en la figura 43.

Figura 112: Procesos de Apoyo a Concursos

187

Como se puede apreciar en la figura, se considera por un lado la información de

disponibilidad de recursos existente que proviene en particular de los procesos de la cadena de valor (Macro 1), y que para el caso de manejo de los proyectos de telecomunicaciones manejados por la GFDT se ve reflejado en la información de disponibilidad de los técnicos (ingenieros de eléctricos o de telecomunicaciones, ingenieros industriales o con conocimientos en manejo económico de proyectos, abogados para la construcción de las bases, geógrafos y otro tipo de personal calificado).

La información anterior gatilla la necesidad de contratación de nuevos recursos de

acuerdo a los requerimientos solicitados, y de la decisión de cual será el destino posterior de cada recursos.

Junto a lo anterior se utiliza también como medida de control de la adquisición de

nuevos recursos, la información de control de los planes estratégicos de la organización respecto a la realización de futuros proyectos y el como éstos serán abordados de acuerdo a los objetivos planteados.

Una vez definida la obtención de nuevos recursos, se procederá a definir los

subprocesos encargados del ingreso e incorporación de los recursos a las diferentes áreas de la organización, de la definición de las funciones que cumplirán cada uno de los recursos y de la mejora de los mismos dependiendo de las funciones que deberán cumplir, que en el caso de nuevos proyectos de acceso inalámbrico puede considerar la capacitación de técnicos en tecnologías como WiMax, 3G o LTE, entre otros.

En general los equipos de proyectos son definidos en base a los recursos disponibles en

la organización, y es aquí donde toma fuerza el proceso encargado de la transferencia de recursos de manera de reubicar a los diferentes recursos en las áreas y por ende a los proyectos a los que sean un mayor aporte, pero en el caso de la contratación de nuevos recursos, particularmente aquellos recursos sean ingresados de manera provisoria debido a que en la mayoría de los casos realizan tareas de asesoría o desarrollo de trabajos puntuales como es el caso de apoyo en proyectos particulares, el proceso de transferencia no tendrá la connotación de transferir al recurso dentro de la organización a diferentes áreas o proyectos, sino más bien cumple la función de devolver al recurso al mercado.

En la figura siguiente se muestra lo mencionado anteriormente, y que corresponde al subproceso denominado “Ingreso, manejo y transferencia recurso”:

189

Anexo B: Ejemplos de Proyectos de la DGDFT

Con el fin de mostrar tareas más particulares para los proyectos desarrollados por la GFDT, se mostrará a continuación la carta Gantt correspondientes a uno de los proyectos emblemáticos del FDT, perteneciente a las categorías de Acceso y Core (debido a la naturaleza del proyecto en el cual se construirán tanto infraestructura para el acceso a internet como los Backbone de F.O., es que deberán ser considerados ambos tipos de servicios) y particularmente con las características de proyectos grandes y de apertura, esto debido al gran tamaño del proyecto en cuestión:

El diagrama fue realizado utilizando Microsoft Project Professional 2007.

Figura 114: Gantt del Proyecto IDCI

A continuación se describen brevemente algunos de los proyectos desarrollados por la GFDT, entre los que se encuentra IDCI:

190

Proyecto Infraestructura Digital para la Competitividad y la Innovación 2008 Alcance del Proyecto

Dotar de infraestructura y servicios de telecomunicaciones a un conjunto de localidades a lo largo de todo el país que según los antecedentes preparados por las mesas TICs regionales, validados por los Intendentes; el Ministerio de Agricultura; Sercotec; y Sernatur, tienen vocación productiva y la llegada de esta clase de servicios permite incrementarla.

El proyecto se desarrolla por intermedio del Instrumento Fondo de Desarrollo de las

Telecomunicaciones, el cual es un subsidio a la oferta. Los ejes programáticos del Proyecto se relacionan con la equidad en el acceso y la

competitividad. Objetivos del Proyecto

Concurso nacional de adjudicación regional que permita dotar de servicio de telecomunicaciones a las localidades objeto del proyecto en condiciones de precio y calidad equivalentes al de la Capital Provincial respectiva. Modalidad del Concurso 1.- Servicio Intermedio: Extender la red de alta capacidad de telecomunicaciones del país para lo cual se subsidiará la construcción de 717 km de fibra con M$4.200 en los siguientes lugares:

REGIÓN NOMBRE FOCO KM

Aysén Lago General Carrera Turismo 120

Los Ríos La Unión Capital Provincial 45

Bío Bío Trapatrapa Desarrollo Indígena - Producto 150

Maule Cauquenes Capital Provincial 55

O`Higgins Pichilemu Capital Provincial - Turismo 128

Valparaíso Litoral Central Turismo - Productivo 36

Coquimbo Vicuña Turismo - Productivo 63

Atacama Alto del Carmen Productivo 45

Antofagasta Tocopilla Capital Provincial – Desarrollo Portuario 75

Tabla 13: Kilómetros de Tramos de Fibra Óptica por Región.

2.- Servicio Público de Transmisión de datos: Dotar de oferta de servicio de Internet a las localidades beneficiadas con una inversión, según la siguiente tabla:

191

Tabla 14: Nivel de Cobertura del Proyecto por Región.

Resultados Esperados 1.- Contar con servicios de telecomunicaciones a precio y calidad equivalente a los de las Capitales Provinciales para un 20% de chilenas y chilenos que hoy no cuentan con esta clase de servicios, aumentando la conectividad en Chile de un 71,4% de la población al 91,8%. 2.- Mejorar las condiciones de competitividad de las Pymes, el agro y el turismo en las localidades beneficiadas. Principales Hitos44

HITO FECHA OBSERVACIONES

Llamado a Concurso 15/09/2008 Supone la autorización del CDT.

Adjudicación del Concurso 19/12/2008 Supone la existencia de ofertas que cumplan con los requisitos de las Bases.

Inicio de Servicios 25/11/2009 Supone adjudicatario.

Pago Subsidios 11/12/2009 Supone adjudicatario y recepción de obras.

Tabla 15: Principales Hitos Proyecto IDCI

44 Suponen la suscripción de los Convenios de Programación con cada una de las Regiones.

Región Población Cubierta

Previo al Proyecto

Población a

Beneficiar

Población que contará

con Oferta de Servicio de

Telecomunicaciones

Población de la

Región

Cobertura de la

Ruralidad en la

Región *

Cobertura

Total de la

Región **Arica - Parinacota 175.441 9.470 184.911 189.644 66,7% 97,5%

Tarapacá 164.396 63.753 228.149 238.950 85,5% 95,5%

Antofagasta 454.332 27.819 482.151 493.984 70,2% 97,6%

Atacama 169.733 60.547 230.280 254.336 71,6% 90,5%

Coquimbo 362.658 178.575 541.233 603.210 74,2% 89,7%

Valparaíso 1.204.386 294.544 1.498.930 1.539.852 87,8% 97,3%

Metropolitana 5.595.643 274.997 5.870.640 6.061.185 59,1% 96,9%

O´Higgins 257.420 469.310 726.730 780.627 89,7% 93,1%

Maule 396.638 401.343 797.981 908.097 78,5% 87,9%

Bío-Bío 887.037 683.471 1.570.508 1.861.562 70,1% 84,4%

Araucanía 288.286 291.427 579.713 869.535 50,1% 66,7%

Los Ríos 127.750 157.819 285.569 356.396 69,0% 80,1%

Aysén 61.852 17.595 79.447 91.492 59,4% 86,8%

Total 10.145.572 2.930.670 13.076.242 14.248.870 71,4% 91,8%

* Entiéndase como Cobertura de Ruralidad, el porcentaje de habitantes que no contaban con servicios de telecomunicaciones y son cubiertos con el proyecto.

** Entiéndase como Cobertura Regional, el porcentaje de habitantes que contará con servicios de telecomunicaciones (de forma previa al proyecto e incluídos los cubiertos por el proyecto)

*** Entiéndase como Cobertura del Proyecto a Nivel Regional, el porcentaje de habitantes

192

Proyecto de Telefonía Móvil I Alcance del Proyecto

Conectar las localidades objeto del presente concurso a través de inversión privada subsidiada por el Fondo de Desarrollo de las Telecomunicaciones, ampliando la cobertura de las actuales redes de telefonía móvil, generando oferta de este servicio en condiciones similares a las que se presta en los otros lugares que cuentas con telefonía móvil, todo ello contribuyendo al permanente desarrollo e inversión de la industria de telecomunicaciones en la zona. Objetivos del Proyecto

Concurso de infraestructura de adjudicación por localidad que permita dotar de servicio público de telefonía móvil en condiciones de precio y calidad equivalentes al del resto del país. Modelar la mejor forma de extensión del servicio de telefonía en las zonas más aisladas del país. Modalidad del Concurso 1.- Servicio Público de Telefonía Móvil. Extender la cobertura del servicio de telefonía móvil en los siguientes lugares:

ID REGIÓN PROVINCIA COMUNA LOCALIDAD 1 ARICA PARINACOTA PARINACOTA PUTRE SOCOROMA

2 ARICA PARINACOTA PARINACOTA PUTRE CHAPIQUIÑA

3 TARAPACÁ TAMARUGAL COLCHANE COLCHANE

4 ATACAMA HUASCO ALTO DEL CARMEN EL TRANSITO (ALTO DEL CARMEN)

5 ATACAMA HUASCO ALTO DEL CARMEN SAN FELIX

6 ATACAMA HUASCO FREIRINA CARRIZALILLO

7 VALPARAÍSO SAN FELIPE DE ACONCAGUA PUTAENDO LOS PATOS

8 VALPARAÍSO SAN FELIPE DE ACONCAGUA PUTAENDO CASABLANCA

9 O'HIGGINS CARDENAL CARO LA ESTRELLA LAS CHACRAS

10 O'HIGGINS CARDENAL CARO PAREDONES EL CARDAL

11 MAULE CURICÓ RAUCO EL PARRON

12 MAULE TALCA PENCAHUE PAJONAL

13 MAULE TALCA EMPEDRADO COLMENARES

14 MAULE CAUQUENES CHANCO LOANCO

15 MAULE CAUQUENES CHANCO PAHUIL

16 MAULE CAUQUENES CHANCO CARRERAS CORTAS

17 MAULE CAUQUENES CAUQUENES CABRERIA

18 MAULE CAUQUENES PELLUHUE CHOVELLEN

19 MAULE CAUQUENES PELLUHUE CANELILLO

20 MAULE CAUQUENES CAUQUENES POCILLAS SUR

21 MAULE LINARES LONGAVÍ LOMA DE VASQUEZ

22 BIOBÍO ÑUBLE QUIRIHUE CULENCO

23 BIOBÍO ARAUCO CURANILAHUE COLICO NORTE

24 ARAUCANÍA MALLECO ANGOL MAITENREHUE

25 ARAUCANÍA MALLECO ANGOL VEGAS BLANCAS

26 LOS RÍOS VALDIVIA MARIQUINA MAIQUILLAHUE

27 LOS RÍOS VALDIVIA MARIQUINA CHANCHAN DE LA COSTA

28 LOS RÍOS VALDIVIA CORRAL CHAIHUIN

29 LOS RÍOS RANCO FUTRONO MAIHUE

30 LOS RÍOS RANCO RÍO BUENO MAIHUE

31 LOS LAGOS PALENA CHAITÉN CHUMELDEN

32 AISÉN COIHAIQUE COIHAIQUE LAGO ATRAVESADO

33 MAGALLANES TIERRA DEL FUEGO TIMAUKEL PAMPA GUANACO

34 TARAPACÁ TAMARUGAL HUARA TARAPACÁ

Tabla 16: Cobertura del Proyecto Telefonía Móvil

193

Resultados Esperados 1.- Ampliar la cobertura de telefonía móvil a sectores que hoy se encuentran desprovisto de telefonía. 2.- Probar la telefonía móvil como medio de extensión del servicio de telefonía a lugares carenciados, como sustituto de la telefonía tradicional. Principales Hitos

HITO FECHA

Llamado a concurso 16 de Junio de 2008

Recepción de propuestas 15 de Julio de 2008

Asignación 01 de Agosto 2008

Inicio de obras Octubre de 2008

Entrega de obras Diciembre de 2008 y Junio 2009

Inicio de servicio Diciembre de 2008 y Junio de 2009

Tabla 17: Hitos Principales del Proyecto Telefonía Móvil

Proyecto Localidades Intermedias Palena Alcance del Proyecto

Conectar las localidades objeto del concurso a través de inversión privada subsidiada por el Fondo de Desarrollo de las Telecomunicaciones, por medio de una red troncal de fibra óptica, que cumpla con estándares de calidad internacionalmente reconocidos, a objeto de que el servicio intermedio de telecomunicaciones se preste en forma transparente, no discriminatoria, asegurando la interconexión a las redes nacionales existentes, todo ello contribuyendo al permanente desarrollo e inversión de la industria de telecomunicaciones en la zona. Adicionalmente, el adjudicatario deberá ofrecer a todas las localidades objeto del proyecto servicio de Internet en condiciones de precio y calidad equivalente a los de la Capital Provincial. Objetivos del Proyecto

Concurso de extensión de la fibra óptica existente en la Provincia hacia las localidades intermedias, asegurando la provisión del servicio en condiciones de calidad y precio equivalentes al de la Capital Provincial.

194

Modalidad del Concurso 1.- Servicio Intermedio. Extender la red de alta capacidad de telecomunicaciones del país para lo cual se subsidiará su construcción hacia los siguientes lugares:

Tabla 18: Tramos de Fibra Óptica por Localidad.

2.- Servicio Público de Transmisión de datos. Dotar de oferta de servicio de Internet a las localidades, según la siguiente tabla:

Tabla 19: Cobertura del Proyecto por Localidad.

Resultados Esperados 1.- Contar con servicios de telecomunicaciones a precio y calidad equivalentes a los de las Capitales Provinciales para los habitantes de las localidades intermedias. 2.- Mejorar las condiciones de competitividad de las Pymes, el agro y el turismo en las localidades beneficiadas.

REGIÓN COMUNA LOCALIDAD CAPACIDAD

X FUTALEUFÚ EL AZUL 8xE1

X FUTALEUFÚ EL LÍMITE (Frontera) 8xE1

X HUALAIHUÉ EL MANZANO 16xE1

X HUALAIHUÉ PUERTO HUALAIHUÉ 16xE1

X HUALAIHUÉ PICHICOLO 16xE1

X PALENA FRONTERA PALENA 8xE1

X PALENA EL ACEITE 8xE1

X PALENA VALLE CALIFORNIA Comparte con Frontera con Palena

X FUTALEUFÚ EL ESPOLÓN 8xE1

COMUNA LOCALIDAD (*) CHAITÉN PUERTO CÁRDENAS

CHAITÉN VILLA SANTA LUCÍA

FUTALEUFÚ EL AZUL

FUTALEUFÚ EL LÍMITE (Frontera)

FUTALEUFÚ EL ESPOLÓN

HUALAIHUÉ EL MANZANO

HUALAIHUÉ PUERTO HUALAIHUÉ

HUALAIHUÉ PICHICOLO

HUALAIHUÉ CHAUCHIL

HUALAIHUÉ LLEGUIMÁN

HUALAIHUÉ ROLECHA

PALENA FRONTERA PALENA

PALENA EL MALITO

PALENA PUERTO RAMÍREZ

PALENA EL ACEITE

PALENA VALLE CALIFORNIA

195

Principales Hitos

HITO FECHA

Llamado a concurso 16 de Junio de 2008

Recepción de propuestas 31 de Julio de 2008

Asignación 13 de Agosto 2008

Inicio de obras 30 de Septiembre de 2009

Entrega de obras 30 de Noviembre de 2008 y 31 Septiembre de 2009

Inicio de servicio 19 de Diciembre de 2008 y 20 de Octubre de 2009

Tabla 20: Hitos Principales del Proyecto Localidades Intermedias Palena

196

Anexo C: Evolución de Proyectos Tipo de la DGFDT

A continuación se muestran los costos operativos para el diseño y desarrollo de 4 proyectos al interior de la DGFDT, desde la perspectiva de los procesos del departamento de ingeniería:

IDCI I El detalle y características principales de este proyecto se pueden ver en el Anexo B,

junto con esto los costos relacionados con los procesos de diseño y desarrollo de cada proyecto, hasta llegar a las evaluaciones privada y social (y finalmente el cálculo de subsidio) serán mostrados a continuación:


Ingeniero Económico 8 40 320 $1.222.222 $61.111 $7.639 $2.444.444

$2.444.444


mensualCosto

16 80 320 $495.000 36 $13.750 $27.500



0 0 320 $5.254 10 $52.544 $105.088

$132.588

$2.577.032

TOTAL H-H

TOTAL OPERATIVOS

TOTAL ESTUDIO DE DEMANDA POTENCIAL

Tabla 21: Costos del Proceso de Estudio de Demanda Potencial IDCI I

Este proyecto debió considerar el desarrollo de un estudio de demanda, y que fue realizado por la Universidad de Chile, teniendo como contraparte al equipo de analistas económicos del departamento de ingeniería. Como se ve en la tabla 21, se consideró un mes de trabajo para los 2 analistas económicos para entregar el producto final que consistía en un modelo de demanda así como los datos relevantes que serían posteriormente considerados para el proceso de estimación y cálculo de subsidio.



Geógrafo 8 40 320 $940.000 $47.000 $5.875 $1.880.000

$4.324.444


mensualCosto

16 80 640 $495.000 36 $13.750 $55.000



16 80 640 $5.254 10 $52.544 $210.175

$265.175

$4.589.619

TOTAL H-H

TOTAL OPERATIVOS


Tabla 22: Costos del Proceso Pre-evaluación de la Solución Técnica IDCI I

197

Los procesos siguientes implicaron un uso importante y exhaustivo de recursos, dada la

cantidad de localidades que conformaban la cartera de requerimientos de este proyecto. Se utilizó la totalidad de recursos disponibles, esto es, los 2 analistas económicos y los 2 geógrafos durante un mes para la validación de la cartera y la generación del universo de entidades, y los 5 ingenieros de diseño para el proceso de diseño de las redes que darán cobertura al gran número de localidades.


5 8 40 160 $1.222.222 $61.111 $7.639 $6.111.110


mensualCosto

5 8 40 160 $495.000 36 $13.750 $68.750



5 8 40 160 $5.254 10 $52.544 $262.719

$6.442.579TOTAL DISEÑO DE RED y CALCULO DE INVERSIONES

Tabla 23: Costos del Proceso Diseño Técnico y Cálculo de Inversiones IDCI I Finalmente para el último proceso, el de cálculo de subsidio, nuevamente participaron

los 2 analistas económicos esta vez durante un período de 2 semanas, recopilando toda la información generada en los procesos anteriores, obteniendo como resultado la cantidad de subsidio estimada necesaria para hacer rentable el proyecto.


2 8 40 80 $1.222.222 $61.111 $7.639 $1.222.222


mensualCosto

2 8 40 80 $495.000 36 $13.750 $13.750



2 8 40 80 $5.254 10 $52.544 $52.544

$1.288.516TOTAL CÁLCULO DE SUBSIDIO

Tabla 24: Costos del Proceso Cálculo de Subsidio IDCI I

IDCI II El detalle de los costos de este proyecto se puede ver en el Capítulo 3 en el punto 3.7

Evaluación Financiera.

MÓVILES II

Al igual como en el caso de IDCI I este proyecto debió considerar la realización de un estudio, pero que a diferencia del anterior estuvo enfocado a la obtención de un modelo de operación de telefonía móvil determinando los costos de operación y mantención involucrados. Todo este trabajo implicó 2 semanas de trabajo por parte de los 2 analistas económicos.

198



$1.222.222


mensualCosto

16 80 160 $495.000 36 $13.750 $13.750



0 0 160 $5.254 10 $52.544 $52.544

$66.294

$1.288.516

TOTAL H-H

TOTAL OPERATIVOS

TOTAL ESTUDIOS

Tabla 25: Costos del Proceso de Estudio de Demanda Potencial Móviles II

Luego, tanto los procesos de pre-evaluación como de diseño y cálculo de inversiones requirió de un número reducido de recursos debido a que la cantidad de localidades a cubrir era baja. Es así como se tiene el trabajo de 2 semanas de un analista económico y de una semana de un geógrafo. Posteriormente se tiene el diseño de redes durante 1 semana por parte de 2 ingenieros de diseño.



Geógrafo 8 40 40 $940.000 $47.000 $5.875 $235.000

$846.111


mensualCosto

16 80 120 $495.000 36 $13.750 $10.313



16 80 120 $5.254 10 $52.544 $39.408

$49.720

$895.831

TOTAL H-H

TOTAL OPERATIVOS


Tabla 26: Costos del Proceso Pre-evaluación de la Solución Técnica Móviles II


2 8 40 40 $1.222.222 $61.111 $7.639 $611.111


mensualCosto

2 8 40 40 $495.000 36 $13.750 $6.875



2 8 40 40 $5.254 10 $52.544 $26.272

$644.258TOTAL DISEÑO DE RED y CALCULO DE INVERSIONES

Tabla 27: Costos del Proceso Diseño Técnico y Cálculo de Inversiones Móviles II


2 8 40 40 $1.222.222 $61.111 $7.639 $611.111


mensualCosto

2 8 40 40 $495.000 36 $13.750 $6.875



2 8 40 40 $5.254 10 $52.544 $26.272

$644.258TOTAL CÁLCULO DE SUBSIDIO

Tabla 28: Costos del Proceso Cálculo de Subsidio Móviles II

199

RUTAS DE ANTOFAGASTA

Finalmente este proyecto aprovechó el conocimiento obtenido del proyecto Móviles II para acelerar el proceso de diseño y desarrollo simplificando las tareas requeridas y por ende los costos involucrados. Esto se refleja en que se requirió tanto un analista económico como a un geógrafo con dedicación de una semana para validar los requerimientos ingresados.



Geógrafo 8 40 40 $940.000 $47.000 $5.875 $235.000

$540.556


mensualCosto

16 80 80 $495.000 36 $13.750 $6.875



16 80 80 $5.254 10 $52.544 $26.272

$33.147

$573.702

TOTAL H-H

TOTAL OPERATIVOS


Tabla 29: Costos del Proceso Pre-evaluación de la Solución Técnica Rutas Antofagasta Los procesos siguientes de diseño de red, cálculo de inversiones y finalmente cálculo de

subsidio siguieron un camino también expedito en lo que respecta a utilización de recursos, canalizándose de mejor forma las necesidades de información los recursos.


2 8 40 40 $1.222.222 $61.111 $7.639 $611.111


mensualCosto

2 8 40 40 $495.000 36 $13.750 $6.875



2 8 40 40 $5.254 10 $52.544 $26.272

$644.258TOTAL DISEÑO DE RED y CALCULO DE INVERSIONES

Tabla 30: Costos del Proceso Diseño Técnico y Cálculo de Inversiones Rutas Antofagasta


2 8 40 40 $1.222.222 $61.111 $7.639 $611.111


mensualCosto

2 8 40 40 $495.000 36 $13.750 $6.875



2 8 40 40 $5.254 10 $52.544 $26.272

$644.258TOTAL CÁLCULO DE SUBSIDIO

Tabla 31: Costos del Proceso Cálculo de Subsidio Rutas Antofagasta

200

Anexo D: Manual de Usuario Portal DGFDT

A continuación se muestra parte del manual de usuario del Portal DGFDT utilizado por los integrantes de la División para saber cómo utilizar la plataforma implementada y parte de la funcionalidad que esta entrega:

Introducción

El presente manual tiene por objeto clarificar el uso de la Portal de la División Gerencia del Fondo de Desarrollo de las Telecomunicaciones, con el fin de permitir que sus usuarios obtengan el máximo provecho de la misma para el desarrollo de sus tareas al interior de la DGFDT.

¿Qué es el Portal DGFDT?

El Portal DGFDT es una plataforma para el manejo de todo tipo de información al interior de la División Gerencia del Fondo de Desarrollo de las Telecomunicaciones y que le permitirá almacenar y hacer seguimiento a los documentos al interior de la División.

El Portal DGFDT proporciona una interfaz fácil de usar que simplifica la administración y publicación de grandes volúmenes de documentos. Puede ser utilizado también por la organización como una plataforma de comunicación al interior de la División pudiendo ser utilizada como una intranet.

Elementos Principales del Portal DGFDT

A continuación se detallarán cada uno de los componentes principales del Portal. MENÚ PRINCIPAL En el menú principal se muestran 7 viñetas que permiten acceder a:

• Inicio Al hacer clic el usuario, vuelve a la pantalla de entrada

• Visión general de la DGFDT Al hacer clic el usuario, se despliega un listado de información oficial relevante asociada a la División Gerencia del Fondo de Desarrollo de las Telecomunicaciones.

• FAQ Al hacer clic el usuario, se despliega una lista de ítems relacionados con información del Portal.

• Enlaces Al hacer clic el usuario, se despliega una lista de 2 categorías Normativa Vigente y Empresas de Telecomunicaciones. En la primera se despliega un listado con toda la normativa vigente relacionada con el Fondo de Desarrollo de las Telecomunicaciones.

201

• Gestión Documental Al hacer clic el usuario, accede a una base de datos que le permite buscar información oficial respecto a la documentación generada en la DGFDT.

• Foro DGFDT Al hacer clic el usuario, el usuario accede a un foro en el cual se detallan distintos temas relacionados con la DGFDT y que son incorporados por el responsable de cada tema sobre el cual se desea trabajar. Tiene como utilidad principal el permitir registrar la discusión de temas relevantes y difundirlos ya sea a todos los involucrados o a todos aquellos interesados en el tema y que deseen entregar su aporte.

• Proyectos en Curso Al hacer clic el usuario, el usuario accede a una aplicación que permite realizar seguimiento a los distintos proyectos y sus respectivas tareas realizados al interior de la DGFDT. RECURSOS

En el menú de Recursos se detallan varios enlaces a páginas de interés en lo que respecta a información actualizada de Telecomunicaciones (Fayerwayer, Wayerless, Telesemana y Bnamericas), a información pública de la Subsecretaría de Telecomunicaciones (Gobierno Transparente y Concursos FDT), e información del programa utilizado en los Diseños Técnicos para el cálculo de propagación (Radio Mobile).

202

CONCEPTOS

En el menú Conceptos, se muestran algunos enlaces a información teórica relacionada con la tecnología utilizada en proyectos de la DGFDT e información de tecnologías Futuras. También se incluye un enlace a las principales definiciones que se utilizan al interior de la DGFDT y que forman parte de los 2 procedimientos desarrollados para la Certificación ISO 9001:2008.

NOTICIAS

En el menú de Noticias se detallan las noticias que han sido subidas por los usuarios de la plataforma debido a su contenido relevante en temas de telecomunicaciones, particularmente en lo que respecta al trabajo desarrollado por la DGFDT. ACCESO y MENU DE USUARIO

En el menú de Acceso los usuarios de la plataforma deberán ingresar su nombre de usuario y contraseña que los acredite como tales, y de esa forma puedan acceder a todos los contenidos dispuestos en la plataforma. Sn perjuicio de lo anterior, existe por supuesto contenido sensible y que es accesible sólo por aquellos usuarios responsables o involucrados de alguna manera con dicho contenido.

203

Una vez que el usuario ha ingresado sus datos, aparece en la misma ubicación el Menú

de Usuario, y en el cual permite que cada usuario edite su perfil (nombre, email, contraseña, etc.), y permite enviar noticias y enlaces de manera que el administrador encargado de la plataforma. PÁGINA PRINCIPAL

En la página principal se detallan las noticias (u artículos) más destacadas que han sido subidas por los usuarios de la plataforma debido a su contenido relevante en temas de telecomunicaciones particularmente en lo que respecta al trabajo desarrollado por la DGFDT.

GESTIÓN DOCUMENTAL

Corresponde a una aplicación que permite crear fácilmente un repositorio de descargas donde los usuarios de pueden subir y descargar documentos de toda índole.

El acceso a Gestión Documental se describe a continuación:

ESTRUCTURA PRINCIPAL (Downloads Home)

Como se aprecia en la figura 114, se estableció una estructura de carpetas para almacenar los documentos, de manera tal que siguen la siguiente estructura:

Figura 115: Gestión Documental (Downloads Home)

Gestión Documental

Menú Princ

ipal

Home Portal

204

El detalle del contenido de las carpetas se describe a continuación, dando una breve

explicación de lo que actualmente posee cada carpeta o de lo que debiera contener: • Gestión: Todos aquellos documentos manejados por la coordinadora de gestión de la DGFDT, y que son de conocimiento público. • Gestión de Documentos: • Procesos y Certificación ISO 9001:2008: Todos aquellos documentos relacionados con el proceso de Certificación ISO 9001:2008 y que no se encuentren dentro de la documentación oficial de SADOC. • Departamento de Ingeniería: Todos aquellos documentos establecidos como productos intermedios en el sistema de gestión de la DGFDT, así como todos los productos relacionados con los proyectos desarrollados por el Departamento de Ingeniería. De manera adicional se incorpora documentación de apoyo al trabajo realizado (biblioteca, contactos) en la que se almacenará información teórica y práctica de telecomunicaciones, así como los contactos con las empresas en el mercado de las telecomunicaciones particularmente en lo referido a los vendors45. También se contará con información de las cotizaciones de equipamiento, infraestructura, entre otros. Otra información relevante está dada por el Maestro de localidades que contiene toda la información recopilada a lo largo del desarrollo de los diferentes concursos. • Unidad de Gestión de Proyectos: Todos aquellos documentos establecidos como productos intermedios en el sistema de gestión de la DGFDT desarrollados por la Unidad de Gestión de Proyectos y aquellos en que la Unidad es responsable y constituye un registro relevante para el concurso en cuestión. ESTRUCTURA SECUNDARIA

Llegando al detalle del contenido de cada carpeta es posible ver algo similar a lo que se muestra en la figura 115, donde para cada documento es posible realizar una serie de acciones (estas varían dependiendo de las características del usuario, ya que por ejemplo sólo los administradores y usuarios con permiso pueden borrar o publicar un documento).

45

Empresas del rubro de telecomunicaciones enfocadas a la manufactura, distribución y venta de

equipamiento, así como al diseño, desarrollo e implementación de proyectos de telecomunicaciones.

205

Figura 116: Gestión Documental46 Los botones principales a utilizar con cada documento son los siguientes: • Download: Permite realizar la descarga del archivo o documento. • View: Permite previsualizar el documento siempre y cuando el formato sea compatible (Principalmente documentos en formato Word y Pdf). • Details: Permite ver el detalle o metadato del documento o archivo en cuestión. Entre la información entregada se cuenta el nombre del documento o archivo, una breve descripción realizada por el usuario que subió el archivo, el peso en Bytes, el tipo de archivo, el nombre del usuario que subió el archivo , entre otros.

BÚSQUEDA DE DOCUMENTOS (Search Document)

La búsqueda de documentos pretende simplificar la tarea de buscar documentos al

interior de la estructura de carpetas definida. De esta forma es posible buscar documentos aplicando diferentes criterios, puede ser utilizando únicamente el nombre del documento, o seleccionando la categoría en la que se sabe que se ubica dicho documento. También es posible ordenar los resultados de la búsqueda por antigüedad, el que más revisiones ha tenido (Most Popular), por orden alfabético o por categoría. Por último es posible definir si la búsqueda es por el título del documento, por la descripción dejada para el mismo o ambas.

46 Navegación Carpeta Procesos y Certificación ISO 9001:2008.

206

Figura 117: Búsqueda de Documentos

CARGAR DOCUMENTOS A LA BASE DE DATOS (Submit File)

Aquellos que tengan los permisos necesarios podrán cargar documentos a la base de datos del sistema y publicarlos (para que los documentos que se han subido al sistema sean visibles por todos los usuarios es necesario darles el estatus de publicados).

Como se aprecia en la figura 117, se carga un archivo desde el computador de

escritorio, para luego seleccionar desde que ubicación se subirá dicho archivo (figura 118).

Figura 118: Cargar Documentos Paso 1

Paso 1

207


Finalmente se define las características de la carga del documento, entre otros: el

nombre, la categoría a la que pertenecerá (esto es a que carpeta dentro del sistema de carpetas definido como se apreciaba en la figura 114), la fecha a la que se subió el archivo (en principio corresponde a la fecha actual, pero puede ser modificada en caso de ser necesario), entre otros.

Adicionalmente se pueden dar permisos particulares para que sólo algunos usuarios

puedan visualizar o mantener el documento a cargar, y se le puede incorporar alguna descripción que permita facilitar la búsqueda del documento y alguna imagen.


Paso 2

Paso 3

208

Como se aprecia en la parte inferior de la figura 119 es posible incorporar el estatus de

documento aprobado o no dependiendo de si requiere una visación previa o no.

FORO DGFDT

Corresponde a una aplicación que permite crear foros de discusión donde los usuarios de pueden publicar diversos temas y comentarlos en un entorno ordenado y que permite hacer un fácil seguimiento a las conversaciones generadas.

El acceso al Foro DGFDT se describe a continuación:

Figura 121: Foro DGFDT

Foro DGFDT Menú Principal

Home Portal

209

Anexo E: Áreas de Conocimiento del PMI

A continuación se muestra un pequeño resumen de cada uno de ellos:

Gestión del Tiempo

Para efectos de gestionar los tiempos de desarrollo de tareas y actividades en un proyecto, es que se requiere del uso de herramientas como las tan conocidas cartas Gantt, esto permite establecer fechas meta de inicio y terminación para los elementos identificados en la administración de alcance. Estas fechas están basadas en el esfuerzo requerido para completar las tareas, las relaciones entre ellas y la disponibilidad de los recursos para ejecutarlas. Junto con esto, el calendario es utilizado para comunicar a los miembros del equipo y al cliente cuando se realizarán las tareas y cuando estarán disponibles los entregables.47

Esta área consta en particular de las siguientes etapas:

Definición de Tareas

Establecimiento de la Secuencia de Tareas

Estimación de Recursos de las Tareas

Gestión de los Costos y Recursos

Es claro que gran parte de los problemas que tienen los proyectos es que terminan sobrepasando el presupuesto definido inicialmente, traduciéndose en una pérdida monetaria para la empresa desarrolladora del proyecto.

Es por esto que es de gran importancia el correcto control de los costos asociados así como de los recursos disponibles para el proyecto dejando siempre espacio a la posibilidad de tener que incorpora más recursos, y teniendo claro cual será el destino del nuevo recurso.

Esta área incluye los procesos involucrados en la planificación, estimación, preparación del presupuesto y control de costes de forma que el proyecto se pueda completar dentro del presupuesto aprobado.

Junto con esto se requiere de un manejo de recursos adecuado a los requerimientos del proyecto y que maximice el uso de recursos de forma que cada tarea sea realizada por un número de estos acorde a su complejidad, de forma de disminuir tiempos y costos.

47 Es aquí donde la herramienta a desarrollar debe manejar muy bien la utilización de este tipo de elementos, como por ejemplo lo hace la herramienta GanttProject.

210

Se incluyen aquí los procesos que organizan y dirigen el equipo de trabajo, que está

compuesto por las personas a quienes se les han asignado roles y responsabilidades para llevar a cabo el proyecto. La participación temprana de los miembros del equipo aporta experiencia durante el proceso de planificación y fortalece el compromiso con el proyecto.


Estimación de Costos

Preparación del Presupuesto de Costos

Planificación de Recursos

Gestión de la Calidad

Los procesos relacionados con esta área involucran a todas aquellas actividades de la empresa que lleva a cabo el proyecto que determinan las políticas, los objetivos y las responsabilidades relativos al modo en el cual se satisfacen las necesidades por las que se emprendió el proyecto inicialmente.48


Planificación de Calidad

Aseguramiento de Calidad

Control de Calidad

Gestión de las Comunicaciones

Esta área incluye los procesos necesarios para asegurar la generación, recolección, distribución, almacenamiento, recuperación y destino final de la información del proyecto en tiempo y forma. Estos procesos proporcionan los enlaces cruciales entre las personas y la información, necesarios para unas comunicaciones exitosas. Los responsables de proyectos pueden invertir una cantidad excesiva de tiempo comunicándose con el equipo del proyecto, los interesados, el cliente y el patrocinador.

Todos los actores involucrados en el proyecto deben comprender cómo afectan las comunicaciones al proyecto como un todo.

En particular los procesos de gestión de las comunicaciones del proyecto incluyen lo

siguiente:

La planificación de las comunicaciones, determinando las necesidades de información y comunicaciones de los interesados en el proyecto.

48 Respecto a la aplicación de esta área de gestión en la herramienta es en principio difusa, ya que estará sujeta al desarrollo de otros procesos y a la generación de indicadores que permitan determinar cuando las normas de calidad para un proyecto son seguidas o no.

211

La distribución de la información, colocando la información necesaria a disposición de los interesados en el proyecto cuando corresponda.

El informar el rendimiento, recopilando y distribuyendo la información sobre el rendimiento. Esto incluye informes de estado, medición del progreso y proyecciones.

El gestionar a los interesados, gestionando las comunicaciones a fin de satisfacer los requisitos de los interesados en el proyecto y resolver polémicas con ellos.

Gestión de los Riesgos

Toma a todos aquellos procesos encargados de identificar, analizar y responder ante la incertidumbre. Implica maximizar los resultados de eventos favorables o positivos y minimizar las consecuencias de eventos adversos. Aquí se aplican la identificación de los riesgos, cuantificación de los riesgos, desarrollo de respuestas y el control del riesgo. Existen riesgos internos (propios del proyecto) y externos (asociados a la economía nacional e internacional, aspectos gubernamentales, etc.), los cuales debido a la incertidumbre, conllevan una difícil tarea para que se mitiguen.

Los procesos de gestión de los riesgos del proyecto incluyen lo siguiente:

Planificación de la Gestión de Riesgos

Identificación de Riesgos

Análisis Cualitativo de Riesgos

Análisis Cuantitativo de Riesgos

Planificación de la Respuesta a los Riesgos

Seguimiento y Control de Riesgos.

Gestión de las Adquisiciones

En esta área se apoya la adquisición de bienes y servicios desde fuera de la organización que realiza el proyecto. Se compone de la planificación de la adquisición, planificación de las solicitudes, selección de la fuente (vendedores), administración del contrato y cierre del contrato.

Se espera definir las especificaciones técnicas de los materiales, recursos técnicos e insumos que se necesitarán para cumplir con los objetivos propuestos. Luego se estimará la demanda y las proyecciones de crecimiento del proyecto, para cuantificar los recursos, materiales e insumos a ser comprados para el despliegue del proyecto.

212

Gestión del Alcance

La consecución de logros dentro de un proyecto está relacionada con una correcta estructuración y subdivisión del trabajo en tareas manejables, de esta forma se selecciona el enfoque más adecuado y se estiman los costos y la fecha de terminación, evaluando el impacto de cambios potenciales del alcance en el calendario, presupuesto, requerimientos y satisfacción del cliente.

Incluye los procesos necesarios para asegurarse que el proyecto incluya todo el trabajo requerido, y sólo el trabajo requerido, para completar el proyecto satisfactoriamente.

La gestión del alcance de un proyecto se relaciona principalmente con la definición y el control de lo que está y no está incluido en el proyecto.


Planificación del Alcance

Definición del Alcance

Creación de Diagrama de Descomposición Funcional (WBS)49

Verificación del Alcance

Control del Alcance

Gestión de la Integración

Considera principalmente los procesos y actividades necesarios para poder identificar, definir, combinar, unificar y coordinar los procesos y actividades de dirección de proyectos y que pertenecen al grupo de procesos de la dirección de proyectos.

En particular y en el contexto de la dirección de proyectos esta área incluye características fundamentales para concluir un proyecto y a la vez cumplir los requerimientos de los clientes y de otros interesados de manera satisfactoria, y gestionar las expectativas. Algunas de estas características son: unificación, consolidación, articulación, entre otros.

Ahora bien, desde el contexto de la dirección de un proyecto considera la toma de decisiones sobre donde concentrar recursos y esfuerzos a diario, anticipando probables focos de conflicto de manera que se puedan tratar antes de que lleguen a mayores y coordinando el trabajo para el bien del proyecto.

Es posible comprender mejor la naturaleza integradora de los proyectos y de la dirección de proyectos observando las actividades que se deben llevar a cabo, y entre las que se pueden ver son:

Análisis y comprensión del alcance.

49 Work Breakdown Structure

213

Documentar los criterios específicos de los requisitos del producto.

Comprender cómo tomar la información identificada y transformarla en un plan de gestión del proyecto usando el grupo de procesos de planificación.

Preparar la estructura de desglose del trabajo.

Adoptar las acciones apropiadas para que el proyecto se lleve a cabo de acuerdo con el plan de gestión del proyecto, el conjunto planificado de procesos integrados y el alcance planificado.

Medir y supervisar el estado, los procesos y los productos del proyecto.

214

Anexo F: Gestión de Proyectos en el Estándar CMMI

Áreas de Proceso para el Manejo Básico de Proyectos A continuación se detallarán los procesos más relevantes para los efectos de la solución

diseñada, como son la planificación de proyectos (PP) y el monitoreo y control de proyectos (PMC):

Planificación de Proyectos (PP)

El propósito de la planificación de proyectos es establecer y mantener los planes que

definen las actividades de un proyecto.

Meta Específica 1: Establecer Estimaciones

Se establecen estimaciones de los parámetros de la planificación de un proyecto y son mantenidos.

Subproceso 1.1: Estimación de la duración del Proyecto

Establecer el nivel máximo de descomposición de la estructura de trabajo (WBS) para estimar la duración de un proyecto.

Subproceso 1.2: Establecer una estimación del producto de trabajo y de los atributos de las tareas

Establece y mantiene estimaciones de los atributos del producto de trabajo y de las

tareas.

Subproceso 1.3: Define el Ciclo de Vida Proyecto

Define las fases del ciclo de vida de un proyecto sobre las cuales determinar el esfuerzo de planificación.

Subproceso 1.4: Determinar Estimaciones de Esfuerzo y Costo

Estimar el esfuerzo y el costo de un proyecto para los productos de trabajo y tareas basados en estimaciones razonables.

215

Meta Específica 2: Desarrollo de un Plan para el Proyecto

Se establece y mantiene un plan para un proyecto como base para el manejo del proyecto.

Subproceso 2.1: Establecer el Presupuesto y Calendario

Establecer y mantener el presupuesto y el calendario de un proyecto

Subproceso 2.2: Identificar los Riesgos

Identificar y analizar los riesgos de un proyecto.

Subproceso 2.3: Plan para el Manejo de Datos

Plan para el manejo de los datos de un proyecto

Subproceso 2.4: Plan para los Recursos del Proyecto

Plan para determinar los recursos necesarios para llevar a cabo un proyecto.

Subproceso 2.5: Plan para Habilidades y Conocimiento Requeridos

Plan para determinar el conocimiento y las habilidades necesarias de los recursos para desarrollar un proyecto.

Meta Específica 3: Obtención de Compromisos al Plan

Se establecen y mantienen los compromisos con el plan de un proyecto.

Subproceso 3.1: Revisar los Planes Involucrados con el Proyecto

Revisar todos los planes que afecten al proyecto, para comprender los compromisos del proyecto.

Subproceso 3.2: Reconciliar el Trabajo y los Niveles de Recurso

Reconciliar el plan de un proyecto para reflejar los recursos estimados y disponibles.

Monitoreo y Control de Proyectos (PMC)

El propósito del monitoreo y control de proyectos es entregar la comprensión de los avances de un proyecto de manera que acciones correctivas apropiadas puedan ser tomadas cuando el funcionamiento del proyecto se desvía significativamente del plan.

216

Meta Específica 1: Monitorear el Proyecto Comparándolo al Plan

El funcionamiento actual y avance de un proyecto es monitoreado comparándolo con el plan original.

Subproceso 1.1: Parámetros de Monitoreo de la Planificación del Proyecto

Monitorear los valores actuales de los parámetros de la planificación de un proyecto comparándolos con los del plan.

Subproceso 1.2: Monitoreo de Compromisos

Monitorear los compromisos comparándolos con aquellos identificados en el plan del proyecto.

Subproceso 1.3: Monitoreo los Riesgos del Proyecto

Monitorear los riesgos comparándolos con aquellos identificados en el plan del proyecto.

Subproceso 1.4: Monitoreo del Manejo de los Datos

Monitorear el manejo de los datos del proyecto comparándolos con aquellos identificados en el plan del proyecto.

Subproceso 1.5: Revisión del Avance

Periódicamente revisar los avances del proyecto, funcionamiento e incidencias.

Subproceso 1.6: Revisión de Indicadores

Revisión de los logros y resultados del proyecto para un indicador determinado.

Meta Específica 2: Manejar Acciones Correctivas al Cierre

Acciones correctivas son manejadas al cierre cuando el funcionamiento o los resultados de un proyecto se desvían significativamente del plan.

Subproceso 2.1: Análisis de Problemas

Recolectar y analizar los problemas y determinar las acciones correctivas para solucionarlos.

Subproceso 2.2: Toma de Acciones Correctivas

Tomar acciones correctivas e identificar problemas.

217

Subproceso 2.3: Manejo de Acciones Correctivas

Manejar acciones correctivas al cierre de un proyecto.

Áreas de Proceso para el Manejo Avanzado de Proyectos

A continuación se detallarán los procesos más relevantes para los efectos de la solución diseñada:

Gestión Cuantitativa de Proyectos (QPM)

El propósito del manejo cuantitativo de proyectos es manejar cuantitativamente los procesos definidos en los proyectos con el fin de lograr la calidad establecida para cada proyecto y los objetivos de funcionamiento de los procesos.

Meta Específica 1: Gestión Cuantitativa del Proyecto

El proyecto es manejado cuantitativamente utilizando los objetivos de calidad y funcionamiento de los procesos.

Subproceso 1.1: Establecer los Objetivos del Proyecto Establecer y mantener los objetivos de calidad y funcionamiento de los procesos.

Subproceso 1.2: Componer el Proceso Definido Seleccionar los subprocesos que componen el proceso definido para el proyecto, basado en los datos históricos de estabilidad y capacidad.

Subproceso 1.3: Seleccionar los Subprocesos que serán Manejados Estadísticamente

Seleccionar los subprocesos del proceso definido para el proyecto que serán manejados estadísticamente.

Subproceso 1.4: Manejo del Funcionamiento del Proyecto

Monitorear el proyecto para determinar si los objetivos de calidad y funcionamiento de los procesos del proyecto serán satisfactorios, e identificar las acciones correctivas adecuadas.

218

Meta Específica 2: Gestión Estadística del Funcionamiento de los Subprocesos

El funcionamiento de los subprocesos seleccionados dentro del proceso definido para el proyecto es manejado estadísticamente.

Subproceso 2.1: Seleccionar Medidas y Técnicas Analíticas

Seleccionar las medidas y técnicas analíticas que serán utilizadas en el manejo estadístico de los subprocesos seleccionados.

Subproceso 2.2: Aplicar Métodos Estadísticos para Entender Variaciones

Establecer y mantener la comprensión de las variaciones de los subprocesos seleccionados utilizando las medidas seleccionadas y técnicas analíticas.

Subproceso 2.3: Monitorear el Funcionamiento de los Subprocesos Seleccionados

Monitorear el funcionamiento de los subprocesos seleccionados para determinar su

capacidad de satisfacer los objetivos de calidad y funcionamiento de los procesos, e identificar las acciones correctivas necesarias.

Subproceso 2.4: Almacenamiento de Datos Estadísticos

Almacenamiento de datos para el manejo estadístico y de calidad en el repositorio de mediciones de la organización.

Gestión Integral de Proyectos (IPM)

El propósito de la gestión integral de proyectos es establecer y manejar el proyecto y el poder involucrar a los grupos con intereses en la organización relevantes, de acuerdo a un proceso definido e integral que es supervisado desde un conjunto de procesos estándar de la organización.

Meta Específica 1: Utilizar los Procesos Definidos para el Proyecto

El proyecto es conducido utilizando un proceso definido que es supervisado desde un

conjunto de procesos estándar de la organización.

Subproceso 1.1: Establecer los Procesos Definidos del Proyecto Establecer y mantener los procesos definidos del proyecto desde el inicio del proyecto y a través de todo el ciclo de vida del proyecto.

219

Subproceso 1.2: Utilizar los Procesos Activos Organizacionales para Planificar las Actividades del Proyecto

Utilizar los procesos activos organizacionales y un repositorio de medidas para estimar y planificar las actividades del proyecto.

Subproceso 1.3: Establecer el Ambiente de Trabajo del Proyecto

Establecer y mantener el ambiente de trabajo del proyecto basado en los estándares definidos por la organización.

Subproceso 1.4: Internalizar los Planes

Incorporar los planes del proyecto y los otros planes que afecten al proyecto de manera de poder describir los procesos definidos para el proyecto.

Subproceso 1.5: Gestionar el Proyecto Utilizando los Planes Internalizados

Gestionar el proyecto utilizando el plan del proyecto, los otros planes que afectan al proyecto y los procesos definidos para el proyecto.

Subproceso 1.6: Contribuir a los Procesos Activos de la Organización

Contribuir con herramientas de productos, mediciones y experiencias documentadas a los procesos activos de la organización.

Aparece luego el concepto de IPPD50, que sumado al anterior, Gestión Integral de

Proyectos + IPPD incluye el establecimiento de una visión común para el proyecto y del establecimiento de equipos integrales que llevarán a cabo los objetivos del proyecto.

Meta Específica 2: Aplicar los Principios IPPD

El proyecto es gestionado utilizando los principios de IPPD.

Subproceso 2.1: Establecer la Visión Compartida del Proyecto

Establecer y mantener una visión compartida para el proyecto.

Subproceso 2.2: Establecer la Estructura del Equipo Integrado

Establecer y mantener la estructura del equipo integrado del proyecto.

50 Desarrollo de Productos y Procesos Integrados

220

Subproceso 2.3: Asignar Requerimientos a los Equipos Integrados

Asignar requerimientos, responsabilidades, tareas e interfaces a los equipos en la estructura de equipos integrados.

Subproceso 2.4: Establecer Equipos Integrados Establecer y mantener equipos integrados en la estructura.

Subproceso 2.5: Asegurar la Colaboración entre los Equipos Asegurar la colaboración entre los equipos que deben relacionarse entre sí.

221

Anexo G: Estándar BPMN

La notación de modelamiento de procesos de negocio (BPMN) es un estándar de importancia cada vez mayor para el modelado de procesos y que ha tenido altos niveles de atención y de respuesta en la práctica de BPM.

BPMN fue desarrollado por un consorcio que comprende a representantes de la mayoría de los actores en el mercado mundial del BPM.

A continuación se describe un estudio en el que casi 600 modeladores con BPMN respondieron y entregaron ideas en el quién, donde, cómo y porqué del modelamiento de procesos en BPMN como también los problemas que experimentaron los usuarios cuando modelaron con BPMN. [42]

BPMN es de hecho un lenguaje rico que permite definir una gran cantidad de

escenarios de negocio, midiendo desde coreografías de procesos internos a orquestaciones de procesos inter-organizacionales, interacción de servicios y excepciones en los flujos de trabajo (workflows).

Sin embargo todavía existe un desconocimiento respecto cómo BPMN es utilizado por

los usuarios: arquitectos de procesos, gerentes de sistemas, analistas de negocio y consultores.

Algunos problemas de los usuarios con BPMN que dan espacio para futuras mejoras Los usuarios que utilizan BPMN lo consideran muy útil porque se desempeña muy

bien en los proyectos de modelamiento de procesos, así como la simplicidad en realizar diagramas de los modelos, donde por un lado lo convierte en un lenguaje bastante completo pero por la misma razón no es uno de los lenguajes más fáciles con los que se puede trabajar.

A continuación se mencionan algunas de las falencias principales de este tipo de

modelamiento, información que fue recogida en el estudio realizado a los usuarios de BPMN:

Apoyo a la Especificación de Reglas de Negocios El estudio destacó un déficit de BPMN en el apoyo de la articulación de las reglas de negocio, como se ve en la figura. Modelamiento de procesos y lenguajes para el modelamiento de reglas son utilizados en las organizaciones para documentar políticas y procedimientos. Sin embargo, se ha hecho poco esfuerzo para comprender sus sinergias y superposiciones. La especificación de reglas es de hecho una tarea esencial para comprender los procesos de negocios, y sería muy bueno ver que las soluciones de modelamiento de procesos reconozcan esto un poco más y entreguen un mejor soporte para estas tareas.

222

Figura 122: Modelamiento de Procesos y reglas de Negocio

Apoyo a la Descomposición de Procesos

Una situación similar fue encontrada en cuanto a la articulación de una estructura de procesos y descomposición. Modeladores de procesos comúnmente requieren definir de manera precisa el alcance y los límites de los procesos que modelan, pero fallan en hacerlo adecuadamente con aproximaciones de modelamiento de procesos existentes. BPMN carece de conceptos avanzados para apoyar esta tarea, al menos desde la perspectiva del usuario.

Apoyo al Modelamiento Organizacional Los diagramas de pistas representan comúnmente una carga para los usuarios de BPMN. Claramente, han sido previstos por los diseñadores de BPMN para ser flexibles en la interpretación y el uso. Sin embargo, la ambigüedad que viene con su semántica flexible es contradictoria a la facilidad con la cual los diagramas de pistas pueden ser usados para el modelado de BPMN.

De acuerdo al estudio el esfuerzo extra requerido para especificar el significado de los diagramas de pistas disminuye la facilidad con la cual construimos el modelo de BPMN.

Entradas, Conectores Apagado de página y Grupos

Es aquí donde surge la pregunta: ¿Son efectivamente todos los símbolos de BPMN utilizados?

BPMN tiene un número de símbolos que son considerados simplemente superfluos e innecesarios, como se puede ver en la figura siguiente:

223

Figura 123: Uso de símbolos de BPMN seleccionados

Los símbolos de apagado de página, grupo y de instancias múltiples fueron clasificados por más del 50% como “no utilizados”, “no comprendidos” o “no enterado”. En contraste, algunos de los otros símbolos fueron catalogados como esenciales para el modelamiento de procesos, como por ejemplo los flujos tradicionales, links o anotaciones de texto.

Eventos

La última área de este estudio está relacionada con la gran abundancia de los diferentes símbolos de evento en BPMN. La diferencia entre los eventos de negocio en diferentes tiempos y tipos de dimensiones crea una larga lista de diferentes símbolos que puedan encontrar su camino en un modelo de procesos.

224

Anexo H: Plataforma J2EE

J2EE son las siglas de Java 2 Enterprise Edition que es la edición empresarial del paquete Java creada y distribuido por Sun Microsystems. Comprenden un conjunto de especificaciones y funcionalidades orientadas al desarrollo de aplicaciones Empresariales.

Debido a que J2EE no deja de ser un estándar, existen otros productos desarrollados a

partir de ella aunque no exclusivamente.

La idea es definir una plataforma robusta y flexible orientada a cubrir las necesidades empresariales en e-business y business-to-business, dado que las empresas necesitan constantemente expandirse, reducir costos, y bajar los tiempos de respuesta para proporcionar un fácil y mejor acceso a sus clientes, empleados y proveedores.

Para lograr esto las empresas necesitan sistemas de información que cumplan con las siguientes características:

Alta disponibilidad: para percibir las necesidades de hoy, en un ambiente global de negocios.

Seguridad: para proteger la privacidad de los usuarios y la integridad de la información de la empresa.

Confiable y escalable: para asegurar que las transacciones del negocio sean procesadas prontamente y con precisión.

La plataforma Java2 Edición Empresarial (J2EE) reduce el costo y complejidad de

desarrollo de estos servicios en ambientes multi-capa (multi-tier) y Web, y da por resultado servicios que pueden ser creados rápidamente y fácilmente mejorados respondiendo a las presiones competitivas de la empresa. Además, al utilizar Java, se puede ejecutar en cualquier plataforma sin tener que reescribir el código.

Básicamente J2EE consiste en lo siguiente:

Guías de diseño para desarrollo de aplicaciones empresariales utilizando J2EE.

Una implementación de referencia para dar una vista operacional de J2EE.

Un conjunto de pruebas de compatibilidad para el uso de 3ras partes para asegurar que

sus productos cumplen con los estándares J2EE.

Varias APIs (Application Programming Interfaces) para permitir acceso genérico a los

recursos y la infraestructura.

Tecnologías para simplificar el desarrollo empresarial con Java.

225

Desarrollo J2EE con Frameworks

Primero hay que explicar que un Framework es un conjunto de servicios y componentes reutilizables organizados en una estructura extensible, que busca simplificar el desarrollo de aplicaciones.

En general permiten reducir el tiempo de desarrollo de los proyectos, reducir el tiempo de entrenamiento de los desarrolladores, reducir la curva de aprendizaje y evitar algunos problemas técnicos que ya han sido resueltos anteriormente.

Considerando todas las ventajas de J2EE todavía hay algunas áreas, como las interfaces de usuario, que están muy desarrolladas y es en este tipo de áreas donde los Frameworks son muy útiles para los desarrolladores.

Los Frameworks generalmente se especializan en alguna capa o en alguna función específica, hay Frameworks para la capa Web que administra la Interfaz de Usuario, otros que se especializan en la capa de negocio para trabajar con los EJB y otros que se especializan en la persistencia de entidades, haciendo transparente el acceso a las bases de datos.

Para la Interfaz de usuario algunos de los Frameworks más utilizados son Struts y JFS. Para la capa de lógica de negocio, se ha popularizado del uso de Spring y para la abstracción de las bases de datos se utiliza Hibernate.

El uso combinado de estos Frameworks facilita y agiliza enormemente la construcción de aplicaciones complejas.

Figura 124: Relación entre Capas y Frameworks J2EE

226

Solución Integrada: UML – J2EE + DB

J2EE es muy eficiente en Sistemas Empresariales, dada su escalabilidad y flexibilidad, pero la agilidad se pierde al crecer el desarrollo, dado la complejidad de esta plataforma.

UML por su parte, provee la arquitectura necesaria para construir sistemas complejos y su forma de modelado permite la generación de gran parte del código de las aplicaciones.

Figura 125: Arquitectura Multi-capa con J2EE

¿Por qué usar UML y J2EE?

UML provee las herramientas necesarias para diseñar la arquitectura y construir sistemas complejos requeridos por las empresas de hoy. Este soporta requerimientos de ingeniería a nivel de diseño de arquitectura y diseño detallado. Adicionalmente las herramientas de modelado UML están desarrolladas de la forma que el modelo puede ser utilizado para lograr generar gran parte del código J2EE.

El soporte de UML para los requerimientos se manifiesta en el apoyo de los casos de uso, los cuales son utilizados para entender y comunicar los requerimientos funcionales.

Utilizando UML para el modelado de los requerimientos, en conjunto con un proceso de desarrollo basado en casos de uso facilita el seguimiento de los requerimientos al diseño, en este caso para poder identificar los elementos del diseño que y como tienen que ver con algún requerimiento especifico. En un proceso de desarrollo por casos de uso, los elementos del diseño son creados para satisfacer a algún determinado caso de uso. Además permite identificar el impacto de los cambios de requerimientos en el diseño.

227

Los diagramas UML pueden ser utilizados para comprender complejas interacciones en

el sistema. Esto ayuda considerablemente en el análisis del problema además de proveer detallada documentación de cómo se diseño el comportamiento y la estructura del sistema.

Adicionalmente UML permite a los desarrolladores trabajar en un real entorno visual, incorporando patrones de diseño en sus modelos, que, además facilitan que las herramientas modernas basadas en UML sean capaces de generar una gran cantidad funcional de código J2EE.

228

Anexo I: Tratamiento de Información XML

¿Qué es el XML?

XML es básicamente un meta-lenguaje de marcas. Un lenguaje de marcas es esencialmente un conjunto de marcas (tags) que tienen cada una de ellas una semántica particular. El ejemplo más conocido de lenguaje de marcas es HTML, sus marcas indican formas de presentación de los datos en el navegador (<BR> indica un cambio de línea, <B> letras en negrita, etc…). Otros lenguajes de marcas son XSLT, SVG, etc.

XML no utiliza tags predefinidas en sus documentos, por ello es un meta-lenguaje. En XML es el propio usuario el que define su propio vocabulario de tags o utiliza vocabularios de tags estandarizados. Los términos elemento y tag son utilizadas indistintamente con el mismo significado, pero si estamos hablando de programas que utilizan XML el tag y el elemento representan matices distintos.

Mientras que por elemento se entiende al concepto que modelamos, el tag es la representación física dentro del XML de ese elemento. <paciente> es un tag, que representa al elemento paciente dentro del programa.

Aunque XML se parezca a HTML, XML es un lenguaje con muchas más restricciones sintácticas. Por ejemplo, los tags XML tienen que estar debidamente terminadas y otros muchos de detalles que los diferencian. Un documento XML debe de estar “bien formado”, es decir, cumplir las reglas sintácticas, para ser un documento válido.

La estructura del documento XML puede ser o bien totalmente libre, sin ninguna regla de validación, o bien poseer una estructura completamente definida. Las estructuras XML se definen mediante mecanismos como las DTD, mecanismo obsoleto de definición de los elementos que contienen un XML, o los XML Schemas que es el mecanismo más completo y más utilizado en el trabajo real, pero con dificultades para su estandarización dada su complejidad.

Glosario de Términos Fundamentales

SGML (Standard Generalized Markup Language)

Es un meta-lenguaje definido con el propósito de manejar documentación de gran volumen y complejidad. Como metalenguaje, no define tags específicas sino reglas sintácticas. Ejemplos de implementación de SGML es el lenguaje HTML que presenta un conjunto específico y cerrado de tags con una semántica concreta.

229

XML (Extensible Markup Language)

Es un subconjunto de SGML, de mucho menor volumen y complejidad. Su simplicidad hace que se pueda trabajar con él óptimamente en entornos Web. Las operaciones de parsing51 y validación de XML son mucho más sencillas de realizar que en SGML. Como meta-lenguaje no define tags que deben ser definidas por el propio usuario. Existen lenguajes derivados de XML como XSLT.

DTD (Document Type Definition)

El DTD es una definición en un documento SGML ó XML que especifica restricciones en la estructura del mismo. El DTD puede ser incluido dentro del archivo del documento, pero normalmente se almacena en un fichero ASCII de texto separado. La sintaxis de los DTDs para SGML y XML es similar pero no idéntica.

XSD: (XML Schemas)

Es el sucesor lógico de las DTD en cuanto a validación de documentos XML. Es una especificación estándar todavía en evolución con grandes posibilidades para validar documentos complejos (inviables para una DTD). Serán los utilizados durante estas prácticas.

XSL (Extensible Style Language)

El lenguaje de páginas de estilo que ha sido desarrollado por el consorcio W3C, para dar formato a los documentos XML. Una página de estilo XSL permite modificar un documento XML, produciendo varios un resultado que puede estar en varios formatos diferentes incluyendo el propio XML y HTML.

XSLT (Extensible Stylesheet Language Transformations)

Su principal utilización en la actualidad es la presentación de datos procedentes de XML en páginas HTML/JavaScript. Por ejemplo, un HTML que presente la ficha de un cliente, o un Javascript que presente un árbol de nodos con todas las carpetas de un buzón de correo electrónico.

Documentos XML

Dentro de la definición del lenguaje es un aspecto muy importante la distinción entre debemos de distinguir dos tipos (no disjuntos) de documentos XML:

51

Parsing o parseo se define como el proceso de analizar una secuencia de símbolos a fin de determinar su

estructura gramatical con respecto a una gramática formal dada. Formalmente es llamado análisis de sintaxis.

El parseo transforma una entrada de texto en una estructura de datos (usualmente un árbol) que es apropiada

para ser procesada.

230

Bien formados: son todos los que cumplen las especificaciones del lenguaje respecto a las reglas sintácticas, sin estar sujetos a unos elementos fijados en un DTD/XSD. Los documentos XML deben tener una estructura jerárquica muy estricta que deben cumplir los documentos bien formados.

Válidos: Además de estar bien formados, siguen una estructura y una semántica determinada por un DTD o un esquema XSD: sus elementos y sobre todo la estructura jerárquica que define el DTD o esquema, además de los atributos, deben ajustarse a lo que el DTD o esquema dicte.

Cuando se procesa cualquier información formateada mediante XML lo primero es

comprobar si está bien formada y posteriormente comprobar reglas gramaticales si existe definido un DTD o un esquema para el XML en cuestión.

Reglas Sintácticas

Línea cabecera: Es la primera línea de todo documento XML. (<?xml version="1.0" encoding="UTF-8" standalone="yes"?>). Es opcional pero es muy recomendable que esté incluida en todo documento XML que se precie. Posee varios atributos (campos dentro de la declaración) como versión (del lenguaje 1.0), encoding (codificación del texto del documento, generalmente UTF-8 o ISO-8859.1) y standalone (indica si el documento es autosuficiente con el valor yes o necesita otros mecanismos de validación como DTD o esquemas con el valor no).

Los documentos XML son sensibles a mayúsculas, esto es, en ellos se diferencia las mayúsculas de las minúsculas. Por ello <FICHA> sería una etiqueta diferente a <ficha>.

Todos los espacios y retornos de carro se tienen en cuenta (dentro de las etiquetas, en los elementos).

Hay algunos caracteres especiales reservados, que forman parte de la sintaxis de XML: <, >, &, " y '. En su lugar cuando queramos representarlos deberemos usar las entidades &lt, &gt, &amp, &quot, y ' respectivamente.

Los valores de los atributos de todas las etiquetas deben ir siempre entrecomillados. Son válidas las dobles comillas (") y la comilla simple (').

Toda etiqueta no vacía debe tener una etiqueta de cerrado: <etiqueta> debe estar seguida de </etiqueta>.

Todos los elementos deben estar perfectamente anidados.

Los elementos vacíos son aquellos que no tienen contenido dentro del documento (<etiqueta/>).

231

Canonizalización de Documentos

La forma canónica de un documento XML es una manera de mostrar una representación física que asegura que si dos documentos XML son aparentemente diferentes, pero sus canónicos son iguales, los dos documentos son equivalentes.

Cualquier documento puede ser convertido en un equivalente (con algunas limitaciones) a un documento sin DTD a través de un proceso XML llamado canonizalización. El documento generado se llama un documento XML canónico.

Dentro de la recomendación W3C existe la definición formal y estandarizada de documento XML canónico:

"Cualquier documento XML es parte de un conjunto de documentos XML que son

equivalentes lógicos dentro de un contexto de aplicación, pero que podrían variar en la representación física basada en los cambios de sintaxis permitidos por XML 1.0 y namespaces en XML. Esta especificación describe un método para generar una representación física, la forma canónica, de un documento XML que cuenta con los cambios permisibles. Excepto para las limitaciones de unos pocos casos inusuales, si dos documentos tienen la misma forma canónica, los dos documentos son lógicamente equivalentes dentro de un contexto de aplicación dado. Observa que los dos documentos podrían tener formas canónicas diferentes y todavía ser equivalentes en un contexto dado basado en las reglas de equivalencia específicas de la aplicación para las que la especificación XML generalizada podría no tenerse en cuenta".

El proceso de canonizalización resulta en algunos cambios en el documento original, entre otros:

1. Eliminación de la cabecera XML.

2. Eliminación de cualquier definición de DTD.

3. Eliminación de comentarios.

4. Eliminación de líneas en blanco.

5. Eliminación de espacios no significativos:

a. Espacios entre la definición de atributos.

b. Espacios dentro de tags.

6. Expandir todos los elementos con <.... />

7. Organización alfabética de los atributos.

232

Definición de Tipos de Documentos (DTD)

El DTD es una definición en un documento XML que especifica restricciones en la estructura del mismo.

La definición de un DTD especifica la sintaxis de una aplicación de XML, que puede ser un estándar ampliamente utilizado como XHTML o una aplicación local.

Los DTDs son generalmente empleados para determinar la estructura de un documento XML. Un DTD describirá típicamente cada elemento admisible dentro del documento, los atributos posibles y (opcionalmente) los valores de atributo permitidos para cada elemento. Es más, describirá los anidamientos y ocurrencias de elementos. La mayoría de los DTD se componen generalmente de definiciones de ELEMENT y definiciones de ATTLIST.

Hay varios modos de referenciar un DTD en un documento XML:

Incluir dentro del documento una referencia al documento DTD en forma de URI (Universal Resource Identifier, o identificador universal de recursos) y mediante la siguiente sintáxis: <!DOCTYPE familia SYSTEM "http://localhost/ familia.dtd">

Incluir dentro del propio documento el DTD incorporando a la declaración forma de incluir el DTD directamente como en este ejemplo pasa por añadir a la declaración <!DOCTYPE seguida del nombre del nombre del tipo de documento, en vez de la URI del DTD, el propio DTD entre los símbolos '[' y ']'. Todo lo que hay entre ellos será considerado parte del DTD.

La definición de los elementos es bastante intuitiva: después de la cláusula

<!ELEMENT se incluye el nombre del elemento (el que luego se indicara en la etiqueta), y después diferentes cosas en función del elemento:

Entre paréntesis, si el elemento es no vacío, se indica el contenido que puede tener el elemento: la lista de elementos hijos o que descienden de él si los tiene, separados por comas; o el tipo de contenido, normalmente #PCDATA, que indica datos de tipo texto.

Si es un elemento vacío, se indica con la palabra EMPTY.

Si es un elemento vacío, a la hora de indicar los elementos descendientes (los que están entre paréntesis) vemos que van seguidos de unos caracteres especiales: '+', '*', '?' y '|'. Sirven para indicar qué tipo de uso se permite hacer de esos elementos dentro del documento:

+: Uso obligatorio y múltiple; permite uno o más elementos de ese tipo dentro del elemento padre, pero como mínimo uno.

*: Opcional y múltiple; puede no haber ninguna ocurrencia, una o varias.

233

? : Opcional pero singular; puede no haber ninguno o como mucho uno.

|: Equivale a un OR, es decir, da la opción de usar un elemento de entre los que forman la expresión, y solo uno.

Para la definición de los atributos, se usa la declaración <!ATTLIST, seguida de:

El nombre de elemento del que estamos declarando los atributos;

El nombre del atributo;

Los posibles valores del atributo, entre paréntesis y separados por el carácter |, que al igual que para los elementos, significa que el atributo puede tener uno y sólo uno de los valores incluidos entre paréntesis. O bien, si no hay valores definidos, se escribe CDATA para indicar que puede ser cualquier valor (alfanumérico, vamos). También podemos indicar con la declaración ID que el valor alfanumérico que se le de será único en el documento, y se podrá referenciar ese elemento a través de ese atributo y valor;

De forma opcional y entrecomillado, un valor por defecto del atributo si no se incluye otro en la declaración;

Por último, si es obligatorio cada vez que se usa el elemento en cuestión declarar este atributo, es necesario declararlo con la cláusula #REQUIRED; si no lo es, se debe poner #IMPLIED, o bien #FIXED si el valor de dicho atributo se debe mantener fijo a lo largo de todo el documento para todos los elementos del mismo tipo (no es lo mismo esto a lo que significaba ID).

universidad de chile facultad de ciencias...

Documents