Cf-Munoz - FG Planificacion PDF

UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS

DEPARTAMENTO DE INGENIERÍA INDUSTRIAL
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
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
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

Í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
I
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
II
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
III
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
IV
Í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
V
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
VI
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 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
VII
Í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
VIII
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.
60%
50%
40%
30%
20%
10%
0%
1998 2000 2002 2004 2006 2009
Exitosos 26% 28% 34% 29% 35% 32%
Fallidos 28% 23% 15% 18% 19% 24%
Completados 46% 49% 51% 53% 46% 44%
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.
1
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
2
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
3
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.
4
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
5
 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
6
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.
7
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
8
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.
9
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
10
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.
11
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.
12
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
13
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
14
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.
15
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
16
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.
17
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.
18
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
11La 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.
19
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.
20
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.
21
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:
Fortaleza Debilidades
 Buen momento económico del  Falta de incentivos suficientes
país para invertir en proyectos para que las empresas postulen
Tecnológicos a los Concursos
 Proyectos Desarrollados  Focalización de los recursos

Previamente y que sirven inicialmente destinados al
Misión como Base para el desarrollo
de futuros proyectos
FDT, para otros fines “más
prioritarios”
 Mejora y mayor precisión en la  Postulación y adjudicación de

construcción de los Diseños y concursos por parte de
por consecuencia de las Bases empresas carentes de un
producto de la experiencia respaldo sólido que les permita
obtenida implementar el Proyecto
Oportunidades
 Recursos de calidad y con Nuevos Proyectos Aumento de satisfacción de
experiencia en clientes.
Telecomunicaciones y en el Innovación
desarrollo de concursos
Buscar nuevos potenciales Incorporar nuevas
 Existe aún en Chile una brecha proyectos aprovechando el restricciones para la
importante de acceso a redes buen momento económico y postulación a los concursos
de Telecomunicaciones que la búsqueda de metas a nivel que mayor seguridad y certeza
debe ser resuelta país (OCDE12). de su implementación final.
Amenazas
 Todavía es escaso la cantidad Desarrollo de capital humano. Generar integración con el
de recursos Humanos y cliente rediseñando procesos
Económicos para innovación de este, entregando un mejor
Aumento de capacidad y servicio.
 Falta de Recursos productividad
especializados para ciertos Optimizar el uso de los
proyectos. recursos por medio de nuevas
metodologías, procesos y
 Recursos Limitados herramientas.
Tabla 1: Análisis FODA
Dado el reciente ingreso de Chile como país miembro de la Organización para la Cooperación y Desarrollo
12
Económico (OCDE), es que se busca cumplir con los niveles exigidos en dicho organismo.
22
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.
23
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
TOTAL H-H $1.621.667
Depreciación
Equipos N° Horas x día Semanales Total Dedicado Costo Equipo Vida Útil Meses Costo
mensual
16 80 240 $495.000 36 $13.750 $20.625
Costo Mensual
Activo Fijo N° Horas x día Semanales Total Dedicado M2 utilizados Total Costo AF
m2
16 80 240 $5.254 10 $52.544 $78.816
TOTAL OPERATIVOS $99.441
TOTAL VALIDACION CARTERA $1.721.107
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
Depreciación
Nª Equipos N° Horas x día Semanales Total Dedicado Costo Equipo Vida Útil Meses Costo
mensual
6 8 40 120 $495.000 36 $13.750 $61.875
Costo Mensual
m2
6 8 40 120 $5.254 10 $52.544 $236.447
TOTAL DISEÑO DE RED y CALCULO DE INVERSIONES $5.798.321
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.
24
2 8 40 120 $1.222.222 $61.111 $7.639 $1.833.333
Depreciación
mensual
2 8 40 120 $495.000 36 $13.750 $20.625
Costo Mensual
m2
2 8 40 120 $5.254 10 $52.544 $78.816
TOTAL CÁLCULO DE SUBSIDIO $1.932.774
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).
25
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
26
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.
27
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 MMOO 16 y
ATM.
15 La red de núcleo es la que se aprecia enmarcada en azul.

16 Redes de Microondas
28
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.
29
 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
30
 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.
31
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.
32
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.
33
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.
34
 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
35
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.
36
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.
37
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.
38
MAGNITUD CRITERIOS
Alcance
Pequeños Complejidad
Costos
Magnitud Estandarizables Innovación
Nivel Tecnológico
Singulares Plazos del Proyecto
Tamaño
Tabla 6: Característica Magnitud
NATURALEZA CRITERIOS
Plazos del Proyecto
Costos-CAPEX
Infraestructura
Apertura y Construcción
Normativas y Restricciones
Alcance
Cantidad de Recursos Requeridos
Integración
Interoperabilidad
Naturaleza Migración
Mejoramiento
Calidad de Servicio
Seguridad
Disponibilidad
Escalabilidad
Cobertura
Ampliación Cantidad de Recursos Requeridos
Infraestructura
Alcance
Tabla 7: Característica Naturaleza
39
TIPO DE SERVICIO CRITERIOS
Disponibilidad
Ancho de Banda
Seguridad
Alcance
Calidad de Servicio
Core
Integración
Nivel Tecnológico
Interoperabilidad
Complejidad
Innovación
Infraestructura
Disponibilidad
Distribución Medio Ambiente
Normativas y Restricciones
Costos Capex
Costos-CAPEX
Legalizaciones de Obras
Acceso Cableado
Infraestructura
Plazos
Ancho de Banda
Disponibilidad de Servicio
Nivel Tecnológico
Innovación
Legalizaciones de Obras
Redes Inalámbricas
Tipo de Servicio Seguridad y Control
Calidad de Servicio
Medio Ambiente
Costos Opex
Estructura de Precios
Flexibilidad
Complejidad
Innovación
Conocimiento de la Tecnología
Integración
NGN Nivel Tecnológico
Alcance
Migración
Interoperabilidad
Ancho de Banda
Servicios
Costos Opex
Nivel Tecnológico
Innovación
Complejidad
Conocimiento de la Tecnología
Servicios de Valor Agregado
Ancho de Banda
Servicios
Medio Ambiente
Integración
Estructura de Precios
Tabla 8: Característica Tipo de Servicio
40
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.
41
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
42
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]
43
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:
Nivel de Madurez Área de Procesos 1 2 3 4 5

Innovación Organizacional
Optimizado 5
Despliege del análisis causal y resolutivo
Cuantitativamente Funcionamiento de los procesos en la Organización
4
Gestionado Manejo Cuantitativo de Proyectos
Subprocesos Seleccionados
Subprocesos Seleccionados
Desarrollo de Requerimientos
Soluciones Técnicas Integración de Productos
Definido Verificación Validación Manejo 3
Integral de Proyectos +IPPD Manejo de
Riesgo
Manejo de Requerimientos
Planificación de Proyectos
Repetible Seguimiento y Control de Proyectos 2
Manejo de Proveedores
Calidad de Productos y Procesos
Inicial
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.
44
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.
45
 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
46
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
47
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
48
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.
49
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.
50
 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.
51
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.
52
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
53
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.
54
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/hr 27,
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
55
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.
56
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 Parámetros de Monitoreo
Atributos de Productos y Tareas Compromisos
Ciclo de Vida Manejo de Datos
Esfuerzo y Costo Estado de Avance
Presupuesto y Calendario Análisis de Problemas
Manejo de Datos Toma de Acciones Correctivas
Recursos Manejo de Acciones Correctivas
Habilidades y Conocimientos Requeridos
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.
57
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.
58
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.
59
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:
60
Elementos de Gestión Elementos de Procesos Elementos de Principios
Cuantitativa Definidos IPPD
Establecer Objetivos Internalizar los Planes Establecer la Visión
Compartida del Proyecto
Componer el Proceso Definido Establecer los Procesos de Establecer la Estructura del

Definidos del Proyecto Equipo Integrado
Manejo del Funcionamiento del Gestionar el Proyecto Utilizando Asignar Requerimientos a los
Proyecto los Planes Internalizados Equipos Integrados
Contribuir a los Procesos Asegurar la Colaboración

Activos de la Organizació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.
61
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:
62
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
63
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
64
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.
65
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.
66
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].
30Es precisamente la característica de código abierto la que se privilegiará por fines docentes para el diseño de la
herramienta.
67
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 Java XML, JPG, HTML,
Public License 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
68
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.
69
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).
70
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
71
 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.
72
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
73
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
74
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.
75
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
76
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
77
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
78
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.
79
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.
80
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
81
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.
33Es 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.
82
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
83
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.
84
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.
85
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.
86
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
87
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.
88
 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.
89
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
90
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
91
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.
92
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
93
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
94
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.
95
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.
96
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.
97
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
98
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.
34El 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.
99
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.
100
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.
101
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].
102
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.
37Dentro del concepto de técnico se incorporan los siguientes perfiles: ingeniero de proyectos, analistas
económicos y geógrafos.
103
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.
104
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.
105
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
106
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.
107
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.
108
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
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”
111
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.
112
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.
113
Figura 76: Diagrama de Secuencia “Asignación Recursos a Tareas”
114
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.
115
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.
116
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:
117
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.
118
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
119
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.
120
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.
121
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.
122
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
123
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.
124
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"/>
125
</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"
/>
/>
/>
</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"
/>
/>
/>
/>
/>
</allocations>
126
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" />
</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>;
127
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.
128
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
129
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.
130
Figura 87: Estimación de la Cantidad de Recursos Requeridos
131
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
132
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
133
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
134
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
135
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.
136
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
137
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.
138
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
139
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
140
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
39El sistema mencionado corresponde a una aplicación desarrollada especialmente para plataformas Joomla
denominada Docman. Ver Manual de Usuario en Anexo D.
141
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
142
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
143
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
144
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
145
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
146
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
147
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.
148
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.
149
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.
150
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.
151
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).
152
 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).
153
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:
COSTOS DE DISEÑO Y DESARROLLO
$ 14.897.745
$ 16.000.000
$ 14.000.000
$ 12.000.000
$ 9.452.202
$ 10.000.000
$ 8.000.000
$ 6.000.000
$ 3.472.863
$ 4.000.000 $ 1.862.218
$ 2.000.000
$0
IDCI I IDCI II MOVILES II RUTAS
Transmisión de Datos Telefonía Móvil
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.
154
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
155
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:
156
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.
157
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.
158
 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
159
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.
160
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.
161
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.
162
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.
163
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.
164
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.
42Sistema 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.
165
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.
166
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 Planificación Mayor Rentabilidad
Plazos Control y Seguimiento Aumento Calidad de Productos
Costos y Presupuesto Desarrollos Paralelos y Servicios
Identificación de Riesgos Aprovechar Conocimiento 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.
167
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.
168
 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.
169
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.
170
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.
171
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.
172
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.
173
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.
174
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).
175
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.
176
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.
177
 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.
178
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_15020
7.pdf>
8. AURAPORTAL. Soluciones de Gestión de Proyectos con AuraPortal.

<http://www.comunicacionaura.com/AuraPortal/Emails/GAP/E_GAP_SolGestion
Proyectos.htm>.
9. BARROS V., O. 2004. Ingeniería e – Business, Ingeniería de negocios para la

economía digital. J.C. SAEZ editor.
179
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 >
180
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.
181
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.
182
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
183
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
184
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
185
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
186
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”:
187
188
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:
189
 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:
190
Población que contará Cobertura de la Cobertura
Población Cubierta Población a Población de la
Región con Oferta de Servicio de Ruralidad en la Total de la
Previo al Proyecto Beneficiar Región
Telecomunicaciones Región * 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
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.
191
 Proyecto de Telefonía Móvil I
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.
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.
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
192
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
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.
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.
193
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:
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
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:
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
Tabla 19: Cobertura del Proyecto por Localidad.
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.
194
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
195
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
TOTAL H-H $2.444.444

Depreciación
mensual
16 80 320 $495.000 36 $13.750 $27.500
Costo Mensual
m2
0 0 320 $5.254 10 $52.544 $105.088
TOTAL ESTUDIO DE DEMANDA POTENCIAL $2.577.032
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
TOTAL H-H $4.324.444
Depreciación
mensual
16 80 640 $495.000 36 $13.750 $55.000
Costo Mensual
m2
16 80 640 $5.254 10 $52.544 $210.175
TOTAL VALIDACION CARTERA $4.589.619
Tabla 22: Costos del Proceso Pre-evaluación de la Solución Técnica IDCI I
196
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
Depreciación
mensual
5 8 40 160 $495.000 36 $13.750 $68.750
Costo Mensual
m2
5 8 40 160 $5.254 10 $52.544 $262.719
TOTAL DISEÑO DE RED y CALCULO DE INVERSIONES $6.442.579
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
Depreciación
mensual
2 8 40 80 $495.000 36 $13.750 $13.750
Costo Mensual
m2
2 8 40 80 $5.254 10 $52.544 $52.544
TOTAL CÁLCULO DE SUBSIDIO $1.288.516
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.
197
TOTAL H-H $1.222.222

Depreciación
mensual
16 80 160
$495.000 36 $13.750 $13.750
Costo Mensual
m2
0 0 160 $5.254 10 $52.544 $52.544
TOTAL ESTUDIOS $1.288.516
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
TOTAL H-H $846.111
Depreciación
mensual
16 80 120 $495.000 36 $13.750 $10.313
Costo Mensual
m2
16 80 120 $5.254 10 $52.544 $39.408
TOTAL VALIDACION CARTERA $895.831
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
Depreciación
mensual
2 8 40 40 $495.000 36 $13.750 $6.875
Costo Mensual
m2
2 8 40 40 $5.254 10 $52.544 $26.272
TOTAL DISEÑO DE RED y CALCULO DE INVERSIONES $644.258
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
Depreciación
mensual
2 8 40 40 $495.000 36 $13.750 $6.875
Costo Mensual
m2
2 8 40 40 $5.254 10 $52.544 $26.272
TOTAL CÁLCULO DE SUBSIDIO $644.258
Tabla 28: Costos del Proceso Cálculo de Subsidio Móviles II
198
 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
TOTAL H-H $540.556
Depreciación
mensual
16 80 80 $495.000 36 $13.750 $6.875
Costo Mensual
m2
16 80 80 $5.254 10 $52.544 $26.272
TOTAL VALIDACION CARTERA $573.702
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
Depreciación
mensual
2 8 40 40 $495.000 36 $13.750 $6.875
Costo Mensual
m2
2 8 40 40 $5.254 10 $52.544 $26.272
TOTAL DISEÑO DE RED y CALCULO DE INVERSIONES $644.258
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
Depreciación
mensual
2 8 40 40$495.000 36 $13.750 $6.875
Costo Mensual
m2
2 8 40 40 $5.254 10 $52.544 $26.272
TOTAL CÁLCULO DE SUBSIDIO $644.258
Tabla 31: Costos del Proceso Cálculo de Subsidio Rutas Antofagasta
199
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.
200
• 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).
201
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.
202
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:
Home Menú Gestión

Portal Princ Documental
ipal
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)
203
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.
204
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.
205
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).
Paso 1
Figura 118: Cargar Documentos Paso 1
206
Paso 2
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 3
207
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:
Home Menú Foro DGFDT

Portal Princ
ipal
Figura 121: Foro DGFDT
208
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.
47Es 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.
209
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.
48Respecto 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.
210
 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.
211
 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
212
 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.
213
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.
214
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.
215
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.
216
 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.
217
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.
218
 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
219
 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í.
220
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.
221
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:
222
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.
223
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.
224
 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
225
 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.
226
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.
227
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.
228
 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.
229
 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/>).
230
 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.
231
 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.
232
 ? : 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).
233

Cf-Munoz - FG Planificacion PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Cf-Munoz - FG Planificacion PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE CHILE

FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS

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

PROYECTO DE GRADO PARA OPTAR AL GRADO DE MAGÌSTER

FELIPE ANDRES MUÑOZ GUERRA

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

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

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

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

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

No dejes nunca de creer que todo es posible

A Erick, porque más que un jefe ha sido un consejero y un amigo entregándome un

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

Gracias a todos por su apoyo incondicional

Índice de Tablas VIII

Capítulo 3 Modelo de Negocios 18

Capítulo 4 Marco Teórico 27

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

Capítulo 7 Construcción del Prototipo 122

Capítulo 8 Implementación Organizacional 147

Capítulo 9 Generalización 155

Capítulo 10 Discusiones 161

Referencias Bibliográficas 179

Figura 1 Estudios del Informe Chaos. 1

Tabla 1 Análisis FODA. 22

Figura 1: Estudios del Informe Chaos2.

1 El estudio de The Chaos Report cubre más de 60000 proyectos.

3 Tecnologías de Información y Comunicaciones

“Optimizar el manejo de recursos por medio de un sistema de planificación, asignación y

La importancia de este trabajo de tesis radica en la idea de desarrollar un sistema eficiente

El problema a resolver considera el mejorar el desarrollo de proyectos y que entregan

Figura 2: Descripción del Proyecto Desarrollado

4 Subsecretaría de Telecomunicaciones de Chile

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

 Facilitar la creación e ingreso de un nuevo proyecto de telecomunicaciones a la

 Utilizar la información de proyectos de telecomunicaciones anteriores para simplificar

 Optimizar la asignación de recursos a los distintos proyectos para evitar el “recurso

 Desarrollar un prototipo funcional que permita poner a prueba el diseño realizado

5 Project Management Institute

En la actualidad el proceso de planificación de proyectos, asignación de los recursos

 Consultas y Respuestas: Período en el cual se reciben y responden todas las

 Recepción de Propuestas y Acto de Apertura: Fecha límite para recibir las

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

 La Unidad de Gestión de Proyectos (UGP)

Los hitos mencionados anteriormente constan de la entrega de información y documentos

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

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

1.6 Descripción del Informe

El Capítulo 1 describe las motivaciones para la realización del proyecto de tesis,

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

El Capítulo 4 considera los conceptos, teorías e información respecto a proyectos de

En el Capítulo 6 se entregan los resultados obtenidos del rediseño de los procesos de

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

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

10 Unified Modeling Language o Lenguaje Unificado de Modelación

Tiene como principales funciones proponer las políticas nacionales en materias de

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

 Reconocimiento de la fuerte globalización y exposición a los mercados mundiales que

2.1.3 Objetivos Estratégicos