Informe Etapa 1_Diagnóstico de Procesos de TI

Informe Diagnóstico de Procesos de TI y Propuestas de

Mejoras (Etapa 1)

“Levantamiento de procesos, Servicios, Propuesta de Arquitectura y Definición de

competencias de Tecnologías de Información”

Dirección General de Aeronáutica Civil

(DGAC)

Santiago, Enero del 2009

SOAINT TUXPAN Gestión S.A.

INFORME ETAPA 1: DIAGNÓSTICO DE PROCESOS DE TI Y PROPUESTAS DE MEJORAS - DGAC

2

Información del documento identificador

01INFDP00-2 Título

Informe Etapa 1: Diagnóstico de Procesos de TI y Propuestas de Mejoras Versión

2.0 Archivo

Informe Diagnóstico de Procesos de TI.doc Autores Ildegard Bustos K. Mónica Gómez F. Marianela Salomó L. Jorge Delgado R.

Fecha Envío

09/01/2009 Estado

Aprobación del documento Jefe de Proyecto

Pía Gamboa <firma>

<fecha>

Registro de cambios Nº de

cambio Fecha Tipo 1 Descripción del cambio Autor Petición

1 05-12-2008 M

Se modifica texto de primera viñeta del ítem “Caso Nivel Central”. Se

modificó “Elaboración Marco Presupuestario” por “Elaboración

Anteproyecto Presupuestario”.

SOAINT Pía Gamboa Mauro Chávez

2 05-12-2008 M

En el Punto 2 (Resumen Ejecutivo) se modifica la

redacción del primer y quinto párrafo. Además, se inserta una referencia al pie de página, en el

sexto párrafo.


3 05-12-2008 M

En el Punto 2 (Resumen Ejecutivo) se modifica redacción respecto al Análisis de la situación actual de

los procesos de TI.


4 05-12-2008 A En el Punto 3.4 se agregan 3 Objetivos Estratégicos. SOAINT Pía Gamboa

Mauro Chávez

5 05-12-2008 A

En el Punto 6, ítem 2, se agrega el texto “a través de empresas

externas” en el párrafo del Área de Mantención y Desarrollo de

Sistemas.


6 05-12-2008 M

En el Punto 6, ítem 2, se modifica el texto “sistemas operativos

aeronáuticos” por “sistemas de información orientados al área

administrativa y operativa”, en el párrafo del Área de Soporte y

Operaciones.


7 05-12-2008 M Se modifica Tabla 1 “Procesos y

subprocesos de TI”, agregándose columna “Disciplina Asociada”.


1 A, Agregar; M, Modificar; E, Eliminar


3



8 05-12-2008 M

Se modifica Tabla 1 “Procesos y subprocesos de TI”, modificándose

el nombre del subproceso “Elaboración Marco

Presupuestario” por “Elaboración Anteproyecto Presupuestario”.


9 05-12-2008 M

Se modifica Tabla 1 “Procesos y subprocesos de TI”, Proceso

“Ejecución y Control de Proyectos”, Subproceso “Implantación”,

modificándose su descripción.


10 05-12-2008 M

Se modifica Tabla 1 “Procesos y subprocesos de TI”, Proceso

“Capacitación de Funcionarios”, modificándose el nombre

“Departamento de Informática” por “Departamento TIC’s”.


11 05-12-2008 M

Se modifica en la Tabla 2: “Problemas Presentados en

Procesos de TI Unidades / Oficinas Informáticas de la DGAC”, Proceso “Administración de la Inversión de

TI”, el nombre del subproceso “Elaboración de Marco

Presupuestario” por “Elaboración Anteproyecto Presupuestario”.


12 05-12-2008 M

En la Tabla 2: “Problemas Presentados en Procesos de TI

Unidades / Oficinas Informáticas de la DGAC“, Proceso “Administración

de la Inversión de TI”, se elimina primer problema del Subproceso

“Elaboración Anteproyecto Presupuestario”.


13 05-12-2008 M


Unidades / Oficinas Informáticas de la DGAC“, Proceso “Administración de la Inversión de TI”, se modifica

redacción del segundo y tercer problema del Subproceso “Elaboración Anteproyecto

Presupuestario”.


14 05-12-2008 M


Unidades / Oficinas Informáticas de la DGAC“, Proceso “Administración de la Inversión de TI”, se modifica redacción del primer problema del

Subproceso “Gestión de Requerimientos Fuera de



15 05-12-2008 M


Unidades / Oficinas Informáticas de la DGAC”, Proceso “Administración

de Proveedores”, se modifica



4



redacción del primer y tercer problema del Proceso

“Administración de Proveedores”, Subproceso “Licitaciones”.

16 05-12-2008 M

Se modifica en la Tabla 3: “Problemas en Procesos de TI Presentados en DGAC Nivel

Central”,Proceso “Administración de la Inversión de TI”, el nombre del subproceso “Elaboración de

Marco Presupuestario” por “Elaboración Anteproyecto

Presupuestario”.


17 05-12-2008 M


Central”, Proceso “Administración de la Inversión de TI”, la redacción

de los puntos cuarto, quinto y séptimo pertenecientes al Subproceso “Elaboración



18 05-12-2008 M


Central”, Proceso “Administración de la Inversión de TI”, Subproceso “Gestión de Requerimientos Fuera de Anteproyecto Presupuestario”, la redacción del cuarto problema.


19 05-12-2008 M


Central”, Proceso “Administración de Proyectos”, la redacción de los

problemas primero y segundo pertenecientes al Subproceso

“Administración de Requerimientos de HW y SW”.


20 05-12-2008 M


Central”, Proceso “Administración de Proveedores”, la redacción del penúltimo problema perteneciente

al Subproceso “Licitaciones.”


21 05-12-2008 M


Central”, Proceso “Administración de Proveedores”, la redacción del último problema perteneciente al

Subproceso “Evaluación de Proveedores”.


22 05-12-2008 M Se modifica en la Tabla 3:

“Problemas en Procesos de TI Presentados en DGAC Nivel



5



Central”, Proceso “Ejecución y Control de Proyectos”, la redacción de los problemas primero, quinto y

sexto.

23 05-12-2008 M


Central”, Proceso “Ejecución y Control de Proyectos”, la

redacción del primer problema perteneciente al Subproceso

“Planificación Inicial de Proyecto”.


24 05-12-2008 M


Central”, Proceso de “Soporte”, el nombre de “Departamento de

Informática” por “Departamento TIC’s en el séptimo problema.


25 05-12-2008 M


Central”, la redacción del doceavo problema perteneciente al Proceso

“Capacitación a Funcionarios”.


26 05-12-2008 M

Se modifica en Tabla 3: “Problemas en Procesos de TI Presentados en DGAC Nivel Central”, Proceso “Políticas, Procedimientos, Normas –

Seguridad”, la redacción de los problemas segundo y sexto

pertenecientes al subproceso “Políticas, Normas y

Procedimientos”.


27 05-12-2008 A

Se agrega en la Tabla 1: “Procesos que deben ser modificados”, Punto

10.1.2, el Proceso “Planificación Estratégica”.


28 05-12-2008 M

Se modifica en la Tabla 4: “Procesos que deben ser

modificados”, el nombre del subproceso “Elaboración de Marco Presupuestario” por “Elaboración



29 05-12-2008 M

Se modifica en la Tabla 4: “Procesos que deben ser

modificados”, Punto 10.1.2, Proceso “Administración de la Inversión de TI “, párrafo de aspectos a modificar para el subproceso “Elaboración de

Anteproyecto Presupuestario”. Punto 10.1.2.


30 05-12-2008 M Se modifica en la Tabla 2: “Procesos que deben ser SOAINT Pía Gamboa

Mauro Chávez


6



incorporados”, Punto 10.1.3, Proceso “Operación”, párrafo de

aspectos o características a incluir.

31 16-12-2008 M

En la “Tabla 7: Reuniones realizadas”:

- Se modifica el estado de las Minutas MIT028 y MIT029

- Se incluye párrafo explicando la no confección de las últimas reuniones realizadas (con Mauro Chávez y Héctor Mendoza)

SOAINT Pía Gamboa

32 16-12-2008 M

- Se traslada el proceso “Planificación Estratégica”

desde el “Punto 10.1.2 Procesos a

Modificar para adecuarse con los Estándares” al

Punto “10.1.3 Procesos /

Subprocesos recomendables de

Incorporar”

SOAINT Pía Gamboa

33 08-01-2009 M

Se modifica en Tabla 4: “Tabla 4: Procesos que deben ser modificados”, Proceso

“Administración de Proveedores”, la redacción del segundo aspecto a

modificar en el subproceso “Licitaciones”.

SOAINT Mauro Chávez


7

TABLA DE CONTENIDOS

1 INTRODUCCIÓN ............................................................................................................................... 9

2 RESUMEN EJECUTIVO ................................................................................................................ 10

3 DESCRIPCIÓN DE ELEMENTOS ESTRATÉGICOS DE LA DGAC. .................................... 13

3.1 VISION 13 3.2 MISION 13 3.3 VALORES INSTITUCIONALES……………………………………………………………..13

3.3.1 COMPROMISO INSTITUCIONAL .......................................................................................... 13 3.3.2 EFICIENCIA EN EL SERVICIO .............................................................................................. 14 3.3.3 ATENCIÓN AL USUARIO ....................................................................................................... 14 3.3.4 TRABAJO EN EQUIPO............................................................................................................ 14

3.4 OBJETIVOS ESTRATÉGICOS INSTITUCIONALES………………………………………15

4 DESCRIPCIÓN DEL DOCUMENTO. ........................................................................................... 16

5 ENFOQUE METODOLÓGICO. ..................................................................................................... 17

6 UNIDADES U OFICINAS INFORMÁTICAS ............................................................................... 19

7 PROCESOS DE TI .......................................................................................................................... 23

8 MODELAMIENTO DE LOS PROCESOS DE TI. ....................................................................... 29

9 PROBLEMAS PRESENTADOS EN LOS PROCESOS DE TI. ............................................... 29

9.1 PROBLEMAS PRESENTADOS EN LOS PROCESOS DE TI EN LAS UNIDADES / OFICINAS INFORMÁTICAS……………………………………………………………………….29 9.2 PROBLEMAS PRESENTADOS EN LOS PROCESOS DE TI – NIVEL CENTRAL DGAC..34

10 DIAGNÓSTICO DE LOS PROCESOS Y PROPUESTA DE MEJORAS ASOCIADOS A LAS ACTIVIDADES DE TI. ........................................................................................................... 47

10.1 CLASIFICACION DE LOS PROCESOS……………………………………………………..47 10.1.1 PROCESOS QUE CUMPLEN CON LO ESTABLECIDO EN LOS ESTANDARES................. 48 10.1.2 PROCESOS A MODIFICAR PARA ADECUARSE CON LOS ESTANDARES ........................ 49 10.1.3 PROCESOS / SUBPROCESOS RECOMENDABLES DE INCORPORAR............................... 56

11 CRONOGRAMA DE CORTO Y MEDIANO PLAZO PARA LA INCORPO RACIÓN DE LAS MEJORAS Y MODIFICACIONES A LOS PROCESOS. .......................................................... 58

ANEXO 1: DETALLE DE REUNIONES SOSTENIDAS.......................................................................... 61


8

LISTA DE TABLAS

Tabla 1: Procesos y subprocesos de TI .......................................................... 28

Tabla 2: Problemas Presentados en Procesos de TI Unidades / Oficinas Informáticas de la DGAC .......................................................................... 33

Tabla 3: Problemas en Procesos de TI Presentados en DGAC Nivel Central ... 46

Tabla 4: Procesos que deben ser modificados................................................ 55

Tabla 5: Procesos que deben ser incorporados .............................................. 57

Tabla 6: Cronograma Implementación de las Mejoras a los Procesos ............ 60

Tabla 7: Reuniones realizadas ....................................................................... 63


9

1 Introducción El presente informe denominado “Diagnóstico de Procesos de TI y Propuestas de Mejoras ” es la entrega del Hito 1 de la consultoría “Levantamiento de Procesos, Servicios, Propuesta de Arquitectura y De finición de Competencias de Tecnologías de Información ”, el cual es llevado a cabo por la Dirección General de Aeronáutica Civil (en adelante DGAC), y cuyo desarrollo fue adjudicado a SOAInt Tuxpan Gestión S.A. (en adelante SOAInt). Este informe tiene como objetivo presentar el levantamiento de Procesos de TI realizado en las diferentes Unidades Informáticas y Departamentos / Subdepartamentos, en los cuales se realizan labores de TI o bien, que cuentan con una estructura informática. Adicional a lo anterior, se entrega la brecha detectada respecto a la forma en que se lleva a cabo la planificación estratégica (Plan Informático), las actividades de TI y lo establecido por las mejores prácticas en relación a este tipo de procesos, tales como ITIL, CMMI y COBIT, además de la experiencia de SOAInt en relación a implementaciones de mejoras en actividades informáticas. Finalmente, se entrega un cronograma de corto y mediano plazo para la implementación de las mejoras propuestas a los procesos.


10

2 Resumen Ejecutivo En el marco de esta consultoría, SOAInt Tuxpan Gestión S.A. entiende que los procesos y actividades de TI existentes en una organización, conformada por los siguientes tres aspectos centrales, la tecnología de la Información en sí, los procesos que ésta apoya y las personas que hacen uso de la misma, deben estar alineados con el logro de los objetivos y necesidades de la institución. Considerando esta triple perspectiva y el objetivo del presente estudio es que, en el análisis de la situación actual de los procesos de TI de la DGAC, se ha podido establecer que las mayores debilidades2 identificadas, tanto a Nivel Central como en las Unidades / Oficinas de Informática se relacionan directamente a los procesos de: Caso Nivel Central:

• Administración de la Inversión de TI (Elaboración Anteproyecto Presupuestario y Gestión de Requerimientos Fuera de Anteproyecto Presupuestario)

• Administración de Proyectos • Administración de Proveedores • Gestión de Riesgos • Ejecución y Control de Proyectos • Capacitación a Funcionarios

Caso Unidades / Oficinas Informáticas: • Administración de la Inversión de TI (Elaboración Anteproyecto

Presupuestario y Gestión de Requerimientos Fuera de Anteproyecto Presupuestario)

• Gestión de Riesgos • Soporte

En la actualidad, se presentan las siguientes situaciones:

• Existe un documento denominado Plan Informático como resultado del una iniciativa del Subdepartamento de Gestión TIC’s, este documento no ha sido formalizado al interior de la Institución. Aún cuando lo que se plantea en este documento constituye un lineamiento para las actividades del departamento TIC’s, no se aprecia un cronograma actualizado para la realización de los proyectos declarados. Adicionalmente, éste no incorpora los proyectos que deben realizarse en las oficinas/unidades para apoyarlas en el cumplimiento de los objetivos estratégicos de la DGAC. Por todo lo

2 Las debilidades o problemas se encuentran explícitas en la Tablas 2 y 3


11

anterior, el plan existente debe ser: revisado, ampliado en su cobertura, validado por toda la DGAC, formalizado, comunicado y monitoreado en su puesta en marcha.

• No se observa una consolidación de las iniciativas que se transforman en

proyectos tecnológicos, ya sea en el Departamento TIC’s o en las Unidades / Oficinas Informáticas, que permita verificar que estos proyectos están alineados a la Planificación Estratégica de la DGAC, que se generan sobre la base de Políticas, Procesos y Normas establecidas por el Departamento TIC’s, y que sean compatibles con los elementos ya existentes de manera de facilitar la integración y el aprovechamiento más eficiente de la plataforma existente.

• La reciente modificación de la estructura organizacional del Departamento

TIC’s aún no se ha concretado con el concurso de los cargos de jefatura ni se ha revisado en todos sus niveles de acuerdo a una definición que les permita hacerse cargo de proveer servicios al resto de la DGAC y liderar los proyectos informáticos que sean requeridos, esto tiene como consecuencia que aún no exista una evaluación real de la dotación actual para satisfacer los requerimientos organizacionales.

• En general, los procesos que actualmente se llevan a cabo al interior del

Departamento TIC’s no han sido estructurados y formalizados de manera de asegurar su observancia y homogeneizar la realización de las actividades entre los grupos y personas del departamento, esto tiene como consecuencia que existan diferencias en la realización de las actividades o que existan procesos no cubiertos, en especial los relacionados a medidas de control.

• Existen proyectos en curso que tienen como objetivo el mejoramiento de las

actividades del Departamento TIC’s, como son la Definición de una Política de Seguridad de la Información o la Implementación de un Modelo ITIL, los que surgen como iniciativas independientes al interior del Departamento TIC’s (no como resultado de iniciativas presentadas por usuarios finales) y sin una coordinación explícita entre ellos. Como resultado, se visualiza una discontinuidad entre el diseño y la implementación de estos proyectos, en especial a lo referido a Seguridad de la Información (no se aprecia la fase de implementación como continuidad del proyecto anteriormente mencionado). Esto puede traer como consecuencia que las políticas, normas y procedimientos definidos a nivel documental no se traspasen a las actividades del día a día de las funciones y servicios TIC’s, ni se difundan de manera transversal y generalizada en la organización.


12

• No se observa la existencia de elementos de Seguridad lógica 3en relación a las actividades informáticas para cautelar el acceso a los datos, la identificación de los usuarios y la segregación de actividades en las aplicaciones computacionales, esto tiene como consecuencia que existan situaciones que podrían generar riesgo de integridad de datos o de programas.

• No se observa la existencia de una estrategia para abordar las

contingencias informáticas que involucre el dotar a la DGAC de todos los elementos para continuar el procesamiento de las aplicaciones críticas frente a situaciones adversas que afecten en forma parcial o total a la plataforma.

Respecto al análisis de la situación actual de los procesos de TI de la DGAC, se realizó un levantamiento de procesos de TI que cubre el ciclo de vida de un proyecto desde su planificación, pasando por la ejecución, el control e implantación, hasta su cierre y posterior operación. Como resultado se observó que de los procesos levantados y analizados:

• Ningún proceso existente cumple totalmente con lo establecido en los estándares

• Diez procesos existentes deben ser modificados en su estructura para adecuarse a los estándares

• Nueve procesos no existen y sería recomendable incorporar para reforzar las actividades informáticas

El detalle de los aspectos mencionados se entrega en los capítulos del presente informe.

3 Seguridad Lógica: corresponde a todos los accesos y controles aplicados a los productos de SW y Bases de Datos que son intangibles.


13

3 Descripción de Elementos Estratégicos de la DGAC. El trabajo realizado para generar el informe de Diagnóstico de Procesos de TI y Propuestas de Mejoras, abarcó el análisis de todos los procesos de TI de las Unidades y Oficinas Informáticas de la Dirección General de Aeronáutica Civil desde un enfoque TOP – DOWN, por lo tanto, dado este enfoque metodológico, se realizó inicialmente el levantamiento y la revisión de los elementos estratégicos de esta institución, lo cuales son presentados a continuación:

3.1 VISION

La visión declarada por la DGAC es la siguiente:

“Proyectar a la Institución como un organismo esencial del Estado, destinado a operar y desarrollar el Sistema Aeronáutico Nacional con seguridad y eficiencia,

con personal altamente calificado y servicios de excelencia, buscando constituirse en la mejor autoridad aeronáutica de Latinoamérica y la Institución Pública más

eficiente del país”.

3.2 MISION

La misión declarada por la DGAC es la siguiente: “Normar y fiscalizar la actividad aérea que se desarrolla dentro del espacio aéreo

controlado por Chile y aquella que ejecutan en el extranjero empresas aéreas nacionales, desarrollar la infraestructura aeronáutica, prestar servicios de

excelencia de navegación aérea, meteorología, aeroportuarios y seguridad operacional, con el propósito de garantizar la operación del Sistema Aeronáutico

en forma segura y eficiente, contribuyendo de esta manera al desarrollo nacional.”

3.3 VALORES INSTITUCIONALES

3.3.1 COMPROMISO INSTITUCIONAL

“Sentirse comprometido con los objetivos y tareas de la Institución, de este modo no podemos ser pasivos frente a las situaciones y problemas, sino que nuestra actitud debe ser inquieta, proactiva y arraigada a una cultura de servicio”.


14

3.3.2 EFICIENCIA EN EL SERVICIO

“Cumplir con nuestro trabajo responsablemente y de la manera más eficiente posible. Esto significa no desperdiciar recursos, ser consecuentes en la determinación de necesidades y no gastar recursos en actividades que no apunten al cumplimiento de la misión, objetivos y tareas que cada Organización interna tenga”.

3.3.3 ATENCIÓN AL USUARIO

“Somos una Institución Pública que presta un servicio fundamental para el desarrollo del país. Tenemos la responsabilidad y obligación de prestar un servicio eficaz y completo al usuario del Sistema Aeronáutico, con la mejor actitud y entusiasmo, de manera de no sólo satisfacer sus necesidades y requerimientos, sino que hacerlo enmarcado en un ambiente grato y de colaboración mutua”.

3.3.4 TRABAJO EN EQUIPO

“Somos una Institución compleja, principalmente por las múltiples actividades que desarrollamos, las cuales están ligadas entre ellas y son, cada una, un eslabón en la cadena de servicios que prestan todas las organizaciones internas. Por esta razón el trabajo en equipo es fundamental, entendiendo que somos una sola Institución y que el esfuerzo coordinado es la única forma de avanzar en forma eficiente hacia el cumplimiento de nuestros objetivos”.


15

3.4 OBJETIVOS ESTRATÉGICOS INSTITUCIONALES

• Mantener altos estándares de seguridad en las operaciones aeronáuticas, estableciendo la normativa que permita la operación y el desarrollo del sector aeronáutico nacional, fiscalizando eficazmente su cumplimiento.

• Proporcionar servicios aeroportuarios y de navegación aérea, que

respondan a la demanda por los servicios requeridos, bajo un esquema de tasas y derechos consistentes con la gestión del sistema aeronáutico operacional.

• Proporcionar servicios meteorológicos que satisfagan las necesidades de la

comunidad, sectores productivos e instituciones, de acuerdo con estándares internacionales, propendiendo a la generación autónoma de ingresos.

• Consolidar una presencia nacional e internacional eficaz, que permita

promover los intereses que mejor satisfagan al sistema aeronáutico nacional y preservar su patrimonio histórico.

• Gestionar y controlar los procesos internos de la Institución y los servicios que presta a los usuarios del Sistema Aeronáutico Nacional en forma inteligente, eficiente, oportuna y segura.

• Proporcionar el personal necesario, con las competencias, motivación y compromiso, que permita agregar valor a la provisión de los productos estratégicos de la Institución, satisfaciendo en forma eficaz y eficiente las exigencias de los usuarios/clientes.

• Tener presencia internacional, en condiciones de liderazgo, a fin de contribuir a los objetivos de la política exterior del país en materias de desarrollo aeronáutico y comercial.


16

4 Descripción del Documento. Como parte del trabajo de la realización del diagnóstico de los Procesos de TI de las Unidades Informáticas y Oficinas que cuentan con una estructura informática, este documento presenta los elementos correspondientes a:

• Enfoque metodológico

• Identificación de los procesos de TI que permiten proveer los servicios de TI de las Unidades / Oficinas Informáticas.

• Modelamiento (representación gráfica) y documentación de los procesos asociados a las actividades informáticas.

• Problemas presentados y detectados en los procesos de TI. • Diagnóstico y Propuesta de modificaciones de los Procesos asociados a las

actividades de TI, abordando directamente las fuentes de los problemas o las oportunidades de mejora existentes.

• Cronograma de corto y mediano plazo para la implementación de las mejoras

propuestas a los procesos.


17

5 Enfoque Metodológico. Las Unidades u Oficinas Informáticas consideradas en la presente consultoría son los siguientes:

• Departamento TIC’s � Subdepartamento Gestión TIC’s � Subdepartamento Soporte TIC’s

• DASA: Departamento Aeródromos y Servicios Aeronáuticos • DMC: Dirección Meteorológica de Chile • ETA: Escuela Técnica Aeronáutica • DSO: Departamento de Seguridad Operacional

Los Procesos de TI levantados y analizados son:

• Administración de la Inversión de TI • Administración de Proyectos • Administración de Proveedores • Gestión de Riesgos • Ejecución y Control de Proyectos • Administración Infraestructura Tecnológica • Soporte • Control de Cambios • Capacitación Funcionarios • Políticas, Normas y Procedimientos - Seguridad

Para el levantamiento de información y posterior análisis de cada uno de los procesos de TI mencionados anteriormente, se concertaron reuniones4 con las contrapartes de cada Unidad u Oficinas Informáticas de las Direcciones / Departamentos / Subdepartamentos y Escuela, incluidos en la presente consultoría, con el objetivo de obtener los antecedentes referidos a sus servicios, actividades incluidas en cada uno de los procesos, entes involucrados (actores / roles / responsables, clientes y proveedores), los productos generados en cada uno de los procesos de TI y sus actuales problemas presentados. De cada reunión, se solicitó y analizó la documentación existente asociada a los procesos involucrados en el estudio para su posterior modelamiento de procesos y análisis .

Una vez modelado los procesos, se procedió a realizar un diagnóstico de ellos asociados a las actividades de TI que la componen, con el objetivo de determinar la brecha existente en la forma en que se llevan a cabo las actividades de TI y lo establecido por las mejores prácticas en relación a este tipo de procesos, como

4 Ver Anexo 1: Detalle de Reuniones Sostenidas


18

son ITIL5 (Information Technology Infrastructure Library), CMMI6 (Capability Maturity Model Integration) y COBIT7 (Control Objectives for Information and Related Technology), además de la experiencia de SOAInt TUXPAN en relación a implementaciones de mejoras en actividades informáticas. Para ello se realizaron las siguientes tareas:

1. Se compararon los modelos de procesos de las actividades de TI con las mejores prácticas y la experiencia de SOAInt TUXPAN, para realizar una clasificación de los procesos de acuerdo al siguiente esquema:

• Procesos existentes en la actualidad que cumplen con lo establecido en

los estándares • Procesos existentes en la actualidad que deben ser modificados en su

estructura para adecuarse a los estándares • Procesos no existentes en la actualidad que sería recomendable

incorporar para reforzar las actividades informáticas

2. Se especificaron los aspectos que deben ser modificados de los procesos existentes para adecuarse a los estándares.

3. Se especificaron las características de los procesos nuevos que sería recomendable incorporar.

4. Finalmente, se estableció un cronograma de corto y mediano plazo para la implementación de las mejoras a los procesos.

5 ITIL: Marco de Referencia para la Administración de Servicios de TI, creada por CCTA (Central Comunications and Telecom Agency) del gobierno del Reino Unido. 6 CMMI: Modelo para la mejora de procesos, creado por el SEI (Software Engineering Institute). 7 COBIT: Modelo para el Gobierno de la TI desarrollado por Information Systems Audit and Control Association (ISACA) y el IT Governance Institute (ITGI).


19

6 Unidades u Oficinas Informáticas Las unidades u oficinas informáticas consideradas en esta consultoría son las siguientes: Departamento TIC’s: Esta unidad es responsable de Gestionar las Tecnologías de los Sistemas de Información y Comunicaciones (TIC) institucionales. Debe proveer el desarrollo y mantenimiento de hardware, software y sistemas informáticos de la Institución, y establecer los mecanismos de seguridad y control de la información, de acuerdo a las políticas y normativa gubernamental en la materia. Además, el Departamento TIC’s debe asesorar a las unidades en el direccionamiento de los recursos de TI, velando por una adecuada estandarización de los mismos, entre otros.

En la actualidad cuenta con dos Subdepartamentos, estos son:

1. Subdepartamento Gestión TIC’s: Responsable de proponer la planificación de las TIC’s institucionales, de acuerdo al desarrollo Institucional y a las políticas y normativa gubernamental en la materia. Gestionar la investigación y desarrollo en materias de TIC’s. y proponer y controlar el cumplimiento de la normativa de seguridad de la información, conforme a las disposiciones establecidas por el gobierno.

2. Subdepartamento Soporte TIC’s: Responsable de mantener y dar soporte a

los recursos tecnológicos tales como: desarrollo de software y aplicaciones, hardware, plataforma central, infraestructura de redes, bases de datos institucionales, sistemas de información y servicios asociados, según corresponda.

Este Subdepartamento además cuenta con dos áreas: • Área de Mantención y Desarrollo de Sistemas: Se encarga de

estudiar y desarrollar los sistemas, a través de empresas externas, normas y procedimientos relativos al área informática que deben ser aplicados en los diferentes procesos operativos, administrativos y de funcionamiento de la DGAC. Además de estudiar y analizar las necesidades relativas al desarrollo, explotación, mantenimiento de adquisición de equipamiento y software.

• El Área de Soporte y Operaciones se encarga de administrar y

proporcionar el soporte técnico requerido por los diferentes usuarios de la DGAC para la explotación de los sistemas de información


20

orientados al área administrativa y operativa. Además de otorgar el soporte de hardware y software.

Departamento Aeródromos y Servicios Aeronáuticos (D ASA): Esta unidad es responsable de administrar los aeródromos públicos de domino fiscal y autorizar, certificar y fiscalizar los aeródromos públicos y privados del país, velando por el funcionamiento eficaz de los servicios aeronáuticos. En este contexto, el área informática de la DASA proporciona:

• El monitoreo permanente a la conectividad de red de área local y conectividad ampliada disponible a la Unidad.

• Supervisa los contratos de fotocopiado y mantención de PC e impresoras.

• Asesora al Jefe de Planificación y Control en materias del ámbito de Gobierno Electrónico y Tecnologías de la Información.

Además, al interior de la DASA existe una constante preocupación por el desarrollo y mantención de los sistemas informáticos internos que apoyan los servicios aeroportuarios y de navegación aérea (por ejemplo, sistema VITRO). En este ámbito, existe una empresa externa que les entrega el servicio de desarrollo de sistemas. Dirección Meteorológica de Chile (DMC): Esta unidad es responsable del quehacer meteorológico del país, y cuyo propósito es satisfacer las necesidades de información y previsión meteorológica de todas las actividades nacionales.

En este contexto, el área informática de la DMC debe administrar el equipamiento computacional, servidores, aunando los conocimientos técnicos y prácticos para el desarrollo de los sistemas computacionales de acuerdo a las necesidades presentadas por las distintas áreas internas de la DMC, además de participar y dar asesoría técnica informática en la ejecución de contratos relativos a servicios informáticos.

Los principales servicios que presta la oficina de informática de la DMC son:

• Soporte (HW, SW, Comunicaciones) • Desarrollo y mantención de sistemas (Interno) • Preparación de anteproyectos para Anteproyecto Presupuestario. • Asesoría Informática para el desarrollo de proyectos para

dependencias o áreas internas de la DMC.

Escuela Técnica Aeronáutica (ETA): Instituto de Educación Superior, dependiente de la Dirección General de Aeronáutica Civil, cuyo quehacer se


21

orienta a la formación, perfeccionamiento y capacitación de técnicos y profesionales, en las diversas ramas del ámbito aeronáutico.

En este contexto, la unidad informática de la ETA se encarga de:

• Mantener operativos todos los sistemas de informática y computación implementados en la ETA (tanto de hardware y software).

• Prestar servicios de apoyo y soporte para la página Web de unidad, Plataforma e-learning, Software Aula Virtual, Sistema de gestión de curso, Simuladores, Soporte técnico a usuarios de la unidad.

Departamento de Seguridad Operacional (DSO): Departamento responsable de fiscalizar y aplicar las normas para regular las actividades que realizan las empresas de transporte público, clubes aéreos, empresas de trabajos aéreos, aviación general y deportiva, la aeronavegabilidad de las aeronaves, las condiciones sicofísicas y técnicas del personal aeronáutico, los centros de mantenimiento, diseño y fabricación de productos y partes aeronáuticas. En este contexto, la unidad informática de la DSO cuenta con una empresa externa la cual tiene como obligación prestar el servicio de mantención del sistema ALVI (Acreditación de Licencia Virtual e Interactivo). Este servicio se debe prestar con la regularidad y periodicidad necesaria para garantizar el óptimo funcionamiento del sistema. En el levantamiento de los procesos de la DSO, fueron considerados los siguientes subdepartamentos:

1. Subdepartamento de Transporte Público (STP): Este Subdepartamento es responsable de certificar y fiscalizar mediante un proceso de vigilancia continua a: las empresas que realizan operaciones de trasporte aéreo, la aeronavegabilidad de sus aeronaves y los centros de mantenimiento asociados. Esta fiscalización incluye empresas que operan el Chile, todas las aeronaves que operan en el territorio nacional, empresas chilenas y aeronaves de matrícula chilena que operan en el extranjero; centros de mantenimiento en el territorio nacional y en el extranjero a aquellos que le dan servicio a aeronaves de matrícula chilena. En este contexto, la unidad informática del Subdepartamento de Transporte Público (STP) presta los siguientes servicios al interior de su unidad:

• Servicios de apoyo para realizar la fiscalización y la certificación a las compañías comerciales.

• Apoyo al Subdepartamento de Licencias en la toma de exámenes para otorgar licencias.

• Soporte técnico a los usuarios (en primera instancia)


22

• Mantener publicada la información de Operaciones Especiales, donde el Servicio de Tránsito Aéreo puede auto atenderse consultando on-line.

2. Subdepartamento de Licencias: Este Subdepartamento es responsable de

otorgar, renovar, suspender o cancelar las licencias y habilitaciones al personal aeronáutico, efectuando las evaluaciones teóricas y de pericia a los postulantes y titulares de licencias y habilitaciones aeronáuticas. Además fiscalizar el cumplimiento de la normativa en el ámbito de las licencias al personal aeronáutico. En este contexto, el Subdepartamento de Licencia realiza desarrollos internos para apoyar las actividades del negocio.

3. Subdepartamento Aeronavegabilidad: Este Subdepartamento es

responsable de certificar y fiscalizar en el ámbito de la Aeronavegabilidad mediante un proceso de vigilancia continua ha: las empresas que realizan operaciones de transporte aéreo; a todas las que realizan trabajos aéreos; a la aviación general y a los centros de mantenimiento asociados. Además, certificar y fiscalizar a los organismos nacionales de diseño y fabricación de productos aeronáuticos, sus partes y componentes, aplicándose en cada una de estas áreas la normativa vigente. En este contexto, el Subdepartamento de Aeronavegabilidad mantiene desarrollos internos para apoyar las actividades del negocio.


23

7 Procesos de TI Los estándares aplicados para el levantamiento de procesos, fueron definidos de acuerdo al ciclo de vida del desarrollo de los proyectos y sus procesos de soporte. Desde la perspectiva de CMMI, se consideraron las formalizaciones exigidas para los ciclos de desarrollo de proyectos que contemplan las siguientes áreas: Análisis de Causas y Resolución, Gestión de la Configuración, Análisis de Decisiones y Resolución, Gestión Integrada de Proyectos, Medición y Análisis, Monitorización y Control de Proyecto, Planificación de proyecto, Aseguramiento de Calidad de Procesos y Productos, Integración de Productos, Gestión Cuantitativa de Proyectos, Gestión de Requerimientos, Desarrollo de Requerimientos, Gestión de Riesgos, Gestión de Acuerdos con Proveedores, Validación y Verificación.

Desde la perspectiva de ITIL se consideró la clasificación de los procesos relacionados con la entrega y soporte de los servicios de TI en su fase de Operación. Esta clasificación corresponde a:

• Prácticas de los Procesos Operativos: o Gestión de la Configuración o Gestión de Incidentes o Gestión de Problemas o Gestión de Cambios o Gestión de la Liberación

• Prácticas de los Procesos Tácticos: o Gestión de Niveles de Servicio o Gestión de la Disponibilidad o Gestión de la Capacidad o Gestión de la Continuidad o Gestión Financiera

Finalmente, desde la perspectiva de COBIT se consideraron los objetivos de control clasificados en cuatro dominios: Planificación y Organización, Adquisición e Implementación, Entrega y Soporte, y, Supervisión y Evaluación. Estos objetivos de control apuntan a establecer:

• Los lineamientos para Gobierno de TI y un conjunto de herramientas de soporte que permite cubrir la brecha entre los requerimientos de control, los aspectos técnicos y riesgos de negocio.

• Lineamientos para el desarrollo de políticas claras y las buenas

prácticas para los controles de TI a través de las organizaciones.


24

Una vez analizadas las diferentes perspectivas, se procedió a homologar los nombres de los procesos considerados bajo los tres estándares anteriormente mencionados, resultando los siguientes procesos de TI:

Proceso Descripción del Proceso

Disciplina Asociada Subproceso Descripción del

Subproceso

N/A Elaboración

Anteproyecto Presupuestario

Proceso a cargo de levantar y priorizar las necesidades de las Unidades de la Dirección General de Aeronáutica Civil,

para la preparación de la Ficha de Anteproyecto

Presupuestario.

N/A

Gestión de Requerimientos

Fuera de Anteproyecto

Presupuestario

Proceso a cargo de la gestión de requerimientos que surgen durante la ejecución del año

presupuestario en curso y que no fueron considerados en la

Ficha de Anteproyecto Presupuestario en el período

solicitado.

Administración de la Inversión de TI

Proceso que cubre la planificación y

utilización de recursos al interior

de la Dirección General de

Aeronáutica Civil, para asegurar la

continuidad operacional de los

servicios aeronáuticos y

apoyar las tareas administrativas de

la Institución.

COBIT Control Presupuestario

Proceso que cubre el monitoreo y mantención del

registro de los pagos realizados a los proveedores,

verificando que no existan retrasos de los mismos.

ITIL/CMMI/COBIT Administración de Requerimientos de

HW y SW

Proceso que cubre la gestión de requerimientos de

hardware y software que surgen desde el usuario,

hasta que se materializan en un proyecto o producto.

Administración de Proyectos

Proceso que cubre el levantamiento y

gestión de los requerimientos

presentados por los usuarios y la

planificación de la cartera de proyectos

aprobados para el año.

.

ITIL/CMMI/COBIT Gestión de Requerimientos

Proceso que cubre la gestión de requerimientos desde que

son levantados en el área usuaria, hasta que se

materializan en un proyecto o producto.


25



Subproceso

CMMI/COBIT Planificación de Proyectos

Proceso responsable de la calendarización de iniciativas

de acuerdo a las tareas de cada Subdepartamento y a la asignación de responsables

en base a la carga de trabajo de los recursos disponibles.

CMMI/COBIT Licitaciones

Proceso que describe la presentación del requerimiento al

Subdepartamento de Adquisiciones, generación de

las Bases Técnicas, evaluación de los proponentes

y la adjudicación del Proveedor.

CMMI/COBIT Administración de Contratos

Proceso responsable de realizar la formulación y

administración de los contratos que oficializa la DGAC con un Proveedor.

Administración de Proveedores

Proceso que cubre las licitaciones,

administración de contratos y

evaluaciones de desempeño de los

proveedores relacionados con

los servicios operativos de la

DGAC.

CMMI/COBIT Evaluación de Proveedores

Proceso a cargo de la evaluación del desempeño del

proveedor durante un proyecto o un contrato de servicios operacionales.

CMMI/COBIT Análisis de Riesgos

Procesos a cargo de realizar la identificación y análisis de los riesgos que se presentan

en la ejecución de un proyecto.

Gestión de Riesgos

Proceso a cargo del análisis e

identificación de riesgos durante la vida del proyecto,

generación de planes de

mitigación y contingencia.

CMMI/COBIT Realización de

Planes de Mitigación

Proceso a cargo de realizar planes de mitigación en aquellos proyectos que

presentan riesgos.

Ejecución y Control de Proyectos

Proceso a cargo del ciclo de vida de ejecución del

proyecto desde el

CMMI Planificación

Inicial de Proyectos

Proceso que cubre la generación de acuerdos y programación detallada de actividades de un proyecto.


26



Subproceso

CMMI Control y Seguimiento

Proceso que cubre el control y seguimiento de:

- La ejecución de las actividades al interior de un

proyecto.

- Cumplimiento de plazos e Hitos de entrega

- Productos presentados por el Proveedor

CMMI Desarrollo del Proyecto

Corresponde al Proceso que cubre el desarrollo interno de

un proyecto de SW.

ITIL/CMMI/COBIT Control de Calidad

Proceso a cargo del control de calidad de los productos

entregados.

ITIL/CMMI/COBIT Implantación

Proceso que describe desde la liberación de un producto en la fase de pruebas hasta

su configuración en ambientes de producción para entregarlo

al usuario final.

ITIL/CMMI/COBIT Capacitación a Usuarios

Proceso que cubre la capacitación de los usuarios

finales ante la liberación de un nuevo producto o mantención de un sistema al interior de la

Unidad o de la Institución.

inicio de la planificación detallada de

actividades hasta el cierre del Proyecto.

CMMI/COBIT Cierre de Proyecto

Proceso que cubre el cierre de actividades relacionadas con

el proyecto en curso y la realización de actividades de

evaluación de equipo interno y lecciones aprendidas.


27



Subproceso

ITIL/COBIT Análisis de

Infraestructura Tecnológica

Proceso que describe el análisis, dimensionamiento y

proyección de la demanda de infraestructura tecnológica.

ITIL/ COBIT Dimensionamiento de Plataforma

Proceso que se hace cargo de dimensionar los

requerimientos de plataforma que necesitan las nuevas aplicaciones o módulos

desarrollados.

Administración de Infraestructura

Tecnológica

Proceso que cubre:

- El análisis de la infraestructura existente en la Unidad para la generación de

requerimientos.

- Dimensionamiento de la plataforma

para nuevas aplicaciones o componentes.

- Proyección de crecimiento de la

Plataforma de acuerdo a las

necesidades de la Unidad.

ITIL/ COBIT Proyección de

Crecimiento de la Plataforma

Proceso responsable de proyectar el crecimiento de la plataforma de acuerdo a las

necesidades requeridas.

Soporte

Proceso que cubre la operación y soporte a los

sistemas – equipos de la DGAC y a los

usuarios.

ITIL/COBIT Atención Mesa de Ayuda

Proceso responsable de entregar el soporte a los usuarios en términos de

hardware, software y comunicaciones.

Control de Cambios

Proceso que cubre el control y

trazabilidad de los cambios sobre los

ítems de configuración (HW,

SW, Licencias, Documentos)

definidos al interior del área de TI, de

acuerdo a la criticidad de los

servicios asociados.

ITIL/CMMI/COBIT N/A N/A


28



Subproceso

Capacitación Funcionarios

Proceso que cubre las capacitaciones –

especializaciones de los funcionarios de las Unidades /

Oficinas y Departamento TIC’s

ITIL/CMMI/COBIT N/A N/A

ITIL/COBIT Políticas, Normas y Procedimientos

Proceso encargado de estandarizar la definición de

las políticas, normas y procedimientos de TI para la

institución. Políticas, Normas, Procedimientos -

Seguridad

Proceso que cubre la definición de las políticas, normas y procedimientos de TI institucionales,

además de aspectos de

respaldos al interior de la DGAC.

ITIL/COBIT Respaldos

Proceso encargado de mantener los procedimientos de respaldos al interior de de

la DGAC.

Tabla 1: Procesos y subprocesos de TI


29

8 Modelamiento de los Procesos de TI. Esta actividad tiene como objetivo, modelar y documentar los procesos asociados a las actividades informáticas en un formato que parta de una cadena de valor, donde se identifiquen proveedores y clientes, para finalmente, desagregar en los componentes que generan los productos y servicios requeridos por los clientes. Con la información recolectada producto de las reuniones sostenidas con las contrapartes conocedoras de los procesos de TI, se procedió a documentar los procesos de acuerdo a la notación gráfica de la ISO 9001, modelada en la herramienta Bizagi , herramienta que no requiere licencia, y que permite entre otras funcionalidades, las siguientes:

• Modelar los procesos y subprocesos utilizando la notación BPMN8. • Documentar los modelos de procesos, subprocesos y sus actividades. • Agregar atributos a las actividades pertenecientes a cada modelo. • Dependiendo de los atributos definidos, Bizagi es capaz de generar

reportes personalizados en formato Word, Adobe, XPDL, XML. • Posee la capacidad de importar y exportar información con Microsoft Visio

2003 y 2007. • Exportación de los modelos a formatos jpg, png, bmp. • Importación de modelos desde archivos Visio, XPDL y XML.

El detalle del modelamiento de los procesos se encuentra en el Anexo 2: Modelamiento de Procesos de TI.

9 Problemas Presentados en los Procesos de TI.

9.1 PROBLEMAS PRESENTADOS EN LOS PROCESOS DE TI EN LAS UNIDADES / OFICINAS INFORMÁTICAS

Procesos de TI Subprocesos Problemas Levantados 9

Administración de la Inversión TI Elaboración Anteproyecto

Presupuestario • El manejo del presupuesto, es de acuerdo a las

prioridades del Nivel Central y de la comunicación que se mantenga con los encargados de la toma de decisión. Ejemplo: E-learning, por falta de recursos sólo se arrendó la plataforma.

• La elaboración del anteproyecto presupuestario considera la etapa de revisión por varios niveles de decisión, lo cual demora su preparación.

8 Business Process Modeling Notation 9 Fuente: Minutas Técnicas


30


• Para el Subdepartamento de Transporte Público, el análisis de los requerimientos y necesidades de las secciones es complicado, no siempre los jefes de secciones pueden asistir a las reuniones de consolidación de los requerimientos y justificar sus peticiones. Generalmente los jefes se encuentran en terreno y cuesta coordinar una reunión en la cual asistan todos, para suplir este problema, se ejecutan reuniones virtuales.

• Cuando se presentan ítems que no fueron considerados en el presupuesto (requerimientos de emergencia), dificulta mucho incluir o realizar posteriormente la compra.

• El Subdepartamento de Servicios de Aeródromos no tiene control sobre la petición de presupuesto o los presupuestos aprobados a las Regionales. Esto deriva en una poca visibilidad sobre los montos que se manejan en las unidades fuera de Santiago.

Gestión de Requerimientos Fuera de Anteproyecto

Presupuestario

• Tiempos de respuesta prolongados en la gestión y aprobación de los requerimientos solicitados como emergencia por una unidad (requerimientos fuera de presupuesto). Esto deriva en que el requerimiento no sea tratado con la criticidad requerida afectando la ejecución de los procesos al interior de la unidad solicitante.

• Al ser requerimientos no planificados, no siempre se obtienen los recursos necesarios para su implementación, debido a que no se tiene presupuesto disponible para imprevistos.

Problemas Generales del Proceso

• No existe una metodología de apoyo para la ejecución del proceso

Gestión de Requerimientos

• La compra de desarrollo en la DASA no existe, ya que es difícil estimar los requerimientos de un producto con especificaciones técnicas orientadas a la aeronavegabilidad, por lo que se debe trabajar en forma interna con el proveedor hasta generar un producto empaquetado y luego licitar la compra del producto cerrado. Esto deriva en que se está trabajando de acuerdo a la orientación de la unidad y sin un respaldo metodológico de desarrollo de SW.

• La gestión de requerimientos no realiza un control de la evolución de éste durante el desarrollo del proyecto.

• No existe una traza entre los requerimientos que han sido presentados y el proyecto que lo implementa, por lo tanto un Jefe de Proyecto nuevo no tiene visibilidad de las necesidades que dieron origen a la solución implementada.


Planificación de Proyectos

• No existe una metodología de apoyo que formalice las actividades que se realizan, que sirva de guía a los funcionarios existentes o a las nuevas incorporaciones de la DGAC.


31


• Cada Encargado de Informática utiliza una metodología propia para la planificación de los proyectos, lo cual provoca una divergencia de criterios y actividades para la planificación.

Licitaciones

• Falta de participación por parte de la unidad solicitante del requerimiento, en el proceso de licitación (bases, revisión, adjudicación).

• Falta de procedimientos de revisión y análisis de las licitaciones (evaluación de las licitaciones dentro del subdepartamento), lo cual provoca que se seleccionen proveedores de acuerdo al criterio del Nivel Central y sin la visión de la unidad solicitante.

• Al ser definidos los requerimientos por una unidad distinta a la unidad solicitante, estos sufren cambios al ser presentados en las bases técnicas (se desvirtúa el contexto del requerimiento), lo cual conlleva a licitar y adjudicar soluciones que no son las apropiadas para el área solicitante.


Evaluación de Proveedores

• Los tiempos de respuesta del Nivel Central son lentos y no siempre se recibe una respuesta a la petición enviada. Esto genera descontento en las unidades, ya que no se sienten acogidos o apoyados por el Departamento TIC’s.

• No se realizan evaluaciones de proveedores en la DMC, ya que no es solicitado por la D.G.A.C., por lo tanto no se entrega retroalimentación del comportamiento de éste.

• Los contratos no se encuentran difundidos, por lo que no se tiene conocimiento de los términos de exigencia con los proveedores.

• No existen procedimientos formalizados para evaluar a los proveedores, por lo tanto se debe estar realizando consultas a Inspección Fiscal acerca de la documentación a enviar para esta actividad.

• No existe documentación de respaldo en el STP (Subdepartamento Transporte Público) para la evaluación de los Proveedores, por lo que no se almacena un historial o una evidencia de su comportamiento.

Gestión de Riesgos Problemas Generales del Proceso

• No existe una metodología de apoyo para la gestión de riesgos, implicando que cada Jefe de Proyecto administre los riesgos de acuerdo a sus criterios personales, no lográndose una estandarización.

• Los riesgos se evalúan a medida que se van presentando, por lo que no se tienen planes de mitigación o planes de contingencia definidos previamente.

Ejecución y Control de Proyectos Problemas Generales del

Proceso • La etapa de pruebas no se encuentra

formalizada a través de un plan de pruebas actividad específica dentro del ciclo de vida del proyecto.

• La etapa de pruebas no es planificada ni documentada en la DMC, por lo que se


32


desconoce la cantidad de errores corregidos o las soluciones implementadas.

Planificación Inicial del Proyecto

• No se identificaron problemas en este Subproceso

Seguimiento y Control • No se identificaron problemas en este Subproceso

Desarrollo del Proyecto

• El ambiente de pruebas en el STP se realiza en el equipo local del Encargado de Desarrollo. No existe un ambiente formal de pruebas.

• La etapa de Pruebas en la DMC no es planificada ni documentada, por lo que no se tiene retroalimentación de los errores encontrados.

Implantación

• No existen procedimientos formales para el paso a producción, lo cual deriva en que cada Jefe de Proyecto establece los pasos de acuerdo a su experiencia y criterios personales.

Capacitación Usuarios • No se identificaron problemas en este Subproceso

Cierre de Proyecto

• No se realizan reuniones de evaluación de la participación del equipo de proyecto interno de la DGAC, por lo que no se obtiene retroalimentación.

• No se realiza evaluación del proveedor al cierre del proyecto, por lo que no se guarda información del desempeño y servicios entregados.

• No se documenta experiencias o lecciones aprendidas que puedan ser aplicables en un nuevo proyecto.

Administración Infraestructura Tecnológica


Soporte Problemas Generales del Proceso

• No se recibe respuesta desde Nivel Central respecto al problema que fue derivado. Se recibe respuesta sólo en el caso de que exista solución, esto provoca que las unidades no se sientan apoyadas por el Nivel Central.

• Falta de Horas Hombre (no es posible atender los incidentes en el tiempo requerido), lo que deriva en una sobrecarga de trabajo.

• No existe catastro de los incidentes atendidos, por lo que no se pueden realizar estudios de problemas o estadísticas.

• No existe gestión de los niveles de servicios entregados por el proveedor.

• No existe un feedback con las compañías comerciales ni con la empresa externa de soporte (DEIRA), para analizar la calidad de los servicios que están siendo entregados.

• No se realiza cruce de información con el Nivel Central para la verificación de trabajos realizados antes de efectuar el pago de servicios prestados.

• Los incidentes y sus soluciones no son registrados en una base de conocimiento para


33


análisis posteriores. Esto impide poder realizar un análisis de incidencias recurrentes o estadísticas según características.

• El tiempo de respuesta del proveedor es lento, lo cual implica que un usuario puede estar un período de tiempo sin las herramientas necesarias para cumplir con sus funciones. El proveedor Deira demora 1 día en la evaluación del problema para definir las acciones a ejecutar.

Control de Cambios


• No existe respaldo documental del procedimiento de control de Cambios, que sirva de guía a los encargados de informática o a las nuevas contrataciones.

• No existe documentación de los procedimientos de administración de los cambios, por lo que las actividades se realizan de acuerdo al criterio personal del Encargado de Informática.

• No se tiene control de las versiones de Software desarrollados en forma interna, por lo que no se puede analizar los cambios entre una versión y otra.

Capacitación de Funcionarios • No se identificaron problemas en este Subproceso

Políticas, Normas, Procedimientos - Seguridad


• No existe documentación formal de las políticas, normas y procedimientos que rigen los servicios o procedimientos que realizan, sean internas a la unidad o a nivel institucional.

• No se tiene conocimiento si las Regionales realizan sus propios respaldos de sus sistemas locales, no existe un lineamiento con las Regionales en este ámbito.

Tabla 2: Problemas Presentados en Procesos de TI Unidades / Oficinas Informáticas de la DGAC


34

9.2 PROBLEMAS PRESENTADOS EN LOS PROCESOS DE TI – N IVEL CENTRAL DGAC

Procesos de TI Subprocesos Problemas Levantados

Elaboración Anteproyecto Presupuestario

• No existe una integración de presupuesto entre las distintas unidades u oficinas informáticas, por lo que cada una solicita el presupuesto que estime conveniente según sus necesidades operativas.

• No se realiza un control sobre los proyectos tecnológicos que ejecutan todas las unidades u oficinas informáticas de la DGAC (ejemplo, DASA, DMC, etc.). Esto trae como consecuencia el desconocimiento sobre los desarrollos particulares en las dependencias de la DGAC.

• Las personas que tienen más influencia a niveles Directivos son los que logran mayor presupuesto, por lo que la distribución de los presupuestos no es equitativa.

• Los montos del Anteproyecto Presupuestario deben ser similares de un año para el otro. En los casos que existan variaciones significativas, la probabilidad de ser rechazado del Anteproyecto es mayor, Esto provoca que las unidades deban acotar y priorizar sus necesidades.

• Para requerimientos (hardware, software, insumos, otros) que no fueron considerados en el presupuesto inicial de la unidad, se debe realizar la compra en forma directa a través de convenios marcos para agilizar el proceso de solución de la solicitud. Ejemplo: en caso de necesitar un equipo nuevo, se debe utilizar el acuerdo Marco para la compra de repuestos.

• En la fecha que se debe hacer el Anteproyecto Presupuestario, todavía no se cumple la planificación anual, por lo que se deben hacer estimaciones.

• No existe un formato estándar para presentar los requerimientos y necesidades al Director del Departamento TIC’s (formatos por cuentas, por tareas, por actividad, otros). Esto provoca confusión para realizar el análisis por parte de la Dirección.

Administración de la Inversión de TI

Gestión de Requerimientos Fuera

de Anteproyecto Presupuestario

• Demora en la gestión y aprobación de los requerimientos solicitados como emergencia, por lo que no son tratados con la criticidad necesaria para lograr una


35


solución. • Para los proyectos que surgen fuera del

Anteproyecto Presupuestario, se debe conseguir los dineros a través de lobby con las Jefaturas que corresponda, para poder apoyar su realización.

• Si los proyectos están fuera del Anteproyecto Presupuestario, éstos deben esperar el presupuesto del año siguiente, lo cual puede generar una brecha tecnológica entre el requerimiento levantado y el momento de la implementación.

• Priorización de requerimientos de acuerdo a conversaciones entre los Directores de Departamentos involucrados. Ante requerimientos fuera de anteproyecto presupuestario de carácter inmediato, se realizan acuerdos a niveles gerenciales para solucionar las necesidades presentadas por oficinas y/o unidades.

Control Presupuestario • No se identificaron problemas en este

Subproceso. Problemas Generales del Proceso

• Falta de formalización en la asignación de los sistemas entre los funcionarios del Subdepartamento de Soporte TIC’s, no existe un comunicado oficial que informe al funcionario su asignación.

• Falta de recursos humanos, en particular de personal especializado. Ejemplo: Administrador de Base de Datos.


Administración de Requerimientos de HW

y SW

• Retrasos en la entrega de respuesta ante solicitudes de hardware y software derivadas desde las unidades. Para la toma de decisión ante tal solicitud, participan varios actores (ejemplo, Jefe de Subdepartamento, Jefe de Área, Analista, otros.) en el análisis y definición de la respuesta. El tiempo de respuesta promedio es de 1 semana.

• Control y seguimiento de los requerimientos de hardware y software realizado en forma centralizada. Esto provoca sobrecarga de trabajo para la persona que realiza el control y el seguimiento de los requerimientos, implicando una demora en la atención de los requerimientos presentados por los usuarios.

• Los usuarios no están claros en la información que deben presentar a principios de año para formalizar sus necesidades, lo cual trae como consecuencia solicitar requerimientos fuera del Anteproyecto Presupuestario.


36


• La forma de presentar los requerimientos por parte del usuario no es estándar, lo cual dificulta el análisis o priorización de estos (demasiado genéricos, falta de información).

• En la gestión de nuevos requerimientos, sólo a través del Solicitante o el Administrador del Sistema se conoce el estado de avance en el cual se encuentra la implementación del requerimiento.

• El Analista de Sistemas no maneja Carta Gantt del (de los) nuevo (s) requerimiento (s), el Proveedor se entiende directamente con el Solicitante.

• No existe un registro ni documentación formal de los requerimientos recibidos por el Subdepartamento de Soporte TIC’s.

• Generalmente, el Subdepartamento debe asumir los costos de las mantenciones o desarrollos de los requerimientos recibidos.

• Se ha debido contratar servicios de asesoría para resolver algunas funcionalidades y configuración de los servidores.

Planificación de Proyectos

• No existe una metodología de apoyo a la planificación de proyectos, que se pueda utilizar de guía para estandarizar los procedimientos de los jefes de proyecto o que sirva de apoyo para la inducción de personal nuevo.

• Se necesita personal especializado en arquitectura tecnológica con orientación a la unidad de negocio, para cubrir las faltas de conocimiento en esas áreas.

• Existe una alta carga de trabajo entre los funcionarios del Subdepartamento de Soporte TIC’s. Los funcionarios deben ejecutar las tareas asignadas, y en paralelo dar soporte funcional y técnico a los usuarios. (aproximadamente 2500 usuarios a nivel nacional), esto hace que consuman los esfuerzos en la atención de la contingencia diaria.

• Dificultad para asignar las responsabilidades de jefatura de proyectos en el Subdepartamento de Soporte TIC’s, los funcionarios están con sobrecarga de asignaciones.

• Existe una falta de recursos humanos en el Subdepartamento de Soporte TIC’s para cumplir con todas las actividades al interior del subdepartamento.

• No se considera la experiencia de los funcionarios del Subdepartamento de


37


Soporte TIC’s para ajustar el alcance o los requerimientos de los proyectos. En general los proyectos y sus alcances se encuentran previamente definidos al ser recibidos por este Subdepartamento.

Administración de Proveedores Licitaciones

• Demora en tiempo de publicación de las licitaciones por parte de Adquisiciones (puede transcurrir más de 2 meses desde que se envían las bases técnicas hasta que son publicadas en el sitio Mercado Público), lo cual implica una demora en la solución del requerimiento.

• No existe un documento que oficialice las exigencias mínimas que debe cumplir un proveedor para utilizarlo como herramienta de control en las evaluaciones.

• Logística genera calendarizaciones con períodos muy cortos, lo cual no siempre permite realizar las reuniones de aclaración hacia los oferentes y presentación de metodología de los proveedores.

• Cuellos de botella en el área de Adquisiciones, desde que se envían las Bases Técnicas hasta que se realiza la publicación de una licitación. Se debe realizar gestiones personales para apresurar los tiempos de respuesta en ésta área. Incluso, los contratos normalmente tienen que ser retirados directamente de Adquisiciones.

• Si la demora en los plazos es muy extenso, genera un impacto directo en los tiempos del proyecto. La ejecución del contrato se realiza el año siguiente y se debe devengar las facturas por los montos de dinero relacionados que no se ejecutaron durante el año. Esto último es para no afectar la petición del Anteproyecto Presupuestario del año siguiente.

• Falta personal idóneo para apoyar el proceso de las licitaciones.

• Para algunos sistemas el código fuente es del proveedor, lo cual impide licitar sus mantenciones o modificaciones con otras empresas proveedoras.

• Falta de participación del Subdepartamento de Soporte TIC’s en las licitaciones. El Subdepartamento de Soporte no interviene en el levantamiento de los requerimientos y posterior generación de la Licitación. En particular no siempre participa en la elaboración de


38


las bases técnicas y evaluaciones de las propuestas. Este problema depende de la pertenencia del contrato. Es decir, el Subdepartamento responsable de implementar la licitación es quien participa más activamente en el proceso.

• En las adjudicaciones de proveedores, a veces prima sólo la oferta económica (de menor costo) y no la oferta técnica, lo cual va en desmedro de la calidad del servicio a implementar.

Administración de Contratos



• No existen definiciones claras y formales de los niveles de servicios que el proveedor debe cumplir.

• No existe un historial de evaluaciones de proveedores, lo cual implica que al momento de realizar evaluaciones para una licitación, no se tenga evidencia del comportamiento. Esto además influye en el traspaso del conocimiento respecto de un proveedor a futuros o nuevos integrantes del equipo.

• No existe una ficha institucional estándar para evaluar a los proveedores, principalmente se conversan problemas sostenidos con ellos, no conformidades, incumplimientos.

• No se encuentra estandarizado el control de niveles de servicio hacia los proveedores.

• No se genera evidencia sobre los problemas que se ha tenido con algún proveedor.

• No existe una metodología transversal formalizada de evaluación de los proveedores dentro del área de Desarrollo.

• La evaluación de proveedores entre el Jefe de Subdepartamento Soporte TIC’s y el Jefe de Proyecto se realiza en forma verbal, no existe un documento asociado a la reunión de evaluación. No se genera documentación interna al Subdepartamento de Soporte TIC’s asociada a las evaluaciones de los proveedores.

• No existe una retroalimentación con la unidad de Inspección Fiscal, donde se señale el ranking de proveedores de acuerdo a sus evaluaciones.

• No existe una evaluación del desempeño de los proveedores que cuentan con contrato de cantidad de horas de


39


desarrollo y mantención mensuales. Sólo se les evalúa a fines de mes antes de cursar el pago.

• No existe una definición de los niveles de servicio para cada servicio solicitado que deban cumplir los proveedores, sólo se basan en las condiciones exigidas en las bases técnicas.

• No contar con la documentación formal para controlar fechas de hitos, evaluar el desempeño del proveedor, En particular el Jefe de Proyecto al no contar con el contrato firmado con el proveedor, debe revisar las bases técnicas para exigir las condiciones contratadas. En las bases técnicas no aparecen fechas del contrato, lo cual complica evaluar el cumplimiento de los plazos indicados.

Problemas Generales al Proceso

• La evaluación de riesgos se realiza en la marcha del proyecto, identificando los riesgos a medida que se van presentando. Esto implica que los riesgos se trabajan en forma reactiva y los planes de contingencia se deben generar al momento de la materialización del riesgo.

• No existe un documento oficial de respaldo del seguimiento de los riesgos que se presentan, el líder de proyecto manifiesta las exigencias en forma verbal al proveedor y se respaldan vía mail.

• La estructura rígida de la institución (estructura Organizacional) dificulta la exigencia y control del cumplimiento de tareas hacia los usuarios, asociadas a cada etapa del proyecto.

• No existe una metodología de guía para el control de los riesgos para los Jefes de Proyecto (nuevos o antiguos), esto aumenta la probabilidad de que los proyectos no lleguen a buen término. En particular, genera retrasos significativos, incumplimiento de etapas o hitos, disminución de la calidad de los entregables, entre otros.

• No se tiene formalizada una metodología de evaluación y seguimiento de riesgos para los proyectos al interior del Subdepartamento, lo que deriva en un trabajo más reactivo que proactivo.

Análisis de Riesgos • Se identificaron problemas transversales

(Ver problemas generales al proceso)

Gestión de Riesgos

Realización de Planes de Mitigación

• Se identificaron problemas transversales (Ver fila de problemas generales al proceso)


40


Ejecución y Control de Proyectos Problemas Generales al

Proceso

• El control de los retrasos del proveedor se realiza en forma tardía y reactiva.

• No existe una metodología transversal de apoyo al proceso, que guíe a las personas que se integran por primera vez a la institución.

• Soporte TIC’s no ve los problemas en forma transversal, si no que los ve desde su perspectiva de Subdepartamento. Esto puede llegar a producir desconocimiento de las soluciones existentes al interior de un área.

• El Subdepartamento de Soporte TIC’s no cuenta con las habilidades necesarias para realizar algunas tareas de mantención, ejemplo, análisis de requerimientos o diseño de solución, impidiendo realizarlas en forma interna, aumentando el gasto en contrato de proveedores.

• Deficiencia en la definición de la participación e intervención que tendrá el Subdepartamento Soporte TIC’s en proyectos pertenecientes a otros Departamentos. En ocasiones el alcance de la asesoría o apoyo que brinda el subdepartamento de soporte a proyectos de otras unidades se encuentra fuera de sus competencias profesionales.

• Dificultad para apoyar y ejecutar proyectos pertenecientes a otras unidades de la DGAC. En este contexto, el desconocimiento del negocio de la unidad dueña del proyecto y además el hecho de recibir responsabilidades fuera del contexto de soporte, (mencionado en problema anterior) dificulta la ejecución de los proyectos. (ejemplo, apoyo a sistema de Recursos Humanos) al Subdepartamento de Soporte TIC’s.

• La unidad solicitante envía los requerimientos al Subdepartamento Soporte TIC’s a través de Oficios. De esta forma, los solicitantes asumen que la responsabilidad en la ejecución del proyecto recae en el Subdepartamento Soporte TIC’s y se desentienden de la responsabilidad como área mandante. Esto ocurre generalmente cuando el requerimiento involucra incrementos mayores, los cuales deberán ser necesariamente pagados por no estar contempladas en los contratos de mantención, o cuando se sabe que el requerimiento no se puede realizar ya sea por tiempo, presupuesto, otros.


41


• Algunos sistemas desarrollados no han podido ser instalados en la plataforma de la D.G.A.C. (Soporte no ha identificado la causa), debiendo instalarse en otro servidor fuera de la plataforma (Remuneraciones).

• Existen problemas de desempeño de las aplicaciones para los usuarios que trabajan conectados a través de Wifi, ya que la red inalámbrica no ofrece una conexión estable.

• Algunos Departamentos (ejemplo Finanzas) no desean cambiar su proveedor, ya que se asume que otro proveedor tendrá un alto costo en conocer y mantener el sistema existente.

• No existen procedimientos formales para realizar las tareas de Mantención de Sistemas.

• No existe un documento formal que indique las modificaciones a sistemas realizadas por los proveedores.

• Los cambios de proveedores, producto del término de vigencia del contrato, provocan descontento y molestias entre los usuarios de la DGAC (ejemplo, cambio de proveedores de equipos multifuncionales), dado la existencia de un período de acomodación.

• Falta de manuales de usuarios para los sistemas implementados.

• Falta de Administrador de Base de Datos.

Planificación Inicial de Proyecto

• El Subdepartamento de Soporte TIC’s no participa en el análisis de los requerimientos y planificación de los proyectos que a futuro se deben implementar, sólo participa en la etapa de licitación como ayuda para la definición de las bases técnicas. Esto impide mejorar la planificación anual de los proyectos dentro del Subdepartamento, ya que a medida que se le asignan proyectos, debe modificar su planificación y priorización anual de proyectos.

• No existe una metodología estandarizada para gestionar y evaluar los proyectos, lo que implica que cada Jefe de Proyecto ejecuta las actividades de planificación de acuerdo a su experiencia.

• En la planificación de los proyectos, el Subdepartamento de Gestión TIC’s es el encargado de evaluar y elegir al proveedor adjudicado, y el Subdepartamento de Soporte TIC’s es el encargado de ejecutar el proyecto. El problema radica en que no


42


se participa en la evaluación del proveedor y posteriormente se debe asumir la ejecución de un proyecto ya definido.

Control y Seguimiento

• Los Jefes de Proyectos pertenecientes al Subdepartamento de Soporte TIC’s mantienen una alta carga de trabajo, lo cual dificulta el control y seguimiento de los proyectos.

• Existe un déficit de profesionales en el Subdepartamento de Soporte TIC’s. En la actualidad trabajan 2 funcionarios especialistas en el área de soporte y mantención.

• En determinadas situaciones, el retraso de los pagos a los proveedores implica un retraso en el desarrollo del proyecto.

• Las cargas de trabajo de los Jefes de Proyecto del Subdepartamento de Soporte TIC’s no permiten que se realice todos los controles y documentaciones que se requieren.

Control de Calidad

• No existe una metodología de apoyo para el control de calidad, lo cual deriva en que cada Jefe de Proyecto ejecute sus propias actividades para controlar la calidad del producto, en base a su experiencia.

• Falta de equipos adecuados para ser utilizados como servidores de prueba en el Subdepartamento de Soporte TIC’s, lo cual no permite disponer de un ambiente de pruebas adecuado para revisar los productos del proveedor.

• Demora de los proveedores en dar respuesta satisfactoria a los nuevos requerimientos derivados del control de calidad.

• No existen niveles de servicio o metodología de desarrollo para exigir al proveedor, éste desarrolla bajo sus estándares y nomenclaturas propias.

Implantación

• No existen procedimientos formales para el paso a producción.

• No hay metodología de apoyo que establezca una documentación, puntos de retorno o certificaciones del producto instalado.

• No hay documentación de respaldo de la autorización y responsables para el paso a producción.

• No existe un procedimiento oficial para implantar nuevos sistemas o productos en ambiente de producción, lo que deriva en que se avisa con poco tiempo o a último minuto la liberación de un producto.

• Los casos urgentes DEBEN implantarse,


43


implicando una reorganización de los servidores apresuradamente, lo cual puede provocar disminución de su desempeño.

• Existen restricciones de tiempo para implantar los sistemas o hardware. Por norma la plataforma no puede tener períodos de desconexión durante la última semana del mes y la primera semana del mes siguiente, sólo existen dos semanas al mes para realizar las implantaciones masivas.

• No existe un análisis formal del impacto que puede producir la implantación de un sistema en la plataforma de la DGAC. Esta es una falencia del proveedor y que el área de desarrollo no está controlando.

Capacitaciones Usuarios

• No existen metodologías para: - Realizar evaluación de los perfiles profesionales - Identificar las brechas (en términos de competencias profesionales) que pueda tener un funcionario. - Análisis de planes de acción para la nivelación de conocimientos y corrección de brechas.

Cierre de Proyecto

• Falta una metodología de apoyo a la etapa de cierre de los proyectos en el Subdepartamento de Soporte TIC’s, lo cual facilitaría a los funcionarios que no tiene experiencia en la dirección de proyectos.

• No existe un documento asociado a la evaluación de proveedores en el Subdepartamento de Soporte TIC’s, ésta es realizada de manera verbal.

• Los cierres de proyectos son una debilidad en el Subdepartamento de Soporte TIC’s. En la actualidad cuesta que los usuarios asuman los cierres de proyectos.

Análisis de Infraestructura Tecnológica

• El subdepartamento de soporte TIC's no cuenta con una metodología para realizar la administración de la infraestructura tecnológica

• Respecto a la gestión de capacidades, no hay una planificación de crecimiento de la infraestructura, específicamente de la capacidad de los servidores.

Dimensionamiento de Plataforma


Administración de Infraestructura Tecnológica

Proyección de Crecimiento de la

Plataforma


Soporte Problemas Generales al

Proceso

• No existe un procedimiento estandarizado para recibir y dar curso a los requerimientos de soporte, por lo que los requerimientos son recibidos desde la


44


Mesa de Ayuda o directamente desde los usuarios.

• No se respeta el procedimiento o los canales de comunicación formales para requerir soporte de segundo nivel (soporte especializado en funcionalidad de una herramienta específica), muchas veces los usuarios se saltan la Mesa de Ayuda.

• Los usuarios presentan los incidentes por múltiples canales (tanto a la Mesa de Ayuda, como a la Unidad de Soporte y Mantención), para lograr una atención rápida. Esto implica recibir más de una vez el mismo requerimiento.

• Las peticiones son presentadas con carácter urgente por funcionarios con un alto rango dentro de la DGAC, lo cual exige solucionar de inmediato el problema, provocando una alteración en la priorización de los requerimientos a solucionar.

• Generalmente el soporte de primer nivel (Soporte de HW o SW básico) no es atendido por la mesa de ayuda de DEIRA. Estos son derivados directamente al área de Plataforma de Servidores.

• No existe un procedimiento para realizar el monitoreo de la red, tanto interna como externa al Nivel Central.

• En la actualidad, no existe claridad en la definición de los servicios que debe proveer el Departamento TIC’s. Se han asumido responsabilidades de manera informal, por ejemplo, la atención de requerimientos de redes.

• Ante algunas necesidades de soluciones técnicas para desarrollar sus labores, los usuarios no cuentan con un interlocutor válido en el Subdepartamento de Soporte, por la falta de capacidades técnicas requeridas.

Control de Cambios


• No existe un orden para la gestión de los ítems de configuración. Algunos documentos electrónicos son publicados en la Intranet, otros los almacena el Jefe de Proyecto y otros se encuentran almacenados en carpetas físicas.

• No se cuenta con una metodología de apoyo para la trazabilidad de versiones de SW, esto deriva en que cada Jefe de Proyecto lleva sus propias políticas de versionamiento.

Capacitación a Funcionarios


• El Subdepartamento de Soporte TIC’s no cuenta con expertos en el área del negocio. Esto se debe a la rotación que


45


existe al interior del Subdepartamento y a la no existencia de un programa de desarrollo profesional.

• Existe un proceso estructurado y formal para solicitar las capacitaciones, pero no se cumple.

• Las decisiones sobre los cursos solicitados las toman personas que tienen otras prioridades.

• Las especializaciones o capacitaciones de novedades en el ámbito de las TIC’s deben ser atendidos en forma personal, ya que no son prioridad para la Institución.

• Las capacitaciones de los funcionarios del Subdepartamento de Soporte TIC’s han sido muy pocas. La razón se debe a que los cursos que requiere el personal interno al subdepartamento son caros.

• El Subdepartamento de Soporte TIC’s no cuenta con personal experto. Falta contar con capital humano con mayores competencias.

• Es necesario definir una base mínima de competencias mayor a la que existe hoy al interior del Subdepartamento de Soporte TIC’s. En este contexto, la escala de sueldos bajo impide contratar a gente experta.

• El nivel de peticiones aprobadas desde RRHH es muy bajo y los requerimientos de cursos no se concretan, debido a lo anterior, se solicitan cursos de especialización como parte del programa de actividades del proveedor. Estos cursos son de mala calidad y no cumplen con las expectativas de especialización de los funcionarios del Subdepartamento.

• Si las capacitaciones no son consideradas en los programas de un año para el otro, es difícil conseguirlas en forma extra al presupuesto.

• La asignación de cursos entre los Subdepartamentos (Soporte y Gestión) no son equitativos, ya que en Gestión TIC's hay funcionarios cursando Diplomados y en Soporte no hay ningún curso de esas características aprobado.

• Los funcionarios del Subdepartamento de Soporte TIC’s no tienen definición de cargos o funciones en sus contratos, por lo que no se tiene formalizado cuales son las responsabilidades y capacidades que debería tener cada funcionario.

• Algunos funcionarios del Subdepartamento de Soporte TIC’s no tienen experiencia en


46


la gestión de proyectos, no manejan todas las actividades que conlleva la dirección de un proyecto (ejemplo, manejo de presupuestos, evaluar condiciones contractuales, otros), por lo que puede derivar en demoras o errores en la ejecución del proyecto.

Políticas, Normas y Procedimientos

• Se desconoce donde quedan archivadas las políticas, normas y procedimientos que han sido publicadas, pero deberían ser guardados por Secretaría General de la DGAC.

• No existe un Comité para la revisión de las políticas, procedimientos o normas, por lo que las políticas se definen de acuerdo a la experiencia de los miembros del Subdepartamento de Gestión TIC’s.

• Falta de políticas, normas y procedimientos en el Subdepartamento de Soporte TIC’s, para esto se están esperando los resultados de la auditoria interna efectuada y en base a los resultados, establecer planes de acción.

• La definición de políticas de TI no obedece a un proceso formal. Estas definiciones no siempre son documentadas.

• No existe la seguridad de que las políticas, normas y procedimientos son difundidas y recibidas en toda la organización.

• El actual Departamento TIC’s no tiene participación en la toma de decisiones respecto a las acciones a realizar en los departamentos / subdepartamentos / secciones, producto de las inconformidades levantadas en las auditorias internas.

• En los Subdepartamentos, principalmente existen políticas de TI informales las cuales son traspasadas en forma verbal entre los funcionarios.

• No existen políticas de seguridad ni de normalización de las bases de datos (por ejemplo, nombres de tablas, de campos, entre otros), implicando un alto tiempo de respuesta cuando se presenta algún problema en ellas.

Políticas, Procedimientos,

Normas - Seguridad

Respaldos • No se identificaron problemas en este

Subproceso

Tabla 3: Problemas en Procesos de TI Presentados en DGAC Nivel Central


47

10 Diagnóstico de los Procesos y Propuesta de Mejor as asociados a las actividades de TI.

Para realizar el diagnóstico de los procesos asociados a las actividades de TI, se realizaron las siguientes tareas:

a. Se compararon los modelos de procesos de las actividades de TI con las mejores prácticas y la experiencia de SOAInt TUXPAN, para realizar una clasificación de los procesos de acuerdo al siguiente esquema:

� Procesos existentes en la actualidad que cumplen con lo establecido en los estándares

� Procesos existentes en la actualidad que deben ser modificados en su estructura para adecuarse a los estándares

� Procesos no existentes en la actualidad que sería recomendable incorporar para reforzar las actividades informáticas

b. Se especificaron los aspectos que deben ser modificados de los procesos existentes para adecuarse a los estándares.

c. Se especificaron las características de los procesos nuevos que sería recomendable incorporar.

d. Finalmente, se estableció un cronograma de corto y mediano plazo para la implementación de las mejoras a los procesos.

10.1 CLASIFICACION DE LOS PROCESOS Para poder establecer la brecha existente en la forma en que se llevan a cabo las actividades de TI en las diferentes Unidades y Oficinas Informáticas de la DGAC, éstas fueron comparadas con las mejores prácticas (mencionadas en el Punto 7: Procesos de TI) en relación a este tipo de procesos, además de la experiencia de SOAInt TUXPAN en relación a implementaciones de mejoras en actividades informáticas.

La definición de las prácticas de mercado que se utilizaron son las siguientes:

• CMMI: Modelo de referencia de prácticas usadas para evaluar y mejorar la capacidad de los procesos, el cual incluye una ruta evolutiva de implementación de las mejores prácticas en los procesos organizacionales.


48

• ITIL: Metodología para la gestión de servicios de Tecnologías de

Información que recopila las mejores prácticas tanto del sector público como del sector privado. Estas mejores prácticas se dan en base a toda la experiencia adquirida con el tiempo en determinada actividad, y son soportadas bajo esquemas organizacionales complejos, pero a su vez bien definidos, y que se apoyan en herramientas de evaluación e implementación.

• COBIT: Marco aceptado internacionalmente como una buena práctica

para el control de la información, TI y los riesgos que conllevan. Se utiliza para implementar el gobierno de TI y mejorar los controles de TI. Contiene objetivos de control, directrices de aseguramiento, medidas de desempeño y resultados, factores críticos de éxito y modelos de madurez.

De acuerdo a estas prácticas, se realizó la siguiente clasificación:

10.1.1 PROCESOS QUE CUMPLEN CON LO ESTABLECIDO EN L OS ESTANDARES

Como resultado del análisis de los procesos levantados en las Unidades / Oficinas de Informática y en el Nivel Central, no se encontraron procesos que cumplan totalmente con lo establecido en los estándares. Lo anterior no implica que los procesos estén incorrectos, si no que poseen las desviaciones y falencias propias de haber surgido como resultado de la experiencia particular de la DGAC en la ejecución de sus tareas operativas y no como parte de la aplicación de un marco de trabajo definido y estructurado.


49

10.1.2 PROCESOS A MODIFICAR PARA ADECUARSE CON LOS ESTANDARES

Los siguientes procesos deben ser modificados en su estructura para adecuarse a los estándares:

PROCESO SUBPROCESO ASPECTOS A MODIFICAR

Elaboración Anteproyecto Presupuestario

• El presupuesto de la DGAC en el ámbito TIC’s, debe reflejar todas las inversiones y gastos en los cuentas presupuestarias adecuadas, esto incluye al Departamento TIC’s y a las Unidades/Oficinas.

Gestión Requerimientos fuera del Anteproyecto Presupuestario

• Se debe incorporar un proceso para gestionar los proyectos que surgen durante el año y que, por lo tanto no están incluidos en el presupuesto vigente. Este proceso debe incorporar actividades de estimación de presupuesto para requerimientos de emergencia con comportamiento conocido. Por ejemplo: financiamiento para HW y SW base, mantenciones de emergencia.

Administración de la Inversión

de TI

Control Presupuestario

• Se debe incorporar un proceso para verificar el cumplimiento presupuestario en forma real y generar estadísticas para analizar su ejecución anual, debe considerar actividades de análisis de eficiencia en la utilización de los recursos y benchmarking de proyectos.


Administración Requerimientos HW, y SW

• Generación de una metodología de Gestión de Requerimientos. Este proceso debe considerar las actividades de levantamiento de requerimientos desde el origen (Usuarios Finales, Unidades, Departamento TIC’s), análisis de factibilidad técnico y económico, seguimiento de implementación del requerimiento.

• Generación y definición de la calendarización para la incorporación de modificaciones.


50


Planificación de proyectos

• Se debe incorporar un proceso estructurado y estándar para la planificación y control de los proyectos, de manera de contar con parámetros similares de definición, evaluación y establecimiento de hitos, además debe velarse por la incorporación de Políticas, normas y procedimientos TIC de la DGAC como requisitos a cumplir.

• Se debe crear y dar mantenimiento a un marco de trabajo de administración de riesgos. El marco de trabajo documenta un nivel común y acordado de riesgos de TI, estrategias de mitigación y riesgos residuales acordados.

Licitaciones

• Se debe incluir un proceso para tomar conocimiento a nivel central de las licitaciones en curso relacionadas con la incorporación de TIC a la DGAC.

• Incorporación de participantes de Subdepartamento de Gestión TIC’s y Soporte TIC’s en el Proceso de Licitaciones para establecer un trabajo colaborativo y facilitar la comunicación de nuevas iniciativas.

• Establecimiento de un calendario de licitación con acuerdo entre las partes para la realización de actividades complementarias a la evaluación de proponentes.


Administración de Contratos

• Se debe incluir un proceso de gestión de los Contratos asociados a las TIC’s para verificar que se incluyan cláusulas específicas como Confidencialidad, Integridad, Protección de activos, etc., así como la especificación detallada de obligaciones del proveedor asociadas a sanciones en caso de incumplimiento con lo establecido.

• Incorporación de actividades de difusión de los contratos suscritos hacia el personal que corresponda. Ejemplo: Difundir los niveles de servicios definidos por contrato de soporte hacia los usuarios finales.


51



• Debe existir un proceso estructurado, formal y permanente de evaluación de proveedores en función de su cumplimiento, calidad e idoneidad.

• Desarrollo de una base de conocimiento con la experiencia y resultados obtenidos con todos los proveedores del Departamento TIC’s, dentro de un periodo de tiempo previamente determinado. Este repositorio debe considerar: Nombre de Proveedor, Proyecto asociado, periodo, Evaluación, Justificación.

Análisis de Riesgos

Gestión de Riesgos

Realización de Planes de mitigación

• Se debe crear y dar mantenimiento a un marco de trabajo de administración de riesgos. El marco de trabajo documenta un nivel común y acordado de riesgos de TI, estrategias de mitigación y riesgos residuales acordados.

• Generación de una metodología de evaluación y seguimiento de riesgos para todos los proyectos del departamento TIC’s. Este proceso debe considerar identificación de riesgos, determinación de probabilidad de ocurrencia, acciones de mitigación y planes de contingencia en caso que el riesgo se materialice.

Planificación Inicial del Proyecto

• Se debe estandarizar las actividades de inicio de proyecto, que se realizan actualmente al interior del subdepartamento de Gestión TIC’s, para todos los proyectos que se lleven acabo dentro de la DGAC, es decir desarrollos, consultorías, mantenciones, HW.

Ejecución y Control de Proyectos

Control y Seguimiento

• Incorporación de herramientas de apoyo para el control de proyectos.

• Establecer estándares asociados a la documentación de compromisos relacionados con el Proveedor.


52


Control de Calidad

• Se debe elaborar y mantener un sistema de administración de calidad, el cual incluya procesos y estándares probados de desarrollo y de adquisición. Esto se facilita por medio de la planeación, implantación y mantenimiento del sistema de administración de calidad, proporcionando requerimientos, procedimientos y políticas claras de calidad. Los requerimientos de calidad se deben manifestar y documentar con indicadores cuantificables y alcanzables. La mejora continua se logra por medio del constante monitoreo, corrección de desviaciones y la comunicación de los resultados a los interesados. El proceso debe contemplar la solicitud de programación de pruebas unitarias, pruebas integradas y pruebas de integración con otros sistemas.

Implantación

• Estructurar y formalizar un proceso que norme las actividades relacionadas con paso a producción, definición de responsabilidades asociada a cada uno de los roles así como sus limitaciones y atribuciones.

• Definir, estructurar y restringir los ambientes de desarrollo, pruebas y producción.

• Incorporar actividades de certificación de productos liberados en ambiente de producción.

Capacitación (usuarios finales)

• Se debe concretar un proceso que norme los aspectos a ser cubiertos en las capacitaciones a los usuarios finales, de manera de estandarizar el alcance, cobertura, medios de apoyo y metodologías de enseñanza a utilizar.

• Formalizar y estructurar las capacitaciones de usuario a través de:

o sesiones programadas con insumos como pizarra, equipo, otros.

o Presentaciones de introducción, manuales de usuario, ejercicios


53

PROCESO SUBPROCESO ASPECTOS A MODIFICAR prácticos.

Cierre de Proyecto

• Incorporar actividades de evaluación del equipo interno que participo en el desarrollo del proyecto, evaluación del desempeño del proveedor, identificación de lecciones aprendidas.

• Generación de una base de conocimiento de lecciones aprendidas para que sirva de apoyo a próximos proyectos en el Departamento TIC’s.

Análisis de Infraestructura Tecnológica

Dimensionamiento Plataforma

Proyección Crecimiento de la Plataforma

• Generación de una metodología de Gestión de la Disponibilidad. Este proceso está orientado a diseñar, implementar, medir y administrar la infraestructura de TI para asegurar el cumplimiento de los requerimientos de la Institución.

• Generación de una metodología de Gestión de la Capacidad. Este proceso está orientado a garantizar que la infraestructura de TI satisface la demanda de capacidad del procesamiento actual y proyectado para el negocio de la Organización.

• Generación de una metodología de Gestión de Continuidad. Este proceso corresponde a la recuperación de los servicios críticos y de soporte de la organización dentro de un límite de tiempo previamente establecido.

Administración de

infraestructura tecnológica

Definir y administrar los niveles de servicio

• Establecer un proceso para contar con una definición documentada y un acuerdo de servicios de TI y de niveles de servicio, que hagan posible una comunicación efectiva entre la Nivel estratégico de TI y los clientes de negocio respecto de los servicios requeridos. Este proceso también incluye el monitoreo y la notificación oportuna a los participantes sobre el cumplimiento de los niveles de servicio.

Soporte • Se debe contar con canales centralizados y coordinados de recepción

de requerimientos de soporte, de manera de gestionar el proceso de respuesta y de análisis de las situaciones recurrentes para determinar origen y establecer posibles mecanismos de corrección que permita


54

PROCESO SUBPROCESO ASPECTOS A MODIFICAR configurar una Mesa de Servicios que de soporte a todos los servicios críticos de la Organización como:

o HW y SW Base o SW Operativo

• Documentar los incidentes Reportados por los usuarios para obtener una base de conocimientos que disponibilice la entrega de soluciones.

Administrar los problemas

• Establecer un proceso para una efectiva administración de problemas, sobre la base de la identificación y clasificación de problemas, el análisis de las causas desde su raíz, y la resolución de problemas. El proceso de administración de problemas también incluye la identificación de recomendaciones para la mejora, el mantenimiento de registros de problemas y la revisión del estatus de las acciones correctivas.

Control de Cambios

• Generación de Metodología de Control de Configuración. Este proceso debe considerar identificación de ítems de configuración (documentación, sw, hw, otros) que deben ser controlados, establecimiento de nomenclaturas para el control de versiones, definición de estructuras para repositorios documentales y clasificación de activos físicos, definición de criterios para la generación de requerimientos de cambio.

Capacitación de

Funcionarios

• La Capacitación del personal TIC debe enmarcarse en una especificación de perfiles, evaluación de competencias y establecimiento de brechas en relación a lo requerido para la ejecución de las actividades que le han sido asignadas.

• Generar procedimientos de solicitudes de cursos de especialización que garanticen la asignación continua y equitativa de capacitaciones para el personal del Departamento TIC’S.

• Definición de actividades de nivelación de conocimiento por grupos de usuarios del Departamento TIC’s.

Políticas, Normas y

Procedimientos - Seguridad

Políticas, Normas y Procedimientos

• Verificación de políticas de seguridad actuales con respecto a los estándares ISO 17799.

• Se deben realizar los esfuerzos para implementar las Políticas de seguridad definidas en la organización, de manera que sean aplicadas de manera consistente y homogénea tanto al interior del Departamento TIC como en toda la DGAC.


55


Respaldos

• Se debe verificar la concordancia de los procedimientos de respaldo establecidos con lo establecido en las políticas, normas y procedimientos.

Tabla 4: Procesos que deben ser modificados


56

10.1.3 PROCESOS / SUBPROCESOS RECOMENDABLES DE INCO RPORAR

Los siguientes procesos y/o subprocesos no existen en el actual Departamento TIC’s, los cuales recomendamos incorporar para reforzar las actividades informáticas: Disciplina Asociada

PROCESO SUBPROCESO ASPECTOS / CARACTERISTICAS A

INCLUIR

CMMI Planificación Estratégica

Generar Plan Estratégico de TI

• Incorporar un proceso sistemático, con participación de los representantes de las unidades y de la Dirección de la DGAC, para la definición de un Plan estratégico de TI que permita administrar y dirigir todos los recursos y servicios críticos de TI de acuerdo con la estrategia del negocio y sus prioridades.

ITIL Definición de arquitectura

• Establecer un proceso que permita definir un Modelo de información de negocio (Diccionario corporativo de datos, el esquema de clasificación de datos y los niveles de seguridad) y definir los sistemas necesarios para optimizar el uso de esta información.

• Establecimiento de la Arquitectura lógica que debe ser utilizada como marco de desarrollo para los productos entregados por los proveedores. Debe contemplar plataforma de desarrollo a utilizar, patrones de diseño que deben ser considerados, arquitectura empresarial de la organización (3 capas, 4 capas, otros), motor de base de datos.

• Establecimiento de la Arquitectura física de la organización. Debe considerar plataforma de HW y SW base para los usuarios finales, catastro de los activos físicos existentes, configuración de servidores. configuración de la red, identificación de la ubicación de filtros contra intrusos, otros.

Cobit/CMMI Definición de

Orgánica Institucional

• Establecer un proceso que permita definir una organización de TI tomando en cuenta los requerimientos de personal, funciones, delegación, autoridad, roles, responsabilidades y supervisión.

Cobit

Promoción de

Lineamientos Gerenciales

de TI

• La dirección debe elaborar un marco de trabajo de control empresarial para TI, y definir y comunicar las políticas. Un programa de comunicación continua se debe implantar para articular la misión, los objetivos de servicio, las políticas y procedimientos, etc., aprobados y apoyados por la dirección. El proceso debe garantizar el cumplimiento de las leyes y reglamentos relevantes.

Cobit Distribución de Costos

• Establecer un proceso para cubrir la necesidad de un sistema justo y equitativo para asignar costos de TI al negocio, esto requiere de una medición precisa y un acuerdo con los usuarios del negocio sobre una asignación justa. Este proceso


57

Disciplina Asociada

PROCESO SUBPROCESO ASPECTOS / CARACTERISTICAS A

INCLUIR incluye la construcción y operación de un sistema para capturar, distribuir y reportar costos de TI a los usuarios de los servicios.

ITIL/ Cobit Operación

• Establecer un proceso de operación que consideré una efectiva administración del procesamiento de datos y del mantenimiento del hardware. Este proceso incluye:

o la definición de políticas y procedimientos de operación

o protección de datos de salida sensitivos, o monitoreo de infraestructura o mantenimiento preventivo de hardware.

Monitorear y evaluar el desempeño de TI

• Establecer un proceso para una efectiva administración del desempeño de TI basada en un proceso de monitoreo. El proceso incluye la definición de indicadores de desempeño relevantes, reportes sistemáticos y oportunos de desempeño y tomar medidas expeditas cuando existan desviaciones. ITIL/ Cobit Monitoreo

Monitorear y evaluar el control interno

• Este proceso incluye el monitoreo y el reporte de:

o las excepciones de control de las actividades de TI,

o resultados de las auto-evaluaciones10 en relación al control interno de TI

o revisiones por parte de terceros del control interno de TI (Auditorías)

Cobit Garantizar el cumplimiento

regulatorio

• Una supervisión efectiva del cumplimiento regulatorio requiere del establecimiento de un proceso independiente de revisión para garantizar la observancia de las leyes y regulaciones incluyendo los requisitos gubernamentales. Este proceso incluye la definición de un estatuto de auditoria, independencia de los auditores, ética y estándares profesionales, planeación, desempeño del trabajo de auditoria y reportes y seguimiento a las actividades de auditoria.

Cobit Proporcionar gobierno de

TI

• El establecimiento de un marco de trabajo de gobierno efectivo, incluye la definición de estructuras, procesos, liderazgo, roles y responsabilidades organizacionales para garantizar así que las inversiones empresariales en TI estén alineadas y de acuerdo con las estrategias y objetivos empresariales.

Tabla 5: Procesos que deben ser incorporados

10 Se entiende por auto-evaluaciones la aplicación periódica de un cuestionario que incluya las principales áreas de riesgo TIC’s para determinar la situación actual. Éste debe ser completado por el personal del Departamento TIC’s.


58

11 Cronograma de corto y mediano plazo para la incorporación de las mejoras y modificaciones a los procesos.

A continuación se presenta un cronograma estimado de los proyectos a ser implementados tanto a corto como mediano plazo en la DGAC:

N° Proyecto Plazo de implementación

Dependencia Proceso/Subproceso relacionado

Tipo de Proyecto 11

1 Elaborar catastro de toda la configuración actual de la DGAC en relación a : � Hw básico � Sw Básico � Aplicaciones � Servidores

Primer trimestre 2009 No Definición de Arquitectura

I

2 Elaborar catastro de todos los proyectos relacionados con TIC que se estén llevando a cabo en la DGAC

Primer trimestre 2009 No Promoción de Lineamientos gerenciales de TI

I

3 Concretar la definición organizacional del Departamento TIC, incluyendo el nombramiento formal del Director TIC y Jefaturas de Sub Departamentos

Primer trimestre 2009 No Definición de orgánica institucional

I

4 Revisar, complementar y formalizar una Estrategia de TI

Primer semestre 2009

No Planificación estratégica/Generar Plan estratégico de TI

M

5 Establecer los procedimientos que normen la forma en que deben ser incorporados los componentes de Hw y Sw básico a la DGAC


Proyecto 1 Administración de proyectos /Administración Requerimientos Hw, Sw

M

6 Establecer los procedimientos para capturar las necesidades en relación a nuevos proyectos TIC, evaluarlos y priorizarlos dentro de la cartera de proyectos ya establecidos


Proyectos 1 y 2

Administración de proyectos/ Administración Requerimientos HW, y SW/ Planificación de proyectos

M

7 Formalizar los procedimientos asociados a las actividades del Departamento TIC, incorporando las definiciones de los proyectos de mejoramiento ya en curso como Seguridad de la Información


Proyecto 4 Se aplica a todos los procesos

8 Definir arquitectura organizacional que sea la base para integrar lo existente y a la que deben adecuarse los nuevos proyectos

Segundo semestre 2009

Proyecto 4 Definición de arquitectura I

11 I: Implantación, M: Modificación


59



Tipo de Proyecto 11

9 Definir roles y funciones asociadas a los profesionales del Departamento TIC


Proyecto 3 Definición de Orgánica institucional I

10 Se debe establecer una Política de Seguridad a partir de las definiciones ya existentes y que incorpore elementos de control en relación a Seguridad Física, Seguridad lógica (accesos, seguridad de datos , cuentas, privilegios, perfiles, detección de transgresiones, prevención, etc)


Proyecto 4, Proyecto 7 y Proyecto 8

Políticas, Normas y procedimientos – Seguridad (Políticas, Normas y Procedimientos, Respaldos)

M

11 Establecer una estrategia para enfrentar contingencias asociadas a las actividades informáticas


Proyecto 7 y Proyecto 8

Administración de infraestructura tecnológica(Análisis de Infraestructura Tecnológica, Dimensionamiento Plataforma, Proyección Crecimiento de la Plataforma, Definir y administrar los niveles de servicio)

M

12 Establecer un procedimiento para Evaluar la Capacidad de la plataforma, monitorearla y determinar necesidad de crecimiento



Administración de infraestructura tecnológica(Análisis de Infraestructura Tecnológica, Dimensionamiento Plataforma, Proyección Crecimiento de la Plataforma, Definir y administrar los niveles de servicio)

M

13 Establecer los Skills requeridos por el personal TIC, definir la brecha y Definir Calendario capacitación al personal TIC


Proyecto 9 Capacitación de Funcionarios M

14 Formalizar un proceso de Gestión de riesgos asociado a las actividades de Ti


Proyecto 4 Gestión de Riesgos/ Análisis de Riesgos/ Realización de Planes de mitigación

M

15 Mejorar la Mesa de ayuda para canalizar todos los requerimientos de soporte, analizarlos, detectar recurrencia y buscar soluciones


Proyecto 7 Soporte/Administrar Problemas M

16 Establecer los SLA que deben incorporarse a los servicios de proveedores, definir los mecanismos de medición, los períodos de tiempo y las sanciones



Administración de infraestructura tecnológica / Definir y administrar los niveles de servicio

M


60



Tipo de Proyecto 11

asociadas a su cumplimiento 17 Mejoramiento del control de

configuración de hw, sw y documentación de servicios de TI



Control de cambios M

18 Generar indicadores en relación a las actividades de TI y definir informes de gestión


Proyecto 4 Monitoreo (Monitorear y evaluar el desempeño de TI, Monitorear y evaluar el control interno)

I

19 Generar plan de ciclo de vida formal para los proyectos de acuerdo a sus características


Proyecto 5 Ejecución y Control de Proyectos (Planificación Inicial del Proyecto, Control y Seguimiento, Control de Calidad, Implantación, Capacitación (usuarios finales), Cierre de Proyecto)

M

20 Generar un plan de calidad que sirva de marco para los proyectos de HW, SW de mercado y desarrollos a medida.

Primer Semestre2010

Proyecto 19 Ejecución y Control de Proyectos/ Control de Calidad

M

21 Generar proceso de implantación de soluciones de acuerdo a las características del Producto.

Primer Semestre2010

Proyecto 19 Ejecución y Control de Proyectos/ Implantación,

M

22 Generar un plan de asignación de costos equitativo, para dar soporte a los requerimientos de los usuarios independiente de la unidad/oficina solicitante


No Distribución de Costos

I

23 Generación de estrategia de operación de TIC’s para la administración y control efectiva de los recursos

Primer Semestre2010

Proyecto 19 Operación

I

24 Generación de plan regulatorio para la programación y aplicación de controles internos

Primer Semestre2010

Proyecto 19 Garantizar el cumplimiento regulatorio

I

25 Definición e implantación de un marco de trabajo para la formalización de estructuras de liderazgo al interior de la organización

Primer Semestre2010

Proyecto 19

Proporcionar gobierno de TI I

Tabla 6: Cronograma Implementación de las Mejoras a los Procesos


61

ANEXO 1: Detalle de Reuniones Sostenidas

Para llevar a cabo la etapa de “Diagnóstico de Procesos de TI y Propuesta de Mejoras ”, se realizaron 38 Reuniones de trabajo (con la participación de 39 personas en total) con las responsables de los procesos de TI o que conformaban los distintos subdepartamentos involucrados en la presente consultoría. Una vez realizadas las reuniones de trabajo, se enviaron Minutas de Reunión, para el caso de las reuniones de control de avance y Minutas Técnicas para el caso de las reuniones de levantamiento de los procesos de TI. Todas ellas, fueron validadas por los propios participantes. Una vez validadas, fueron publicadas en el sitio documental Web Alfresco, entregándose acceso controlado al equipo contraparte del proyecto. La tabla siguiente presenta un listado con las reuniones de trabajo realizadas durante esta primera etapa: NRO. FECHA

REUNION NRO. MINUTA DE

REUNION UNIDAD / DEPTO

/SUBDEPTO.

ASISTENTES DGAC

1 11/09/2008 MIR001 Gestión TIC’s • Pía Gamboa • Mauro Chávez

2 22/09/2008 MIR002 DGAC • Pía Gamboa • Mauro Chávez • Rafael Cuevas • Héctor Mendoza • Hermes Bastías • Cristian Miranda • Santiago Alonso

3 25/09/2008 MIT001 DASA12 • Héctor Barrientos • Guillermo Fuentes • Juan Luis Rodríguez • Rafael Cuevas • Rodrigo Silva

4 25/09/2008 MIT002 ETA13 • Christian Miranda • Guido Martínez

5 26/09/2008 MIT003 DSO14 • Carlos Cerda 6 29/09/2008 MIT004 DMC15 • Hermes Bastías

• Marcelo Cerda Castillo 7 29/09/2008 MIT005 DASA • Juan Luis Rodríguez

• Rafael Cuevas • Rodrigo González

8 30/09/2008 MIT006 Subdepartamento Gestión TIC’s

• Fernando Matus

12 DASA : Dirección de Aeródromos y Servicios Aeronáuticos 13 ETA: Escuela Técnica Aeronáutica 14 DSO: Departamento de Seguridad Operacional 15 DMC: Dirección Meteorológica de Chile


62

NRO. FECHA REUNION

NRO. MINUTA DE REUNION

UNIDAD / DEPTO

/SUBDEPTO.

ASISTENTES DGAC

9 01/10/2008 MIT007 DASA • José Carrasco • Rafael Cuevas


• Pía Gamboa

11 03/10/2008 MIT009 DASA • José Carrasco • Rafael Cuevas • Alberto Fernández • Guillermo Fuentes


• Maritza Fuentes


• Rodrigo Ancavil

14 07/10/2008 y 08/10/2008

MIT012 Subdepartamento Gestión TIC’s

• Mauro Chávez

15 07/10/2008 MIT013 Subdepartamento Soporte TIC’s

• José Antonio Espinoza

16 08/10/2008 y 14/10/2008

MIT014 Subdepartamento Soporte TIC’s

• José Collío

17 08/10/2008 MIR003 Contrapartes de Proyecto

• Pía Gamboa • Mauro Chávez • Héctor Mendoza


• Sabina Pizarro

19 09/10/2008 MIT016 DSO • Fernando Frenkel • Emiliano Hernández


• Alejandro Correa


• Pablo Berríos

22 10/10/2008 MIT019 DSO • Aníbal Camus • Antonio Montserrat


• Luis Mella Sagredo


• Víctor Pantoja


• Patricia Cortés-Monroy


• Alicia Mc Millan


• Manuel Barraza


• René Miranda


• José Zabala


• Héctor Mendoza

31 21/10/2008 MIR04 DGAC • Pía Gamboa • Mauro Chávez • Héctor Mendoza


63

NRO. FECHA REUNION

NRO. MINUTA DE REUNION

UNIDAD / DEPTO

/SUBDEPTO.

ASISTENTES DGAC

32 23/10/2008 MIT028 Subdepartamento Licencias

• Carlos Arredondo

33 28/10/2008 MIT029 Subdepartamento Licencias

• Luis Siviragol

34 05/11/2008 MIR05 Contrapartes de Proyecto

• Pía Gamboa • Mauro Chávez • Héctor Mendoza

35 18/11/2008 MIR06 Departamento TIC’s

• Pía Gamboa • Mauro Chávez • Héctor Mendoza • Fernando Matus

36 19/11/2008 (*) Gestión TIC’s • Mauro Chávez 37 20/11/2008 (*) Soporte TIC’s • Héctor Mendoza

38 26/11/2008 (*) Gestión TIC’s • Mauro Chávez

Tabla 7: Reuniones realizadas

(*) No se confeccionaron minutas de reunión, por ser éstas de carácter aclaratorias y de levantamiento de información de riesgos para la confección de las matrices consolidadas.

Informe Etapa 1_Diagnóstico de Procesos de TI

Documents

Transcript of Informe Etapa 1_Diagnóstico de Procesos de TI