UNIVERSIDAD DE CHILE

FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN











DISEÑO DE UN CENTRO DE SERVICIOS COMPARTIDOS DE TECNOLOGÍAS DE
INFORMACIÓN PARA UNA EMPRESA PRODUCTORA DE PULPA Y PAPEL



TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN TECNOLOGÍAS DE LA
INFORMACIÓN





CLAUDIO ALEJANDRO BERTON CÁRDENAS






PROFESOR GUÍA:
SR. JOSÉ A. PINO URTUBIA.

MIEMBROS DE LA COMISIÓN:
SR. NELSON BALOIAN TATARYAN.
SR. PATRICIO INOSTROZA FAJARDIN.
SRA. ROSA ALARCÓN CHOQUE.






SANTIAGO DE CHILE
OCTUBRE 2007


RESUMEN

En esta tesis se presenta el diseño general de los procesos de negocio y organización,
de un área de tecnologías de información, que operará dentro de un holding de
empresas especializadas en los negocios de la industria de la pulpa y el papel, bajo el
modelo de servicios compartidos.

El holding ha definido la creación de una nueva empresa de servicios, que congregará
las funciones de contabilidad, compras, recursos humanos y tecnologías de
información. El problema abordado en este trabajo corresponde a la definición de la
manera en que se prestarán los servicios de TI a las empresas filiales.

La hipótesis es mostrar que, mediante la estructuración e implantación de procesos
basados en estándares, orientados a la provisión de servicios de tecnologías de
información, se pueden lograr beneficios y oportunidades importantes, tales como: la
consolidación, la optimización de procesos a través de la reingeniería, la
estandarización de aplicaciones y la reducción de los costos de operación.

La metodología de solución corresponde a una visión desde la re-ingeniería de
procesos, utilizando para las definiciones, elementos de los modelos CMMi e ITIL y
abordando tres grandes ciclos de las actividades de tecnologías de información:
planeación estratégica, ingeniería de software, soporte y provisión de servicios. Para
cada uno de estos ciclos, se definieron actividades de carácter operativo considerando
la distribución geográfica. En el caso de la gestión, el esquema propuesto es de
centralización. Además, se plantea una estrategia para la mejora de los procesos de
software, cuyo objetivo final es la adopción y evaluación en CMMi.

Producto de la definición e implantación de los servicios, procesos y organización
propuestos en esta tesis, se ha logrado una disminución de un 11.7% en los costos de
TI para una planta industrial promedio de 500 usuarios, paradójicamente los costos de
proyectos de software han aumentado un 15%, debido a la transparentación de costos
que antes eran ocultos. Otro resultado importante, es que con la adopción de un
esquema de servicio compartido con un marco de procesos basado en estándares, se
cuenta con una base que permite la implementación de soluciones tecnológicas
transversales al holding, generando sinergia, economías de escala y simplificación en la
operación.



























A mi familia



AGRADECIMIENTOS


A mi familia, por su constante apoyo, cariño, comprensión y por permitirme dedicar
tiempo y recursos para desarrollar mis estudios y este trabajo, en desmedro de ellos.

A mis colegas de trabajo, por permitirme discutir con ellos alguna de las ideas
presentadas en esta tesis.



i

TABLA DE CONTENIDOS

CAPÍTULO 1 - INTRODUCCIÓN ............................................................................................................. 1
1. LA INDUSTRIA DE LA PULPA Y EL PAPEL ................................................................................................. 1
2. SITUACIÓN INICIAL .............................................................................................................................. 2
3. DEFINICIÓN DEL PROBLEMA ................................................................................................................. 6
4. HIPÓTESIS ......................................................................................................................................... 7
CAPÍTULO 2 – REVISIÓN TEÓRICA Y METODOLOGÍA ........................................................................ 9
1. REVISIÓN TEÓRICA ............................................................................................................................. 9
1.1 Análisis, Modelamiento y Diseño de Procesos ........................................................................... 9
1.1.1 SADT (Structured Analysis and Design Technique) ........................................................... 10
1.1.2 IDEF (Integrated DEFinition Methods) ............................................................................... 10
1.1.3 Ciclos de Trabajo .............................................................................................................. 12
1.1.4 UML (Unified Modeling Language) .................................................................................... 13
1.2 Proceso de Planificación Estratégica........................................................................................ 14
1.3 Modelos y Prácticas para Procesos de Software ...................................................................... 16
1.3.1 CMMi (Capability Maturity Model Integration) .................................................................... 17
1.3.2 Normas ISO ...................................................................................................................... 18
1.3.2.1 ISO 9000:2000 .......................................................................................................... 18
1.3.2.2 ISO 9126 para Ingeniería de Software ....................................................................... 19
1.4 ITIL (IT Infraestructure Library) ................................................................................................. 19
1.5 Criterios de Selección de Herramientas.................................................................................... 20
2. METODOLOGÍA ................................................................................................................................. 21
2.1 Enfoque de Trabajo ................................................................................................................. 21
2.2 Estrategia del Proyecto ............................................................................................................ 22
2.2.1 Actividades de Gestión del Proyecto ................................................................................. 22
2.2.2 Actividades Propias del Proyecto ...................................................................................... 23
2.3 Selección de Herramientas Metodológicas ............................................................................... 24
CAPÍTULO 3 – DISEÑO DE SERVICIOS Y PROCESOS ....................................................................... 26
1. DISEÑO DE SERVICIOS ...................................................................................................................... 26
1.1 Servicios TIC ........................................................................................................................... 26
1.2 Modelo de costos de los servicios ............................................................................................ 28
1.3 Niveles de Servicio .................................................................................................................. 31
2. DISEÑO DE PROCESOS ..................................................................................................................... 39
2.1 Proceso de planeación estratégica TIC para las filiales ............................................................ 39
2.1.1 Proceso para la planeación estratégica ............................................................................. 39
2.1.2 Proceso para la elaboración del presupuesto .................................................................... 42
2.2 Procesos de software............................................................................................................... 46
2.2.1 Administración de Proyectos ............................................................................................. 46
2.2.1.1 Administración de proyectos con metodologías ágiles ................................................ 47
2.2.1.2 Administración de proyectos con metodologías tradicionales ..................................... 48
2.2.2 Proceso de Desarrollo y Administración de Requerimientos .............................................. 51
2.2.3 Proceso de Desarrollo de Software ................................................................................... 54
2.2.4 Proceso de Pruebas de Software ...................................................................................... 58
2.2.5 Proceso de Mantención de Software ................................................................................. 61
2.3 Procesos de soporte al servicio ................................................................................................ 64
2.3.1 Gestión de incidencias ...................................................................................................... 64
2.3.2 Gestión de problemas ....................................................................................................... 66
2.3.3 Gestión de inventario y configuración ................................................................................ 68
2.3.4 Gestión del cambio ........................................................................................................... 71
2.3.5 Control y distribución de software y hardware ................................................................... 74
2.4 Procesos de entrega del servicio.............................................................................................. 76
2.4.1 Gestión de disponibilidad y continuidad ............................................................................. 76
2.4.2 Gestión del nivel de servicio .............................................................................................. 77
2.4.3 Gestión de finanzas TI ...................................................................................................... 80
ii

2.4.4 Gestión de capacidad ....................................................................................................... 81
2.4.4.1 Gestión de capacidad del negocio ............................................................................. 81
2.4.4.2 Gestión de capacidad de los recursos y servicios....................................................... 82
2.4.5 Gestión de proveedores .................................................................................................... 86
2.5 Procesos de gestión de la infraestructura y seguridad .............................................................. 90
2.5.1 Gestión de infraestructura ................................................................................................. 90
2.5.1.1 Administración de la Infraestructura ........................................................................... 92
2.5.1.2 Administración de la Seguridad .................................................................................. 93
2.5.1.3 Monitoreo y Control de Servicios ............................................................................... 93
2.5.1.4 Actividades de Operación .......................................................................................... 94
2.5.2 Gestión de seguridad ........................................................................................................ 95
CAPÍTULO 4 – ORGANIZACIÓN .......................................................................................................... 97
1. ESTRUCTURA ORGANIZACIONAL. ........................................................................................................ 97
1.1 Primer nivel organizacional ...................................................................................................... 98
1.2 Segundo, tercer y cuarto nivel organizacional ........................................................................ 100
1.2.1 Subgerencia Relación Comercial Cliente......................................................................... 101
1.2.2 Subgerencia Servicio al Cliente ....................................................................................... 102
1.2.3 Subgerencia de Proyectos .............................................................................................. 104
1.2.4 Subgerencia de Infraestructura ....................................................................................... 107
2. DEFINICIÓN DE CARGOS .................................................................................................................. 108
2.1 Gerencia de Servicios TIC ..................................................................................................... 108
2.2 Subgerencia de Relación Comercial....................................................................................... 109
2.3 Subgerencia de Servicio al Cliente ......................................................................................... 109
2.4 Subgerencia de Proyectos ..................................................................................................... 110
2.5 Subgerencia de Infraestructura .............................................................................................. 111
CAPÍTULO 5 – IMPLEMENTACIÓN, TRANSICIÓN Y CAMBIO .......................................................... 113
1. PLAN DE IMPLEMENTACIÓN, TRANSICIÓN Y CAMBIO ............................................................................. 113
1.1 Etapa previa al cambio ........................................................................................................... 113
1.1.1 Actividades de Capacitación ........................................................................................... 114
1.1.2 Actividades de definición de los procesos TI ................................................................... 114
1.1.3 Actividades de definición de la estructura organizacional ................................................ 114
1.2 Etapa de transición y cambio ................................................................................................. 115
1.3 Etapa de entrega del servicio ................................................................................................. 116
CAPÍTULO 6 – ESTRATEGIA PARA LA MEJORA DEL SOFTWARE ................................................ 118
1. MARCO DEL PROCESO DE MEJORA DE SOFTWARE ............................................................................. 118
2. PLAN ESTRATÉGICO DE MEJORA DEL PROCESO DE SOFTWARE ........................................................... 119
2.1 Misión .................................................................................................................................... 119
2.2 Visión .................................................................................................................................... 119
2.3 Valores .................................................................................................................................. 119
2.4 Principios Guías ..................................................................................................................... 119
2.5 Metas de Corto Plazo............................................................................................................. 120
2.6 Metas de Largo Plazo ............................................................................................................ 120
2.7 Metas Estratégicas Derivadas del Negocio............................................................................. 120
2.8 Objetivo ................................................................................................................................. 120
2.9 Beneficios Esperados ............................................................................................................ 120
2.10 Principios Guía del SPI ........................................................................................................ 120
2.11 Supuestos............................................................................................................................ 121
2.12 Auspicio ............................................................................................................................... 121
2.13 Riesgos ............................................................................................................................... 122
2.14 Barreras ............................................................................................................................... 122
2.15 Organización para la Mejora del Proceso ............................................................................. 123
2.15.1 Alcance Organizacional ................................................................................................ 123
2.15.2 Comité Ejecutivo ........................................................................................................... 123
2.15.3 Jefe del Proyecto SPI.................................................................................................... 124
2.15.4 SEPG (Software Engineering Process Group) ............................................................... 124
iii

2.15.5 Grupos de Trabajo Técnicos (TWG) .............................................................................. 124
2.15.6 Consultores Externos .................................................................................................... 125
2.16 Criterios de Éxito.................................................................................................................. 126
2.16.1 Medición de Metas de Corto Plazo ............................................................................... 126
2.16.2 Medición de Metas de Largo Plazo ............................................................................... 126
2.16.3 Medición de Metas Estratégicas Derivadas del Negocio ................................................ 126
2.17 Planificación ........................................................................................................................ 127
2.17.1 Costos Estimados ......................................................................................................... 127
2.17.2 Roadmap ...................................................................................................................... 128
CAPÍTULO 7 - CONCLUSIONES ........................................................................................................ 129
BIBLIOGRAFÍA ................................................................................................................................... 131
ANEXOS ............................................................................................................................................. 134
ANEXO I: COMPARACIÓN ENTRE LAS PLATAFORMAS .NET Y J2EE ......................................................... 135
ANEXO II: EJEMPLOS DE NORMAS Y PROCEDIMIENTOS ......................................................................... 140


ÍNDICE DE TABLAS

TABLA 1: SITUACIÓN INICIAL DE LOS PROCESOS DE SOFTWARE ........................................................................ 4
TABLA 2: SITUACIÓN INICIAL DE LOS PROCESOS DE SOPORTE .......................................................................... 5
TABLA 3: LOS NIVELES DE MADUREZ Y LAS ÁREAS DE PROCESO DE CMMI ...................................................... 18
TABLA 4: EL CATÁLOGO DE SERVICIOS ........................................................................................................ 27
TABLA 5: CRITERIOS PARA LA APLICABILIDAD DE COSTOS A LOS SERVICIOS ..................................................... 29
TABLA 6: CRITERIOS PARA APLICAR PRORRATEO A LOS COSTOS DE LOS SERVICIOS ......................................... 30
TABLA 7: ASIGNACIÓN DE VALORES A LA IMPORTANCIA DE UN SERVICIO .......................................................... 33
TABLA 8: IMPORTANCIA DE LOS SERVICIOS SEGÚN LA SEGMENTACIÓN DE USUARIOS ........................................ 33
TABLA 9: NIVELES DE SERVICIO PARA LOS SERVICIOS FIJOS .......................................................................... 34
TABLA 10: NIVELES DE SERVICIO PARA SERVICIOS VARIABLES ....................................................................... 37
TABLA 11: NIVELES DE SERVICIO PARA LA MANTENCIÓN DE SOFTWARE DE CORTO PLAZO ................................. 37
TABLA 12: NIVELES DE SERVICIO PARA SERVICIOS DE VALOR AGREGADO ........................................................ 38
TABLA 13: EJEMPLO DE UN PRESUPUESTO .................................................................................................. 43
TABLA 14: CRITERIOS PARA LA PRESUPUESTACIÓN ...................................................................................... 44
TABLA 15: CRITERIOS PARA DETALLAR EL PRESUPUESTO ............................................................................. 44
TABLA 16: COMPONENTES TECNOLÓGICOS DE LOS SERVICIOS ...................................................................... 83
TABLA 17: INDICADORES DE CAPACIDAD DE SERVIDORES Y PC...................................................................... 84
TABLA 18: INDICADORES DE CAPACIDAD PARA IMPRESORAS .......................................................................... 85
TABLA 19: INDICADORES DE CAPACIDAD DE EQUIPOS DE COMUNICACIÓN ........................................................ 85
TABLA 20: DIFERENCIAS ENTRE SLA Y OLA ............................................................................................... 88
TABLA 21: OLA PARA SERVICIOS FIJOS ....................................................................................................... 89
TABLA 22: DESCRIPCIÓN DE LOS SERVICIOS DE INFRAESTRUCTURA ............................................................... 92
TABLA 23: VARIABLES DE MONITOREO DE UN SERVIDOR ............................................................................... 94
TABLA 24: ACTIVIDADES DE OPERACIÓN HABITUAL DE LA INFRAESTRUCTURA .................................................. 94
TABLA 25: PLAN GLOBAL DE DIFUSIÓN Y CAMBIO ........................................................................................ 117
TABLA 26: RIESGOS DEL PROYECTO DE MEJORA DEL PROCESO DE SOFTWARE .............................................. 122
TABLA 27: COSTOS DEL PROYECTO DE MEJORA DEL PROCESO DE SOFTWARE ............................................... 127
TABLA 28: ROADMAP DEL PROYECTO DE MEJORA DEL PROCESO DE SOFTWARE ............................................ 128




iv

ÍNDICE DE FIGURAS

FIGURA 1: ESTRUCTURA DE EMPRESAS DEL HOLDING ..................................................................................... 2
FIGURA 2: ORGANIGRAMAS DE LAS ÁREAS DE SISTEMAS ................................................................................ 3
FIGURA 3: REPRESENTACIÓN GRÁFICA DE IDEF0 ........................................................................................ 11
FIGURA 4: REPRESENTACIÓN GRÁFICA DEL MODELO DE CICLOS DE TRABAJO .................................................. 12
FIGURA 5: MODELO DE PLANEACIÓN ESTRATÉGICA ...................................................................................... 14
FIGURA 6: REPRESENTACIÓN GRÁFICA DEL MODELO DE LAS 5 FUERZAS DE PORTER ........................................ 15
FIGURA 7: LA CADENA DE VALOR ................................................................................................................ 16
FIGURA 8: SEGMENTACIÓN DE LOS USUARIOS ............................................................................................. 32
FIGURA 9: LÍNEA DE TIEMPO DE UN INCIDENTE ............................................................................................. 34
FIGURA 10: PROCESO DE PLANEACIÓN ESTRATÉGICA DE TI .......................................................................... 40
FIGURA 11: PROCESO DE ELABORACIÓN DEL PRESUPUESTO ......................................................................... 45
FIGURA 12: ADMINISTRACIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES .................................................... 48
FIGURA 13: ADMINISTRACIÓN DE PROYECTOS CON METODOLOGÍAS TRADICIONALES ........................................ 49
FIGURA 14: PROCESO DE DESARROLLO Y ADMINISTRACIÓN DE REQUERIMIENTOS ............................................ 53
FIGURA 15: PROCESO DE DESARROLLO DE SOFTWARE CON METODOLOGÍA ÁGIL ............................................. 55
FIGURA 16: PROCESO DE DESARROLLO DE SOFTWARE CON METODOLOGÍAS TRADICIONALES ........................... 56
FIGURA 17: PROCESO DE PRUEBAS CON METODOLOGÍA ÁGIL ........................................................................ 59
FIGURA 18: PROCESO DE PRUEBAS CON METODOLOGÍAS TRADICIONALES ...................................................... 60
FIGURA 19: DIAGRAMA DE DESCOMPOSICIÓN PARA EL TESTING ..................................................................... 61
FIGURA 20: PROCESO DE MANTENCIÓN DEL SOFTWARE ................................................................................ 63
FIGURA 21: PROCESO DE GESTIÓN DE INCIDENCIAS ..................................................................................... 66
FIGURA 22: PROCESO DE GESTIÓN DE PROBLEMAS ...................................................................................... 68
FIGURA 23: PROCESO DE GESTIÓN DE INVENTARIO Y CONFIGURACIÓN ........................................................... 70
FIGURA 24: PROCESO DE PASO A PRODUCCIÓN ........................................................................................... 72
FIGURA 25: PROCESO DE GESTIÓN DEL CAMBIO PARA EQUIPOS DE ESCRITORIO .............................................. 73
FIGURA 26: DESCOMPOSICIÓN DEL PRODUCTO DE SOFTWARE PARA EL CONTROL DE VERSIONES ...................... 75
FIGURA 27: PROCESO DE GESTIÓN DE LA DISPONIBILIDAD Y LA CONTINUIDAD .................................................. 77
FIGURA 28: CICLO DE GESTIÓN DEL NIVEL DE SERVICIO ................................................................................ 78
FIGURA 29: PROCESO DE GESTIÓN DEL NIVEL DE SERVICIO ........................................................................... 79
FIGURA 30: PROCESO DE GESTIÓN DE LAS FINANZAS ................................................................................... 81
FIGURA 31: PROCESO DE GESTIÓN DE PROVEEDORES ................................................................................. 87
FIGURA 32: ACTIVIDADES GENERALES DE UN PROYECTO DE INFRAESTRUCTURA ............................................. 91
FIGURA 33: JERARQUIZACIÓN DE LAS ACTIVIDADES DE INFRAESTRUCTURA ..................................................... 91
FIGURA 34: ORGANIGRAMA GENERAL, OPCIÓN 1 .......................................................................................... 98
FIGURA 35: ORGANIGRAMA GENERAL, OPCIÓN 2 .......................................................................................... 99
FIGURA 36: ORGANIGRAMA GENERAL, OPCIÓN 3 ........................................................................................ 100
FIGURA 37: ORGANIGRAMA SUBGERENCIA RELACIÓN COMERCIAL CLIENTE ................................................... 101
FIGURA 38: ORGANIGRAMA SUBGERENCIA DE SERVICIO AL CLIENTE ............................................................. 103
FIGURA 39: ORGANIGRAMA SUBGERENCIA DE PROYECTOS ......................................................................... 105
FIGURA 40: ORGANIGRAMA ALTERNATIVO DE LA SUBGERENCIA DE PROYECTOS ............................................ 105
FIGURA 41: ORGANIGRAMA SUBGERENCIA DE INFRAESTRUCTURA ............................................................... 107


ÍNDICE DE ECUACIONES

ECUACIÓN 1: TIEMPO DE NO DISPONIBILIDAD DE LOS SERVICIOS FIJOS ........................................................... 32
ECUACIÓN 2: PORCENTAJE DE DISPONIBILIDAD DEL SERVICIO FIJO ................................................................. 32
ECUACIÓN 3: PORCENTAJE DE PRODUCTOS ENTREGADOS DENTRO DE PLAZO ................................................. 50
ECUACIÓN 4: PORCENTAJE DE PRODUCTOS ENTREGADOS FUERA DE PLAZO ................................................... 50
ECUACIÓN 5: PORCENTAJE DE AVANCE DEL PROYECTO ................................................................................ 50

1

Capítulo 1 - Introducción

1. La industria de la pulpa y el papel

La industria de la pulpa y el papel es un sector que se encuentra en plena madurez,
orientado a la producción de commodities, en un mercado en que los precios son
extremadamente volátiles, las empresas se ven obligadas a invertir fuertemente para
mantenerse en pie. Sin embargo, pese a que el crecimiento promedio del mercado es
entre un 2.5% - 3% anual [27], los márgenes se han visto deteriorados producto de los
excesos de capacidad existentes.

Los crecimientos de capacidad de las grandes empresas se realizan mediante la
adquisición de compañías más pequeñas, existiendo una tendencia continua a la
globalización [12].

Desde el punto de vista de los productos existe una tendencia a focalizarse más que en
diversificarse [27]. Las grandes líneas de productos del sector son: maderas, celulosa,
papel para impresión y escritura, papel para corrugar, papel tissue, papel de diario y
cartulinas.

Las empresas del sector se caracterizan por ser altamente dependientes de la logística,
siendo la eficiencia en costos uno de los grandes objetivos de negocio. Las
preocupaciones del sector radican principalmente en [12,27]:

a) Necesidad de asegurar los suministros de insumos al menor costo posible.
b) Necesidad de focalizarse en la generación de valor para los clientes y
accionistas.
c) Necesidad de focalizarse en el negocio.
d) Generar economías de escala.
e) Necesidad de integrarse con la cadena de suministros.
f) El aumento en la dependencia de las Tecnologías de Información (TI). En
general, se cuenta con sistemas antiguos que incorporan prácticas y procesos
que se encuentran obsoletos.
g) Necesidad de focalizarse en el cliente más que en el proceso productivo.
h) Mantener una relación armoniosa con el medio ambiente.

En este contexto, las Tecnologías de Información juegan, aparentemente, un rol
secundario, sin embargo la tendencia es la incorporación de tecnologías que faciliten la
gestión de la información, la automatización y la operación de las plantas productivas.

El presente trabajo, se desarrolla en un holding que está compuesto por seis filiales que
a su vez congregan a empresas especializadas en los distintos negocios de la industria
de la pulpa y el papel, tal como se puede observar en la figura 1.

Geográficamente, las empresas y sus plantas productivas están distribuidas a lo largo
de Chile y en el extranjero, con plantas productoras en Argentina, Uruguay, Perú, Brasil
y México.
2




Figura 1: Estructura de empresas del holding

2. Situación Inicial

Cada filial posee un área de informática propia e independiente. A nivel de la matriz,
existe una gerencia de informática que entrega a las filiales los lineamientos base en
cuanto a políticas de seguridad, licenciamiento de software y servicios centralizados.
Además, define y mantiene los sistemas corporativos y administra la red de datos
corporativa.

Hay 458 aplicaciones distintas, de los cuales 60% están relacionadas con el apoyo a la
administración de los negocios y un 40% apoyan la operación de plantas productivas.
Estas aplicaciones son soportadas por 357 servidores, que se encuentran distribuidos
geográficamente en Chile y en el extranjero.

Cada área informática posee su propia organización, identificándose tres tipos
genéricos:

1. Una subgerencia, con tres áreas dependientes: soporte, mantención de software
y desarrollo de software.
2. Varias subgerencias con dos áreas dependientes: soporte, mantención y
desarrollo de software.
3

3. Una subgerencia con dos áreas dependientes: soporte y coordinación. Siendo
responsabilidad de la coordinación la realización de proyectos informáticos con
terceros.

La representación de esta organización se visualiza en la figura 2. Las líneas punteadas
indican que existe una relación de dependencia implícita.



Figura 2: Organigramas de las áreas de Sistemas

El área de soporte es la encargada de entregar el soporte a usuarios, administrar la
infraestructura informática y asegurar la continuidad de los servicios. Las áreas de
desarrollo y mantención se encargan del ámbito del software. No se presentan
unidades que gestionen la relación con el cliente.

Las funciones realizadas por las unidades informáticas son equivalentes entre sí y son:

a) Realizar la planificación estratégica de TI para la filial, a través de un proceso
informal y medianamente definido, cuyo objetivo final es la obtención del
presupuesto anual de TI.
b) Mantener y operar la infraestructura informática.
c) Entregar soporte a los usuarios, sistemas y aplicaciones.
d) Desarrollar aplicaciones propias y con terceros.
e) Mantener la seguridad informática.
f) Entregar soporte a la gestión (captura de requerimientos y análisis de sistemas).
4

g) Entregar consultoría tecnológica.

Desde el punto de vista de los procesos, existe un desarrollo propio e incipiente con
grandes diferencias entre las divisiones del holding. En la tabla 1, se presenta un
resumen de la situación para procesos básicos de software.



Tabla 1: Situación inicial de los procesos de software

La administración y desarrollo de requisitos consiste solamente en la recepción directa
desde el usuario y la aprobación por parte de un comité. En el caso de las metodologías
de desarrollo, se depende exclusivamente del desarrollador, lo que provoca que se
presenten diferencias respecto al enfoque de solución y a la manera como es
construido el software. Las pruebas de software son prácticamente nulas. Respecto a la
mantención de software, el proceso consiste en la recepción formal de un requerimiento
de cambio, previa aprobación en caso que signifique un gasto, no existe una definición
para la asignación de tareas y manejo de prioridades. Tampoco existe documentación
técnica del software. Además, no se manejan conceptos de calidad y la gestión de
proyectos depende del enfoque y voluntad de cada jefe de proyecto.

Para el caso de soporte, los procesos definidos no son estándares en la organización,
presentándose distintos niveles de profundización y formalización en las filiales. En la
tabla 2, se presenta un resumen de la situación con los procesos que han sido
identificados.

5



Tabla 2: Situación inicial de los procesos de soporte

En resumen, si bien hay procesos definidos, existen patologías en cuanto a la
implementación, estas son:

a) Las herramientas de software utilizadas para el soporte del proceso no son
adecuadas para el tamaño del negocio.
b) Algunos procesos no se encuentran debidamente institucionalizados y, en
general, no son gestionados como tal.
c) Los procedimientos se enfocan en lo que hay que hacer más que en cómo
hacerlo.
d) Los procesos de administración de la infraestructura son descentralizados y
siguen criterios que no son comunes dentro de las divisiones de negocio.
e) No existe claridad respecto a la responsabilidad y roles de las personas sobre los
procesos.
f) Existen iniciativas de formalización de procesos, sin embargo, no son llevadas a
cabo producto de la falta de tiempo de las personas encargadas de definirlos y
documentarlos y a la falta de auspicio por parte de la alta dirección.
g) Existe resistencia de las personas para adoptar procesos estructurados y
normas.

Además, existen diferencias en cuanto al enfoque con que cada unidad informática
afronta a sus clientes y usuarios, se distinguen:

a) Los que se encuentran orientados al cliente.
b) Los que imponen reglas y soluciones.
c) Los que son guiados por el cliente, vale decir, aquellos en los que el cliente
define los aspectos técnicos de informática.

Pese a estas patologías, una fortaleza que destaca es el conocimiento de los negocios
que tiene el personal de informática, además del compromiso y dedicación a las labores
que les han sido encomendadas.
6


Culturalmente, hay un sentido altamente jerárquico respecto a las responsabilidades,
donde la mayoría de las decisiones son tomadas por Gerentes y Subgerentes.

En general, el holding se caracteriza por tener un carácter conservador desde el punto
de vista adopción de nuevas tecnologías. Sin embargo, se encuentra abierto a los
estándares que apoyen la mejora de procesos y aseguren la calidad de sus productos.

3. Definición del Problema

El holding matriz ha definido la creación de una nueva empresa que proveerá a todas
las filiales los servicios de: contabilidad, recursos humanos, tecnologías de información
y comunicaciones (TIC) y compras.

Todas las filiales del holding serán atendidas por esta nueva empresa, sin poder ellas
optar por otro proveedor o mantener un servicio propio. Tampoco se podrán proveer
servicios fuera del conglomerado de empresas y se deberá operar con procesos y
aplicaciones estándares de la industria. La nueva empresa no deberá generar utilidades
y se deberá regir por acuerdos de servicio y costos con las filiales. Para este proyecto,
el holding matriz ha contratado una consultora que se encargará de los procesos de
contabilidad, recursos humanos y compras [5]. En el caso de Tecnologías de
Información, se ha contratado a otra empresa consultora especialista en procesos TI
que apoyará la definición de los procesos y estructura organizacional. El holding matriz
ha definido que este trabajo sea realizado en conjunto por personal propio y de la
consultora, teniendo como marco de referencia para la provisión de servicios el
estándar ITIL, no definiéndose un marco para los procesos de desarrollo de software.

Esta tesis se concentra en la definición global de procesos, transición y organización del
área de tecnologías de información bajo el paradigma de servicios compartidos, siendo
el objetivo general de este trabajo el diseñar los procesos y la estructura organizacional
del área que prestará los servicios compartidos de informática a todas las filiales del
holding, tomando como marco de referencia modelos de servicio y calidad estándares
de la industria.

Específicamente, los objetivos a satisfacer son:

a) Diseñar la estructura organizacional de tecnologías de información en la empresa
de servicios compartidos del holding matriz, que entregará los servicios a las
empresas del holding.
b) Definir los procesos de negocio del área de tecnologías de información que
prestará los servicios, utilizando como marco de referencia modelos y estándares
de calidad y buenas prácticas existentes en la industria.
c) Definir el plan de transición que implementará el cambio organizacional.

Tal como se mencionó, el holding matriz ha definido la utilización del modelo ITIL para
la provisión de servicios. Sin embargo, no se han realizado definiciones respecto al
proceso de desarrollo de software. Para resolver este punto, plantearemos el uso, como
7

marco de referencia, de algún modelo o estándar de calidad de software existente en la
industria.

En esta tesis, no se contempla la implementación y/o certificación de modelos y/o
estándares de calidad. Este proyecto supone una transformación fuerte en términos de
procesos, organización, cultura organizacional y paradigma, por lo que una adopción
completa de algún modelo, en esta etapa, puede resultar contraproducente e incluso no
beneficioso para la empresa y el cambio a implementar.

Este trabajo surge como respuesta a la necesidad de responder a la estrategia de
negocio del holding matriz, que considera los siguientes focos tácticos, a los cuales se
contribuiría directamente [5]:

a) Incrementar la calidad de los productos y servicios.
b) Simplificar la operación y el control.
c) Minimizar los costos de operación de las actividades de apoyo al negocio.
d) Crecimiento por adquisiciones y fusiones.
e) Promover la mejora continua.

4. Hipótesis

El concepto de servicios compartidos, se ha convertido en un estándar global como
modelo de organización de las unidades de apoyo al negocio para las corporaciones,
en particular las tecnologías de información. En Chile, hay al menos 10 empresas
operando bajo el esquema y varias otras en diferentes grados de implementación y
avance [5].

La hipótesis de trabajo es mostrar que mediante la estructuración e implantación de
procesos basados en estándares, orientados a la provisión de servicios de tecnologías
de información bajo servicios compartidos, se pueden lograr beneficios y oportunidades
importantes, tales como [5]:

1. Incremento de la calidad de los productos y servicios, sustentado en:
a) Estandarización y optimización de procesos.
b) Mejores condiciones para la implementación de soluciones tecnológicas,
estándares y transversales, con la posibilidad de generar sinergias.
2. Simplificación de la operación y el control, a partir de:
a) La implementación de un modelo único de operación.
b) Aplicaciones informáticas estandarizadas.
c) Focalización en las actividades propias de cada empresa del holding.
3. Reducción de los costos de operación de las unidades de apoyo al negocio.
4. Optimización de los procesos a través de la reingeniería, estandarización y
consolidación de los mismos generando economías de escala para minimizar los
costos operativos
1
.


1
De acuerdo a Ernst & Young, compañías con servicios compartidos han reducido los costos asociados a la
prestación de servicios de soporte al negocio entre un 25% y un 45%
8


Para evaluar el cumplimiento de la hipótesis propuesta, se utilizarán los siguientes
mecanismos de evaluación:

1. A nivel de procesos: Comparación cualitativa entre la situación inicial versus la
situación con los procesos implantados, y el cumplimiento de los objetivos
propuestos para esta tesis.
2. A nivel de servicio: Comparación cualitativa de la situación inicial versus la
situación con el servicio compartido de tecnologías de información en
funcionamiento.
3. A nivel de costos: Comparación entre los costos en tecnologías de información
de la situación inicial y los obtenidos después de la implementación de los
procesos para una planta industrial promedio con 500 usuarios.


La evaluación de estos puntos será abordada en el capítulo 7.


9

Capítulo 2 – Revisión Teórica y Metodología

1. Revisión Teórica
1.1 Análisis, Modelamiento y Diseño de Procesos

Un proceso es un conjunto de compromisos, acciones y decisiones necesarias para
satisfacer un requerimiento de un cliente. Se basa en redes de compromisos en torno a
un ciclo de trabajo. Un proceso de negocio es un conjunto de tareas lógicamente
relacionadas que utilizan recursos de la organización para el cumplimiento de los
objetivos de negocio [31].

Los procesos pueden ser calificados mediante un modelo de madurez, que define 5
niveles y provee [30]:

a) Una guía para el desarrollo evolutivo de procesos.
b) Un modelo organizacional orientado al mejoramiento continúo.
c) Una estructura confiable de diagnostico de procesos y evaluación de su
capacidad.

Los niveles del modelo de madurez se categorizan en [7, 30]:

Nivel 1 (Inicial): No hay procedimientos formales, ni estimación de costos, ni
planificación y programación de procesos. No hay mecanismos de administración que
aseguren que se siguen procedimientos. Las herramientas no están bien integradas y el
control de cambios no es riguroso. La administración superior no entiende los puntos
clave del proceso.

Nivel 2 (Repetible): Los procesos dependen de los individuos y se establecen
controles básicos para los proyectos. Se busca hacer el trabajo en forma similar, pero
hay riesgos mayores cuando hay que enfrentar nuevos desafíos. No existe un marco
para enfrentar el mejoramiento.

Nivel 3 (Definido): Los procesos están definidos e institucionalizados. Existe un grupo
de procesos que lidera las mejoras y las promueve.

Nivel 4 (Administrado): Los procesos son medidos y se han establecido un conjunto
mínimo de medidas de calidad y productividad.

Nivel 5 (Optimizante): El mejoramiento continúo realimenta a los procesos. La
recolección de información es automatizada. La evidencia numérica es usada para
justificar la aplicación de tecnología a las tareas críticas. Se realizan análisis rigurosos
de tipo causa-efecto y prevención de defectos.

10

Para el diseño y modelamiento de procesos, existen una diversidad de métodos y
técnicas, de los cuales se han revisado los principales.

1.1.1 SADT (Structured Analysis and Design Technique)

Desarrollada a finales de la década del 70, SADT es una técnica de análisis y diseño de
sistemas que ha sido ampliamente utilizada. Provee de un conjunto de procedimientos
que permiten al analista descomponer las funciones del software o el sistema, los que
están compuestos de [15]:

a) Diagramas de actividades, que representan las actividades del sistema.
b) Diagramas de datos.
c) Textos y diagramas explicativos para los diagramas.
d) Esquema jerárquico del sistema.
e) Glosario de definiciones y términos utilizados.
f) Condiciones de activación.

Se utiliza descomposición funcional para la jerarquización del sistema, en particular,
diagramas de contexto y de flujo de datos de nivel 0 hasta el nivel que sea requerido,
para especificar completamente el sistema. Los archivos de datos son especificados,
así como también los agentes (proveedores o receptores de datos externos al sistema).

El problema de este modelo es que es una caja negra, los procesos poseen entradas y
salidas pero no se especifica la forma de hacer las cosas. Se centra en los datos y no
en el proceso. Por lo tanto no resulta adecuado para el modelamiento de procesos,
pero si para los sistemas [15].

1.1.2 IDEF (Integrated DEFinition Methods)

Es un conjunto de métodos para el modelamiento de procesos, fue desarrollado, a partir
de 1970, por el Departamento de Defensa de EEUU. Actualmente son mantenidos por
Knowledge Based Systems Inc, empresa dedicada a la investigación de tecnologías.

Los métodos se clasifican de acuerdo al tipo de modelamiento que se quiera realizar
[32]:

IDEFØ: Es un método diseñado para modelar las decisiones, acciones y actividades de
una organización o sistema, es derivado de SADT.

11



Figura 3: Representación gráfica de IDEF0
2


En la figura 3, el cuadro representa a la función o actividad del sistema u organización,
las flechas de la izquierda son las entradas, las de la derecha las salidas. Las flechas
por sobre el cuadro corresponden a controles sobre la función y las flechas por debajo
corresponden a los mecanismos. Al conjunto de entradas, salidas, controles y
mecanismos se les denomina ICOM.

IDEFØ produce una representación organizada de las funciones y actividades y es
independiente del tiempo y la organización. Captura lo que se hace o no se hace y
utiliza la noción de descomposición funcional para modelar las actividades o funciones.
La descripción de los detalles y la temporalidad de los procesos se especifica utilizando
IDEF3.

IDEF1: Es un método de modelamiento de la información. Un modelo de información
representa la estructura y semántica de la información dentro del sistema u
organización modelada. Generalmente se utiliza para identificar qué información es la
que actualmente es gestionada por la organización, determinar cuáles problemas son
causados por falta de información y especificar qué información será administrada en la
implementación.

IDEF1X: Es un método para diseñar bases de datos relacionales, posee una sintaxis
diseñada para soportar construcciones semánticas necesarias para desarrollar
esquemas conceptuales. Un esquema conceptual es una definición integrada de un
dato de la organización independiente de su representación computacional.

IDEF3: Es un método que provee los mecanismos para capturar y documentar
procesos. IDEF3 captura el comportamiento, la precedencia y las relaciones de

2
Fuente: http://www.idef.com/idef0.html [consulta: 22 de Marzo de 2006]
12

causalidad entre situaciones y eventos. Permite expresar el conocimiento sobre como
un sistema, los procesos o la organización trabaja.

El método contempla dos modalidades: flujo de procesos y redes de estado-transición
de objetos. La primera modalidad captura el conocimiento de cómo los componentes
funcionan en una organización, la segunda resume las transiciones permitidas para un
objeto a través de un proceso particular.

IDEF4: Es un método de diseño orientado a objetos que apoya la correcta aplicación de
la programación orientada a objetos. IDEF4 provee un marco para el desarrollo de
software con orientación a objetos. Conceptualmente, consiste en dos submodelos: el
de clases y el de métodos. El submodelo de clases contiene los diagramas de tipos,
herencia, protocolos e instanciación. El submodelo de métodos contiene los diagramas
de taxonomía para los métodos y los diagramas de contratos y clientes.

IDEF5: Es un método específicamente diseñado para apoyar la creación, modificación y
mantención de ontologías.

1.1.3 Ciclos de Trabajo

El modelo de ciclos de trabajo fue desarrollado por la empresa Action Tech en torno a la
semántica de compromisos y cumplimiento [31]. Los procesos son redes de acciones y
compromisos. El ciclo parte desde un cliente con una petición a un ejecutor, luego el
cliente y el ejecutor negocian la realización (promesas mutuas), el ejecutor realiza las
acciones para cumplir sus promesas, declarando el termino del trabajo. Por último, el
cliente realiza la acción de satisfacción, de acuerdo a las promesas (condiciones de
satisfacción) [31]. En la figura 4, se muestra la representación gráfica de este modelo.



Figura 4: Representación gráfica del modelo de ciclos de trabajo
3


3
Fuente: VARAS, SAMUEL. 2003. Apuntes del curso “Tecnologías de Información y Rediseño de Procesos”.
Departamento de Ingeniería Industrial. Universidad de Chile.
13

1.1.4 UML (Unified Modeling Language)

UML es un leguaje gráfico para visualizar, especificar, construir y documentar todos los
artefactos de un sistema de software [10]. Cubre aspectos conceptuales, como
procesos de negocio y elementos concretos: clases, esquemas de bases de datos, etc.
La característica de UML es que es orientado a objetos. Las representaciones son
realizadas mediante diagramas, existiendo varios tipos [10]:

1. Diagrama de clases: Es la representación de los bloques de construcción más
importantes del sistema y sus relaciones. La unidad básica es la clase, que es
una descripción de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semántica.

2. Diagrama de objetos: Los diagramas de objetos modelan las instancias de los
elementos contenidos en los diagramas de clases. Muestran los objetos y sus
relaciones en un momento concreto, congela un instante en el tiempo de
ejecución.

3. Diagrama de casos de uso: Un caso de uso especifica el comportamiento de un
sistema o parte del mismo. El diagrama corresponde a una descripción de un
conjunto de secuencias de acciones donde cada secuencia representa la
interacción de los elementos externos del sistema con el propio sistema. Un caso
de uso representa un requerimiento funcional del sistema.

4. Diagrama de secuencia y de colaboración: Se utilizan para modelar aspectos
dinámicos de un sistema. Consiste en un conjunto de objetos y sus relaciones,
incluyendo los mensajes que se pueden enviar entre ellos. Los diagramas de
secuencia destacan el orden temporal de los mensajes, los de colaboración
destacan la organización estructural de los objetos que envían y reciben
mensajes. Ambos diagramas son semánticamente equivalentes.

5. Diagrama de estados: Describen gráficamente los eventos y los estados de los
objetos. A la relación entre dos estados se le llama transición, e indica, que
cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.

6. Diagrama de actividades: Se usan para modelar los aspectos dinámicos de un
sistema, mostrando el flujo de control entre actividades. Este tipo de diagrama es
una especialización de los diagramas de estado, organizados respecto de las
acciones. Son usados para especificar: métodos, casos de uso, procesos de
negocio.

7. Diagrama de componentes: Muestra las relaciones entre los componentes de un
sistema, es decir la interacción de la parte física y reemplazable de un sistema,
que conforma un conjunto de interfaces y proporciona la realización de dicho
conjunto.

8. Diagrama de despliegue: Describe la arquitectura física del sistema durante la
ejecución, en términos de: procesadores, dispositivos, componentes de software.
14

Además, describen la topología del sistema, la estructura de los elementos de
hardware y software que ejecuta cada uno de ellos.

1.2 Proceso de Planificación Estratégica

Para abordar los procesos de planificación estratégica es necesario realizar la distinción
entre estrategia y el proceso de formación de la estrategia. Entenderemos por
estrategia de negocio, a un conjunto bien coordinado de programas de acción que
apuntan a asegurar una ventaja sostenible en el largo plazo. Un proceso de formación
de la estrategia es un conjunto de actividades tendientes a definir la estrategia de un
negocio, las prioridades y asignación de recursos y los programas de acción generales
[11]. Un proceso de planeación estratégica, consiste en:

a) La definición y declaración de la misión y la visión.
b) El análisis del medio externo e interno.
c) La formulación de los planes y programas generales de acción, incluyendo la
estrategia del negocio.
d) La programación y evaluación de los programas de acción propuestos y fijación
de las prioridades para la asignación de los recursos.
e) La asignación de recursos y la elaboración del presupuesto.

La figura 5 presenta el aspecto general del proceso.



Figura 5: Modelo de planeación estratégica
4



4
Fuente: JORRAT, MICHAEL. 2000. Apuntes del curso “Evaluación de Proyectos”. Departamento de Ingeniería
Industrial. Universidad de Chile.
15

Existen herramientas que facilitan el proceso de planeación estratégica. Para el análisis
del medio externo se utiliza ampliamente el modelo de las cinco fuerzas de Porter,
representado en la figura 6, el que esencialmente postula que hay cinco fuerzas que
conforman la estructura de una industria: intensidad de la rivalidad de los competidores,
amenaza de nuevos participantes, amenaza de sustitutos, poder de negociación de los
compradores y el poder de negociación de los proveedores. Estas cinco fuerzas
delimitan, precios, costos y requerimientos de inversión, que constituyen factores
básicos que explican la expectativa de rentabilidad de largo plazo y por lo tanto, el
atractivo de la industria [11]. Otras herramientas son, por ejemplo: el análisis financiero,
el análisis de factores externos, etc.



Figura 6: Representación gráfica del modelo de las 5 fuerzas de Porter
5


Para el análisis interno, es decir, el examen sistemático de los modos que tiene un
negocio para lograr una ventaja competitiva, es ampliamente utilizado el concepto de
cadena de valor [11].

La cadena de valor es la caracterización de las actividades realizadas por una unidad
estratégica de negocios [11]. Las tareas son clasificadas en actividades primarias y
actividades de apoyo. Las actividades primarias son aquéllas relacionadas con el
movimiento físico de materias primas y productos terminados, en la producción de
bienes y servicios [11]. Las actividades de apoyo, como su nombre lo índica, apoyan las
actividades primarias y establecen una infraestructura para el funcionamiento de una
empresa.

En la figura 7, las actividades primarias de la cadena son la logística de entrada y
salida, las operaciones, el servicio, el marketing y ventas. Las actividades de apoyo son

5
Fuente: Fuente: JORRAT, MICHAEL. 2000. Apuntes del curso “Evaluación de Proyectos”. Departamento de
Ingeniería Industrial. Universidad de Chile.
16

representadas por las adquisiciones, el desarrollo de tecnología, el manejo de recursos
humanos y la infraestructura de la firma.



Figura 7: La cadena de valor
6



En el ámbito de la informática, la planeación estratégica consiste en la identificación e
implementación de la tecnología requerida por el negocio para la consecución de su
misión, objetivos y estrategias [8].

Las herramientas mencionadas anteriormente, apoyan la formulación de la estrategia
informática desde la perspectiva de entender el negocio para conseguir el alineamiento
de las iniciativas tecnológicas. Por lo tanto, el resultado de la planeación en informática,
tiene relación con la manera con que son gestionados los recursos de TI, la arquitectura
informática del negocio, el portafolio de proyectos, el presupuesto y el plan de
infraestructura.

1.3 Modelos y Prácticas para Procesos de Software

Existen dos modelos, ampliamente utilizados en la industria, que entregan un marco de
referencia para los procesos de software: CMMi e ISO. Ambos, proveen una guía para
mejorar los procesos de la organización y por lo tanto tienen el efecto de producir
mejoras en la calidad de los productos y servicios.

Para este proyecto, se escogerá uno de los modelos, el que será tomado como marco
de referencia para definir procesos básicos de producción de software. Si bien, existen
diversas metodologías, el objetivo final en esta etapa es concentrarse en los procesos
globales más que en el detalle.


6
Fuente: Fuente: JORRAT, MICHAEL. 2000. Apuntes del curso “Evaluación de Proyectos”. Departamento de
Ingeniería Industrial. Universidad de Chile.
17

Los modelos entregan un marco sobre el cual se pueden obtener las definiciones para
afrontar los procesos de software. A continuación se presenta una breve descripción de
ambos.

1.3.1 CMMi (Capability Maturity Model Integration)

El modelo, desarrollado por la Universidad de Carnegie-Mellon, tiene como propósito
proveer una guía para mejorar el proceso de una organización y la capacidad para
administrar el desarrollo, adquisición y mantención de productos y servicios [7]. Ayuda a
la organización a examinar la efectividad de sus procesos y establece las prioridades de
mejoramiento [30]. Provee una terminología común y una metodología integrada para la
auditoria de los procesos [30]. Desde el punto de vista del negocio, CMMi, beneficia a la
organización en:

a) Reducir la integración de sistemas y el tiempo de pruebas.
b) Permitir la integración entre varias funciones y ámbitos de la ingeniería.
c) Emplear principios de ingeniería de sistemas para el desarrollo de software.

Desde el punto de vista técnico, los principales beneficios son:

a) Focalización en la gestión y desarrollo de los requisitos.
b) Focalización en el diseño y desarrollo.
c) Incorporación de la gestión de riesgos.
d) Incorporación de medidas y análisis de métricas.

CMMi define cuatro disciplinas: ingeniería de software, ingeniería de sistemas,
proveedores y desarrollo integrado de procesos y productos [30]. Provee 5 niveles de
madurez donde cada nivel es una capa en la fundación para un proceso de
mejoramiento continuo, comenzando por prácticas y áreas de proceso básicas de
administración y progresando a través de un camino predefinido y probado de niveles
sucesivos [30]. Cabe señalar que en la medida que se avanza en madurez, la calidad y
productividad aumenta y el re-trabajo junto con el riesgo van disminuyendo. En la tabla
3 se presenta un resumen del modelo.

18



Tabla 3: Los niveles de madurez y las áreas de proceso de CMMi
7


1.3.2 Normas ISO

ISO es una organización mundial de cuerpos de estandarización a nivel mundial. Su
misión es proveer estandarización internacional para facilitar el intercambio de bienes y
servicios [1]. Para el caso de los procesos de Tecnologías de Información, pueden ser
aplicables dos normas: ISO 9000:2000 de carácter general e ISO 9126 para ingeniería
de software, las que son revisadas a continuación.

1.3.2.1 ISO 9000:2000

Es un conjunto de normas utilizadas para establecer la gestión de calidad de una
organización, satisfacer los compromisos entre la organización y sus clientes y lograr
mejoramiento en el desempeño de una empresa [1]. Se compone de 3 partes:

a) ISO 9000, que describe los fundamentos y la terminología.
b) ISO 9001, que describe los requisitos.
c) ISO 9004, referente a las directrices para la mejora del desempeño.

Dentro de los beneficios esperados de la adopción de este modelo, se encuentran:
mejor control de la gestión, mayor facilidad para eliminar y percibir los problemas de
procedimiento, aumento de la eficacia y una mejor percepción de los problemas de
calidad [1].


7
Fuente: PINTO, FERNANDO. 2004. Apuntes del curso “Introducción a CMMi”. Departamento de Ciencias de la
Computación. Universidad de Chile.
19

ISO 9000, define una serie de requisitos que se orientan a la elaboración y mantención
de procedimientos relacionados con el producto y el proceso. Lo que se alcanza,
mediante la implantación de un sistema de gestión de calidad y la obtención como
resultado final del manual de calidad.

Si bien, la norma es aplicable a procesos de software, por su carácter general, no
define guías ni opciones que provean una referencia para ese tipo de procesos.

1.3.2.2 ISO 9126 para Ingeniería de Software

Esta norma está compuesta de 4 secciones:

1. ISO 9126-1:2001, que provee el modelo de calidad que clasifica al software en
seis grandes atributos de calidad [1]:

a) Funcionalidad, que contempla los siguientes atributos: pertinencia, precisión,
interoperabilidad, adherencia, seguridad.
b) Confiabilidad que contempla los siguientes atributos: madurez,
recuperabilidad, tolerancia a fallos.
c) Usabilidad, que contempla los siguientes atributos: entendibilidad,
aprendibilidad, operatividad, aceptación de uso.
d) Eficiencia, que contempla los atributos de rendimiento y uso de recursos.
e) Mantenibilidad, que contempla los atributos: analizabilidad, cambiabilidad,
estabilidad, demostrabilidad.
f) Portabilidad, que contempla los atributos: adaptabilidad, instanciabilidad,
adecuación, reemplazabilidad.

2. ISO 9126-2:2003, que provee métricas externas para la medición de las seis
características de calidad definidas en ISO 9126-1. Las métricas externas, miden
el comportamiento de un sistema computacional que incluye el software y las
mediciones de la calidad, en el uso bajo un contexto específico [33].

3. ISO 9126-3:2003, que provee métricas internas para la medición de las seis
características de calidad definidas en ISO 9126-1. Las métricas internas miden
el software como tal, bajo los procesos de requisitos, evaluación de productos y
medidas de calidad [33].

4. ISO 9126-4:2004, que provee métricas para medir el uso de calidad de los
procesos de ingeniería de software [33].

1.4 ITIL (IT Infraestructure Library)

ITIL fue desarrollado a fines de 1980 por la Oficina de Comercio (OGC) del Reino Unido
y es un conjunto de las mejores prácticas comúnmente aceptadas por la industria para
la provisión y administración de servicios de tecnologías de información. Promueve un
enfoque desde la perspectiva de la calidad, para conseguir efectividad en el negocio y
eficiencia en el uso de los sistemas de información [26]. Se basa en la experiencia
20

colectiva de organizaciones gubernamentales y comerciales a nivel mundial, lo que ha
convertido a este framework en un estándar de facto de la industria [26].

Define cuatro áreas de macro procesos que a su vez definen procesos de negocio para
la función de tecnologías de información, estos son [26]:

1. Service Support: El objetivo de este macro proceso es definir y entregar los
procesos relacionados con el soporte al servicio de informática, vale decir:
gestión de incidencias, gestión de problemas, gestión del inventario y la
configuración, gestión del cambio, control y distribución de hardware y software.

2. Service Delivery: El objetivo de este macro proceso es definir y entregar los
procesos relacionados con la entrega del servicio de informática, vale decir:
gestión de la disponibilidad, gestión de la continuidad, gestión de los niveles de
servicio, gestión de las finanzas TI, gestión de la capacidad y la gestión de
proveedores.

3. Infraestructure & Security Management: El objetivo de este macro proceso es
definir y entregar los procesos relacionados con la administración de la
infraestructura y la seguridad de aplicaciones, redes y servicios.

4. Application Management: El objetivo de este macro proceso es definir y entregar
un ciclo de vida del software que permita el alineamiento con el negocio. La
gestión e implementación puede ser llevada a cabo con metodologías orientadas
al desarrollo, mantención y adquisición de software. Pero, no define ni
compromete prácticas para el proceso de producción de software, las que han de
ser seleccionadas o definidas según cada organización.

1.5 Criterios de Selección de Herramientas

Para efectos de este trabajo y dentro del conjunto de métodos presentados para el
modelamiento de procesos, se debe seleccionar uno o una combinación de ellos. Los
criterios de selección de la herramienta a utilizar son los siguientes:

a) La herramienta debe estar orientada al modelamiento de procesos de negocio.
b) Debe ser de fácil comprensión y lectura para una persona que no se encuentre
capacitada en su uso.
c) Debe capturar el detalle y las relaciones de flujos de trabajo entre las diferentes
etapas del proceso y proveer una estructura para priorizar acciones.
d) Debe ser ampliamente utilizada, en lo posible un estándar.
e) Debe proveer los elementos semánticos y gráficos para modelar las decisiones,
acciones y actividades.

Para el caso del proceso de desarrollo de software, se especificará más adelante el
modelo o estándar a utilizar, sin embargo, es importante señalar los criterios de
selección:

a) Debe ser un modelo o estándar de la industria.
21

b) Debe promover la mejora continua de procesos y productos.
c) Debe estar orientado al proceso de producción de software.
d) Debe proveer un mecanismo de evaluación de madurez de los procesos.

Por último, para los procesos de planeación estratégica, es claro que se deben tomar
elementos que permitan su aplicación al ámbito de la informática, en ese sentido, el
criterio es utilizar una combinación de las herramientas comúnmente utilizadas de
planificación.

2. Metodología
2.1 Enfoque de Trabajo

Este trabajo, consiste en el cambio y redefinición de los procesos de negocio del área
de tecnologías de información del holding de empresas. Siendo el desafío el
transformar a la organización inicial de TI desde unidades no sinérgicas distribuidas a
una unidad de servicios con orientación al cliente, planteando procesos que sean
acordes a la cultura y realidad de la empresa y que estén basados en modelos y/o
estándares de la industria, sin que las empresas clientes sufran un alto impacto en el
servicio que actualmente están recibiendo.

Existen varias aproximaciones para afrontar el cambio de los procesos en la
organización, en particular, existe una serie de conceptos que son utilizados
indistintamente para representar el fenómeno de cambio de los procesos del negocio,
por ejemplo: reingeniería de procesos de negocio, mejoramiento de procesos,
transformación del negocio, innovación de procesos y rediseño de procesos de negocio.
Pero, ¿Qué es el cambio de los procesos de negocio? Existen, una serie de
definiciones, que ayudan a entender este fenómeno [15]:

a) Es el rediseño y replanteamiento radical de los procesos de negocio para
alcanzar mejoras dramáticas de rendimiento.
b) Es la reconfiguración del negocio usando TI como eje central.
c) Es el análisis y diseño de workflows y procesos basados en equipos dentro o
entre organizaciones.
d) Es una iniciativa estratégica de la organización para (re)diseñar los procesos de
negocio para alcanzar ventajas competitivas, distinguiendo el alcance desde la
mejora de procesos hasta el diseño de nuevos procesos, contingentes al grado
de cambio socio-tecnológico requerido.

Para afrontar proyectos que significan cambios en los procesos de negocio, se utiliza
ampliamente el enfoque de re-ingeniería. La re-ingeniería es definida como el rediseño
radical de los procesos de negocio transversales a una organización con el objetivo de
obtener ganancias o ahorros en uno o más órdenes de magnitud, usualmente apoyado
por tecnologías de información. Otra definición, ve a la re-ingeniería como una
transformación organizacional general [14].

22

Cabe señalar, que uno de los aspectos importantes de la re-ingeniería es que parte de
procesos de negocio que se encuentran en funcionamiento, en contraste con la
innovación de procesos, que parte de procesos que no existen o no han sido definidos.

Como este proyecto se desarrollará en una organización en funcionamiento, en la que
se introducirán cambios, se plantea el uso de un enfoque de re-ingeniería de procesos.
Esta metodología establece los siguientes pasos generales [14]:

1. Definición del proceso a ser estudiado.
2. Evaluación de la situación actual.
a) Documentar el proceso actual.
b) Diagnosticar patologías.
3. Definición y evaluación de las áreas de rediseño.
a) Explorar opciones de diseño.
b) Diseñar el nuevo proceso.
c) Diseñar la estructura organizacional asociada al proceso.
4. Implantación del rediseño propuesto.
5. Puesta en marcha y operación.
a) Evaluación.
b) Mejora continua.

Entonces, para realizar este proyecto y en concordancia con las necesidades de la
organización, se plantea, a continuación, la estrategia y metodología para el re-diseño
de los procesos y la definición de la estructura organizacional.

2.2 Estrategia del Proyecto

La estrategia del proyecto es la definición de la manera en cómo será enfrentado este
trabajo, por lo tanto, es necesario distinguir entre las actividades propias del proyecto y
las actividades de gestión del proyecto.

2.2.1 Actividades de Gestión del Proyecto

Para la dirección general del proyecto, la empresa ha definido la formación de un
comité ejecutivo compuesto del Gerente de servicios TIC, el Gerente General de la
empresa de Servicios Compartidos y el Gerente representante de la empresa de
consultoría. La función de este comité es velar por el cumplimiento de los objetivos del
proyecto y resolver las diferencias de alto nivel que puedan surgir producto de las
definiciones que se tomarán.

El equipo de proyecto, estará compuesto por un jefe de proyecto por parte del área de
tecnologías de información y que reporta al Gerente de servicios TIC, un jefe de
proyecto por parte de la empresa consultora y un grupo de dos ingenieros consultores.
El equipo extendido de proyecto contempla la participación del Gerente de servicios TIC
y el personal que haya sido escogido como Subgerente o Jefe para cada área a definir.
La función del equipo de proyecto, es definir e implementar los procesos y
procedimientos de la nueva organización de tecnologías de información.
23


El seguimiento del proyecto se hará mediante reuniones semanales de coordinación del
equipo de proyecto y reuniones mensuales del comité ejecutivo. Todas las reuniones
generaran minutas, las que deberán ser aprobadas. Además, se llevará un control
respecto al cumplimiento de compromisos, tanto interno como externo y un control de
riesgos del proyecto.

El plan comunicacional del proyecto se ajustará a lo que sea indicado por el comité
ejecutivo. Sin embargo, se ha definido el siguiente conjunto mínimo de comunicaciones
a la organización:

a) Inicio del proyecto.
b) Estado de situación después de 1 mes de ejecución.
c) Difusión de la nueva organización.
d) Estado de situación después de 1 mes de difundida la organización.
e) Estado de situación mensual dentro de la etapa de transición.
f) Estado de situación una vez que la nueva organización sea considerada que se
encuentra en régimen.

Los comunicados se entregarán mediante un boletín impreso a todo el personal del
área de tecnologías de información. Además, serán publicados electrónicamente para
facilitar la difusión. En el caso de la difusión de la organización, se realizará una reunión
plenaria con todo el personal de tecnologías de información, los cargos serán
comunicados personalmente por cada Subgerente de área.

Para la difusión de los procesos, se ha contemplado una serie de presentaciones,
primero a nivel de todo el personal, para dar a conocer el contexto global y luego a nivel
de cada área, o grupos de áreas en caso de que el proceso relacione a más de una. Se
contempla la participación y difusión a las jefaturas, quienes posteriormente deberán
capacitar al personal que tienen a cargo.

2.2.2 Actividades Propias del Proyecto

En concordancia con el enfoque de re-ingeniería de procesos, el proyecto se plantea en
cuatro fases, estas son:

Fase 1: Levantamiento

Durante esta fase se realiza la evaluación y levantamiento de la situación actual, con el
objeto de entender la problemática de la organización. Se diagnostican las patologías y
se rescatan los procesos o elementos que puedan servir para la nueva organización. La
obtención de la información será a través de entrevistas con personal clave de cada
área y la obtención de documentación previa según sea el caso.

En el capítulo 1, se ha presentado un resumen de los puntos más relevantes del
levantamiento de la situación inicial.


24

Fase 2: Definición, Análisis y Diseño de Procesos

En esta fase, se definirán los procesos, servicios y la estructura organizacional. Se
utilizará como marco de referencia el modelo ITIL. En el caso del software, se utilizará
un modelo de acuerdo a la selección que se propondrá más adelante en este capítulo.
Los resultados de esta etapa son presentados en el capítulo 3.

Esta actividad, será realizada en conjunto con la Gerencia TIC y el personal que sea
designado como líder de la nueva estructura. El resultado de esta etapa son los
procesos, la organización y la planificación estratégica del área TIC. Se presentarán los
procesos definidos en esta etapa en forma global.

Fase 3: Transición

La fase de transición consiste en la puesta en marcha, implementación y adopción
paulatina de los procesos mediante un plan de transición y cambio. Este será
presentado en el capítulo 5.

Junto con lo anterior, se implementa la nueva estructura organizacional, la que será
presentada en el capítulo 4.

Fase 4: Prestación de Servicios

En esta fase el servicio se encuentra en operación. Sin embargo, es necesario definir
procesos de mejora continua con el objeto de entregar servicios que sean mejores en el
tiempo. En el capítulo 6, se planteará una estrategia para la mejora del proceso de
software, cuya intención es dar pie para la definición y adopción de procesos de mejora
continua en el futuro.

2.3 Selección de Herramientas Metodológicas

De acuerdo a los criterios de selección de herramientas mencionados en el punto 1.5,
para el modelamiento de los procesos se utilizará IDEFØ y eventualmente algunos
elementos de UML, con el objeto de clarificar las representaciones. La elección se basa
en que IDEFØ es una herramienta orientada al modelamiento de procesos, es
ampliamente utilizada y de fácil comprensión. En cambio SADT solamente contempla
un enfoque que es respecto a los sistemas. El modelo de ciclos de trabajo no captura el
detalle de los procesos, si no que más bien las relaciones de tipo conversacional que se
producen. Por otro lado, UML entrega un marco general para el modelamiento de
sistemas, procesos y sus relaciones, lo que lo hace bastante entendible y completo.

Para los procesos de software, se revisaron dos modelos ampliamente utilizados: ISO
9000 y CMMi. El problema de ISO es que al ser de carácter general no se encuentra
orientado para resolver la definición de los procesos de software y debe ser interpretado
para ser adaptado a esta realidad, en cambio CMMi está pensado para solucionar dicha
problemática.

25

CMMi provee de un método de evaluación de madurez, en cambio ISO 9000, se
preocupa solamente del cumplimiento de una serie de requisitos a alcanzar. En el caso
de ISO 9126, que si está enfocado a software, solamente se concentra en los atributos
para productos de software, pero no en los procesos, argumentando que una mejor
evaluación de los atributos de calidad implica tener procesos mejores, sin embargo,
estos no son definidos por el estándar. En contraste, CMMi establece una guía para los
procesos y su institucionalización.

Por lo tanto, es claro que CMMi posee ventajas para la definición de los procesos de
software, proveyendo una guía, cumpliendo con los criterios de selección mencionados
anteriormente, por ello, se utilizará como marco de referencia para la definición de los
procesos básicos de software.

En el caso del proceso de planeación estratégica se han revisado una serie de
actividades que tienen relación directa con un negocio. Si bien, un área de informática,
puede ser un negocio, el enfoque a considerar es el de apoyo, porque en este caso, se
está entregando un servicio a un conjunto de empresas dentro de un marco global de
una cartera de servicios. En definitiva, lo que hay que plantear es una metodología que
permita al servicio TIC apoyar a las empresas clientes en la elaboración de un plan
informático, teniendo en consideración los siguientes elementos:

a) La definición y declaración de la misión y la visión.
b) El análisis de la situación actual de TI.
c) La formulación de los planes y programas generales de acción, es decir: la
estrategia de gestión de recursos de TI, la arquitectura informática del negocio, el
portafolio de proyectos, el presupuesto y el plan de infraestructura.
d) La programación y evaluación de los planes de acción propuestos y la fijación las
prioridades para la asignación de los recursos.
e) La asignación de recursos y elaboración el presupuesto.
26

Capítulo 3 – Diseño de Servicios y Procesos

1. Diseño de Servicios
1.1 Servicios TIC

El catálogo de servicios, es el conjunto de servicios que se proveerán a las filiales. El
objetivo es entregar a los clientes una visión de la oferta de servicios TIC, su definición
y su disponibilidad.

La idea general, es que los servicios sean entregados integralmente, de manera tal, que
los clientes finales no se tengan que preocupar de la contratación y la gestión, incluso,
con terceros proveedores [5]. Por ejemplo, si una persona es contratada, el PC será
provisto por el servicio compartido, quien luego realizará el cobro respectivo a la
empresa cliente.

Para simplificar, los servicios pueden ser clasificados de la siguiente manera:

a) Servicio fijo, es decir, son todos los servicios informáticos requeridos para que un
usuario pueda realizar sus labores habituales dentro de su organización. Por
ejemplo: PC, teléfono, sistemas de apoyo, impresoras, etc.
b) Servicios variables, es decir, servicios que son requeridos por el usuario sin ser
permanentes su consumo en el tiempo. Por ejemplo: el uso de la mesa de ayuda,
las mantenciones de corto plazo, etc.
c) Servicios de valor agregado, es decir, los servicios que agregan valor y producen
el cambio dentro de una organización. Por ejemplo: los proyectos que
implementan software nuevo, la propia gestión de las tecnologías de información,
las mantenciones que significan una evolución en el software que está en
funcionamiento, etc.

Esta clasificación tiene por objetivo facilitar el entendimiento de los usuarios respecto a
los servicios ofrecidos por TI. Otra opción, puede ser una categorización de carácter
técnico, pero no tendría sentido ya que tendería a confundir a los clientes más que
aclararlos.

Los servicios que se presentan en la tabla 4, están basados en la definición comercial
que ha tomado la empresa. Si bien, pueden haber servicios que sean requeridos y que
no estén dentro del catálogo, estos eventualmente, pueden ser creados o contratados a
terceros, previa evaluación técnico-económica.

Para cada tipo de servicio, se pueden definir agrupaciones y subservicios, lo que define
finalmente la oferta y por lo tanto el catálogo de servicios. La disponibilidad de los
servicios será abordada en la sección de niveles de servicio.

27



Tabla 4: El catálogo de servicios
8


8
Fuente: Documento Interno. 2004. Catálogo de Servicios para un holding de empresas forestales. Empresa Forestal
Chilena.
28

1.2 Modelo de costos de los servicios

El objetivo es establecer un marco agregado para los costos, con la finalidad de
simplificar el entendimiento a los clientes finales, respecto a la facturación de los
servicios recibidos durante un periodo.

Para definir el modelo de costo de los servicios, revisaremos cuales son las
componentes sujetas a costo, considerando que:

a) Los PC, notebook, servidores, impresoras y equipos de redes pueden ser
arrendados a terceros.
b) Los servicios de impresión poseen un costo fijo y un costo variable.
c) Los servicios de comunicaciones son contratados a terceros y se rigen de
acuerdo a lo que ofrece el mercado.
d) El costo de las mantenciones correctivas es asumido por el servicio, como parte
de la garantía del software.
e) Los servicios básicos (agua, luz, electricidad, etc.) son de costo de la empresa
que recibe el servicio.
f) Pueden existir servicios de carácter corporativo y que pueden ser recibidos por
varias empresas simultáneamente.
g) Pueden existir servicios de carácter particular y que pueden ser recibidos por una
empresa.
h) Los costos de los servicios pueden ser de carácter mensual o por única vez.

Distinguiremos los costos entre gasto e inversión. La diferencia es que una inversión es
para bienes nuevos, realizada por única vez y considerada contablemente como un
activo de la organización. En cambio, el gasto es de carácter permanente o temporal y
se realiza sobre servicios y bienes ya adquiridos. Entonces, cada tipo de costo se
puede agrupar de manera tal de establecer un marco para el modelo:

1. Las inversiones agruparan los siguientes tipos de costo:
a) Licencias de software.
b) Obras civiles.
c) Instalación de redes de datos y telefonía nuevas.
d) Hardware.
2. Los gastos contendrán los siguientes tipos de costo:
a) Consultoría, que corresponde al costo hora-hombre de realizar una
actividad para una filial, esta puede ser interna o contratada a terceros.
b) Arriendo de equipos.
c) Servicios de terceros bajo contrato permanente ya sea de carácter
temporal o indefinido.
d) Mantención de redes de datos y telefonía.
e) Mantención de hardware.
f) Viajes, viáticos y alimentación.

Luego, para cada tipo de servicio, los costos se pueden desglosar de manera tal de
definir su aplicabilidad de acuerdo a la tabla 5.

29



Tabla 5: Criterios para la aplicabilidad de costos a los servicios

Cabe señalar que dependiendo de la naturaleza del contrato de servicio, las
componentes mencionadas pueden o no presentarse.

Para el cálculo del costo final, es necesario diferenciar entre servicios que son provistos
corporativamente, es decir, aquellos en que se utiliza una infraestructura tecnológica
común y por lo tanto podrían ser prorrateados y servicios que son costeados localmente
para cada filial, es decir, aquellos que se proveen con la infraestructura tecnológica
propia de la filial o son dirigidos puntualmente a esta.



30

El factor de prorrateo puede ser calculado según las siguientes opciones:

a) Por número total de trabajadores de la filial.
b) Por número total de trabajadores que tienen computador.
c) Por número total de computadores, no considerando equipos servidores, es
decir, solo PC y notebooks.

La elección de una u otra opción dependerá del ámbito del servicio que se está
prorrateando. En la tabla 6, se presenta cada servicio con una propuesta para el criterio
de prorrateo. El tipo de costeo es directo, cuando el costo es generado directamente
por la filial.



Tabla 6: Criterios para aplicar prorrateo a los costos de los servicios

Con esto, se ha establecido un modelo que permite el entendimiento y la asignación de
los costos a los distintos servicios definidos.

31

1.3 Niveles de Servicio

Para definir los niveles de servicio, es necesario entender la problemática desde el
punto de vista del cliente final. En general, las personas perciben los servicios de
informática desde el punto de vista del resultado, vale decir, evalúan en términos
absolutos lo que reciben, sin haber términos medios, ni considerar elementos técnicos
dentro de la evaluación. Bajo este paradigma, conviene definir niveles de servicio
respecto a la disponibilidad global de los servicios entregados, dentro de un
determinado tiempo y que resguarden la posibilidad de falla del servicio. El problema es
encontrar el indicador adecuado.

Para resolver lo anterior, se puede utilizar la agrupación de servicios propuesta en el
catálogo de servicios y definir una segmentación de los usuarios, tomando en cuenta
que por la naturaleza de los procesos de negocio de las filiales, no todos requieren los
mismos niveles de servicio. Para determinar los distintos segmentos, existen dos
criterios que se pueden utilizar:

a) El impacto sobre el negocio de una persona que frente a una pérdida de servicio
deja de realizar sus labores o traba procesos productivos o del negocio.
b) La sensibilidad de una persona y/o la llegada sobre la alta dirección de la
empresa cliente, es decir, su capacidad de reclamo ante la gerencia, frente a
pérdidas de servicio.

Tal como se aprecia en la figura 8, estos componentes permiten identificar cuatro
segmentos distintos de usuarios:

a) Usuario Normal: Es una persona que no necesariamente posee una alta
jerarquía dentro de la empresa y que frente a una pérdida de servicio TI, el
impacto sobre el negocio es bajo. Esta categoría, agrupa a usuarios de tipo
administrativo.
b) Usuario Crítico: Es una persona que no necesariamente posee una alta jerarquía
dentro de las empresas, pero que frente a una pérdida de servicio TI, produce
un alto impacto sobre el negocio. Esta categoría, agrupa a usuarios que tienen
directa relación con los procesos de ventas, facturación, operación y productivos
de las filiales.
c) Usuario Especial: Es una persona que no necesariamente posee una alta
jerarquía y que frente a perdidas de servicio no produce impacto en el negocio,
sin embargo, tiene llegada con la alta dirección o posee una alta capacidad de
reclamo. Esta categoría, agrupa a usuarios que serán identificados respecto a su
comportamiento de reclamo.
d) Usuario VIP: Es una persona que posee una alta jerarquía dentro de las filiales y
que posee una alta capacidad de reclamo y que frente a perdidas de servicio TI
produce un alto impacto en el negocio. Esta categoría, agrupa a Gerentes y
Subgerentes.


32



Figura 8: Segmentación de los usuarios

Para el caso de los servicios fijos, la idea es definir un único indicador de disponibilidad
que capture el comportamiento global de los servicios recibidos por el usuario. Cada
servicio que compone el servicio fijo, tiene una no disponibilidad dentro de un periodo
de tiempo y una importancia relativa, que en principio es asignada por el usuario. Por
ejemplo, para un operador de etiquetaje de productos, es más importante que funcione
la impresora de etiquetas a que funcione Internet.

Entonces, sea
i
ND la no disponibilidad del servicio i dentro de un horizonte de tiempo t
, medido en horas, e
i
I la importancia relativa del servicio i . El tiempo de no
disponibilidad del servicio fijo (TND), será la suma de cada no disponibilidad ponderada
por la importancia relativa da cada servicio, es decir:

¯
=
× =
n
i
i i
I ND TND
1


Ecuación 1: Tiempo de no disponibilidad de los servicios fijos

Donde 1 0 s s
i
I y n es la cantidad de servicios que componen el servicio fijo. Luego, el
porcentaje de disponibilidad del servicio fijo es:

100 1 %
1
× |
.
|

\
| ×
÷ =
¯
=
n
i
i i
t
I ND
DSF

Ecuación 2: Porcentaje de disponibilidad del servicio fijo

Pero, ¿cómo se calcula la importancia relativa del servicio? En principio, la importancia
de cada servicio debería ser idealmente asignada por cada usuario, sin embargo, esto
es impracticable en el corto plazo. Por ello, se asignará arbitrariamente una importancia
relativa en relación a la segmentación de los usuarios.
33


Para simplificar la escala de importancia, se definen cinco niveles: alta, media-alta,
media, media-baja y nula. Donde el nivel alto toma el máximo valor de importancia y el
nivel nulo toma el mínimo valor. La importancia media-alta, media y media-baja tomaran
valores intermedios, siendo la importancia media, el valor medio del rango establecido
para
i
I , esto se puede ser en la tabla 7.



Tabla 7: Asignación de valores a la importancia de un servicio

Ahora, se debe asignar la importancia de cada servicio respecto a la segmentación de
usuarios definida, la que se muestra en la tabla 8. El criterio de asignación de la
importancia es respecto al grado de uso estimado por cada tipo de usuario, según el
comportamiento habitual observado empíricamente dentro de las empresas.



Tabla 8: Importancia de los servicios según la segmentación de usuarios

Para el caso del Usuario Especial, el supuesto es que las componentes de servicio
tienen una importancia media ya que a priori no es posible establecer un patrón de
comportamiento previo de los reclamos, por lo tanto el valor medio es el que mejor
podría representar la importancia de los servicios para este tipo de usuario.

Finalmente, los niveles de servicio para los servicios fijos y para cada segmento de
usuarios se han definido de acuerdo a la tabla 9.
34




Tabla 9: Niveles de servicio para los servicios fijos

En el caso de los servicios variables, se debe distinguir entre los que son a pedido y los
orientados al soporte a usuarios y de aplicaciones. Para este caso, se considerará el
service desk, el soporte en terreno y las mantenciones de corto plazo, como servicios
orientados al soporte a usuarios y de aplicaciones. La videoconferencia y los
dispositivos de configuración móvil se considerarán como servicios a pedido, cuyos
niveles de servicio serán los que sean contratados de acuerdo al requerimiento de la
filial.

Existe una serie de indicadores estándares para el service desk, soporte en terreno y el
mantenimiento, tanto desde el punto de vista del servicio como del proceso. Por lo
tanto, el problema es escoger cuales son los indicadores de servicio adecuados, que
aseguren al cliente final que el servicio que está recibiendo se encuentre dentro de
márgenes razonables de agilidad, oportunidad y fluidez.

Desde el punto de vista del cliente, el interés principal es que el requerimiento o
incidente, sea contestado en el menor tiempo posible y que una vez que es registrado
por el service desk, sea resuelto en el menor tiempo posible. En resumen, se puede
construir una línea de tiempo de acuerdo a la figura 9.



Figura 9: Línea de tiempo de un incidente



35

Se distingue entonces:

a) t0: como el tiempo donde se inicia el proceso de soporte y que es gatillado por la
recepción y atención de una llamada en el service desk.
b) ta: como el tiempo en el que se asigno un incidente a un técnico o especialista.
c) tr: como el tiempo de resolución del requerimiento o incidente.
d) ts: como el máximo tiempo que un usuario puede esperar a que su requerimiento
sea resuelto sin reclamar.
e) T1: como el intervalo de tiempo entre la recepción y asignación del incidente o
requerimiento.
f) T2: como el intervalo de tiempo entre la recepción y la solución del
requerimiento.
g) T3: como el intervalo de tiempo de resolución del requerimiento por parte de un
técnico o especialista.
h) TMAX: como el intervalo de tiempo máximo en el que un usuario puede esperar
sin reclamar.

Como no todos los incidentes o requerimientos pueden ser resueltos en TMAX para
todo el universo de usuarios, la idea es apuntar a que un grupo de requerimientos sea
resuelto antes de un cierto periodo de tiempo.

Considerando la segmentación propuesta para los servicios fijos, se puede definir
niveles de servicio escalonados de acuerdo al tipo de usuario que recibe la atención,
según los siguientes supuestos:

a) Usuario Normal: Como el perfil es de tipo administrativo, una pérdida de servicio
no tiene impacto sobre el negocio, su capacidad de reclamo es limitada, por lo
tanto es el que tiene más baja prioridad de atención y niveles de servicio
inferiores a las otras categorías.
b) Usuario Crítico: Como produce un alto impacto sobre el negocio frente a una
pérdida de servicio, es el que tiene mayor prioridad de atención y por lo tanto el
mejor nivel de servicio.
c) Usuario Especial: Esta categoría, debe tener niveles de servicio y prioridad
equivalentes al usuario normal, sin embargo debe considerarse, a nivel del
proceso, un método de excepción, que agilice los tiempos de atención y
modifique prioridades, para el caso en que se detecte que este usuario pueda
establecer un reclamo frente a la alta dirección.
d) Usuario VIP: A pesar de que este segmento posee una alta jerarquía y una alta
capacidad de reclamo y que frente a perdidas de servicio TI produce un alto
impacto, se le asigna la segunda prioridad de atención y los mismos niveles de
servicio que un usuario crítico, ya que el supuesto es que el usuario crítico
corresponde a personas que están ligadas directamente con la operación de las
fábricas, por lo tanto es más impactante para el negocio una pérdida de servicio
para ese tipo de personas, que para un usuario VIP.

Para reflejar la resolución de requerimientos de soporte antes de un periodo de tiempo,
definiremos dos indicadores:

36

a) %RNR4, que corresponde al porcentaje de requerimientos no resueltos antes de
4 horas, sobre el total de requerimientos para el tipo de usuario VIP y crítico.
b) %RNR8, que corresponde al porcentaje de requerimientos no resueltos antes de
8 horas, sobre el total de requerimientos para el tipo de usuario normal y
especial.

El supuesto para estos indicadores, es que un día de trabajo tiene 8 horas, por lo tanto
el objetivo de %RNR4 es incentivar la resolución de requerimientos antes de 4 horas y
%RNR8 antes de 8 horas. Para efectos de cálculo, ambos indicadores serán de
carácter semanal ya que la idea es privilegiar la resolución.

Para el service desk, los indicadores habituales son [22]:

a) Llamadas recibidas, que corresponde al total de llamados recibidos por la central
telefónica del service desk.
b) Llamadas contestadas, que corresponde a las llamadas contestadas por los
agentes del service desk.
c) Llamadas abandonadas, que corresponde a las llamadas perdidas o no
contestadas por los agentes del service desk.
d) Tiempo medio antes de contestar, que corresponde al tiempo promedio en
contestar una llamada por el grupo de agentes del service desk.
e) Tiempo medio de conversación, que corresponde a la duración promedio de una
llamada.
f) Porcentaje de llamadas abandonadas, que corresponde al porcentaje de
llamadas que se abandonaron sobre el total de llamadas.
g) Porcentaje de nivel de servicio, que corresponde a la cantidad de llamadas
contestadas antes de un periodo de tiempo, sobre el total de llamadas.
h) Porcentaje de llamadas contestadas, que corresponde al porcentaje de llamadas
contestadas sobre el total de llamadas recibidas.

De estos indicadores, los que están relacionados directamente con la percepción del
usuario respecto al servicio son: porcentaje de nivel de servicio, el tiempo medio antes
de contestar (TMC), porcentaje de llamadas abandonadas (%LLA) y el porcentaje de
llamadas contestadas. (%LLC). Un indicador adicional, que impacta directamente en la
percepción y el proceso, es la cantidad de requerimientos que son resueltos
telefónicamente, por lo tanto se puede definir el porcentaje de resolución, como la
cantidad de llamadas resueltas por el service desk, sobre el total de llamadas
contestadas. Entonces, de acuerdo a la segmentación de usuarios propuesta y a la
definición comercial de la empresa, los niveles de servicio se muestran en la tabla 10.

37



Tabla 10: Niveles de servicio para servicios variables

Hay que notar, que los niveles del service desk, son uniformes para todo tipo de
usuario, no así los relacionados con el soporte en terreno.

Para el caso del mantenimiento de corto plazo, el que consideraremos con un horizonte
de tiempo no mayor a 3 meses, no son aplicables los indicadores mencionados, ya que
este tipo de actividad la mayor parte del tiempo no es de carácter operativo. Es por ello
que se propone utilizar indicadores de cumplimiento mensual, es decir:

a) %RMNR_1m, que corresponde al porcentaje de requerimientos de
mantenimiento no resueltos antes de 1 mes, sobre el total de requerimientos y de
acuerdo a la prioridad del usuario.
b) %RMNR_2m, que corresponde al porcentaje de requerimientos no resueltos
antes de 2 meses, sobre el total de requerimientos y de acuerdo a la prioridad
del usuario.
c) %RMNR_2m, que corresponde al porcentaje de requerimientos no resueltos
antes de 3 meses, sobre el total de requerimientos y de acuerdo a la prioridad
del usuario.

La definición de la empresa, es apuntar a que el 80% de los requerimientos sea
resuelto en menos de un mes, el 90% antes de dos meses y el 95% antes de tres
meses, por lo tanto, los niveles de servicio son los indicados en la tabla 11.



Tabla 11: Niveles de servicio para la mantención de software de corto plazo

38

Respecto a los servicios de valor agregado, el enfoque es diferente. Este tipo de
servicio contempla proyectos y consultoría, donde el cumplimiento de los compromisos
juega un rol relevante respecto a la percepción del servicio. Entonces, para el lado del
cliente, más que definir métricas relacionadas con el proyecto o con el software, hay
que considerar la capacidad de cumplimiento y de gestión y la obtención de resultados
dentro de los plazos comprometidos. Bajo este enfoque, se pueden distinguir niveles de
servicios asociados a la globalidad, es decir, al conjunto o cartera de proyectos y/o
consultorías que es realizado durante un año para una determinada empresa y a la
particularidad, es decir, a lo que se espera recibir para un proyecto y/o consultoría
puntual.

Para reflejar el cumplimiento antes de un periodo de tiempo, definiremos los siguientes
indicadores:

a) %PA, de carácter global, que corresponde al porcentaje de proyectos o
consultorías atrasadas respecto a la planificación que fue aprobada por el
servicio y por el cliente, sobre la cantidad total de proyectos o consultorías en
ejecución, para un cliente y dentro del año. Responde a la pregunta: ¿Cómo es
la gestión general de la cartera de proyectos?
b) %CC_PG, de carácter global, que corresponde al promedio del porcentaje de
cumplimiento de compromisos para la cartera de proyectos o consultorías
realizadas dentro del año. Responde a la pregunta: ¿Cómo es el cumplimiento
de compromisos del servicio?
c) %CC_P, de carácter particular, que corresponde al porcentaje de cumplimiento
de compromisos para un proyecto o consultoría particular, sobre la cantidad total
de compromisos a la fecha de cálculo del indicador. Responde a la pregunta:
¿Cómo es el cumplimiento de compromisos del proyecto o consultoría?
d) DA, de carácter particular y corresponde a los días de atraso de un proyecto o
consultoría particular respecto a su planificación aprobada. Responde a la
pregunta: ¿Cuánto es el atraso del proyecto?

Entonces, de acuerdo las expectativas y definición de la empresa, los niveles de
servicio son los indicados en la tabla 12.



Tabla 12: Niveles de servicio para servicios de valor agregado

39

2. Diseño de Procesos

Para el desarrollo de los siguientes puntos y debido a la profundidad, extensión y
cantidad de temas que pueden ser tratados, se han considerado los aspectos más
relevantes que pueden ser mejorados como parte de un primer diseño de los procesos
de TI. El enfoque de diseño de los procesos es de carácter general, sugiriendo guías
ya que algunos temas por si mismos pueden ser abordados en forma independiente
como tema de tesis, memoria, o trabajo posterior.

2.1 Proceso de planeación estratégica TIC para las filiales

2.1.1 Proceso para la planeación estratégica

Típicamente, la planificación estratégica en TI se refiere a la identificación e
implementación de la tecnología requerida por el negocio para la consecución de su
misión, objetivos y estrategias [8]. El carácter multinacional, la cantidad de filiales y la
distribución de las localizaciones del holding agregan una complejidad importante a este
proceso. Esto sugiere, que cada plan debe ser acorde a las necesidades de cada filial,
teniendo en consideración la posibilidad de generar sinergia e intercambio tecnológico
entre diferentes empresas.

Por otro lado, la velocidad de los avances tecnológicos incorpora, además, una
componente temporal que debe ser contrastada con la capacidad de cambio de las
empresas en el tiempo y su habilidad para adoptar e incorporar nuevas tecnologías a
los procesos de negocio.

Se distinguen dos planeaciones según el horizonte de tiempo: una de carácter
estratégico, que tendrá relación con la determinación de los lineamientos tecnológicos
de largo plazo y otra de carácter más táctico, orientado a alinearse con los periodos de
planificación anual de las filiales.

La planeación de largo plazo, será entendida como la identificación de la tecnología
requerida por el negocio para la consecución de su misión, objetivos y estrategias. En
cambio, la de carácter táctico, tendrá relación con el plan de implementación de dichas
tecnologías dentro de periodos anuales.

Un elemento importante a considerar, es la velocidad de cambio de la tecnología, sin
embargo, el carácter conservador del holding respecto a la adopción tecnológica lo
sitúan como una empresa netamente seguidora más que adoptadora. Por lo tanto, el
horizonte de largo plazo será el que considere tecnología que se encuentre
ampliamente probada y desarrollada, es decir cuatro a cinco años.

Tomando en consideración lo mencionado en el aspecto teórico de la planeación
estratégica, se propone un proceso que sigue los siguientes pasos:

40

1. Definición y declaración de la misión y la visión de TI, con horizonte de tiempo de
largo plazo.
2. Análisis de la situación actual de TI.
3. Definición de la situación deseada de TI, con horizonte de tiempo de largo plazo.
4. Formulación de los planes y programas generales de acción:
a) Estrategia de gestión de recursos de TI.
b) Arquitectura informática del negocio, con horizonte de tiempo de largo
plazo.
c) Definición del portafolio de proyectos.
d) Plan de infraestructura.
5. Programación y asignación de prioridades y recursos.
6. Elaboración del presupuesto.

En la figura 10 se muestra la representación del flujo del proceso.



Figura 10: Proceso de planeación estratégica de TI

De la figura 10, las actividades de planeación deben ser abordadas conjuntamente con
la empresa, por ello es necesaria la creación de un comité de TI que este compuesto de
representantes de alto nivel de la empresa y del servicio TIC.

El comité tendrá como función realizar la planeación informática, priorizar y aprobar el
presupuesto y dirimir respecto a los gastos adicionales que surjan, producto de nuevas
necesidades o adecuaciones de procesos de negocio propios, que impacten la
componente de tecnologías de información.

41

Profundizando, la declaración de la misión consiste en la expresión del propósito del
negocio, en este caso, el servicio de TI, la que incluye, la definición del ámbito actual y
los cambios esperados en el futuro, la descripción general de productos y servicios
ofrecidos, cobertura geográfica y la selección de una forma de conseguir una posición
ya sea de liderazgo, de excelencia, o de asesoramiento, que permita tener una
supervivencia sostenible en el tiempo [11]. La visión corresponde a lo que se espera y
quiere del servicio de TI desde la perspectiva de la empresa que recibe el servicio [11].

El siguiente paso, análisis de la situación actual de TI, corresponde a la determinación y
diagnostico de:

a) La arquitectura informática del negocio.
b) La infraestructura, vale decir, cantidad y tipo de equipos, tecnologías utilizadas y
el diagnostico de procesos.
c) Los recursos utilizados para el desarrollo y mantención de software, gestión de
TI, soporte a usuarios e infraestructura.
d) El estado de los proyectos y mantenciones en curso.
e) El gasto realizado para el funcionamiento del servicio de TI.

Como resultado del análisis de la situación actual, la definición de la situación deseada
de TI, el plan informático con horizonte de tiempo de largo plazo debe recoger las
necesidades actuales y futuras que hayan sido previstas. Este plan general, debe
incluir:

a) Estrategia general de recursos de TI, es decir, las definiciones y políticas
respecto a: la compra y/o arriendo de equipos, la contratación de servicios y
recursos humanos, tanto internos como externos.
b) La arquitectura informática deseada, idealmente considerando soluciones
probadas y estándares para la definición de tecnología a utilizar.
c) Estrategia general de infraestructura, es decir, tecnología a utilizar, arquitectura
de red, servidores y servicios deseados.
d) Procesos de TI que serán mejorados o abordados, con el objetivo de establecer
en el mediano plazo procesos de mejora continua.

La formulación de los planes y programas generales de acción junto con la
programación y asignación de prioridades y recursos, corresponde a la definición en
detalle y con carácter anual de:

a) Plan táctico de gestión de recursos de TI, es decir, determinación anual de los
recursos requeridos para realizar el plan anual de proyectos e infraestructura.
b) Plan anual de mejora e implantación de la arquitectura informática del negocio.
c) Definición del portafolio de proyectos de software, el que incluye la descripción
de los proyectos con una valorización previa.
d) Plan de infraestructura, el que incluye, proyectos, plan de mantenimiento y
recambio de tecnología, servicios que se requerirán dentro del periodo.


42

2.1.2 Proceso para la elaboración del presupuesto

Derivado de la planeación estratégica de TI de la filial, el presupuesto es la estimación
de los recursos de dinero para llevar a cabo los planes de acción definidos en la
planeación estratégica. El presupuesto de informática se puede dividir según la
siguiente clasificación:

a) Proyectos, es decir, toda actividad relacionada con proyectos que signifiquen la
adquisición, adecuación e implantación de software nuevo o infraestructura
nueva.
b) Mantención de Software, que considera los recursos para las mantenciones
evolutivas y adaptativas. Las correctivas no son consideradas ya que se define
como una garantía permanente al software instalado, por lo tanto no pueden ser
costo de la empresa que recibe el servicio.
c) Licencias de Software, es decir, compra de nuevas licencias y mantención anual
de licencias.
d) Mantención de Hardware y Redes, que considera partes y piezas, repuestos y
mano de obra tendientes a reparar un producto de hardware o una red de
comunicaciones.
e) Arriendo de Equipos, es decir, el arriendo de PC, notebooks, servidores,
impresoras, etc.
f) Servicios Informáticos, donde se consideran, los servicios permanentes
prestados por terceros.
g) Comunicaciones, que considera los costos de la telefonía fija, móvil y las redes
de comunicación WAN.

El presupuesto debe ser especificado en dólares. El tipo de cambio presupuestado es
entregado anualmente por el área de finanzas, el que debe ser tomado como referencia
para la elaboración del presupuesto. Además, deben ser especificadas todas las
actividades y los flujos mensuales, los que son determinados respecto a la planeación
anual de las actividades. En la tabla 13, se presenta un ejemplo de un presupuesto.

43



Tabla 13: Ejemplo de un presupuesto

El problema de la elaboración del presupuesto es la estimación de los recursos
económicos a considerar. Para resolver este punto, en la tabla 14 se presenta una
propuesta de criterios que pueden ser utilizados.

44



Tabla 14: Criterios para la presupuestación

Además, es importante detallar los ítems que se considerarán dentro del presupuesto
ya que es considerado como el plan anual de actividades y servicios de TI, en la tabla
15 se proponen los criterios.



Tabla 15: Criterios para detallar el presupuesto

El presupuesto debe ser presentado al comité de TI de la empresa, quienes, dentro del
marco de la planeación anual, fijarán el detalle de las prioridades y definirán los
recursos.



45

Entonces, el proceso propuesto es:

1. De la planeación estratégica, determinar las actividades y servicios que serán
abordados dentro del periodo, contrastando con las necesidades de cada área
de la empresa. Esta actividad puede ser en conjunto con los jefes de cada área.
2. Estimar los costos para cada una de las actividades y servicios.
3. Clasificar las actividades de acuerdo a la guía proporcionada anteriormente.
4. Completar la planilla de presupuesto, considerando los tiempos de las
actividades y servicios.
5. Revisar, junto con el comité de TI el presupuesto. El comité determinará el
detalle de las prioridades y recursos que proveerá la empresa.
6. Obtener la aprobación del comité de TI.

En la figura 11 se muestra la representación del flujo del proceso.



Figura 11: Proceso de elaboración del presupuesto





46

2.2 Procesos de software

Los procesos de software pueden ser caracterizados y cubiertos por cinco macro
procesos:

a) Administración de Proyectos.
b) Desarrollo y Administración de Requerimientos.
c) Desarrollo de Software.
d) Pruebas de Software.
e) Mantención de Software.

En esta sección, se presentará la definición general de estos procesos tomando como
marco de referencia algunos elementos de la guía proporcionada por CMMi.

2.2.1 Administración de Proyectos

La administración de proyectos bajo CMMi abarca una serie de áreas de procesos de
los niveles de madurez 2, 3 y 4, identificándose las siguientes como parte de este
proceso:

a) Planificación de proyectos.
b) Monitoreo y control de proyectos.
c) Administración de acuerdos con proveedores.
d) Administración integrada de proyectos.
e) Administración de riesgos.
f) Equipos integrados.
g) Administración integrada de proveedores.
h) Administración cuantitativa de proyectos.

La idea es generar el proceso básico de administración de proyectos, de acuerdo al tipo
de metodología de desarrollo de software.

En la industria se encuentran dos grandes visiones metodológicas para el desarrollo de
software: los métodos ágiles y los métodos tradicionales. Pero, ¿Cuales son los criterios
para escoger entre uno u otro tipo de metodología? Para responder a la pregunta, se
pueden definir los siguientes elementos de juicio para apoyar la decisión [2]:

a) Los métodos ágiles tienen una mejor efectividad que los tradicionales cuando se
presentan requisitos cambiantes o mal definidos.
b) Si los tiempos de desarrollo del proyecto son ajustados, se está aplicando nueva
tecnología y hay poca experiencia del equipo de desarrollo, se puede utilizar
metodología ágil con una buena posibilidad de éxito del proyecto.
c) Si se requieren resultados en corto tiempo y existe compromiso y voluntad para
que el usuario final y la administración sea parte del equipo de desarrollo, la
metodología ágil puede ser aplicada.
d) Si bien la metodología ágil puede ser utilizada en todo tipo de proyectos, es
recomendable que para proyectos de mediano y largo plazo se utilicen métodos
tradicionales debido a que:
47

a. Se entiende que un proyecto de corto plazo es para resolver algo puntual,
por lo tanto un control de proyectos mediante el seguimiento de
actividades puede ser aplicado.
b. La cantidad de personas del equipo de proyecto es mayor a la de un
proyecto de corto plazo.
c. La cultura organizacional es de carácter tradicional, por lo que la falta de
formalidad del método ágil puede ser interpretada por la organización
como mala gestión y desorden del proyecto.

Se ha señalado, que en la práctica no existe un proceso de administración de
proyectos. Sin embargo, de la situación inicial, se destacan los siguientes puntos:

a) Los proyectos son planificados en tiempo mediante una carta Gantt y los
recursos son costeados, de acuerdo a la voluntad del jefe de proyecto.
b) El seguimiento del proyecto no siempre es realizado y cuando se hace, la
actividad la ejecuta el superior inmediato del jefe de proyecto, tampoco hay una
participación directa del cliente.

Por lo tanto, el énfasis de esta definición, debe ser respecto a la planificación,
monitoreo y control de los proyectos. Cabe notar, que por el tamaño de la organización
y la escasez de recursos, es necesario contar con una función que concentre el
seguimiento e información de control y monitoreo de los proyectos y que permita
establecer a nivel del portafolio, la planeación, priorización y coordinación de los
recursos asignados a los proyectos.

Otro punto importante, es que el servicio de TI puede tercerizar la ejecución de los
proyectos, manteniendo un jefe de proyecto interno, es por ello que cobra relevancia la
administración de los proveedores, tema que será discutido en el proceso de gestión de
proveedores.

2.2.1.1 Administración de proyectos con metodologías ágiles

Las metodologías ágiles son caracterizadas por iteraciones de corta duración, por lo
tanto la administración de proyectos de este tipo, tiene que ver con el ciclo: planeación,
control y monitoreo para el startup del proyecto y las iteraciones posteriores [29].
Entonces, utilizando algunos elementos conceptuales del desarrollo de software ágil, se
proponen las siguientes actividades para la administración de proyectos de este tipo:

1. Planificar la iteración.
a) Determinar las actividades y su duración.
b) Determinar los costos de la iteración.
c) Determinar los casos de prueba para el testing [16].
d) Agendar la iteración.
e) Agendar la revisión de errores y defectos del software [16].
2. Guiar la iteración.
a) Monitorear y controlar la iteración, resolver problemas.
b) Evaluar y mitigar riesgos durante la iteración [16].
c) Agendar y realizar la revisión de lo que se hizo durante la iteración.
48

3. Guiar el proyecto.
a) Revisar objetivos [16].
b) Mantener actualizado el avance de las actividades.
c) Realizar seguimiento y priorización de las actividades de corrección de
errores y defectos [16].
d) Identificar riesgos.


En la figura 12 se muestra la representación del flujo del proceso.



Figura 12: Administración de proyectos con metodologías ágiles


2.2.1.2 Administración de proyectos con metodologías tradicionales

Para este tipo de proyectos, el desarrollo puede ser abordado mediante métodos
tradicionales, por ejemplo: cascada, espiral, incremental, etc. Las actividades
propuestas son:

1. Planificar el proyecto.
a) Establecer los objetivos, alcances y ámbito del proyecto [25].
b) Definir el ciclo de vida del proyecto [17].
c) Definir la metodología de desarrollo.
49

d) Definir y estimar las actividades, recursos y costos [25].
e) Definir el plan comunicacional del proyecto.
f) Identificar los riesgos del proyecto.
2. Obtener el compromiso de la organización para el plan del proyecto.
a) Identificar a los terceros relevantes [25].
b) Obtener el compromiso con el proyecto.
3. Monitorear el proyecto de acuerdo al plan establecido.
a) Realizar reuniones de seguimiento y revisión.
b) Revisar los compromisos.
c) Revisar y mitigar los riesgos [25].
d) Revisar y realizar acciones correctivas.
4. Comunicar el estado del proyecto [17].

En la figura 13 se muestra la representación del flujo del proceso.



Figura 13: Administración de proyectos con metodologías tradicionales

Hay que notar, que las variables de monitoreo y control deben estar ligadas a los
niveles de servicio comprometidos con las empresas. Esto sugiere, la utilización de los
mismos indicadores de cumplimiento vistos en el diseño de los servicios de valor
agregado, es decir, la medición de los días de atraso respecto a la planeación original y
el grado de cumplimiento de compromisos.

Sin embargo, lo anterior no es suficiente para determinar el estado de avance real de
un proyecto o un desarrollo de software. Para resolver la problemática, hay que
distinguir que cada actividad del proyecto debe producir productos tangibles o
entregables bajo una cierta temporalidad definida.
50


Entonces, si n es el número total de actividades del proyecto,
i
P es la cantidad de
productos entregables para una actividad i , con un plazo planificado de realización
i
t y
i
tr es el tiempo real transcurrido para la realización de la actividad i , se proponen las
siguientes métricas para el control y seguimiento:

1. Porcentaje de productos entregados en
i ri
t t s : es decir, todas aquellas
actividades que produjeron el producto de acuerdo a lo planeado, sobre el total
de productos definidos:

100 %
1
× =
¯
¯
=
n
i
i
j
j
p
P
P
PE donde j es tal que
j j
t tr s

Ecuación 3: Porcentaje de productos entregados dentro de plazo

2. Porcentaje de productos entregados en
i ri
t t  : es decir, todas aquellas
actividades que produjeron el producto por sobre el tiempo planificado, sobre el
total de productos definidos:

100 %
1
× =
¯
¯
=
n
i
i
j
j
a
P
P
PE donde j es tal que
j j
t tr 

Ecuación 4: Porcentaje de productos entregados fuera de plazo

3. Porcentaje de avance del proyecto: es decir, la ponderación entre la cantidad
total de actividades y el factor de cumplimiento de tiempo
i
ri
t
t
, de manera tal que
1 s
i
ri
t
t
, es decir todas aquellas actividades que se encuentren sin atraso respecto
a lo planificado:

100
1
% × × =
¯
i i
ri
t
t
n
AP

Ecuación 5: Porcentaje de avance del proyecto

Pero, ¿qué ocurre con las actividades con atraso? Si una actividad está atrasada
respecto a lo planificado quiere decir que, o la planeación no fue la correcta, o
que la actividad presenta un problema que debe ser corregido, si eso es así, es
un riesgo del proyecto que ha de ser mitigado.

51

Cabe señalar, que los indicadores planteados en los puntos 1 y 2 son de carácter ex-
post y miden cumplimiento. Respecto a lo propuesto en el punto 3, la idea es tener un
indicador de avance, en relación al tiempo respecto a lo planeado, sin embargo si la
planificación es mala, esto no tiene sentido. Hay que notar, que la planificación es una
estimación de tiempo y actividades de lo que se hará en el proyecto y como tal, debe
ser de carácter dinámico ya que debe adaptarse de acuerdo a las situaciones y
necesidades que se vayan dando durante la ejecución del proyecto, por ello el indicador
propuesto en el punto 3 cobra relevancia desde el punto de vista operativo, entregando
una noción de la situación de avance.

La realización de las actividades de un proyecto depende de las personas, por lo tanto,
está sujeto a variabilidad, esto puede ser mitigado o modelado de acuerdo a la historia
del comportamiento productivo de los recursos humanos. Se puede definir, una serie de
indicadores de productividad que permitan obtener mejores estimaciones para la
planificación, pero hay que tener en cuenta que un indicador debe considerar al menos
temporalidad y complejidad, entonces se pueden plantear dos preguntas: Para un
producto de software con un cierto nivel de complejidad, ¿Cuánto tiempo se demora un
recurso en desarrollarlo de manera tal que la cantidad de defectos sea inferior a una
cierta tasa preestablecida? ¿Cuál es la varianza de ese proceso?

Se puede considerar una métrica que clasifique piezas de software en base a
complejidad, por ejemplo puntos de función y que mediante mediciones, establezca una
tasa de tiempo para el desarrollo, lo que finalmente establecerá un criterio de
productividad para los recursos. El problema con esta métrica es que depende del
recurso, es decir, la actividad de registro de tiempo puede no ser ajustada a la realidad
ya sea por olvido, resistencia al control de tiempo y los temores propios de una
medición de productividad para una persona. La problemática puede ser resuelta desde
varios aspectos, primero a la toma de conciencia de las personas que son medidas, con
el sentido de que este tipo de iniciativas permiten tener un mejor control del proceso del
proyecto, por lo tanto mejores estimaciones y un mejor servicio entregado al cliente; y
segundo, a la automatización y sistematización del proceso de captura de los datos, de
manera tal de que la información sea obtenida oportunamente.

2.2.2 Proceso de Desarrollo y Administración de Requerimientos

De acuerdo a CMMi, el propósito del desarrollo de requerimientos es producir y analizar
los requerimientos de clientes, productos y componentes de productos. La
administración de requerimientos, es la gestión de los requerimientos de los productos
del proyecto y los componentes del producto y la identificación de las inconsistencias
entre esos requerimientos, los planes del proyecto y los productos de trabajo [7].

Ambos procesos distinguen las siguientes etapas [7]:

Caso: Desarrollo de Requerimientos.

a) Desarrollar requerimientos de clientes.
b) Desarrollar requerimientos de productos.
c) Analizar y validar requerimientos.
52


Caso: Administración de Requerimientos.

a) Obtener una comprensión de los requerimientos.
b) Obtener compromiso con los requerimientos.
c) Administrar los cambios a los requerimientos.
d) Mantener la trazabilidad bidireccional de los requerimientos.
e) Identificar inconsistencias entre el trabajo del proyecto y los requerimientos.

El enfoque de este proceso, será abocarse a la problemática de levantar el
requerimiento del cliente ya que es la falencia principal de la organización. Como se vio
anteriormente, la etapa de requerimientos, corresponde a la recepción y aprobación. En
términos prácticos, es el usuario quien especifica el requerimiento, de acuerdo a sus
propias palabras. El requerimiento es recepcionado por un encargado de TIC, que
intenta interpretar y evaluar el requerimiento. Luego, se presenta para aprobación a un
comité y de ser aprobado, se realiza. No se genera documentación.

Independiente de la metodología del proyecto y del tipo de solicitud, la idea es tener un
proceso estándar para el levantamiento de requerimientos. Los elementos relevantes
son los relacionados con el levantamiento, es decir: el desarrollo de los requerimientos
del cliente, la obtención de una comprensión de los requerimientos el análisis y la
validación de los requerimientos y la obtención de compromisos con los requerimientos.
Además, es imprescindible la participación de las áreas que transformaran los
requerimientos en software.

Entonces, el proceso se puede definir de la siguiente manera:

1. Recepción de una solicitud de cambio o de levantamiento de requerimientos.
2. Desarrollar el requerimiento.
a) Determinar los objetivos, visión y alcance [17].
b) Determinar la situación actual y lo deseado.
c) Determinar los procesos de negocio y sus requerimientos [17].
d) Determinar los requerimientos funcionales respecto al software.
e) Determinar los requerimientos técnicos del software.
3. Comprender el requerimiento.
a) Analizar el requerimiento, mediante reuniones y revisión de a pares [17].
b) Determinar el impacto [17].
c) Elaborar el documento de requerimientos.
4. Obtener compromiso.
a) Validar con usuario, que lo documentado respecto al requerimiento,
corresponde a lo solicitado [17].
b) Solicitar y obtener compromiso del usuario [17].
5. Evaluar la solicitud.
a) Determinar la evaluación económica.
b) Determinar la evaluación técnica.
c) Determinar si es un proyecto o un mantenimiento.
6. Presentar al comité de informática para aprobación.

53

En la figura 14 se muestra la representación del flujo del proceso. Para las solicitudes
de cambio, el ingreso debe ser realizado a través de la mesa de ayuda, se sigue el flujo
normal de evaluación, con la diferencia que solamente es validado por el Service
Manager, obteniéndose el compromiso y luego sometido a aprobación en el comité. La
diferencia con un requerimiento normal, es que se considera una solicitud de cambio
como una solicitud de mantención de software.




Figura 14: Proceso de desarrollo y administración de requerimientos

Pero, ¿Cómo manejar los cambios de los requerimientos? La posibilidad de cambios
siempre se encuentra presente, en cualquier etapa, lo importante es que estos sean
realizados, idealmente en el levantamiento de requerimientos, antes de obtener el
compromiso con el usuario, entendiendo que dicho compromiso, es la aceptación de la
especificación de una cierta funcionalidad, que para ser evaluada y presentada al
comité, no puede ser modificada. En la práctica, pueden presentarse situaciones en las
que por cambios en el negocio, haya un cambio en los requerimientos. Bajo ese
escenario, la propuesta es realizar el ciclo completo de requerimientos, más que
concentrarse en los cambios. Si el cambio es menor, debe evaluarse el impacto y
comunicar al comité la nueva evaluación.

54

Una vez establecidos los requerimientos, es parte de la evaluación técnica determinar
la adecuación al software. Para ello, se propone el uso de una matriz de trazabilidad
entre la funcionalidad de software versus los requerimientos.

Respecto a las técnicas para el levantamiento y especificación de requerimientos, se
propone:

1. La realización de entrevistas con todos los involucrados, utilizando preguntas
abiertas para obtener un panorama general del requerimiento y preguntas
especificas para el detalle.
2. La utilización de diagramas UML de casos de uso para la especificación ya que
son simples, es un modelo estándar, evita ambigüedades y es entendible por
usuarios no técnicos.
3. Evitar el uso de palabras o redacciones que puedan estar sujetas a varias
interpretaciones, o sean ambiguas.


2.2.3 Proceso de Desarrollo de Software

El proceso de desarrollo de software consiste en establecer la manera en que serán
desarrolladas las aplicaciones en la empresa, esta definición también va asociada a qué
tecnología utilizar para el desarrollo de software.

CMMi establece como parte de su área de proceso de solución técnica la guía para
afrontar esta problemática, considerando típicamente las fases que siguen al análisis de
requerimientos, es decir el diseño y la construcción.

Para el caso de metodologías ágiles, el proceso general es definido como sigue:

1. Definir una arquitectura de software para la solución.
a) Escoger un patrón arquitectónico de software [16].
b) Crear actividades de desarrollo para implementar la arquitectura [16].
c) Determinar y diseñar las interfaces.
d) Identificar los objetivos de rendimiento de la aplicación.
e) Definir un prototipo arquitectónico de la aplicación [16].
f) Definir la infraestructura.
2. Ejecutar las actividades de desarrollo.
a) Determinar el tiempo para desarrollar la actividad.
b) Definir los tests unitarios a aplicar [16].
c) Construir el software [16].
d) Analizar el código.
e) Realizar los tests unitarios.
f) Verificar y corregir código.
3. Corregir errores.
a) Realizar testing con el usuario y encontrar errores [16].
b) Reproducir el error.
c) Localizar la causa del error.
d) Corregir el error.
55

e) Realizar testing del usuario y volver a iterar en caso de ser necesario [16].
4. Entregar el producto.
a) Construir el instalador de la aplicación [16].
b) Instalar la aplicación.
c) Corregir errores en caso de que se presenten.
d) Realizar la aceptación del producto [16].

En la figura 15 se muestra la representación del flujo del proceso.



Figura 15: Proceso de desarrollo de software con metodología ágil

Para el caso de métodos tradicionales, el proceso general es definido como sigue:

1. Definir y seleccionar las componentes del producto.
a) Crear alternativas detalladas de diseño de la aplicación [17].
b) Diseñar y seleccionar la arquitectura del sistema.
c) Determinar y diseñar las interfaces.
d) Determinar los requerimientos y escenarios operacionales [17].
e) Crear pruebas de concepto de la aplicación, mediante diagramas [17].
f) Identificar los objetivos de rendimiento de la aplicación.
2. Desarrollar el diseño.
56

a) Revisar el diseño.
b) Crear y definir el tiempo de las actividades de desarrollo para implementar
el diseño y la arquitectura [17].
c) Definir los tests unitarios a aplicar.
d) Construir el software [17].
e) Analizar el código.
f) Realizar los tests unitarios.
g) Verificar y corregir código.
h) Integrar los cambios.
3. Implementar el diseño
a) Escribir y revisar la documentación [17].
b) Corregir el software en caso de presentarse errores.
4. Integrar el producto
a) Construir el instalador de la aplicación [17].
b) Instalar la aplicación.
c) Corregir errores en caso de que se presenten.
d) Realizar la aceptación del producto para su entrega [17].

En la figura 16 se muestra la representación del flujo del proceso.




Figura 16: Proceso de desarrollo de software con metodologías tradicionales
57


Cabe señalar, que las actividades de ensamblaje y entrega de producto, son
abordadas en CMMi bajo el proceso de integración del producto, en contraste con el
método ágil, el que realiza la entrega dentro de su propio ciclo de desarrollo.
Posteriormente se presentan las etapas de validación y verificación, donde el testing del
software es realizado, lo que será revisado en el siguiente punto.

En resumen, el proceso de desarrollo de software contempla las siguientes grandes
etapas:

1. Definir la metodología de proyecto a utilizar: ágil o tradicional, de acuerdo a los
criterios propuestos en la sección de administración de proyectos.
2. Seguir los procesos definidos anteriormente de acuerdo a la elección
metodológica.

Respecto a la definición de la tecnología a utilizar para el desarrollo de software, en la
industria hay dos herramientas comúnmente utilizadas para el diseño y construcción de
software empresarial, por una parte .NET de Microsoft y por otra J2EE de Sun
Microsystems.

Para optar por uno u otro, hay que tener en cuenta las siguientes consideraciones:

1. En la empresa existe software en ambas plataformas, sin embargo, las
aplicaciones son en su mayoría .NET, donde el ambiente Windows es
predominante.
2. Las aplicaciones J2EE corresponden a software propietario, adquirido a terceros,
cuyo ciclo de desarrollo y mantenimiento se ve cubierto por los acuerdos de
licenciamiento y soporte existentes.
3. Ambos entornos de programación presentan ventajas y desventajas, siendo las
principales:
a) J2EE presenta una mejor portabilidad de plataforma que .NET.
b) J2EE es una tecnología más madura que .NET.
c) .NET posee soporte para múltiples lenguajes de programación, con
una arquitectura equivalente a la planteada bajo J2EE.
d) .NET está especialmente orientado a la creación de servicios web,
con una arquitectura clara y sencilla de clases para crear y distribuir
estos servicios.
e) Microsoft con su suite Visual Studio, establece una serie de
prácticas de desarrollo de software que pueden ser aplicadas con
métodos tradicionales y ágiles, en cambio Sun solo ofrece la
plataforma, donde las prácticas son abordadas mediante entornos
de programación de terceros.

Entonces, .NET es la elección natural, debido a la predominancia histórica de las
aplicaciones de este tipo dentro de la empresa y sus filiales y al soporte multilenguaje,
lo que se traduce en mayor flexibilidad para la diversidad que existe actualmente. J2EE
tiene mayor madurez pero es un único lenguaje, las aplicaciones actuales bajo esta
plataforma son propietarias y por lo tanto no representan el problema para el proceso
de desarrollo interno. Por otro lado, el intentar migrar las aplicaciones actuales a J2EE
58

sería demasiado costoso y por lo tanto carente de sentido ya que no aportaría valor a la
empresa.

Como valor agregado, el proceso de desarrollo establecido por Microsoft para la
plataforma .NET contempla un framework para metodologías ágiles y otro orientado a
métodos tradicionales, usando CMMi. De ambos, se tomaron los aspectos más
relevantes para definir los procesos señalados anteriormente.

2.2.4 Proceso de Pruebas de Software

Independiente del enfoque utilizado para desarrollar el software, las pruebas son
consideradas como una etapa que debe ser realizada dentro del proceso de software.
Dentro de la organización no existe un proceso formal de pruebas y tal como se
menciono en el capítulo 1, son realizadas de acuerdo a la voluntad del programador o
del jefe de proyecto.

La idea del proceso de pruebas, es definir un marco de referencia simple, que permita
la aplicación de metodologías de testing en forma permanente.

El proceso de pruebas está directamente relacionado con las actividades de desarrollo
y mantención de software y por lo tanto los artefactos de software son una entrada para
este proceso. En CMMi se definen dos áreas de proceso que abordan la problemática,
por una parte, la verificación, cuyo objetivo es asegurar que los productos de trabajo
cumplan con los requerimientos especificados [30] y por otra la validación, cuyo objetivo
es demostrar que un producto cumple con su uso propuesto cuando es instalado en el
entorno propuesto [30].

Una manera práctica de abordar la verificación es realizar la revisión de pares [30], es
decir, quien realizó el trabajo le cuenta la solución a un par, de acuerdo a un
procedimiento documentado con el objetivo final de encontrar y anticipar errores y
defectos. El proceso se puede definir de la siguiente manera:

1. Planificar la verificación.
a) Establecer el ambiente de pruebas.
b) Seleccionar los productos de trabajo que se verificaran.
c) Establecer los casos de prueba de acuerdo a los requisitos del producto.
d) Establecer los criterios de éxito de la verificación.
2. Realizar la verificación de acuerdo a los requisitos del producto.
a) Identificar a los revisores y agendar la verificación.
b) Revisar la visión del producto.
c) Revisar el diseño del producto.
d) Realizar las pruebas.
3. Registrar los resultados.
a) Registrar resultado para cada caso de prueba.
b) Registrar el éxito de la verificación y determinar acciones correctivas.
4. Preparar el informe de verificación.

En la figura 17 se muestra la representación del flujo del proceso.
59




Figura 17: Proceso de pruebas con metodología ágil

En el caso de la validación, la idea es realizar el testing del software de acuerdo a
casos y datos de prueba, se propone un proceso con las siguientes etapas:

1. Planificar el testing.
a) Establecer el ambiente de pruebas.
b) Seleccionar los productos de trabajo que se verificaran.
c) Establecer la estrategia de testing.
d) Establecer los casos y datos de prueba.
e) Establecer los criterios de éxito de la prueba.
2. Ejecutar.
a) Ejecutar el testing de acuerdo a la estrategia.
3. Registrar resultados.
a) Registrar resultado para cada caso de prueba.
b) Registrar el éxito de la validación y determinar acciones correctivas.
4. Preparar el informe de testing.

En la figura 18 se muestra la representación del flujo del proceso.

60



Figura 18: Proceso de pruebas con metodologías tradicionales

Respecto a la estrategia de testing, se propone que el enfoque sea por proceso
(escenario) de negocio más que orientarse por modulo [9], esto con el fin de garantizar
que el proceso modelado dentro del software funcione de acuerdo a los requisitos y
dentro de cada proceso, realizar el análisis transaccional, esto se puede visualizar en la
figura 19.

Como no existe una definición metodológica respecto a la construcción de los casos de
prueba y no existe mucha experiencia dentro de la organización, se propone utilizar el
enfoque de caja negra, el que está orientado a la construcción de los casos de pruebas
a partir de las funcionalidades del sistema. Se propone utilizar la técnica de clases de
equivalencia, junto con el análisis de valores límite para obtener los casos de prueba
que se utilizarán en el análisis transaccional.

61



Figura 19: Diagrama de descomposición para el testing9


2.2.5 Proceso de Mantención de Software

En CMMi, la mantención es vista como una etapa más del ciclo de vida del software,
que integra los procesos de solución técnica, validación, verificación, junto con la
administración y desarrollo de los requerimientos. Esto ya ha sido abordado en los
procesos anteriores, es decir, una mantención sigue el mismo ciclo de requerimientos –
desarrollo – pruebas. Por lo tanto, el enfoque para definir este proceso, será de acuerdo
a solucionar la problemática para la provisión del servicio.

Uno de los problemas del proceso de mantención es la asignación de tareas y
prioridades al personal que realiza las mantenciones y el entendimiento de lo que es
una mantención. Bajo el escenario de un servicio único para todas las filiales, la
problemática es aun peor debido a la diversidad de software existente y a la
especialización del personal por división de negocio. Esto sugiere dos cosas, por una
parte se debe contar con una metodología eficiente de asignación de recursos y por
otra, se debe contar con las definiciones adecuadas que permitan discriminar el alcance
de una mantención.

Se entenderá como mantención de software al proceso general de cambio de un
sistema después de que ha sido entregado. Se definen tres tipos [28]:

a) Mantención para reparar fallas de software.
b) Mantención para adaptar el software a un ambiente de operación diferente, por
ejemplo modificaciones o cambios de hardware que provoquen cambios en el
software.
c) Mantención para agregar o modificar funcionalidades al software.

9
Fuente: Apuntes del curso “Técnicas de Prueba de Software”. 2004. Diplomado en Gestión de Calidad de Software.
62


Esta definición, permite tener un marco global para una mantención, sin embargo no
establece alcance en cuanto a tiempo o recursos. El problema de esto es que si una
actividad de mantención consume mucho tiempo y recursos, puede transformarse en un
proyecto. Por ello, como elemento adicional diferenciaremos los proyectos de software
respecto a proyectos de mantenimiento.

Un proyecto de software será todo aquel proyecto que implemente un sistema nuevo y
un proyecto de mantención, será aquel que cambie un sistema después de haber sido
entregado.

Una manera rápida de calificar una actividad de mantención de un proyecto, es utilizar
criterios de tiempo y costo. Podrían usarse también medidas de software, por ejemplo,
puntos de función, sin embargo, al no haber experiencia previa su uso y a la necesidad
de responder rápidamente a los clientes, la aplicación podría resultar contraproducente
en esta etapa.

Por lo tanto, una mantención será calificada como proyecto, cuando como resultado de
la estimación de recursos, se determine que el costo de realizar la actividad involucre a
una o dos personas por un tiempo superior a tres meses.

La problemática es que el personal está especializado por división de negocio por lo
que frente a un esquema global, la asignación de tareas no es eficiente. Por ello se
proponen dos opciones de especialización:

a) Por proceso de negocio, vale decir, formando grupos de trabajo por tipo de
proceso, por ejemplo: ventas, bodegas, etc.
b) Por tipo de tecnología, vale decir, por la tecnología característica del software,
por ejemplo: web, aplicaciones en forms, aplicaciones SAP, visual basic, etc.

El problema de la primera opción es que requiere de personas con un amplio dominio
de las herramientas tecnológicas, sin embargo, se especializa en los procesos de
negocio del cliente. La segunda opción requiere de especialistas en las herramientas
tecnológicas utilizadas en el software, pero no es tan relevante la componente de
negocio. Otro antecedente, es que en Chile, el mercado de las empresas proveedoras
ofrece sus servicios por tipo de tecnología, no por tipo de proceso. Por lo tanto, la
opción b) parece la más adecuada para definir líneas de mantenimiento, que en este
caso, serán por zonas geográficas.

La primera división por tipo de tecnología será para diferenciar las aplicaciones SAP del
resto y como es de carácter corporativo y centralizado, no será dividido por zona
geográfica, entonces se propone la siguiente división:

1. Mantenimiento SAP.
2. Mantenimiento no SAP.
a) Chile, zona Centro (desde la VI Región hacia el norte).
b) Chile, zona Sur (desde la VII Región hacia el sur).
c) Argentina y Uruguay.
d) Perú y Brasil.
63

e) México.

Tomando los antecedentes expuestos anteriormente y considerando las definiciones
entregadas, el proceso de mantención es presentado en la figura 20, y se define de la
siguiente manera:

1. Recepción de un requerimiento de cambio a través del service desk.
2. Análisis y clasificación del requerimiento.
a) Determinar si es una mantención o no.
b) Clasificar el requerimiento.
3. Estimación y asignación de recursos.
a) Estimar tiempo y costo.
b) Determinar si es un proyecto o no.
c) Crear una tarea de mantenimiento.
d) Asignar la tarea de mantenimiento, de acuerdo a la disponibilidad de
recursos.
4. Modificación del software, donde se realiza el mantenimiento y tiene que ver con
el proceso de cambio que es realizado sobre el producto, es decir la
programación. Desde el punto de vista de los procesos de software, corresponde
a la aplicación y uso de metodologías de desarrollo de software.
5. Pruebas de software.
6. Pruebas de aceptación del usuario.
a) Pruebas funcionales.
b) Aceptación.
7. Paso a producción.




Figura 20: Proceso de mantención del software
64

2.3 Procesos de soporte al servicio

2.3.1 Gestión de incidencias

La gestión de incidencias tiene por objetivo restaurar la operación de un servicio,
minimizando el impacto en las operaciones del negocio y asegurando el mantenimiento
de la disponibilidad y los niveles de servicio [26].

Para capturar y registrar los requerimientos o incidentes de los usuarios y por el tamaño
de la organización, es necesario la definición e implementación de un service desk.
Para ello, primero se debe definir la estructura y alcance que tendrá está unidad.
Existen tres estructuras básicas [22]:

a) De tipo centralizado, es decir, el service desk atiende centralizadamente todas
las llamadas de usuario de la organización, independiente de su ubicación
geográfica.
b) De tipo descentralizado, es decir, el service desk se encuentra distribuido en
varias zonas geográficas, las que eventualmente pueden ser independientes
entre sí.
c) Virtual service desk, que combina los elementos de las estructuras centralizadas
y descentralizadas para proporcionar el servicio. Basado en un fuerte
componente tecnológico y de telecomunicaciones, provee un único punto de
acceso, sin embargo los agentes pueden estar distribuidos en distintas
ubicaciones geográficas.

La empresa posee filiales en Chile y Sudamérica, por lo que en principio un modelo
descentralizado podría ser la solución. La ventaja, es que al estar localizado
geográficamente, se logra fácilmente que el soporte sea específico para la zona,
además puede servir de respaldo en caso de que otro service desk, de otra zona
geográfica, no se encuentre disponible. Por otro lado, el modelo centralizado requiere
de una menor cantidad de personal para ser operado, la gestión está centralizada y por
lo tanto su costo es eventualmente menor. El virtual service desk se descarta como
opción de solución ya que además introduce costos de comunicación y tecnológicos,
que en los otros modelos no se incurren. Otro elemento a considerar es que
estratégicamente, el holding se define como líder en costos. Por lo tanto, la elección es
por una estructura centralizada en Chile ya permite una mayor optimización y control de
los recursos. Respecto a las localidades en el extranjero, la especialización del soporte
se puede obtener mediante entrenamiento. Esto puede ser más lento que tener un
service desk descentralizado, pero en el mediano plazo se puede lograr el objetivo.

Ya definida la estructura del service desk, el proceso de gestión de incidencias se
define de la siguiente manera:

1. Detección y registro de incidentes, los que pueden ser reportados directamente
al service desk, por correo, o por mecanismos de auto atención [19].
2. Gestión de las solicitudes de servicio.
e) Distribución de los requerimientos de servicio.
3. Clasificación de los incidentes y soporte inicial.
65

a) Determinar tipo de incidente.
b) Determinar impacto y urgencia.
c) Entregar soporte inicial.
4. Investigación y diagnostico del incidente [19].
a) Identificar la solución del incidente.
b) Determinar si es un incidente mayor.
c) Determinar si se trata de un problema.
d) Escalar al siguiente nivel si es necesario.
5. Solución y recuperación.
a) Resolver el incidente.
b) Implementar acciones correctivas.
c) Implementar acciones de recuperación.
d) Verificar que el incidente este resuelto.
6. Cierre del incidente.
a) Verificar la satisfacción del cliente.
b) Cerrar el incidente.

En la figura 21 se muestra la representación del flujo del proceso.

Los niveles de servicio del service desk, deben ser los mismos que se han definido en
la sección de diseño de servicios. Para la gestión, se propone el uso de los indicadores
habituales, es decir:

a) Llamadas recibidas, que corresponde al total de llamados recibidos por la central
telefónica del service desk.
b) Llamadas contestadas, que corresponde a las llamadas contestadas por los
agentes del service desk.
c) Llamadas abandonadas, que corresponde a las llamadas perdidas o no
contestadas por los agentes del service desk.
d) Tiempo medio antes de contestar, que corresponde al tiempo promedio en
contestar una llamada por el grupo de agentes del service desk.
e) Tiempo medio de conversación, que corresponde a la duración promedio de una
llamada.
f) Porcentaje de llamadas abandonadas, que corresponde al porcentaje de
llamadas que se abandonaron sobre el total de llamadas.
g) Porcentaje de nivel de servicio, que corresponde a la cantidad de llamadas
contestadas antes de un periodo de tiempo, sobre el total de llamadas.
h) Porcentaje de llamadas contestadas, que corresponde al porcentaje de llamadas
contestadas sobre el total de llamadas recibidas.

66


Figura 21: Proceso de gestión de incidencias


2.3.2 Gestión de problemas

La gestión de problemas es la búsqueda de la causa de una incidencia, que no ha
podido ser resuelta por el soporte estándar, para convertirla en un error conocido e
iniciar la acción de mejora o corrección de la situación [26].

Considera dos aspectos [26]:

a) Reactivo, que es concerniente a la solución de problemas en respuesta a uno o
más incidentes.
67

b) Proactivo, que tiene relación con la identificación y solución de problemas y
errores conocidos antes de que un incidente vuelva a ocurrir.

Además, define dos tipos de controles [21]:

a) Control de problemas, cuyo objetivo es transformar los problemas en errores
conocidos, actividad que es parte del proceso.
b) Control de errores, cuyo objetivo es resolver estructuralmente los errores
conocidos a través del proceso de gestión de cambio.

La gestión de problemas tiene directa relación con la gestión del cambio ya que los
resultados de este proceso generan modificaciones en la infraestructura informática y
como tales deben ser controlados y registrados.

En el caso de que un error no pueda ser resuelto, el problema es calificado como un
error conocido, para el cual deben elaborarse planes y actividades que permitan la
corrección temporal o workaround, mientras la solución es encontrada [21].

Las etapas del proceso, serán realizadas por un grupo de solución de problemas
(GSP), cuyo objetivo es investigar, diagnosticar y solucionar el problema, considerando
aspectos de infraestructura y software. Este comité será integrado por un representante
de cada unidad organizacional, quién se encargara de coordinar las actividades de
corrección al interior de su unidad organizativa.

Las soluciones y planes serán registrados, con el objeto de tener una base de datos
con el conocimiento de los problemas. Para definir el proceso, se han tomado los
aspectos más relevantes de ITIL y que pueden ser de utilidad para la organización. La
definición es la siguiente:

1. Registro del problema y clasificación.
a) Detección de los incidentes clasificados como problema.
b) Detección de problemas desde otras fuentes, es decir, las provenientes de
la infraestructura informática y el software [21].
c) Determinar el impacto y la urgencia en el negocio [21].
d) Clasificar de acuerdo a lo determinado en el punto c.
2. Investigación y diagnostico del problema.
a) Investigar y diagnosticar la causa del problema.
b) Determinar las actividades para corregir el problema, escalar al proveedor
en caso de ser necesario y realizar seguimiento.
c) En caso de no encontrar la causa del problema, elaborar planes y
actividades que permitan una solución temporal [21].
3. Control de errores.
a) Implantar la corrección del problema mediante el proceso de gestión del
cambio [21].
b) Verificar la eliminación del error [21].
4. Cierre del problema.
a) Registrar los síntomas del problema y los detalles de la solución.
b) Registrar los artefactos, equipos, o ítems de configuración que sufrieron
cambios [21].
68

c) Verificar la satisfacción del cliente.
d) Cerrar el registro del problema.
5. Análisis proactivo y revisión de problemas.
a) Analizar tendencias de problemas y determinar focos de acción preventiva
[21].
b) Revisar los problemas mayores y las acciones tomadas para su solución,
con el objeto de prevenir que vuelva a ocurrir [21].

En la figura 22 se muestra la representación del flujo del proceso.



Figura 22: Proceso de gestión de problemas

2.3.3 Gestión de inventario y configuración

La gestión de inventario y configuración provee la información sobre la estructura de
tecnologías de información de una organización, la que es utilizada por otros procesos y
para la gestión [26]. Establece el control de la infraestructura, a través del monitoreo y
mantención de la información de los recursos necesarios para la distribución del
servicio, la evolución de los ítems de configuración en el tiempo y sus relaciones [26].

Para el servicio de TI es imprescindible tener un inventario actualizado de equipos,
principalmente PC, notebooks, impresoras, equipos de comunicación y servidores ya
que su número y características son utilizados como dato para la facturación de algunos
servicios.

69

El principal problema con el inventario, es tener la información actualizada y mantener
el control sobre el ciclo de vida del equipo, es decir, el registro de los cambios y
configuración, la incorporación, modificación y baja del equipo.

Además, como el equipamiento es arrendado, es necesario controlar los eventos que
signifiquen perdidas o siniestros, las fechas de inicio y termino del periodo de arriendo,
las que no necesariamente pueden concordar con las fechas de recepción y devolución.

El proceso requiere de cierta disciplina por parte de las personas que participan en el
proceso, en el sentido de que todo evento sobre el equipamiento debe ser registrado en
la medida que ocurra.

Otros datos de utilidad para mantener en el inventario son: características técnicas del
equipo, el lugar físico donde se encuentra, quién lo tiene asignado, un identificador que
permita determinar si el equipo está sujeto a servicio técnico y el número del contrato de
arriendo.

El proceso de inventario y configuración, puede modelarse en los siguientes pasos:

1. Recopilar la información de los equipos, mediante software ad-hoc.
2. Mantener la información, es decir registrar los cambios para la configuración,
ubicación y eventos tales como: hurtos, robos, perdidas o siniestros. La
información puede ser mantenida a través del mismo software, o por registro
manual según sea el caso.
3. Validar que la información registrada sea la correcta, mediante auditorias
manuales, realizadas cada cierto tiempo.
4. Activar los seguros comprometidos, en caso de robo, hurto, o siniestro de los
equipos.

En la figura 23 se muestra la representación del flujo del proceso.

Debido a la envergadura de la empresa, la recopilación y mantención de los datos no
puede ser realizada manualmente, es por ello que necesariamente se debe contar con
una herramienta que permita mantener actualizada la información relevante para el
inventario. Por ello, se propone que la herramienta, deba al menos poseer la siguiente
funcionalidad:

1. Permitir la recopilación automática de los siguientes datos:
a) Notebooks, PC y Servidores:
 Marca y modelo del equipo.
 Características técnicas: CPU, RAM, modelo y tamaño del disco
duro, presencia de arreglos de discos, tarjetas de red disponibles,
sistema operativo instalado, otro hardware instalado.
 Software instalado.
b) Impresoras:
 Marca y modelo.
 Marco y modelo del printserver según corresponda.
 Cantidad de bandejas.
c) Equipos de comunicación:
70

 Marca y modelo.
 Tipo de equipo: switch, firewall, hub, etc.
 Cantidad de puertas utilizadas y disponibles.
2. Permitir la edición y adición manual de los siguientes datos, para cada equipo:
a) Número de contrato de arriendo.
b) Número de servicio.
c) Número de serie.
d) A qué persona o empresa se encuentra asignado.
e) Ubicación física, la que entenderemos por: planta o edificio y área del
edificio o planta donde se encuentra.
f) Fecha de recepción del equipo.
g) Fecha de inicio del periodo de arriendo.
h) Fecha de finalización del periodo de arriendo.
i) Fecha de devolución del equipo.
j) Eventos, es decir: hurtos, robos, perdidas o siniestros.
3. Permitir la emisión de informes de inventario.




Figura 23: Proceso de gestión de inventario y configuración





71

2.3.4 Gestión del cambio

El objetivo de la gestión del cambio es minimizar la interrupción de servicios ante
cambios. Es decir, se deben asegurar los métodos y procedimientos estándares que se
utilizarán para el manejo de los cambios en la infraestructura tecnológica. La gestión se
debe realizar desde que se pidió hasta que finalizo [26].

La infraestructura debe ser separada en ambientes de desarrollo, ambiente de pruebas
y ambiente de producción, el que definiremos, como el conjunto de hardware y software
que es utilizado por la empresa para la ejecución de sus sistemas informáticos y para el
cual se debe registrar y establecer una línea base, de manera tal que los cambios sean
registrados sobre dicha configuración.

El problema con el manejo de cambios, es que existe un escaso control sobre la
plataforma de producción, por lo tanto, para esta etapa, el enfoque será la definición de
un proceso de paso a producción, el que tiene como requisito previo, que el ambiente
de producción sea cerrado y controlado por el personal que administre la
infraestructura.

El paso a producción es el proceso mediante el cual se instala en ambiente productivo
las piezas de software y hardware requeridas para que una aplicación funcione.
Entonces, hay que distinguir que un paso a producción tendrá características,
actividades y alcances distintos de acuerdo a lo que se desea instalar. Para ello, se
puede realizar una clasificación, de acuerdo al tipo de software que se coloca en
productivo y al hardware.

En el caso del software se distinguen los siguientes tipos:

a) Aplicaciones que se instalan o modifican en equipos de usuarios, actividad que
ha de ser realizada por técnicos de terreno.
b) Servicios que se instalan o modifican en servidores en funcionamiento, cuya
realización está a cargo de los administradores de la plataforma.
c) Scripts de bases de datos, es decir: procedimientos almacenados, tablas,
definiciones, etc., cuya realización está a cargo del administrador de la base de
datos.
d) Aplicaciones web, cuya realización está a cargo de los administradores de la
plataforma.
e) Otros, es decir, software no clasificado dentro de las categorías anteriores y cuya
realización debe ser sancionada de acuerdo a los elementos que la integran.

Para el caso del hardware, se distinguen los siguientes tipos:

a) Hardware nuevo que es instalado en ambiente productivo.
b) Modificación a hardware existente en ambiente productivo.

Los criterios de realización del paso a producción dependerán de la disponibilidad de
una ventana de tiempo para realizar la actividad y a las restricciones propias impuestas
por políticas de la administración de la infraestructura, por ejemplo: restricciones de
horarios o días, disponibilidad de recursos, etc.
72


Es importante señalar, que como elementos principales de la actividad, se debe definir
el plan de paso a producción, el plan de reversa y un plan de contingencia para el caso
en que se presenten problemas. Si hay hardware comprometido, además deben ser
especificados los componentes nuevos o sujetos a cambio.

En resumen, el proceso de paso a producción significa:

1. Que el desarrollador registra una solicitud de paso a producción, la que debe
contener los programas, planes y justificación para poder ser realizada.
2. La solicitud es derivada por la coordinación del service desk, revisada y
clasificada, de acuerdo al tipo de software o las actividades relacionadas con el
hardware.
3. El paso a producción es agendado de acuerdo a las ventanas de tiempo
disponibles, considerando las restricciones que existan en ese momento. Sin
embargo, pueden haber excepciones, para afrontar incidentes, que signifiquen
perdida de servicio, con posibilidad de detener procesos de negocio, o que
tengan carácter de urgencia.
4. El paso a producción es realizado, en caso de presentarse problemas se escala
con el desarrollador.
5. El resultado del paso a producción es informado al desarrollador.

En la figura 24 se muestra la representación del flujo del proceso.



Figura 24: Proceso de paso a producción
73


Respecto a los equipos de escritorio, notebooks, impresoras y dispositivos que sean
utilizados por los usuarios, pero que no son parte de la plataforma de producción,
también se debe tener el control respecto a la configuración y sus cambios. Estos
provendrán de incidentes de servicio y en general serán realizados por técnicos de
terreno. Eventualmente, podría haber compra de hardware o software por lo que un
ciclo de aprobación debe ser considerado. Entonces, se puede definir un proceso que
aborde esta actividad, de acuerdo a lo siguiente:

1. Recepcionar el incidente de cambio.
a) Determinar si es un cambio que requiere compra de hardware o software.
b) Registrar elementos sujetos a cambio.
2. En caso de que el cambio signifique la compra de hardware o software, cotizar la
realización del cambio e informar al cliente, quién deberá autorizar o no la
compra.
3. Realizar el cambio.
a) Coordinar con el usuario la fecha y hora del cambio.
b) Registrar los cambios realizados.
4. Cerrar el incidente.
a) Verificar satisfacción del usuario.

En la figura 25 se muestra la representación del flujo del proceso.



Figura 25: Proceso de gestión del cambio para equipos de escritorio


74

2.3.5 Control y distribución de software y hardware

El objetivo del proceso es la protección del ambiente productivo y sus servicios, a través
del uso de procedimientos formales y revisiones. Se relaciona directamente con la
gestión del cambio [26]. El proceso debe considerar las etapas de planeación, diseño,
construcción, configuración y comprobación del hardware y el software para crear un
repositorio de versiones para el ambiente productivo [26].

Para el caso del software, las etapas de planeación, diseño, construcción, configuración
y comprobación ya fueron abordadas anteriormente, por lo que el enfoque para este
proceso es respecto al control de versiones de los artefactos de software.

El control de versiones de software puede llevarse a cabo sobre los siguientes
aspectos:

a) A nivel de archivos del código fuente, respecto a sus fechas de creación,
modificación y eliminación, por parte de uno o más autores.
b) A nivel de cambios dentro del código fuente, es decir, modificaciones, por parte
de uno o más autores.
c) A nivel de módulos funcionales del software, es decir un conjunto de archivos de
código fuente que componen un módulo.
d) A nivel del producto de software, de acuerdo a diferencias de funcionalidad, o
diferencias por correcciones producto de defectos o errores.

Entonces, la problemática es definir que se va a considerar como control de versiones
de software y cuáles son los aspectos relevantes para el registro de los cambios.

En general, un producto de software está compuesto de módulos propios que se
componen de archivos de código fuente y librerías externas, las que pueden ser de
terceros o construidas dentro de la empresa. Luego, se puede definir, un control de
versiones de carácter jerárquico desde el producto de software hasta los archivos de
código fuente que lo componen.

Para mantener el orden y en concordancia con lo señalado en el proceso de paso a
producción, se propone categorizar el código fuente según el tipo de tecnología, como
se muestra en la figura 26.

Respecto a la numeración de las versiones, se propone utilizar un correlativo con el
formato zzz yyy xxx . . , donde xxx corresponde al número de release o entrega, yyy
corresponde al número de revisión y zzz corresponde al número de sub-revisión.

Entenderemos por entrega al evento en que una pieza o producto de software, que
implementa un grupo de requerimientos, es liberado para su instalación en ambiente de
producción. Un cambio de funcionalidad es una nueva entrega, por lo tanto una nueva
versión. El número de revisión se incrementará respecto a la entrega de las
modificaciones realizadas en el software con el objeto de corregir defectos pero sin
cambio de funcionalidad. El número de sub-revisión corresponderá a la entrega de
modificaciones menores sobre una revisión del software y que no signifiquen cambio de
funcionalidad.
75


Es indispensable contar con un software para el control de las versiones, sobre todo si
una pieza de código es modificada por más de una persona. Las funcionalidades
mínimas requeridas son:

a) Permitir y llevar la trazabilidad de los cambios realizados sobre el código fuente.
b) Permitir la jerarquización del código fuente de acuerdo a lo propuesto en la figura
26.
c) Soportar múltiples usuarios y con capacidad de administrar la concurrencia sobre
un archivo de código fuente.
d) Manejar el historial de versiones del código fuente y productos de software.
e) Soportar el esquema de numeración de versiones propuesto anteriormente.
f) Tener mecanismos de seguridad y roles que permitan salvaguardar el código
fuente de accesos no autorizados.



Figura 26: Descomposición del producto de software para el control de versiones

En el caso del hardware, es el propio ciclo de gestión del cambio el que realiza el
registro de la planeación, construcción, configuración y comprobación, sin embargo el
diseño no es parte del proceso y por lo tanto se entenderá que es abordado como parte
del diseño del ambiente operacional de un proyecto ya sea de software, mantención, o
infraestructura.






76

2.4 Procesos de entrega del servicio

2.4.1 Gestión de disponibilidad y continuidad

El objetivo de la gestión de la disponibilidad es asegurar que los servicios de TI tengan
una disponibilidad sostenida en el tiempo, a un costo justificable y en satisfacción con
los objetivos del negocio [26]. Por otro lado, la continuidad asegura que los servicios
provistos por TI puedan ser recuperados dentro de los márgenes de tiempo requeridos
y acordados con el negocio [26].

Específicamente, la idea es asegurar la continuidad del negocio frente a un desastre o
falla mayor, reducir las vulnerabilidades, riesgos y producir planes de recuperación que
estén integrados al negocio.

El desarrollo de planes para asegurar la disponibilidad y la continuidad, que contemplen
la recuperación y las acciones a tomar frente a la no disponibilidad de un servicio no es
suficiente. Se debe considerar que las personas que ejecuten el plan deben estar
entrenadas en las actividades que tengan que realizar, con el objeto de que frente a la
contingencia, solamente actúen. Si el plan no satisface los requerimientos del negocio
frente a la no disponibilidad, entonces debe ser reformulado.

Un elemento importante a considerar, es que, las plantas industriales de la empresa,
por la naturaleza y velocidad de sus procesos, disponen de poca holgura de tiempo,
alrededor de 3 horas antes de parar. Por ello, la formalización e institucionalización del
proceso, no solo es a nivel del servicio TIC, sino que también a nivel de la empresa
cliente, la que debe incorporar como parte de sus procesos de operación, los planes
que sean definidos por la gestión de disponibilidad. En ese sentido, es relevante la
participación de un comité con representantes del cliente y del servicio TIC, en el que
se revisen y aprueben los planes.

Pero, ¿Qué ocurre frente a la disponibilidad? A priori, si un servicio está disponible
entonces no habría nada que hacer. Pero, ¿Es suficiente hacer nada para mantener la
continuidad de un servicio? De acuerdo a la experiencia práctica, deben realizarse
actividades para mantener la continuidad, es decir, administrar, prevenir y monitorear
los servicios. No hacerlo significa no estar gestionando la disponibilidad y los niveles de
servicio requeridos por el negocio, por lo tanto el resultado final para el cliente puede
ser desastroso. Las actividades mencionadas son transversales a los procesos que se
han estudiado en esta tesis y por lo tanto son prácticas que han de ser adoptadas por
las personas para el éxito de la organización TIC.

Como proceso, la gestión de disponibilidad y continuidad, contempla determinar los
elementos críticos del negocio, desarrollar planes para gestionar la disponibilidad y la
continuidad y formalizar con la organización tanto cliente como del servicio TIC [26],
entonces, se debe:

1. Definir los niveles de servicios.
a) Determinar las funciones críticas del negocio.
b) Determinar los requerimientos de disponibilidad.
77

2. Proponer un plan para la disponibilidad [26].
a) Identificar los componentes de servicio más relevantes.
b) Diseñar los servicios de acuerdo a los requisitos de disponibilidad.
c) Definir riesgos y su mitigación.
d) Definir el plan de recuperación.
e) Definir el plan para la no disponibilidad.
3. Determinar las actividades para mantener la continuidad.
10

a) Determinar las actividades de administración de la infraestructura.
b) Determinar las variables relevantes para monitorear la continuidad.
c) Establecer umbrales que permitan la prevención proactiva.
4. Formalizar el plan, capacitar, e institucionalizar mediante acuerdos de nivel de
servicio operativos [26].
5. Ejecutar los planes en caso de ser requerido.

En la figura 27 se muestra la representación del flujo del proceso.



Figura 27: Proceso de gestión de la disponibilidad y la continuidad


2.4.2 Gestión del nivel de servicio

De acuerdo a la figura 28, la gestión del nivel de servicio consiste en mantener y
mejorar la calidad del servicio TI, a través de un ciclo continuo de acuerdos, monitoreo y
reportes periódicos de estado de los servicios [26]. Para ello, la existencia de un comité

10
El detalle de estos temas, será revisado en la Gestión de Infraestructura.
78

de representantes de la empresa cliente y del servicio TIC es fundamental, para el
consenso, definición, acuerdo, revisión y optimización de los niveles de servicio.




Figura 28: Ciclo de gestión del nivel de servicio
11



De acuerdo a lo definido por la empresa, los acuerdos de nivel de servicio deben ser
establecidos mediante contratos. Sin embargo, un acuerdo de nivel de servicio o SLA
(Service Leve Agreement) no debe ser considerado solamente como un contrato formal,
es más bien un consenso entre un proveedor y un receptor de servicios y que cubre los
siguientes aspectos [3,23]:

a) El acuerdo de servicios, vale decir la definición de lo que se entrega y sus niveles
de satisfacción.
b) La prevención de conflictos, de acuerdo a la promesa del proveedor versus la
expectativa del cliente.
c) La distinción entre el proceso para entregar el servicio y el proceso de negocio
de la empresa que recibe el servicio.
d) Las expectativas del cliente.

Pero, ¿Qué elementos se deben considerar para especificar formalmente un nivel de
servicio? Primero, debe establecerse un compromiso para la efectividad del servicio
frente a los requerimientos del negocio. Segundo, los servicios deben especificarse
claramente, se manera tal que sus indicadores tengan sentido para el cliente. Los
costos del servicio deben ser claros y diferenciados de acuerdo a los distintos servicios
que se están entregando. Finalmente, los acuerdos deben ser comunicados a toda la
organización cliente y no permanecer en conocimiento de un grupo reducido de
personas.

En términos prácticos, un documento de acuerdo de nivel de servicios debe contener al
menos los siguientes puntos [3]:

1. Propósito del servicio.

11
Fuente: Microsoft Corp. 2003. MOF: Service Level Management.
79

2. Descripción del servicio.
a) Organización para la entrega del servicio.
b) Disponibilidad del servicio.
c) Manejo de cambios de servicio.
3. Niveles de servicio objetivos y medidas.
a) Definición de la métricas de servicio.
b) Definición de la manera en que será monitoreado el servicio.
c) Definición de los reportes del servicio.
4. Costos del servicio.
5. Escalamiento.

Tomando en consideración lo señalado anteriormente, el proceso de gestión del nivel
de servicio se define de la siguiente manera:

1. Levantar los requerimientos de servicio.
2. Definir el catálogo de servicios.
3. Definir los niveles de servicio requeridos por el negocio.
4. Monitorear el cumplimiento de los niveles de servicio.
5. Reportar al cliente los niveles de Servicios.
6. Revisar los acuerdos de nivel de servicio.

En la figura 29 se muestra la representación del flujo del proceso.



Figura 29: Proceso de gestión del nivel de servicio

80

2.4.3 Gestión de finanzas TI

El objetivo de la gestión de finanzas es identificar, calcular y gestionar el costo de
entregar servicios de tecnologías de información [26]. El proceso lo podemos dividir en
tres subprocesos: elaboración del presupuesto, contabilización, facturación y cobro de
los servicios.

Anteriormente, se definió el proceso de presupuesto y el marco para el costeo de los
servicios. La tarificación para el cobro, corresponderá a determinar el precio final que se
facturará a los clientes. En este caso, como el objetivo es que la utilidad de la empresa
de servicios debe ser igual a cero, la tarifa será el costo de los servicios percibidos por
las empresas.

Para simplificar y evitar el re cálculo diario de las tarifas, el costo de los servicios fijos,
variables y de valor agregado, será calculado anualmente de acuerdo a la oferta de
mercado disponible en ese momento. Las variaciones, que pueden representar
pérdidas o utilidad serán absorbidas o invertidas para el siguiente periodo fiscal.

Respecto a la contabilización, facturación y cobro de los servicios, la empresa utilizará
las normas establecidas internamente por el holding, las que no se mencionan por
encontrarse fuera del alcance de esta tesis.

Como proceso, la gestión de finanzas se puede definir de la siguiente manera:

1. Recepción y contabilización de facturas de proveedores.
2. Prorrateo (si corresponde) de las facturas de proveedores.
3. Aprobación de pago facturas de proveedores.
4. Recopilación y valorización de las horas hombre trabajadas en servicios sujetos
a ese ítem de costo.
5. Elaboración de ítems de facturación para cada empresa que percibió servicios.
6. Facturación, de acuerdo a las normas establecidas internamente.
7. Cobranzas, de acuerdo a las normas establecidas internamente.


En la figura 30 se muestra la representación del flujo del proceso.

81



Figura 30: Proceso de gestión de las finanzas


2.4.4 Gestión de capacidad

La gestión de capacidad, tiene por objetivo asegurar que la infraestructura tecnológica
sea acorde a las demandas y crecimiento del negocio, a un costo justificable [26]. El
proceso involucra, el monitoreo del rendimiento de los servicios y la infraestructura que
los soporta, el análisis de los resultados del monitoreo, el tuning de los recursos, el
pronóstico de acuerdo a la demanda y la confección de un plan de capacidad, conforme
a los requerimientos de la empresa [18].

Existen tres ámbitos que han de ser abordados: la gestión de la capacidad del negocio,
la gestión de la capacidad de los servicios y la gestión de la capacidad de los recursos
[18].

2.4.4.1 Gestión de capacidad del negocio

La gestión de la capacidad del negocio tiene relación con asegurar que los
requerimientos futuros de servicio, sean considerados y entendidos y que la capacidad
82

requerida para soportarlos sea planificada e implementada, de acuerdo a la planeación
que sea establecida [18].

Por lo tanto, el servicio TIC, debe proveer los mecanismos para:

1. Identificar los requerimientos de servicio y acordar niveles de servicio.
2. Diseñar la configuración para soportar el servicio.
3. Evaluar económicamente el requerimiento.
4. Implementar de acuerdo a las fechas establecidas.

Como parte del diseño organizacional, la función debe ser cubierta, mediante la relación
directa con el cliente, es decir, con la toma de requerimientos del negocio y el
aseguramiento de que los niveles de servicio comprometidos son cumplidos.

2.4.4.2 Gestión de capacidad de los recursos y servicios

El objetivo de la gestión de capacidad de los servicios es, identificar y entender el uso
de recursos, patrones de comportamiento y peaks, de los servicios, de manera tal, de
asegurar que los niveles de servicio son cumplidos [18]. Por otro lado, la gestión de
capacidad de los recursos, tiene relación con la identificación y comprensión de la
utilización de cada componente de la infraestructura tecnológica. Lo que asegura, el
uso optimo de los recursos de hardware y software, de manera tal de mantener y
cumplir con los niveles de servicio acordados [18].

Derivado de lo anterior, es necesario entender, la composición tecnológica de cada
servicio, con el objeto de definir un marco para las variables que han de ser
consideradas para determinar la capacidad. En la tabla 16, se presenta dicha división.

Hay que notar, que existen recursos tecnológicos comunes, que componen los
servicios, estos son: servidores, computadores de escritorio (incluyendo notebooks),
impresoras y dispositivos de comunicaciones y de red.

83



Tabla 16: Componentes tecnológicos de los servicios

Para cada uno de los componentes señalados, se puede establecer, una serie de
indicadores que describan su comportamiento, teniendo en consideración, que los SLA
definidos tienen relación con la disponibilidad y cumplimiento de compromisos, de
acuerdo al tipo de servicio.

En estricto rigor, la variable de decisión, debiera reducirse a la disponibilidad, porque
independiente del tipo de servicio, los recursos de tecnología son utilizados
transversalmente y apoyan la consecución del cumplimiento de compromisos.

Entonces, el problema se encuentra en determinar las variables que tienen directa
relación con la disponibilidad del recurso tecnológico ya que la falta de capacidad para
afrontar una demanda de uso, implica una no disponibilidad. En las tablas 17, 18 y 19
se han categorizado los recursos tecnológicos con sus correspondientes indicadores y
84

criterios para determinar la no disponibilidad. Los servidores y computadores de
escritorio, se han agrupado ya que, los indicadores son los mismos, porque el sistema
operativo que utilizan es de similares características.



Tabla 17: Indicadores de capacidad de servidores y PC
12



12
Fuente: Documento Interno. 2005. Estudio de rendimiento de un sistema de ejecución de manufactura. Empresa
Forestal. Chile.
85



Tabla 18: Indicadores de capacidad para impresoras




Tabla 19: Indicadores de capacidad de equipos de comunicación

Respecto a la planeación de capacidad para afrontar una demanda de uso, hay que
distinguir entre la proyección o pronóstico de uso frente a la predicción. La primera,
tiene relación con la estimación del uso en el corto plazo, con el objeto de determinar
acciones correctivas en el día a día y entregar tendencias de lo que está ocurriendo con
el servicio. La segunda, se refiere al análisis del comportamiento del servicio y a la
obtención de un modelo lo suficientemente repetible, para que frente a escenarios de
carga distintos, se pueda predecir el comportamiento y por lo tanto, el establecimiento
de planes, que permitan la adecuación del servicio, a la necesidades del negocio.

86

La proyección de la carga de trabajo, se puede realizar mediante técnicas de regresión
lineal, promedios móviles y suavización exponencial. Se propone la utilización de la
suavización exponencial ya que es simple y presenta menor varianza respecto a las
otras técnicas. La predicción de la carga de trabajo, es determinada mediante modelos
de simulación o modelos analíticos basados en redes de colas (queuing networks), los
que se construyen de acuerdo al caso particular y que no se abordarán por encontrarse
fuera del alcance de esta tesis.

2.4.5 Gestión de proveedores

El objetivo de la gestión de proveedores es garantizar un uso eficiente de los
proveedores de servicios internos y externos de TI, de acuerdo a los niveles de
servicios comprometidos con el negocio [26]. En particular, se debe asegurar la calidad
de la relación, evaluar y controlar el desempeño de acuerdo a criterios establecidos y
cuantificables, mantener un inventario de proveedores y su impacto o relación con los
servicios.

Una de las premisas básicas de la empresa para su relación con los proveedores, es
que la relación sea de largo plazo y con carácter de socio estratégico. Por ello la
administración de proveedores, tiene que ver con el ordenamiento y homologación de
los contratos de servicio que se encuentran distribuidos a través de todas las filiales y el
cumplimiento de los niveles de servicio y contratos acordados.

El marco general definido por la empresa, para la homologación, contempla que un
contrato de servicios de terceros debe contener al menos:

a) Objeto del contrato.
b) Especificación, precio, forma de pago y reajuste de los servicios.
c) Cláusula de revisión de los servicios.
d) Declaración de capacidad e idoneidad del tercero para proveer el servicio.
e) Declaración de confidencialidad de la información.
f) Responsabilidad por accidentes y daños y seguros.
g) Declaración de cumplimiento de las normas de comportamiento, higiene y
seguridad de la empresa.
h) Garantías.
i) Vigencia del contrato.
j) Condiciones de término del contrato.
k) Cláusula de arbitraje.
l) Modalidad de las comunicaciones para efectos del contrato.
m) Oferta comercial del servicio.
n) Niveles de Servicio.

Desde el punto de vista del proceso, las actividades propuestas son:

1. Establecer el contrato.
a) Acordar servicios y tarifas.
b) Firmar el contrato.
2. Administrar el contrato.
87

a) Realizar seguimiento a los niveles de servicio acordados.
b) Realizar seguimiento al cumplimiento del servicio.
c) Solicitar modificaciones a los servicios de acuerdo a lo que se estipule en
el contrato.
3. Gestionar el cumplimiento de los contratos de los proveedores.
a) Registrar el cumplimiento de acuerdo a las métricas propuestas en el
diseño de servicios.
b) Comunicar a la organización el grado de cumplimiento.
c) Elaborar ranking de proveedores de acuerdo a su comportamiento.
d) Terminar el contrato de los proveedores que no tengan buen
comportamiento de cumplimiento de contrato.

En la figura 31 se muestra la representación del flujo del proceso.



Figura 31: Proceso de Gestión de Proveedores

Con lo anterior, se estableció un marco del proceso para la administración de
proveedores, donde el supuesto era que los proveedores son externos.

Por otro lado, ITIL plantea además la gestión de proveedores internos, es decir, cada
área de la organización es un receptor y proveedor de servicios de una o más áreas. El
objetivo final es establecer niveles de servicio operacionales (Operational Level
Agreement, OLA), de manera tal que los servicios entregados por la organización se
encuentren dentro de los niveles comprometidos con los clientes.

88

En principio, los OLA debieran ser los mismos indicadores definidos en los SLA,
pensando en que el cumplimiento promedio particular de los niveles asegura el
cumplimiento global. Sin embargo, de acuerdo a la tabla 20, existen diferencias entre
ambos conceptos que deben ser consideradas.



Tabla 20: Diferencias entre SLA y OLA
13


Para el caso de los servicios variables y de valor agregado se puede utilizar el mismo
indicador de SLA como OLA, ya que están orientados al cumplimiento de compromisos
de personas, entre el cliente y el servicio.

Pero, para los servicios fijos es necesario especificar OLA particulares, pensando en
que en algunos casos se trata de hardware, sobre el cual se pueden realizar
operaciones de incorporación, cambio y reparación de elementos de servicio. Entonces,
definiremos tres tipos de OLA:

1. OLA de Incorporación, como el nivel de servicio con que se incorporaran
elementos nuevos al servicio.
2. OLA de Cambio, como el nivel de servicio con que se cambian las
configuraciones del servicio.
3. OLA de Reparación, como el nivel de servicio con que se realizan las
reparaciones o reposiciones a los servicios.

Los OLA definidos, son presentados en la tabla 21.


13
Fuente: Microsoft Corp. 2003. MOF: Service Level Management.
89



Tabla 21: OLA para servicios fijos
90

2.5 Procesos de gestión de la infraestructura y seguridad

2.5.1 Gestión de infraestructura

La gestión de la infraestructura está definida como un conjunto de procesos, en los que
se aborda el (la) [26]:

a) Diseño de la infraestructura y planificación estratégica, es decir la creación
y/o mejoramiento de soluciones a través del tiempo, basado en una estrategia
de largo plazo.
b) Deployment, relacionado con la implementación y puesta en marcha de las
soluciones tecnológicas y del negocio.
c) Operación, es decir, actividades diarias de soporte y mantenimiento de la
infraestructura.
d) Soporte técnico, consistente en la estructuración y apoyo a otros procesos
para garantizar la entrega del servicio.

Los procesos de soporte técnico y deployment, han sido abordados anteriormente. El
primero, como parte del escalamiento en la gestión de incidencias y de problemas y el
segundo como el proceso de paso a producción definido en la gestión del cambio, por
lo tanto no se revisará.

Respecto al diseño y planificación, existen dos aspectos a considerar, primero el
relacionado con los modelos de administración y arquitectura que sean más adecuados
a las necesidades del negocio, y el segundo a la creación y/o mejoramiento de las
soluciones, es decir, el desarrollo de proyectos de infraestructura, que a diferencia del
software, son más simples ya que no hay construcción de aplicaciones, solo
parametrización de productos, pero complejos en cuanto a la integración a la
plataforma. Las actividades propuestas, para un proyecto de infraestructura son:

1. Levantamiento de necesidades.
2. Determinar la solución y la evaluación técnico-económica.
3. Aprobación de la solución por parte del comité de TI.
4. Realización del proyecto de infraestructura.
a) Realizar la ingeniería de detalle.
b) Construir la solución.
c) Determinar el plan de pruebas.
d) Gestionar los riesgos del proyecto.
e) Realizar pruebas.
5. Puesta en productivo (integración a la plataforma).

En la figura 32 se muestra la representación del flujo del proceso.

91



Figura 32: Actividades generales de un Proyecto de Infraestructura

Desde el punto de vista del modelo de gestión, es útil considerar una jerarquización de
los elementos que se pueden abordar, de manera tal de establecer las capas
fundamentales sobre las que se desarrolla la gestión de la infraestructura. De acuerdo a
la figura 33, los elementos de gestión se encuentran divididos, desde lo operativo a lo
táctico, en actividades de operación, control y monitoreo, administración de seguridad y
administración de infraestructura.



Figura 33: Jerarquización de las actividades de Infraestructura
14


14
Fuente: Microsoft Corp. 2005. MOF: Network Administration.
92


2.5.1.1 Administración de la Infraestructura

Para administrar la infraestructura, existen cinco modelos básicos de administración
[20]:

a) Datacenter centralizado y administración centralizada.
b) Datacenter distribuido y administración centralizada.
c) Datacenter distribuido y administración centralizada / delegada.
d) Datacenter distribuido y administración distribuida.
e) Administración de tipo “follow the sun”, es decir datacenters distribuidos entre
distintas localidades geográficas en el mundo, donde la administración y la
operación es transferida entre cada unidad de acuerdo a horarios diurnos de
trabajo.

El modelo más apropiado es tener una gestión centralizada y datacenters distribuidos,
de acuerdo a la disponibilidad de servicios requerida por los negocios. La ventaja de
una gestión centralizada, es que se mantiene el control general de la plataforma, se
producen ahorros ya sea por cantidad de personas, licencias y consolidación. Sin
embargo, puede haber operaciones que requieran la intervención local. Para ello, en
vez de delegar la administración la actividad puede ser ejecutada por un técnico en
terreno y supervisada por un administrador central.

Los servicios de infraestructura son los relacionados con las funcionalidades básicas de
red y aplicaciones, las que son descritas en la tabla 22.



Tabla 22: Descripción de los servicios de infraestructura

Respecto a la arquitectura de provisión de servicios y considerando que el holding es
distribuido geográficamente, conviene definir, un criterio para decidir entre lo que se
encontrará centralizado y lo que será particular a cada localidad.

La centralización debe ocurrir cuando más de dos empresas tengan necesidades
equivalentes y no haya impedimento para la operación normal, es decir, que frente a
perdidas de servicio, no se paralice una empresa. Los servicios localizados deben
permitir autonomía de manera tal, que frente a pérdidas del servicio WAN, no se vean
afectados los procesos de negocio y los servicios básicos de red de la empresa cliente.


93

Finalmente, la administración de la infraestructura define las políticas y estándares, con
el fin de normar y establecer lineamientos y entradas claras al proceso de planeación
estratégica, respecto a:

a) La arquitectura y diseño técnico de las soluciones de hardware, para los
proyectos de software.
b) Equipamiento a utilizar de acuerdo al tipo de aplicación, ambiente, o software.
c) La administración de las comunicaciones, en cuanto a reglas de tráfico,
priorización, disponibilidad y recuperación.
d) El uso de software para proteger el equipamiento, por ejemplo: antivirus,
antispyware, etc.
e) La política de respaldo y recuperación de la información.

2.5.1.2 Administración de la Seguridad

La administración de seguridad se revisará más adelante, en el proceso de gestión de
seguridad.

2.5.1.3 Monitoreo y Control de Servicios

El monitoreo y control de servicios corresponderá a la revisión periódica de indicadores
relacionados con los servicios de infraestructura [24]. Para ello es conveniente utilizar
software que permita realizar la actividad automáticamente, generando alarmas
dirigidas al administrador cuando algún indicador se encuentre fuera de rango por un
cierto periodo de tiempo. El administrador deberá realizar las acciones que re-
establezcan la operación normal, de acuerdo a los procedimientos de operación que se
definan.

Las variables de monitoreo pueden ser clasificadas en las que son propias del servicio y
las que son propias del servidor en donde es ejecutado dicho servicio. Por la extensión
del tema, no se revisarán las variables de los servicios. Sin embargo, a modo de
ejemplo, en la tabla 23, se presenta, una definición de las variables típicas de monitoreo
de un servidor bajo ambiente Windows y sus umbrales de operación.

Cabe señalar, que las variables definidas constituyen una descomposición de servicios,
que es requerida, para gestionar la capacidad, por lo tanto son una entrada a dicho
proceso.

94



Tabla 23: Variables de monitoreo de un servidor
15



2.5.1.4 Actividades de Operación

La operación de la infraestructura corresponde a las actividades diarias de
administración, soporte y mantenimiento de los servicios. En la tabla 24, se proponen
las actividades que debieran ser habituales.



Tabla 24: Actividades de operación habitual de la infraestructura
16


Cada una de las actividades mencionadas, debe estar asociada a procedimientos con
el fin de asegurar que sean prácticas que se realicen a través del tiempo. Para los

15
Fuente: Documento Interno. 2005. Estudio de rendimiento de un sistema de ejecución de manufactura. Empresa
Forestal. Chile.
16
Fuente: Microsoft Corp. 2002. MOF: System Administration.
95

productos Microsoft y Oracle, existen guías ya definidas, las que se pueden encontrar
en los sitios web de dichas compañías.

2.5.2 Gestión de seguridad

El objetivo de este proceso es la definición, control, gestión e implantación de las
políticas de seguridad definidas para las aplicaciones (software) e infraestructura [26].

Dentro del holding, la seguridad solo ha sido abordada desde el punto de vista de
acceso desde redes externas, mediante la definición de políticas y la implementación de
dispositivos firewall. Por lo tanto no existe desarrollo previo.

Como primer paso, se puede establecer un marco para la gestión de la seguridad y
cuyo resultado sea el establecer la visión, los mecanismos de control, las revisiones y
las políticas. En ese sentido, el proceso, que debe ser parte de la administración de la
infraestructura, es continuo en el tiempo.

Para el caso de las aplicaciones, las áreas de mantenimiento y de desarrollo de
software, deben incorporar las políticas de seguridad como un requisito funcional más y
deben entregar herramientas de administración de perfiles para acceder a las
funcionalidades y los datos.

Entonces, para la gestión de seguridad, se propone el siguiente marco:

1. Establecer una política de seguridad para la organización.
a) Acordar una visión compartida de la seguridad y el compromiso de los
terceros relevantes.
b) Identificar los requerimientos de seguridad de la organización.
c) Identificar los niveles de seguridad para los datos de la organización.
d) Implementar revisiones periódicas de la política de seguridad.
2. Establecer un proceso de gestión de riesgos de seguridad.
a) Determinar los mecanismos de control de la seguridad.
b) Revisar periódicamente los riesgos de seguridad.
c) Implementar los mecanismos de control.
3. Establecer un proceso de monitoreo y auditoria de la seguridad.
a) Identificar ataques potenciales y problemas de seguridad.
b) Identificar debilidades de los sistemas periódicamente.
c) Entregar reportes periódicos de los problemas encontrados.
4. Establecer un proceso de respuesta frente a incidentes.

El desarrollo de las políticas y los mecanismos de control han de ser definidos una vez
que el área respectiva comience a funcionar. De todas maneras, se propone abordar
los siguientes puntos como agenda inicial:

1. Definir y establecer la política de seguridad de la organización.
2. Definir la política de seguridad de aplicaciones.
a) SAP.
b) no SAP.
96

c) Shop Floor (Piso planta).
3. Definir la política de seguridad del hardware.
a) Dispositivos de red.
b) Servidores.
c) PC y notebooks.
d) PDA.
e) Impresoras.
4. Implementar las políticas de seguridad definidas.

Una vez realizadas las actividades, se propone la aplicación del proceso marco definido
para la gestión.

97

Capítulo 4 – Organización

1. Estructura Organizacional.

Las organizaciones son grupos de personas que buscan el logro de un propósito
común. Esto se consigue a través de la segmentación o división del trabajo [11]. Para
este caso, la estructura organizacional a definir debe ser capaz de soportar los servicios
y procesos mencionados en el capitulo anterior. Sin embargo, se presentan
inconvenientes adicionales a ser considerados.

Un primer problema es la distribución geográfica de las plantas, personal y oficinas del
holding. Los focos de localización son:

En Chile:

a) Antofagasta, con oficinas comerciales.
b) Coquimbo, con oficinas comerciales.
c) Santiago, con plantas productivas, oficinas centrales y de filiales del holding.
d) Talca, con plantas productivas y oficinas comerciales.
e) Concepción, con oficinas de filiales.
f) Temuco, con oficinas comerciales.
g) Los Ángeles, con oficinas de filiales.
h) Nacimiento, con plantas productivas.

En el extranjero:

a) Perú, con plantas productivas.
b) Argentina, con plantas productivas.
c) Uruguay, con plantas productivas.
d) Brasil, con una oficina comercial.
e) México, con plantas productivas.

Un segundo elemento relevante es considerar las funciones básicas de TI, que en
términos generales, se puede decir que son las siguientes:

a) Gestión de la relación comercial con el cliente.
b) Servicio al cliente.
c) Desarrollo de proyectos de software.
d) Mantención de software.
e) Soporte a usuarios.
f) Gestión de la infraestructura TI.
g) Gestión de la calidad.

Un tercer punto, es referente a la integración y multiplicidad de los negocios del holding,
los que están agrupados por divisiones de negocio y que en su conjunto definen una
cadena de valor.
98


Culturalmente, existen limitantes en cuanto al enfoque con que las decisiones son
tomadas. La manera de funcionamiento del holding es altamente jerarquizada, las
decisiones son tomadas por Gerentes y Subgerentes. Por lo tanto, desde la perspectiva
de orientación al cliente y la oportunidad del servicio, supone un problema ya que en un
esquema de servicios, lo esperado es que las personas sean capaces de tomar sus
propias decisiones de acuerdo a un marco de atribuciones funcionales.

1.1 Primer nivel organizacional

El primer nivel de gestión, tiene relación con las funciones básicas de tecnologías de
información, vale decir: relación comercial con el cliente, servicio al cliente, proyectos de
software, mantención de software, soporte, infraestructura y calidad. Esto nos lleva a las
siguientes opciones de organización para el primer nivel.

Opción 1: 1 Gerencia y 6 Subgerencias funcionales.

De acuerdo a la figura 34, bajo esta opción, se tienen seis subgerencias: calidad,
relación comercial con el cliente, servicio al cliente, proyectos, infraestructura y
mantención. En el caso de soporte, es claro que puede ser integrada bajo la función de
servicio al cliente, básicamente porque es un servicio que impacta directamente al
usuario final en cuanto a la satisfacción de requerimientos básicos relacionados con
herramientas informáticas.



Figura 34: Organigrama general, opción 1

Un problema de esta organización es por un lado, la cantidad de subgerencias y por
otra el tener dos unidades organizativas para atacar el problema de los procesos de
software: proyectos y mantención, las que a nivel de procesos son equivalentes. Esto
lleva a concluir, que podría ser mejor tener una sola unidad que se haga cargo, vale
decir, que desde el punto de vista funcional gestione los proyectos de software y realice
las mantenciones, con el benefició de que todo el ciclo de vida del producto de software
se mantiene bajo una sola responsabilidad. De aquí es que, a continuación, se propone
la opción 2.


Opción 2: 1 Gerencia y 5 Subgerencias funcionales

Esta opción, presentada en la figura 35, plantea tener 5 unidades funcionales: calidad,
relación comercial con el cliente, servicio al cliente, software, e infraestructura. La
unidad o subgerencia de software se hace cargo de los proyectos de software y las
99

mantenciones, por lo que, tal como se dijo anteriormente, el ciclo de vida del producto
se mantiene bajo una sola responsabilidad.



Figura 35: Organigrama general, opción 2

Sin embargo, esta organización tiene el siguiente problema, por ejemplo, si hubiera un
proyecto en el que no solamente sea software el involucrado, si no que hay otros
elementos y entidades de la organización que participan, ¿de quién es la
responsabilidad? La respuesta no es clara. Posiblemente se podría normar la
responsabilidad con un procedimiento, pero semánticamente no sería entendido por los
clientes.

Una manera de resolver el problema, es pensar en que el mantenimiento surge como
un requerimiento de cambio, por parte de un usuario, para un producto de software que
se encuentra en funcionamiento y que la línea de tiempo para realizar las adecuaciones
es de corto plazo. Bajo este enfoque, se puede decir que la mantención es un servicio
que impacta directamente la expectativa del usuario, por lo tanto, debiera ser tratada
bajo ciertas condiciones que manejen dicha variable. En ese sentido, sería razonable
incorporar el mantenimiento de corto plazo como parte de la función de servicio al
cliente, por la integración con la mesa de ayuda (que recibe el requerimiento) y por el
directo impacto sobre el usuario final.

Para el caso de proyectos, es claro que debe ser una unidad funcional aparte, que
considere no solamente los aspectos de software nuevo, sino que también, lidere los
proyectos de manera integral, e incorpore los proyectos de mantención (mantenciones
de largo plazo) como unidad especializada.

Una restricción que ha impuesto la empresa, es no incorporar en esta etapa una unidad
funcional de calidad. La decisión, se basa en que sería más aprovechable esperar a
que la organización se encuentre en régimen por uno o dos años, antes de pensar en
abordar el tema durante el proceso de cambio. En todo caso, en el capítulo 6, se
plantea un plan de mejora de software, cuya conclusión final plantea la creación de una
unidad funcional de calidad.

Por otro lado, es necesario incorporar la función de finanzas TI, que en este caso juega
el rol de controlar la gestión del área, facturar servicios y administrar contratos, por lo
tanto debe ser parte del staff del Gerente.

Todo esto nos lleva a la opción 3, que se describe a continuación.


100

Opción 3: 1 Gerencia y 4 Subgerencias funcionales

De acuerdo a la figura 36, bajo, esta opción, las funciones se han agrupado y
simplificado. Básicamente, se tiene la relación comercial con el cliente, servicio al
cliente, proyectos, e infraestructura. No existe la función de calidad.




Figura 36: Organigrama general, opción 3

De las opciones planteadas, la que más ventajas tiene, en términos de simpleza y
agrupación de funciones, es la opción 3. Por lo tanto es la que se utilizará para la
organización de TI.
1.2 Segundo, tercer y cuarto nivel organizacional

Los siguientes niveles organizacionales tienen un carácter táctico-operativo, que son los
que finalmente entregan el servicio a las empresas. Aparentemente, resulta más fácil
plantear una organización por división de negocio, sin embargo esto es una limitante ya
que el personal debe especializarse y focalizarse en dichas divisiones, lo que desde el
punto de vista de gestión de recursos limita la posibilidad de redistribuir en caso de ser
necesario, entonces, la especialización por negocio no es beneficiosa.

Otra opción es aprovechar la distribución geográfica del holding. Podemos distinguir las
siguientes zonas:

a) Chile Zona Centro, que comprende, Santiago y las oficinas comerciales del
norte del país.
b) Chile Zona Sur, que comprende, Talca, Concepción, Temuco, Los Ángeles y
Nacimiento.

Para el extranjero, es natural pensar agrupar Argentina con Uruguay, Perú con Brasil y
México aparte.

La agrupación por zonas geográficas, resulta más conveniente ya que tiene la facilidad
de que la función de TI no se ve afectada por la especialización en una división y
permite orientarse a los clientes y los procesos que son transversales al holding de
empresas.

101

En consecuencia, la organización para las subgerencias que tienen directa relación con
los usuarios, es decir relación comercial y servicio al cliente, se planteará
geográficamente. En el caso de proyectos e infraestructura, se pueden considerar como
unidades centrales de apoyo y servicios. Por lo tanto la especialización puede
plantearse por procesos y/o tecnologías relevantes.

1.2.1 Subgerencia Relación Comercial Cliente

En el caso de esta subgerencia, la agrupación se ha realizado por zona geográfica,
incorporando jefaturas de zonas: centro, sur, e internacional. Además, se incorpora un
recurso de staff de la subgerencia, encargado de la planificación global y gestión del
servicio, lo que se puede visualizar en la figura 37.



Figura 37: Organigrama subgerencia relación comercial cliente

Las funciones que debe desempeñar esta unidad son las siguientes:

a) Planificación del Servicio TIC.
b) Administración de los Niveles de Servicios.
c) Toma de requerimientos y expectativas de los clientes.
d) Entrega a los clientes de los planes y servicios de TIC con la calidad
requerida y acordada con el Negocio.



102

Las responsabilidades son:

a) Ser el representante de TI ante las filiales del holding, ser el representante de
las filiales del holding ante la gerencia de servicio TI.
b) Definir, mantener y difundir los servicios, a través de un catálogo de servicios.
c) Velar por mantener una relación equilibrada entre las demandas de los
clientes y el costo del servicio.
d) Definir, negociar, seguir y reportar los acuerdos de nivel de servicio con los
clientes.
e) Definir, negociar y recopilar los acuerdos de nivel operacional con las
unidades de TI.
f) La mejora continua de los servicios.
g) La planificación de los servicios y del seguimiento de este plan.
h) Identificar, capturar, especificar, evaluar y canalizar los requerimientos de los
clientes respecto de nuevos servicios o funcionalidades de los sistemas de
información.
i) Actuar como representante del negocio en la evaluación de impactos de
cambios que se produzcan en la infraestructura TIC y sus servicios.
j) Mantener el inventario y configuración de los ítem relacionados a los
acuerdos de nivel de servicio y planificación.
k) Proveer información necesaria de la prestación del servicio TI a control de
gestión TI.
l) Análisis de impacto al negocio ante desastres que afecten los servicios TI.
m) Invocación de planes de contingencia y la relación con las unidades de
negocio ante un desastre que afecte los servicios TI.
n) Representar al servicio, junto con el Gerente TI.
o) Evaluar el desempeño de los proveedores de TI respecto de su impacto en el
servicio TI.

1.2.2 Subgerencia Servicio al Cliente

Servicio al cliente cuenta con la mesa de ayuda (service desk), que entrega los
servicios de soporte de primer, segundo nivel y aplicaciones. Se hace la distinción entre
aplicaciones SAP y el resto ya que SAP es el ERP de carácter corporativo, por lo tanto
se ha incorporado esta figura a la estructura.

Soporte consta de técnicos de terreno que atienden los requerimientos de los usuarios
que les hayan sido derivados desde la mesa de ayuda. Nuevamente, el primer criterio
para organizar es la zona geográfica ya que se tiene un directo impacto sobre los
usuarios.

El área de mantención, se encarga de las mantenciones de corto plazo, consta del
analista de demanda y divisiones por zonas geográficas, salvo SAP que es de carácter
corporativo.

En la figura 38 se muestra la representación de la subgerencia.
103



Figura 38: Organigrama subgerencia de servicio al cliente

Las funciones de la subgerencia son:

a) Atención de usuarios (Service Desk).
b) Administración de incidencias.
c) Control y distribución de software y hardware.
d) Mantención de corto plazo de aplicaciones.
e) Administración de servicios y soporte local.

Las responsabilidades son:

a) Proveer de un punto único de contacto entre el servicio y sus usuarios, el cual
atienda los requerimientos de soporte referente a los servicios TI.
b) Responsable de recomendar y asesorar a la unidad de relación comercial con
el cliente de los niveles de servicios que pueden ser acordados para la
atención, soporte a usuarios y mantenimiento de aplicaciones.
c) Responsable de proveer mecanismos de escalamiento eficiente que permitan
el cumplimiento de los niveles de servicios establecidos para la atención de
incidencias.
d) Responsable del seguimiento, control y cumplimiento de los niveles de
servicios relativos al soporte a usuario, mantenimiento de aplicaciones y
seguridad informática.
e) Reporta los niveles de servicios alcanzados por la unidad a la unidad de
relación comercial con el cliente.
f) Difundir los servicios TI ante los usuarios.
104

g) Responsable del soporte local de los servicios TI en cada una de las
empresas del holding.
h) Responsable de encontrar soluciones de fondo ante incidencias repetitivas o
cuya causa raíz es desconocida.
i) Responsable de la mejora continua del servicio de atención de usuarios,
soporte local, mantenimiento de aplicaciones.
j) Responsable de la planificación del servicio de atención y soporte de usuarios
y del seguimiento de este plan.
k) Responsable de la planificación del servicio de mantenimiento de
aplicaciones y del seguimiento de este plan.
l) Responsable de mantener el inventario y configuración de los ítem
relacionados a la atención de usuarios, soporte de usuarios, mantenimiento
de aplicaciones.
m) Responsable de proveer información necesaria de la prestación del servicio a
los usuarios a control de gestión TI.
n) Responsable de canalizar las solicitudes de cambio a través del servicio de
atención a usuarios.
o) Responsable de la implementación, de acuerdo a los procedimientos
establecidos de la plataforma tecnológica de uso de los usuarios, cumpliendo
los niveles de servicios establecidos.
p) Gestionar los proveedores TI relacionados con las funciones de la unidad de
Servicio al Cliente.
q) Ser el apoyo local de Proyectos e Infraestructura.

1.2.3 Subgerencia de Proyectos

Para la subgerencia de proyectos, el criterio de división es respecto a tecnologías y/o
procesos asociados. Se distinguen los siguientes:

a) Software general, unidad encargada de realizar proyectos que no caben en
las categorías de especialización definidas, por ejemplo: sitios webs,
aplicaciones forms, visual basic, etc.
b) Integración, unidad encargada de realizar proyectos relacionados con
software middleware, vale decir que integra distintos tipos de sistemas o
capas dentro de una arquitectura.
c) Automatización, unidad encargada de realizar proyectos relacionados con la
automatización de plantas productivas, vale decir: sistemas de ejecución de
manufactura, control automático, gestión de procesos de plantas, etc.
d) Inteligencia del negocio, unidad encargada de realizar proyectos de tipo data
warehouse, gestión de la información, minado de datos, etc.
e) SAP, unidad encargada de realizar proyectos SAP, vale decir, se encarga de
los proyectos sobre el ERP de la compañía.
f) Mantenimiento, unidad encargada de realizar los proyectos de mantención.

De acuerdo a la figura 39, la estructura es de Jefes de Proyecto con su respectivo
equipo de Ingenieros de Proyecto, sin embargo, dado el tamaño del holding, es
necesario colocar un nivel que agrupe a los jefes de proyecto según su especialización,
para ello se definen los Project Manager o Gestores de Proyectos, cuya labor es la
105

gestión y control global de la cartera de proyectos del área de especialización. Además,
se contempla una unidad de control y planificación, la que se encarga de realizar el
seguimiento global de los proyectos y la asignación de recursos al portafolio.



Figura 39: Organigrama subgerencia de proyectos

En la figura 40, se plantea una variante para el nivel de Project Manager, que es
desligar la especialización respecto de las actividades de gestión. Para ello se puede
definir un spool, que independiente de la especialidad, sea capaz de gestionar y
controlar los proyectos, dejando la componente técnica al jefe de proyecto. Con esto se
logra una mejor movilidad de recursos dedicados a la gestión.



Figura 40: Organigrama alternativo de la subgerencia de proyectos

Para el servicio que se ha definido, la empresa ha pedido, no separar la especialización
de la gestión debido al carácter jerárquico de la organización, dejando esta mejora para
una implementación posterior.


106

Las funciones de esta subgerencia son:

a) Selección de paquetes de software.
b) Implementación de paquetes de Software.
c) Desarrollo de software.
d) Definir la arquitectura de aplicaciones.
e) Soporte especializado ante problemas.
f) Desarrollo e implementación de soluciones de software de soporte a la
Inteligencia de Negocio y Automatización.
g) Planificación y gestión integral de Proyectos.

Las responsabilidades son:

a) Establecer las normas generales para la Administración de Requerimientos
de proyectos y las responsabilidades de cada uno de los entes involucrados.
b) Asegurar la administración y el control de los requerimientos de software a lo
largo del ciclo de vida de los proyectos de implementación y desarrollo.
c) Asegurar la participación y compromiso de los grupos involucrados.
d) Establecer las normas generales que rigen la Administración de
Configuraciones de Software.
e) Establecer y mantener la integridad y consistencia de los productos de
software a través de todo el ciclo de vida de los proyectos de software.
f) Establecer las normas generales para la planificación general de proyectos de
software y las responsabilidades de cada uno de los entes involucrados.
g) Minimizar los riesgos de la planificación proporcionando confiabilidad
respecto de las estimaciones y de la programación de actividades.
h) Asegurar la participación y compromiso de los grupos involucrados.
i) Establecer las normas generales para la administración de los subcontratistas
y proyectos de software subcontratados y las responsabilidades de cada uno
de los entes involucrados.
j) Normar la contratación de subcontratistas de software, asegurando una
eficiente administración de estos y los proyectos que le son asignados.
k) Establecer las normas generales para realizar el seguimiento y control de
software y las responsabilidades de cada uno de los involucrados.
l) Establecer acciones preventivas con el fin de evitar desviaciones en el plan
de proyecto y/o correctivas si existe una desviación de lo planificado versus lo
real.
m) Entregar una visión del avance real de los proyectos a la gerencia TI y
usuarios involucrados.
n) Asegurar a la organización el cumplimiento del Proceso de Desarrollo e
Implementación de Software.
o) Establecer las normas generales para garantizar la calidad de los productos
de software y las responsabilidades de cada uno de los entes involucrados en
el desarrollo y la implementación de estos.
p) Definir y utilizar los estándares que regirán el desarrollo e implementación de
software.
q) Realizar mantenciones de software de largo plazo, bajo la modalidad de
proyectos.

107

1.2.4 Subgerencia de Infraestructura

Primero, hay notar que las actividades de administración y operación son desarrolladas
centralizadamente. Si se requiere la intervención directa a algún equipo se utiliza como
apoyo el técnico de terreno de soporte. Debido a lo anterior, no vale la pena pensar en
una organización basada en la distribución geográfica. Sin embargo, las
responsabilidades si podrían ser de ese modo, por ejemplo, la administración de
sistemas, puede ser dividida en las mismas zonas geográficas, pero el personal puede
ir rotando con el fin de que tengan conocimiento general de las plataformas. De acuerdo
a lo propuesto en la figura 41, para la subgerencia de infraestructura se considera una
división clásica, vale decir:

a) Operaciones, que se encarga de la operación de los sistemas, ejecución de
procesos batch, etc.
b) Redes, que se encarga de la administración de redes WAN y LAN, además
de la telefonía.
c) Ingeniería, unidad que realiza la ingeniería de sistemas y la administración de
servidores. Se encuentra dividida en: bases de datos, sistemas unix y
sistemas windows.
d) Seguridad, que define y aplica las políticas de seguridad en cuanto a
aplicaciones, acceso a servidores y perimetral.



Figura 41: Organigrama subgerencia de infraestructura

Las funciones definidas para la subgerencia son las siguientes:

a) Diseño y planificación de plataforma computacional.
b) Administración y operación de la plataforma computacional y software del
negocio.
c) Pasos a producción de aplicaciones e infraestructura TI.
d) Gestión de cambios de la infraestructura TI.
108

e) Administración de bases de datos.
f) Administración de la seguridad.
g) Administración de servidores.
h) Sintonía de la plataforma computacional.
i) Asesoría especializada.
j) Resolución de incidentes de la plataforma computacional central o crítica.
k) Diseño y planificación de la infraestructura de telecomunicaciones.

Las responsabilidades son:

a) El monitoreo, soporte a soluciones y escalamiento de los recursos
computacionales servidores, redes, sistemas operativos y aplicativos de
negocio.
b) Diseñar y Planificar la infraestructura de soporte a los servicios TI.
c) Definición de los estándares de Implementación apropiados para las
soluciones de infraestructura TI en el ambiente productivo.
d) Implementación de las soluciones desarrolladas o adquiridas para el negocio
y/o TI, con una mínima interrupción de los procesos de negocio.
e) Proveer una plataforma TI estable y segura, disponible a ser usada como un
soporte fundamental para la provisión de servicios en beneficio del negocio.
f) Mantener y operar de manera eficiente y efectiva los procedimientos
operacionales de la infraestructura TI, asegurando que todos los servicios y
componentes de TI reúnan los objetivos y requerimientos que satisfacen al
negocio.
g) Entregar un soporte y asesoramiento especializado para la adquisición y
utilización de la infraestructura TI que dan soporte a los servicios.
h) Gestión, seguimiento y control de los proveedores de infraestructura y
servicios bases computacionales.
i) Gestión, seguimiento y control de la seguridad informática.
j) Proveer las capacidades y disponibilidades necesarias en la infraestructura y
aplicaciones de TI para el cumplimiento de los SLA.
k) Responsable de la existencia de planes de recuperación ante desastre que
puedan afectar los servicios TI soportados por la plataforma computacional.
l) Provisión, mantención y administración de la infraestructura de
telecomunicaciones acorde a las exigencias de los aplicativos de negocio.

2. Definición de Cargos

De la estructura organizacional definida en el punto 1 de este capítulo, se presenta la
definición de los cargos.
2.1 Gerencia de Servicios TIC

Gerente de Servicios TIC

Es el responsable máximo de la entrega del servicio TIC a cada una de las empresas
del holding.
109


Jefe de Finanzas y Control de Gestión

Responsable del control, soporte y seguimiento del presupuesto TIC. Revisa aspectos
contables, tiene a cargo la facturación y cobro de los servicios.

2.2 Subgerencia de Relación Comercial

Subgerente Relación Comercial

Es el responsable de la definición, planificación, seguimiento y control del servicio TIC
ante los clientes.

Service Manager

Responsable de la entrega del servicio TIC, su planificación y resultados en el ámbito
de la zona o empresas que representa. Canaliza los requerimientos de los clientes de
manera eficiente y efectiva a través de la organización de servicios TIC.

Ingeniero de Planificación y Gestión del Servicio

Apoya las funciones del Subgerente y de cada uno de los Service Manager en la
planificación de la entrega del servicio. Responsable del soporte al seguimiento de los
niveles de servicio.

2.3 Subgerencia de Servicio al Cliente

Subgerente de Servicio al Cliente

Responsable del funcionamiento eficaz y eficiente del área de servicio al cliente, acorde
a los requerimientos del negocio y a un costo justificable.

Jefe de Soporte y Mesa de Ayuda

Responsable de la implantación, revisión y funcionamiento del proceso de incidencias y
problemas y del soporte local.

Jefe de Soporte Zonal

Responsable de los procesos y funcionamiento del soporte de segundo nivel,
incluyendo el seguimiento y solución de problemas y errores conocidos. Se preocupa
de que los incidentes no solucionados por el service desk, sean solucionados,
investigados y evitados.



110

Técnico de Terreno de Soporte

Responsable de entregar apoyo a los procesos y funcionamiento del soporte de
segundo nivel, incluyendo el seguimiento y solución de problemas y errores conocidos.
Se preocupa de que los incidentes que no soluciona el service desk, sean
solucionados, investigados y evitados.

Ingeniero de Soporte

Responsable de entregar apoyo y coordinar los procesos y funcionamiento del soporte
de segundo nivel, incluyendo el seguimiento y solución de problemas y errores
conocidos. Se preocupa de que los incidentes que no soluciona el service desk, sean
solucionados, investigados y evitados.

Jefe de Mantención

Responsable del servicio de mantención de aplicaciones.

Jefe de Mantención Zonal/SAP

Responsable del control y planificación del proceso de mantención de aplicaciones.

Analista de Demanda

Responsable del soporte a la gestión, asignación y control del mantenimiento de las
aplicaciones.

Analista de Aplicaciones

Responsable del soporte al análisis, diseño, modificación y construcción de
aplicaciones de negocio o implantación de paquetes comerciales.

Ingeniero de Mantención

Responsable del análisis, diseño y construcción de aplicaciones de negocio o
implantación de paquetes comerciales.

2.4 Subgerencia de Proyectos

Subgerente de Proyectos

Responsable del funcionamiento del área de proyectos, se encarga de gestionar las
personas, recursos y procesos de manera eficiente.

Project Manager

Responsable de la gestión de proyectos de desarrollo, e implementación de
aplicaciones y paquetes comerciales.
111

Jefe de Proyectos

Responsable del análisis, diseño y construcción de aplicaciones. Se preocupa de la
implementación de paquetes comerciales. Ayuda a los clientes a identificar problemas y
soluciones.

Ingeniero de Proyectos

Responsable de la ejecución de los procesos de desarrollo, mantención, e
implementación de software.

Ingeniero de Control y Planificación

Responsable de apoyar las labores de asignación de recursos, seguimiento y control de
los procesos de desarrollo e implementación de software, arquitectura y plataforma
SAP.

2.5 Subgerencia de Infraestructura

Subgerente de Infraestructura

Responsable de la definición, planificación, coordinación, diseño y funcionamiento de la
infraestructura informática de la organización. Gestiona personas, recursos y procesos
de manera eficiente.

Jefe de Operaciones

Responsable de la operación de la plataforma informática. Coordina y diseña la
infraestructura, establece políticas y documentación necesaria.

Jefe de Redes

Responsable de la coordinación con proveedores y diseño de la infraestructura de
redes de la organización.

Jefe de Ingeniería

Responsable de la coordinación con proveedores y diseño de la plataforma de la
organización.

Jefe de Seguridad Informática

Responsable de la definición y seguimiento de las políticas de seguridad al interior de la
organización.




112

Analista de Seguridad

Responsable de ejecutar las actividades necesarias para cumplir con las políticas de
seguridad.

Operador de Sistemas

Responsable de la operación, mantenimiento y control de los activos informáticos.

Administrador de Red

Administra y coordina los cambios sobre la plataforma de redes de la organización.
Realiza labores de optimización.

Administrador de Base de Datos

Administra y coordina los cambios sobre la plataforma de base de datos de la
organización. Realiza labores de optimización.

Ingeniero de Sistemas

Responsable del diseño, planes y estrategias de implementación de una plataforma de
acuerdo a las necesidades de la organización.


113

Capítulo 5 – Implementación, transición y cambio

1. Plan de implementación, transición y cambio

Para la implementación del servicio, un primer aspecto a considerar es la cultura
organizacional. El holding, se caracteriza por su carácter jerárquico, donde
prácticamente todas las decisiones son validadas o tomadas por los Gerentes o
Subgerentes de área. Esto es contrapuesto con un esquema de servicios ya que es él
cliente quien define lo que necesita y en muchas ocasiones no hay tiempo para recurrir
al Gerente o Subgerente para que valide o decida sobre una determinada acción. Este
problema, se ve aminorado por la definición y el marco de los procesos, sin embargo,
es necesario convencer a las personas para que adopten un nuevo enfoque para la
atención de los requerimientos de los usuarios. Los servicios entregados por la filial de
servicios compartidos, son transversales a las empresas y por lo tanto requieren de un
trabajo de colaboración más que jerárquico entre las diferentes unidades.

Otro elemento a considerar es que la alta dirección ha pedido, que durante el periodo
de transición, las filiales que reciben servicios de TI no sufran impacto por el cambio.
Por lo tanto, el plan de implementación, transición y cambio debe considerar aspectos
culturales, de operación actual y actividades a desarrollar en el tiempo.

Como marco general, se distinguen las siguientes grandes etapas:

a) Previa al cambio.
b) Transición y cambio.
c) Entrega del servicio.

Durante la etapa previa se definen los procesos, la estructura organizacional y la
planeación operativa para la transición. Durante la transición, se va implantando la
nueva estructura organizacional y los procesos definidos, para finalmente entrar en
régimen en la etapa de entrega del servicio.

A continuación se presenta el detalle de cada etapa.
1.1 Etapa previa al cambio

La etapa previa al cambio, corresponde al conjunto de actividades de capacitación y
definición de la estructura organizacional y los procesos TI.

114



1.1.1 Actividades de Capacitación

Dentro de las actividades de capacitación al personal, se distinguen dos aspectos: las
relacionadas con el desarrollo de competencias y habilidades personales y las
relacionadas con el entendimiento del modelo que se está implementando.

Para atacar el primer aspecto, el área de recursos humanos de la empresa ha definido
una serie de cursos y talleres tendientes a entregar herramientas a las personas para
desenvolverse bajo el nuevo paradigma, estos son:

a) Talleres de integración, cuyo objetivo es lograr que las personas de la
gerencia de servicios TIC se conozcan entre sí.
b) Taller de negociación, cuyo objetivo es capacitar y practicar en los aspectos y
técnicas modernas de la negociación, orientado a Subgerentes y a jefes de
área.
c) Taller de manejo de conflictos, cuyo objetivo es entregar elementos y técnicas
de resolución de conflictos, orientado a todo el personal TIC.
d) Curso y taller de servicio al cliente, orientado a todo el personal TIC, con el
objetivo de dar a conocer y aplicar los conceptos y claves de la orientación al
cliente.

Para el segundo aspecto, se contempla la necesidad de los siguientes cursos y talleres:

a) Curso de ITIL, orientado a todo el personal y con el objetivo de dar a conocer
el modelo ITIL desde una perspectiva general.
b) Talleres de procesos, cuyo objetivo es incorporar a los Subgerentes y a jefes
de área en las definiciones de los procesos TI.

1.1.2 Actividades de definición de los procesos TI

Tal como se revisó en el capítulo 2, la definición de los procesos es hecha mediante el
enfoque de re-ingeniería. Contempla la participación de los subgerentes y jefes de área
en la definición de los procesos, mediante talleres.

1.1.3 Actividades de definición de la estructura organizacional

Respecto a la estructura organizacional, el enfoque es realizar la definición en conjunto
con el gerente de servicios TIC y la empresa consultora. Posteriormente, será validado
por cada Subgerente designado para cada área.

115


1.2 Etapa de transición y cambio

Operativamente, el problema de la etapa de transición y cambio es el traspaso de
funciones del personal sin causar un gran impacto sobre el servicio actual. Para afrontar
esto, es necesario definir una estrategia de traspaso y un plan de difusión del servicio.

En primera instancia, el plan de traspaso debe considerar la función actual que es
realizada por una persona y la función futura a la que será destinada. Se pueden
distinguir dos casos:

1. Que una persona se mantenga realizando las mismas funciones, luego no tiene
nada que traspasar, pero si podría recibir, producto de la consolidación de
funciones y servicios.
2. Que una persona no se mantenga realizando las mismas funciones,
distinguiéndose dos situaciones:
a) La función es nueva, por lo tanto solo debe entregar.
b) La función se venía realizando con la estructura antigua y por lo tanto
tiene que recibir y entregar.

Un criterio de traspaso, es realizar un big bang, es decir, hacer traspasos ordenados
independientes de las funciones y criticidades actuales. Por ejemplo, si una persona
está en un proyecto, entonces deberá entregar su función en el proyecto, a la persona
que asumirá el rol en la nueva organización. El problema de esto, es que provoca
inestabilidad en los servicios, por el hecho de introducir cambios de personas en
trabajos que ya están en curso y por lo tanto las empresas pueden verse más afectadas
de lo que podría esperarse.

Otro criterio para minimizar la inestabilidad, es considerar, de la estructura
organizacional antigua, las funciones críticas para mantener operativos los servicios
que reciben las filiales. Entonces se tendrán los siguientes casos:

a) Personas que participan en proyectos en curso.
b) Personas que realizan las mantenciones de software.
c) Personas que realizan funciones de administración de servidores, servicios y
bases de datos.
d) Personas que realizan soporte a usuarios.

Para las personas que participan en proyectos en curso, el objetivo es no incorporar
riesgos que signifiquen atraso o inestabilidad a esos proyectos, por lo tanto deberán
permanecer en ellos hasta que finalicen. Sin embargo, si tienen que entregar funciones
anexas al proyecto y la persona que las recibe, las puede asumir, entonces deberá
hacer entrega de esas funciones.

En el caso de las personas que realizan mantenciones de software, si son asignadas a
funciones nuevas, entonces deberán terminar las mantenciones que tienen asignadas y
luego asumir y/o recibir las nuevas actividades.

116

Para las personas que realizan funciones de soporte a usuarios, administración de
servidores, servicios y bases de datos y que son asignadas a nuevas funciones,
entonces, a diferencia de los casos anteriores, deberán entregar las funciones actuales
y asumir las nuevas.

Entonces, la estrategia de cambio es un proceso que comienza primero con la línea de
subgerentes asumiendo sus funciones y luego, en una segunda etapa, el personal
asignado a cada subgerencia. Los traspasos se han de realizar de acuerdo a los
criterios señalados anteriormente en el tiempo que sea necesario, hasta completar toda
la organización, siendo deseable completar este proceso en un periodo de a lo más un
año. Cada subgerente, coordinara con su par en la estructura antigua el detalle de las
actividades que puedan ser traspasadas, generando así, un plan de traspaso que será
dado a conocer a la organización TIC.

El plan de difusión del servicio, consiste en una serie de reuniones en donde se
presentará y se dará a conocer la nueva modalidad de servicio a los representantes de
las filiales. Además, se distribuirá un folleto explicativo al personal de las empresas.
Esta actividad será ejecutada una vez que los subgerentes asuman sus funciones.

La presentación del servicio será realizada por: el Gerente de servicios TIC, el
Subgerente de Relación Comercial y el Service Manager de la empresa a la cual se
realizará la presentación. Se darán a conocer los siguientes puntos:

a) Breve introducción de la empresa de servicios compartidos.
b) Presentación de la nueva modalidad de servicios: estructura organizacional
TIC, breve descripción de los procesos que se utilizarán, acceso a los
servicios.
c) Descripción de los servicios ofertados.
d) Formalización de inicio de la nueva modalidad de servicios.

En la tabla 25, se presenta el plan global de transición, difusión y cambio.

1.3 Etapa de entrega del servicio

Finalmente, la etapa de entrega del servicio, es el estado de régimen de la
organización, en donde los procesos se encuentran adoptados y en funcionamiento. El
objetivo es llegar a este estado un año después de iniciado el proceso de transición y
cambio.
117



Tabla 25: Plan global de difusión y cambio
118

Capítulo 6 – Estrategia para la Mejora del Software

1. Marco del Proceso de Mejora de Software

El objetivo de este capítulo es diseñar el plan de acción estratégico para la mejora del
proceso de software (SPI) para proyectos de desarrollo y el proceso de mantención del
área de tecnologías de información, dentro de un marco de trabajo futuro, pensando en
la evaluación bajo CMMi en el mediano y largo plazo.

El plan de acción, integrara todas las actividades de mejora del proceso de software
mediante la adopción del modelo CMMi para la disciplina de Ingeniería en Software.
Este modelo, proporciona una guía para mejorar el proceso de una organización y la
capacidad para administrar el desarrollo, adquisición y mantención de productos y
servicios, proveyendo facilidades para ayudar a las organizaciones a examinar la
efectividad de sus procesos, establecer prioridades de mejoramiento y apoyar la
implantación de las mejoras. Los esfuerzos realizados se contrastaran con las
evaluaciones, tanto formales como informales de CMMi, las recomendaciones serán
incorporadas e institucionalizadas con el objeto de incentivar la mejora continua del
proceso.

En este capítulo, se presenta el plan del proyecto SPI cuyos objetivos son alcanzar en
el tiempo los distintos niveles de madurez CMMi, estandarizar las prácticas y procesos
de software para el área, disminuir el costo empresa de los proyectos y mantenciones
de software.

La motivación de esta iniciativa se basa en principios guías y en la oportunidad de
entregar mejores servicios a los clientes.

El compromiso de la alta gerencia es crítico para esta iniciativa, se espera:

a) Se disponga de los recursos apropiados y adecuados para el proyecto.
b) Existan comunicaciones continuas hacia la organización, filiales y gerencia
sobre la importancia del SPI y los avances que se produzcan en el proyecto.
c) Convencer a las filiales para incorporar como propio el proceso de mejora de
software, dejando en claro las expectativas reales de la iniciativa.
d) Se provea de un esquema de incentivos y reconocimiento para aquellas
personas que muestren adherencia a las mejoras del proceso y en general a
la participación y aporte en el proyecto.

El éxito del SPI se medirá mediante la evaluación exitosa en los niveles de madurez de
CMMi. La mejora continua estará dada por: la evaluación periódica del nivel alcanzado,
incorporando los hallazgos de estas actividades a las empresas y el avance en los
niveles de madurez CMMi.

119

2. Plan Estratégico de Mejora del Proceso de Software

2.1 Misión

Promover la mejora de procesos continúa a través de las filiales del holding, proveer la
guía hacia el camino de la excelencia en cada una de las áreas de proceso, que
permitan a la organización aumentar y mantener su nivel de madurez en el tiempo.

2.2 Visión

El servicio compartido de tecnologías de información pondrá todos sus esfuerzos en
institucionalizar los procesos de software mediante estándares documentados y proveer
productos fiables y servicios a tiempo, al mínimo costo.

2.3 Valores

Personas: Nuestra gente es la fortaleza de nuestra área. Creemos en el trabajo en
equipo y el compromiso de las personas, propiciamos un ambiente que permite al
personal crecer y desarrollarse profesionalmente.

Calidad: Creemos que la calidad de nuestros productos está directamente relacionada
con la calidad de nuestros procesos.

Madurez del Proceso de Software: Creemos que el modelo CMMi es un método
práctico de identificación y evaluación para medir la madurez del proceso de software.

2.4 Principios Guías

1. La satisfacción de nuestros clientes es crítica y de suma importancia para los
negocios.
2. La mejora continua del proceso de software es esencial para el éxito.
3. Procesos comunes y estándares son indispensables para el crecimiento
organizacional.
4. Los esfuerzos en la mejora de procesos son administrados con un eficiente uso
de recursos.


120

2.5 Metas de Corto Plazo

Obtener evaluación satisfactoria en CMMi nivel 2 en un plazo no superior a 2 años.

Estandarizar las prácticas y procesos de software del área de tecnologías de
información de la empresa de servicios compartidos.

Disminuir el costo empresa de los proyectos y mantenciones de software.

2.6 Metas de Largo Plazo

Desarrollar e institucionalizar la cultura de ingeniería de software basada en la mejora
continua de los procesos.

Alcanzar los distintos niveles de madurez CMMi cada 2 años, realizando evaluaciones
cada 1 año.

2.7 Metas Estratégicas Derivadas del Negocio

Alinearse con la política de calidad del holding matriz respecto a los procesos
productivos.

Mantener el liderazgo en costos y la producción de productos de alta calidad, conforme
a los estándares internacionales de la industria.

2.8 Objetivo

El objetivo de esta iniciativa es disminuir los costos para los procesos de desarrollo y
mantención de software.

2.9 Beneficios Esperados

1. Aumentar la productividad.
2. Reducir los esfuerzos de retrabajo para las mantenciones.
3. Mejorar el tiempo del ciclo del producto.
4. Disminuir la cantidad de defectos los productos de software.
5. Mejorar la moral de los empleados.

2.10 Principios Guía del SPI

El proyecto SPI pretende atacar las distintas etapas del proceso de software que vale la
pena mejorar, vale decir: issues del negocio, soluciones técnicas, administración de
121

proyectos y calidad. La organización debe ser capaz de explicar a los terceros
relevantes porque una actividad determinada o un entregable son importantes. Los
procesos deben ser concisos, agregar valor y deben ser usables. Se privilegiará la re-
utilización de cualquier práctica, documento, o artefacto existente en la organización.

2.11 Supuestos

Para el desarrollo de este plan es necesario contar con los recursos, tanto humanos,
técnicos y financieros, que permitan llevar a un buen término el proyecto SPI, bajo este
paradigma se asumen una serie de supuestos críticos para el éxito, estos son:

a) La creación de una Subgerencia de Calidad, que se hará cargo de los
procesos, la mejora continua y liderará esta iniciativa a través del tiempo.
b) CMMi será utilizado como base para todas las definiciones de proceso,
políticas y prácticas definidas bajo el proyecto SPI.
c) Cada integrante del proyecto deberá destinar 1 hora diaria a las actividades
de SPI. El Subgerente de calidad o el jefe de proyecto que este designe,
tendrá la facultad para programar y disponer de dicho tiempo.
d) Se debe definir un modelo de incentivos y reconocimientos al personal que
participe activamente en el proyecto.

2.12 Auspicio

Se cuenta con el auspicio del Gerente de TI y del Gerente General de la empresa de
servicios compartidos, de quienes se tiene el compromiso de alinear y comunicar al
holding de empresas respecto a la importancia y alcances del proyecto. Además, será
el canal de comunicación hacia niveles más altos de la organización.

Se cuenta con el auspicio de los subgerentes del área de tecnologías de información,
de quienes se tiene el compromiso de facilitar los recursos humanos.








122

2.13 Riesgos

En la tabla 26, se presenta una matriz de riesgos para el proyecto SPI:



Tabla 26: Riesgos del proyecto de mejora del proceso de software

2.14 Barreras

Una de las principales barreras a enfrentar por este proyecto, es el grado conservador
del holding respecto a la adopción de nuevas tecnologías y a que no se ha tomado
conciencia de que el servicio de informática es un real apoyo para el negocio como
generador de beneficios. Históricamente, las empresas han tenido su focalización en el
negocio desechando actividades que no generan valor, el servicio de informática se
considera como un centro de gastos más que un centro generador de beneficios por lo
que cualquier iniciativa proveniente del área tiene un alto grado de cuestionamiento. Por
otro lado, la capacitación interna en temas de tecnologías de información es bastante
baja por lo que puede ser una barrera al momento de integrarlo con los clientes finales.

Desde el punto de vista financiero, el proyecto debe ser evaluado utilizando los
métodos tradicionales, sin embargo al no existir experiencia previa se dificulta la
medición de beneficios cuantitativos del proyecto y por lo tanto su justificación en el
directorio de la empresa. Se debe partir, por una evaluación cualitativa hasta obtener
algún resultado concreto, por ello no se descarta un enfoque incremental del proyecto.

Las barreras pueden ser superadas mediante el apoyo claro para el proyecto SPI de la
alta dirección del holding y la capacitación continua en el modelo.


123

2.15 Organización para la Mejora del Proceso

2.15.1 Alcance Organizacional

El proyecto SPI tiene alcance sobre el holding completo, afectando a los servicios
informáticos que se prestan en cada una de las filiales, el área involucrada directamente
en esta iniciativa es la Gerencia de Tecnologías de Información y Comunicaciones.

Desde el punto de vista de las filiales, los procesos que les signifiquen participación del
proceso de software están dentro del alcance de este proyecto, el plan comunicacional
deberá incorporar a los clientes finales de cada filial, con el objeto de transmitirles las
prácticas y procedimientos sujetos a mejora continua, esto aportará también la
institucionalización del proceso.

El sponsor de este proyecto es el Gerente General de la empresa de servicios
compartidos, cuyas responsabilidades son:

a) Establecer y promover en el holding el proyecto SPI.
b) Entregar la visión corporativa desde el punto de vista del negocio para el
proyecto SPI.
c) Proponer issues de mejora al comité ejecutivo.
d) Alinear a los Gerentes Generales de las filiales con este proyecto.

2.15.2 Comité Ejecutivo

El comité ejecutivo es el encargado de guiar y gobernar el proyecto SPI. Sus
responsabilidades son:

a) Determinar el tipo de planificación estratégica a utilizar.
b) Definir y crear el plan estratégico de acción.
c) Revisar e integrar la visión, misión y plan de negocio al proceso de mejora de
software.
d) Comunicar a los niveles altos de la organización el desarrollo de los objetivos
y logros del proceso.
e) Supervisar como el proceso se está llevando a cabo.

El comité estará integrado por:

a) Gerente General de Servicios Compartidos.
b) Gerente de Tecnologías de Información y Comunicaciones.
c) Jefe de Proyecto SPI.




124

2.15.3 Jefe del Proyecto SPI

El jefe del proyecto, tendrá la responsabilidad de coordinar y liderar el proceso de
mejora de software, sus responsabilidades son:

a) Documentar el plan de acción estratégico.
b) Planificar las actividades, identificar recursos y esfuerzos.
c) Realizar el seguimiento del progreso del proyecto respecto a lo planificado.
d) Revisar los planes de acción de los grupos de trabajo y el equipo del
proyecto.
e) Recopilar semanalmente el estado de avance de los grupos de trabajo y le
equipo del proyecto.
f) Informar mensualmente el estado de avance al comité ejecutivo.
g) Sugerir acciones correctivas al comité ejecutivo cuando se produzcan
desviaciones respecto a la planificación.
h) Adquirir y coordinar los recursos para capacitación y consultoría.

2.15.4 SEPG (Software Engineering Process Group)

El SEPG tendrá las siguientes responsabilidades:

a) Determinar y definir la organización (procesos y métodos).
b) Establecer la forma de evaluar el proceso.
c) Presentar los resultados del proceso a los diferentes niveles de la
organización.
d) Establecer planes tácticos de acción.
e) Supervisar los proyectos de mejoramiento.
f) Evaluar y verificar los avances.

El SEPG estará compuesto por:

a) Jefe del Proyecto SPI.
b) Project Managers.

2.15.5 Grupos de Trabajo Técnicos (TWG)

Los miembros de los grupos de trabajo técnicos, tendrán la responsabilidad de producir,
revisar y asistir en el piloteo de nuevos procesos de software y de herramientas de
mejora. Cada grupo, tendrá un líder que tendrá la responsabilidad de aceptar cada hito
del plan de proyecto SPI e implementar las recomendaciones de cada ciclo de mejora.

En particular, el TWG:

a) Desarrollará y documentará nuevos procesos.
b) Evaluará los actuales procesos proponiendo mejoras.
c) Documentará y recopilara los artefactos actuales de procesos de la
organización.
125

d) Conducirá los pilotos.
e) Propondrán mejoras y modificaciones a los procesos.

Se definirán 6 TWG, cuyas áreas de proceso serán asignadas de común acuerdo con el
líder del proyecto SPI. Los TWG están compuestos por:

TWG 1:

a) Jefe del Proyecto SPI (como facilitador).
b) Jefe de Proyectos de Automatización.
c) Ingeniero de Proyectos SAP.

TWG 2:

a) Jefe del Proyecto SPI (como facilitador).
b) Jefe de Proyectos de Inteligencia de Negocio.
c) Ingeniero de Mantención.

TWG 3:

a) Jefe del Proyecto SPI (como facilitador).
b) Jefe de Proyectos SAP.
c) Ingeniero de Proyectos Automatización.

TWG 4:

a) Jefe del Proyecto SPI (como facilitador).
b) Jefe de Proyectos de Integración.
c) Ingeniero de Proyectos Inteligencia de Negocio.

TWG 5:

a) Jefe del Proyecto SPI (como facilitador).
b) Jefe de Proyectos Software General.
c) Ingeniero de Proyectos Integración.

TWG 6:

a) Jefe del Proyecto SPI (como facilitador).
b) Jefe de Proyectos de Mantención.
c) Ingeniero de Proyectos Software General.

2.15.6 Consultores Externos

Como parte del proyecto SPI, se utilizarán consultores externos para la evaluación
formal en los niveles de madurez CMMi. Además dado que no existe experiencia en el
holding en este tipo de iniciativas, para el levantamiento y la puesta en marcha del
proyecto SPI se contratará la asesoría de una empresa especializada.
126


2.16 Criterios de Éxito

El éxito de este proyecto será alcanzado de la siguiente manera:

Desde el punto de vista estratégico:

a) Obtener satisfactoriamente la evaluación CMMi nivel 2 en un periodo no
mayor a 2 años.
b) Obtener satisfactoriamente la evaluación CMMi en niveles superiores cada 2
años a partir de la fecha de obtención del nivel 2.
c) Institucionalización de las áreas de procesos relacionadas con el desarrollo
de software.
d) A mediano plazo, el establecimiento de evaluaciones informales cada año y
formales cada año por medio.

2.16.1 Medición de Metas de Corto Plazo

La estandarización de las prácticas y procesos de software, será medida mediante la
adopción de los procedimientos por parte de los involucrados, vale decir, que se medirá
el porcentaje de cantidad de procesos actualmente en uso respecto a la cantidad de
procesos totales, un valor del 100% se considerara exitoso, cualquier otro valor será
considerado como no exitoso. La medición de realizará anualmente mediante
evaluaciones informales.

La disminución del costo empresa de los proyectos y mantenciones de software, será
medida como el porcentaje del costo del esfuerzo en un proyecto o mantención
respecto al costo del esfuerzo de un proyecto o mantención de tamaño similar que haya
sido realizado en el pasado. Para determinar la similaridad del proyecto o mantención
se utilizaran puntos de función. Si para un proyecto o mantención los puntos de función
son iguales, entonces se consideraran equivalentes. El porcentaje de disminución de
proyectos y mantenciones similares debe ser de al menos un 10%.

2.16.2 Medición de Metas de Largo Plazo

Para medir el desarrollo e institucionalización de la cultura de ingeniería de software
basada en la mejora continua de los procesos, se tomarán controles a los integrantes
del área informática. Se considerará logrado el objetivo cuando se obtenga en promedio
un 100% de respuestas correctas en los controles.

2.16.3 Medición de Metas Estratégicas Derivadas del Negocio

La medición del alineamiento con la política de calidad del holding respecto a los
procesos productivos, será medida mediante la obtención de evaluaciones
satisfactorias en los niveles de madurez de CMMi.
127


Para medir el mantenimiento del liderazgo en costos y la producción de productos de
alta calidad conforme a los estándares internacionales de la industria, se establecerán
dos medidas, por una parte se exigirá al proyecto SPI el mismo ROI que es exigido a la
empresa, por el directorio y en segundo lugar los defectos de los productos de software
deberán ser eliminados por sobre el 99%.

2.17 Planificación

2.17.1 Costos Estimados

Para el proyecto SPI se estima un costo de US$ 393.000, cuyo detalle se encuentra en
la tabla 27.



Tabla 27: Costos del proyecto de mejora del proceso de software


128

2.17.2 Roadmap

La planeación estimada de actividades, se puede visualizar en la tabla 28.



Tabla 28: Roadmap del proyecto de mejora del proceso de software


129

Capítulo 7 - Conclusiones


Este proyecto logró el cambio de la estructura organizacional, de acuerdo a los
objetivos planteados. Los servicios son entregados a las empresas y de acuerdo a los
niveles de servicio definidos. Los procesos fueron abordados con un carácter general,
donde la idea era establecer un marco de trabajo para la organización, desde la
planeación estratégica hasta el manejo de la infraestructura informática.

Los procesos TIC fueron definidos bajo el marco de referencia de CMMi e ITIL, lo que
permite tener una base de procesos estándar, contribuyendo a la simplificación de la
operación y control del negocio y con la posibilidad de adoptarlos completamente. En
contraste con la situación inicial, en donde prácticamente no existían procesos formales
ni estandarizados. Sin embargo, el incremento de la calidad de los productos y servicios
entregados no está asegurado ya que los procesos definidos ordenan la organización,
pero no establecen mecanismos que promuevan la mejora continua. Por ello, el plan
estratégico de mejora del proceso de software presentado en el capítulo 6, es un primer
paso en dicha dirección.

El esquema de servicios compartidos permite que las soluciones tecnológicas sean
transversales al holding, generando sinergia, economías de escala, estandarización y
por lo tanto, la posibilidad de disminuir los costos de los proyectos y servicios externos,
contribuyendo a identificar las fuentes para minimizar los gastos de operación de las
actividades de apoyo al negocio. En la situación inicial estos beneficios no se
presentaban ya que no era posible un enfoque global que permitiera tomar decisiones
pensando en el conjunto y en los procesos de negocio de las distintas empresas del
holding, los que son prácticamente equivalentes.

En términos cuantitativos, bajo la situación inicial, el gasto promedio mensual en
tecnologías de información para una planta industrial con 500 usuarios era de US$
70.200, con el servicio compartido TIC bajó aproximadamente a US$ 62.000 promedio
mensual, lo que representa una disminución promedio de un 11,7%. Paradójicamente,
los proyectos de software son aproximadamente un 15% más caros respecto a la
situación inicial, esto producto de la transparentacíon de los costos del personal propio,
pero como son considerados inversiones, en la evaluación económica se exige una
tasa de descuento superior, lo que compensa la situación.
17


Las definiciones entregadas en esta tesis se basan en decidir la mejor estrategia de
provisión de servicios, respecto a la localización geográfica de las instalaciones, el tipo
de industria y al paradigma de servicios compartidos. Es interesante destacar que los
marcos de referencia utilizados, prácticamente se independizan de estas variables y
establecen criterios de diseño de acuerdo a las mejores prácticas, criticidad y
distribución de los procesos propios del negocio.


17
Fuente: Reportes de facturación del servicio TIC y presupuestos internos del holding.
130

Aún queda trabajo por hacer en la definición de, los procedimientos y el detalle de los
procesos que, por su extensión, solo fueron elaborados en sus aspectos más
relevantes. Además, se han de normalizar los dos grandes problemas que aparecieron
producto de la implementación de este proyecto.

El primer problema fue la tendencia de la dirección de este proyecto, a minimizar y
simplificar el esfuerzo requerido para producir el cambio y en focalizarse en definir la
organización antes que los procesos. También, el suponer que todas las personas
colaborarían y adoptarían los nuevos modelos, produjo una serie de dificultades en la
implantación. Se presentaron problemas de coordinación, disputas de poder entre áreas
y en general, desorden respecto a lo que se deseaba alcanzar.

Si bien simplificar el problema puede ser una aproximación para abordarlo y entenderlo,
este criterio no debe ser usado para la ejecución de proyectos de este tipo, que por sus
características y complejidad requiere estudio, participación más amplía de las
personas y análisis en profundidad.

El segundo problema fue que la asignación de las personas a cargos claves, se realizo
sobre el concepto de carrera funcionaria, lo que de alguna manera produjo que
personas que a pesar de tener mucha experiencia, no eran competentes para el cargo
en el que fueron designados, lo que produjo que áreas completas no operen de acuerdo
al marco definido. Un error de este proyecto fue el no haber abordado este punto con el
apoyo de profesionales especialistas en selección de personal. La asignación de
personas a funciones debe realizarse con un conocimiento acabado de competencias y
perfiles.

El uso de modelos y estándares de la industria no garantiza el éxito de una
organización. Se pueden modelar, adoptar, e implementar procesos, pero sin la
contribución y aporte de las personas, este tipo de iniciativas puede fracasar. Por ello,
las llamadas habilidades blandas, juegan un factor relevante como medios para el
cambio, sobre todo, en la modificación de hábitos de trabajo. Una deficiencia en esta
componente dificulta este tipo de proyectos, produciendo resistencia a la adopción de
nuevas formas de trabajar. Por lo tanto, los líderes de este tipo de proyectos deben ser
buenos negociadores, poseer un manejo fluido de la comunicación y ser guías del
proceso de adopción, más que impositores de estructuras.

Finalmente, la adopción de estándares probados, facilita a las áreas de tecnologías de
información, la definición de sus propios procesos de negocios. Ambos modelos son el
esfuerzo de la industria, en respuesta a la manera en que los procesos han
evolucionado, a la dependencia creciente en las tecnologías para la sobrevivencia del
negocio y a la necesidad de las organizaciones de proveer a sus clientes, productos y
servicios en forma oportuna y con la calidad requerida, asegurando así, la
competitividad y por lo tanto, la sustentabilidad a través del tiempo.



131

Bibliografía

[1] ACHÁ, VERONICA. 2004. Apuntes del curso: “ISO 9000”. Diplomado en Gestión de
Calidad de Software. Departamento de Ciencias de la Computación. Universidad de
Chile.

[2] BASTARRICA, MARIA CECILIA. 2004. Apuntes del curso: “Introducción a la
Ingeniería de Software”. Postítulo en Ingeniería y Calidad de Software. Departamento
de Ciencias de la Computación. Universidad de Chile. pp 78-83.

[3] BOUMAN, JACQUES, et al. 2000. Specification of service level agreement, clarifying
concepts on the basis of practical research. University of Technology Eindhoven.
Netherlands. pp 1-3

[4] DOCUMENTO INTERNO. 2004. Catálogo de servicios para un holding de empresas
forestales. Documento Interno. Empresa Forestal. Chile. 120p.

[5] DOCUMENTO INTERNO. 2004. Estudio de viabilidad de un servicio compartido para
una empresa forestal. Documento Interno. Empresa Forestal. Chile. 30p.

[6] DOCUMENTO INTERNO. 2005. Estudio de rendimiento de un sistema de ejecución
de manufactura. Documento Interno. Empresa Forestal. Chile. 93p.

[7] CMMI PRODUCT TEAM. 2002. CMMi for Software Engineering Staged
Representation (CMU/SEI-2002-TR-02, ESC-TR-2002-029). Pittsburgh, PA: Software
Engineering Institute, Carnegie Mellon University. 639p.

[8] CURRY J. y FERGUSON J. 2000. Increasing the Success of the Global Information
Technology Strategic Planning Process. Proceedings of the 33
rd
Hawaii International
Conference on System Sciences. IEEE. USA. pp 4-5.

[9] GUERRERO, JOSÉ. 2004. Apuntes del curso: “Técnicas de Pruebas”. Diplomado en
Gestión de Calidad de Software. Departamento de Ciencias de la Computación.
Universidad de Chile.

[10] GUERRERO, LUIS. 2005. Apuntes del seminario: “Introducción al UML”. Postítulo
en Gestión Informática. Departamento de Ciencias de la Computación. Universidad de
Chile.

[11] HAX A y MAJLUF N. 1996. Gestión de Empresa con una Visión Estratégica.
Ediciones Dolmen. Chile. Capítulo 1.

[12] HUGHET, JOHN. 2001. IT Strategy in Forest Products. Accenture, 36p

[13] JORRAT, MICHAEL. 2000. Apuntes del curso: “Evaluación de Proyectos”.
Departamento de Ingeniería Industrial. Universidad de Chile.

132

[14] KETTINGER W et al. 1998. The process reengineering life cycle methodology: A
case study. En: GROVER, V y KETTINGER W. Business Process Change:
Reengineering, Concepts, Methods and Technologies. USA. IDEA Group. pp 211-244

[15] MAYER R. et al. 1998. A Framework and a suite of methods for business process
reengineering. En: GROVER, V y KETTINGER W. Business Process Change:
Reengineering, Concepts, Methods and Technologies. USA. IDEA Group. pp 245-290.

[16] MICROSOFT CORPORATION. 2005. Microsoft Framework Solutions for Agile
Software Development. Visual Studio Team System. Build 100.4. USA.

[17] MICROSOFT CORPORATION. 2005. Microsoft Framework Solutions for CMMi.
Visual Studio Team System. Versión 1.0. USA.

[18] MICROSOFT CORPORATION. 2004. MOF: Capacity Management. USA. Microsoft
Press. pp 1-9

[19] MICROSOFT CORPORATION. 2002. MOF: Incident Management. USA. Microsoft
Press. pp 11-12

[20] MICROSOFT CORPORATION. 2005. MOF: Network Administration. USA.
Microsoft Press. pp 6-7

[21] MICROSOFT CORPORATION. 2002. MOF: Problem Management. USA. Microsoft
Press. pp 9-11

[22] MICROSOFT CORPORATION. 2002. MOF: Service Desk. USA. Microsoft Press.
pp 7-10

[23] MICROSOFT CORPORATION. 2003. MOF: Service Level Management. USA.
Microsoft Press. pp 9-10

[24] MICROSOFT CORPORATION. 2002. MOF: System Administration. USA. Microsoft
Press. pp 9-20

[25] OCHOA, SERGIO. 2005. Apuntes del curso: “Gestión de Proyectos Informáticos”.
Postítulo en Gestión Informática. Departamento de Ciencias de la Computación.
Universidad de Chile. 247p

[26] OFFICE OF GOVERNMENT COMMERCE. 2003. ITIL Service & Support CD. UK.
The Stationery Office.

[27] PICONE, GERMÁN. 2003. Trends and Directions in the Forest and Paper Industry.
IBM Business Consulting Services, 34p

[28] SOMMERVILLE, IAN. 2000. Software Engineering. 6
th
Edition. USA. Pearson
Education. Capitulo 27, pp 5-6

133

[29] STRAUB, PABLO. 2004. Apuntes del curso: “Introducción a la gestión de calidad”.
Diplomado en Gestión de Calidad. Departamento de Ciencias de la Computación.
Universidad de Chile.

[30] PINTO, FERNANDO. 2004. Apuntes del curso: “Introducción a CMMi”. Diplomado
en Gestión de Calidad de Software. Departamento de Ciencias de la Computación.
Universidad de Chile.

[31] VARAS, SAMUEL. 2003. Apuntes del curso “Tecnologías de Información y
Rediseño de Procesos”. Departamento de Ingeniería Industrial. Universidad de Chile.
554p

[32] WWW.IDEF.COM. Descripción del modelo IDEF [en línea]. http://www.idef.com.
[Consulta: 22 de Marzo de 2006]

[33] WWW.ISO.ORG. Resumen del modelo ISO 9126. [en línea]. http://www.iso.org.
[Consulta: 23 de Noviembre de 2005]


134









ANEXOS


135









ANEXO I: Comparación entre las plataformas .NET y J2EE
136

ANEXO I: Una comparación entre .NET y J2EE

No es sencillo realizar una comparación de ambas plataformas, debido a la cantidad y
complejidad de los elementos que las componen (ver figuras 1 y 2). Por lo tanto, la idea
es entregar algunos criterios que permitan al lector tener una visión rápida de las
diferencias, similitudes, ventajas y desventajas, desde el punto de vista global.




Figura 1: Arquitectura .NET
18



18
Fuente: http://www.microsoft.com/spanish/msdn/arquitectura/das/guias/AppArchCh5.mspx

137



Figura 2: Arquitectura J2EE
19


De acuerdo a SUN, J2EE es un conjunto de especificaciones y prácticas que permiten
el desarrollo de soluciones empresariales multi-capa, basados en la tecnología Java.
Considera un único lenguaje de programación, Java, que se caracteriza por ser portable
robusto, estable, orientado a objetos, e independiente de la plataforma. Al igual que
C++, el que podría considerarse como su predecesor, esta orientado fuertemente a
mantener la consistencia de los tipos de datos, provee mecanismos para herencia
múltiple, pero no permite la programación de funciones fuera de las clases. La
ejecución de aplicaciones se realiza utilizando una máquina virtual, que interpreta el
código intermedio generado por el compilador.

.NET es una plataforma de desarrollo de servidores, clientes y servicios. Se basa en
estándares abiertos como CLI, SOAP y WSDL. Permite al programador trabajar sobre
múltiples lenguajes en un entorno único de desarrollo (Visual Studio). Al igual que
J2EE, utiliza código intermedio, con la diferencia que el compilador traduce los
lenguajes soportados a uno común, el que es ejecutado por un interprete. Esto permite
que un programa en un cierto lenguaje pueda utilizar código o componentes escritos en
otro lenguaje. Los lenguajes base de la plataforma con C# y Visual Basic.

C# es una especie de evolución entre Java y C++, por lo que existen coincidencias con
Java, es decir:

- Ambos lenguajes son compilados a código intermedio, independiente de la
plataforma y del sistema operativo para el caso de Java y dependiente del
sistema operativo para los lenguajes bajo .NET. Cabe señalar, que existen una
serie de iniciativas para portar .NET a ambientes UNIX, siendo el proyecto Mono,
de código abierto, uno de los mas utilizados.
- No permiten el uso de punteros, aunque con C# se pueden utilizar en el modo de
programación unsafe.
- El código es organizado en clases.
- Ambos permiten herencia múltiple mediante el uso de interfaces.


19
Fuente: http://edg.utah.gov/strategies/j2ee/j2ee.html
138

En el siguiente cuadro, se presenta un resumen con las principales diferencias y
coincidencias entre el lenguaje Java y los lenguajes base de .NET.




Tabla 1: Comparación entre lenguajes .NET y Java
20


Respecto a las plataformas, las ventajas de .NET sobre J2EE son:

1. .NET soporta múltiples lenguajes de programación, lo que permite flexibilidad al
programador y una evolución en los entornos de programación, facilitando la
integración y portabilidad de las aplicaciones.
2. El entorno de programación .NET está orientado a la creación de servicios web,
incluyendo nativamente formatos SOAP, WSDL y UDDI, Sin que el programador
tenga que generar por si mismo el código XML.
3. Microsoft con su suite Visual Studio, establece una serie de prácticas de
desarrollo de software que pueden ser aplicadas con métodos tradicionales y
ágiles, en cambio J2EE solo ofrece la plataforma, donde las prácticas son
abordadas mediante entornos de programación de terceros.

Por otro lado, J2EE presenta las siguientes ventajas respecto a .NET:

1. La tecnología Java es abierta y basada en estándares internacionales.
2. J2EE puede ser adquirido en varias compañías, en contraste con .NET, en el
que el proveedor es único.
3. Posee un nivel de madurez superior a .NET en relación a la arquitectura sobre
diferentes plataformas, el tiempo de permanencia en el mercado y en la
estabilidad.

Finalmente, la elección de una u otra plataforma dependerá del contexto empresarial y
de los costos de implementación. Como criterio general, si las aplicaciones de la
empresa son predominantemente Windows, construidas con el entorno Visual Studio,

20
Fuente: JIMÉNEZ, LUZ ELENA. 2003. Una comparación entre JAVA y .NET. En: Sistemas & Telemática.
Universidad ICESI. Colombia. pp 80-81
139

es mejor utilizar .NET ya que la evolución tecnológica no significa mayores costos
(salvo licencias, por supuesto) y resulta ser directa. Lo mismo ocurre con J2EE, si la
plataforma ya está establecida bajo Windows, tiene menos costo seguir con la mismo,
frente a una migración. Por otro lado, en entornos nuevos, si la plataforma per-se es
UNIX, J2EE resulta ser la elección natural. En cambio, para Windows, la diferencia la
hará el costo de implementación y mantención entre J2EE y .NET, el que debe ser
evaluado de acuerdo al caso particular.
140









ANEXO II: Ejemplos de Normas y Procedimientos
141

ANEXO II: Políticas Generales del Servicio TIC

OBJETIVOS

El servicio TIC es la responsable de normar todos los aspectos relacionados con los
sistemas, comunicaciones de red y tecnologías de información del holding y sus filiales,
con el objeto de prestar servicios, para que el personal disponga de las herramientas,
que apoyen efectivamente su gestión en el logro de los objetivos de las empresas,
operando eficientemente sus sistemas de información y de comunicación.

En particular con respecto a esta área se debe tener en cuenta los siguientes aspectos:

1. Todas las Aplicaciones, Software y Sistemas que se carguen en la plataforma
computacional, tanto preliminares como definitivas, deben estar debidamente
licenciadas y deben ser autorizadas.
2. Se deben realizar los respaldos necesarios, en relación a Sistemas, Bases de
Datos y Servidores, que permitan un adecuado nivel de seguridad y resguardo
de la información en caso de fallas o desastre. Los programas de respaldo se
deberán definir cada 6 meses, con el objeto de ajustarlo a las reales necesidades
de las empresas.
3. El acceso a aplicaciones, software y sistemas debe estar autorizado por el Jefe
de Seguridad y/o Gerente, Subgerente del área respectiva. En particular, se
deben tener las siguientes consideraciones:
a. Acceso a aplicaciones y sistemas: Autoriza Jefe de Seguridad y/o
Gerente, Subgerente, quien deberá entregar su aprobación por escrito.
b. Acceso a la red Internet, creación de cuentas de red y cuentas de correo:
Autoriza Jefe directo del usuario.
c. Software licenciado: Autoriza Ingeniero de Soporte teniendo en cuenta el
esquema de licenciamiento.
d. Software no licenciado: No se instala.
e. Software no autorizado: No se instala.
f. Software de desarrollo: No se instala en equipos de usuario solo en el de
personal del servicio TIC y contratistas que realizan desarrollo utilizando
equipos de la plataforma computacional del holding y sus filiales, previa
autorización del Gestor de Proyectos.
g. Software base de datos, es decir Oracle y SQL Server: Solo se instalan a
los clientes con previa autorización del Ingeniero de Soporte.

ALCANCE

Aplicable al personal del holding y sus filiales.

POLÍTICA SOBRE LA SEGURIDAD EN EL ACCESO A LA RED

1. Para el acceso de los usuarios a los Sistemas de Información se dispondrá de
dos niveles de seguridad, definidos por claves o Contraseña. El primero estará
dado por el acceso a la red computacional y el segundo por el acceso al sistema
propiamente tal.
142

2. Para acceder a la red computacional, cada usuario dispondrá de una Contraseña
personal e intransferible, asignada inicialmente por el administrador de red, la
que será cambiada la primera vez que utilice su cuenta de red. Además el
usuario podrá libre e independientemente cambiar su contraseña cuando lo
requiera. Las contraseñas de usuario tendrán una expiración no mayor a 3
meses, cumplido ese tiempo el sistema de autenticación de red pedirá cambiar el
Contraseña al usuario. Las Contraseña asociadas a la Administración de
Servidores serán cambiadas con una frecuencia no mayor de 3 meses. Las
Contraseña tendrán un largo igual o superior a 6 caracteres y no podrá repetirse
el mismo Contraseña por 3 periodos.
3. Para acceder a un sistema de información, los usuarios dispondrán de una
Contraseña, asignada por el Ingeniero de Soporte, el que es responsable de
definir el perfil del usuario. Se recomienda un cambio de Contraseña con una
frecuencia no mayor de 3 meses.
4. Toda vez que un trabajador abandone la empresa, el área de Recursos
Humanos informará con anticipación, con el objeto de eliminar su acceso a la red
computacional y demás privilegios en los sistemas.
5. El ingreso a las Salas de Computación de las Plantas, donde se encuentran los
servidores y otros elementos de hardware relevantes de la red, será restringido
sólo a personal autorizado.

POLÍTICA DE RESPALDO Y RECUPERACIÓN DE DESASTRE.

1. Con el objeto de reponer los servicios en el más breve plazo y disminuir el riesgo
de pérdida de información, frente a contingencias graves en las instalaciones
físicas, se dispondrá de los correspondientes respaldos de información y de
alternativas de acción para reponer las distintas líneas de equipos.
2. Se privilegiará mantener convenios de soporte técnico y mantención de los
equipos críticos con los proveedores o sus representantes oficiales.
3. Para asegurar una adecuada reposición de los sistemas de información y
recuperación de los datos, frente a fallas en los equipos centrales y, o acciones
involuntarias, se dispondrá de los respaldos necesarios de las aplicaciones y de
los datos. A fin de disminuir el riesgo frente a contingencias mayores, estos
respaldos se almacenarán en diferentes lugares de las instalaciones.
4. El servicio TIC, no se hace responsable por el respaldo de PC de usuarios, es el
usuario el responsable de su respaldo mediante las herramientas disponibles
actualmente.

POLÍTICA DE ACCESO RED COMPUTACIONAL

1. Para acceder a los servicios computacionales prestados por el servicio TIC, el
usuario debe poseer una Cuenta de Usuario y una Contraseña.
2. Cada Jefe de Departamento puede solicitar la creación de cuenta de red para el
personal a su cargo, esta solicitud será canalizada al Service Desk,
especificando el nombre y departamento al cual pertenece el usuario, área,
teléfono (anexo) e indicar si el usuario tendrá correo o no.
3. Todas las cuentas de red por defecto tendrán acceso a Internet. El acceso VPN
será a pedido. El solicitante deberá especificar las excepciones.
143

4. La Cuenta de usuario será personal e intransferible. La Contraseña inicial será
asignada al momento de la creación de la Cuenta y puede ser cambiada libre e
independientemente por el propio usuario.
5. La contraseña de red expira, excepto la contraseña empleada para crear la
cuenta.

POLÍTICA DE REQUERIMIENTO DE CORREO ELECTRÓNICO

1. El requerimiento de la cuenta de Correo Electrónico debe ser solicitado al
Service Desk, siguiendo los mismos pasos de la Política Acceso red
Computacional.
2. Se debe tener en cuenta los siguientes puntos:
a. Cada Cuenta de Correo debe estar asociada a una Cuenta de Red.
b. Las Cuentas de Correo de contratistas deben tener como descripción la
función desempeñada y la identificación de la empresa contratista.
c. Se debe configurar la estación cliente con un archivo PST local, la entrega
de los correos tiene que estar direccionada a las carpetas personales.
d. Las casillas de correo poseen una limitación de 10 Megabytes para el
volumen de información de envió y recepción.
e. Los correos almacenados en el servidor están sujetos a un tamaño
máximo de 100 Megabytes.


POLÍTICA DE INSTALACIÓN DE SOFTWARE EN ESTACIONES DE TRABAJO

1. El requerimiento de instalación de Software debe ser solicitado al Service Desk,
por el usuario. El proceso de instalación deberá seguir los siguientes pasos:
a. El Service Desk registrará el requerimiento y asignará la actividad al
Coordinador de Service Desk, con toda la información necesaria del
producto solicitado a instalar.
b. El Coordinador, enviará un correo al Ingeniero de Soporte para que
sancione la solicitud. Si el software no esta licenciado la solicitud se
rechaza inmediatamente.
c. Recibida la confirmación, el Coordinador asignará al Técnico de Terreno,
al Ingeniero de Soporte, o ambos si corresponde para informar y proceder
con la ejecución de la instalación.
d. En caso que la solicitud sea negativa, se informará al usuario

POLÍTICA ACCESO A INTERNET

1. El acceso a Internet está disponible a todo el personal del holding y sus filiales.
2. El usuario realizará un llamado al Service Desk solicitando el acceso a
INTERNET, se registrará el requerimiento y se procederá al igual que en el
procedimiento de instalación de Software.
3. La salida a Internet se realiza a través de un servidor PROXY.
4. El acceso de personas que no pertenezcan al holding y sus filiales, deben ser
autorizado por la línea ejecutiva respectiva.


144

POLÍTICA DE CONEXIÓN DE EQUIPAMIENTO A LA RED

1. El servicio TIC es el responsable de aprobar la incorporación de equipamiento
computacional a la red con el objeto de cautelar la confidencialidad,
disponibilidad e integridad del recurso de información de la empresa.
2. Esta política se basa en los siguientes principios:
a. Ingreso seguro a la red. Todo equipo que no pertenezca al holding y sus
filiales debe ser chequeado técnicamente por personal autorizado con el
objeto de asegurar que no produzcan problemas en el funcionamiento de
la red computacional.
b. Disponibilidad de Software. Los equipos deben disponer del software y
sus respectivas licencias que permitan asegurar un adecuado
funcionamiento y el cumplimiento de leyes de propiedad intelectual.
c. Configuración estándar de equipos. Los equipos deben tener la
configuración estándar de los equipos computacionales de la empresa.
d. Operación segura de equipos conectados de terceros.
3. La detección de una anomalía en algún equipo conectado a la red, que atente
contra la seguridad, debe ser aislado hasta que se supere los inconvenientes y
se logre un re-ingreso seguro.
4. Los equipos conectados a la red deben contener necesariamente antivirus. En el
caso de que no lo tuviesen, se proporcionará el software durante el tiempo que el
computador se encuentre en operación.



145

ANEXO II: Procedimiento de Paso a Producción

OBJETIVOS

Establecer las normas y procedimiento para los pasos a producción.

Disminuir el impacto de los pasos a producción sobre la plataforma informática en
operación.

Controlar y documentar la puesta en marcha de hardware, servicios, software y
servidores.

ALCANCE

Aplicable a todo el personal del holding y sus filiales.

RESPONSABILIDADES

Project Manager, Ingeniero de Proyectos, Ingeniero de Mantención: Realiza una
solicitud de paso a producción y apoya las actividades relacionadas de la solicitud.

Jefe de Operaciones, Jefe de Ingeniería: Aprueba, autoriza o rechaza cualquier tipo de
solicitud de paso a producción.

Ingeniero de Sistemas: Ejecuta el paso a producción según la documentación
entregada.

Administrador de base de datos: Ejecuta el paso a producción según la documentación
entregada.

Coordinación Service Desk: Asigna y coordina el requerimiento de paso a producción.

Mesa de Cambios: Instancia (reunión) donde son analizados los cambios en la
plataforma de servidores derivados de: pasos a producción, mejoras operacionales, o
cualquier cambio que signifique una modificación en la configuración de uno o más
servidores.

EQUIPOS Y MATERIALES

1. Plan de paso a producción: Conjunto de actividades tendientes a realizar el paso
a producción. El plan deberá poseer al menos la siguiente información:
a. Actividad a realizar.
b. Tiempo estimado de la actividad.
c. Responsable de la actividad.
2. Plan de reversa del paso a producción: Conjunto de actividades tendientes a
reversar un paso a producción. El plan deberá poseer al menos la siguiente
información:
a. Actividad a realizar.
b. Tiempo estimado de la actividad.
146

c. Responsable de la actividad.
3. Plan de contingencia: Conjunto de actividades que será aplicado en caso de
presentarse problemas con el servicio, software o el servidor que se encuentra o
que se está pasando a producción.
4. Plan de pruebas ejecutado: Conjunto de actividades realizadas sobre el software
que aseguran y demuestran su buen funcionamiento.
5. Procedimiento de instalación de productos de software: Documento orientado al
soporte, que muestra paso a paso como realizar la instalación de un producto de
software.
6. Documento de especificación de plataforma: Documento único donde se
especifica técnicamente los elementos de un paso a producción de servidor,
servicio, o software sobre un servidor. Se deberán completar las secciones que
apliquen a la actividad que se realizará.
7. Protocolo de entrega: Certificado de la conformidad del paso a producción.
8. Scripts de base de datos.
9. Artefactos de software.
10. Sitios o páginas web.
11. Servicios.
12. Equipos computacionales.

NORMAS GENERALES

1. El Gestor de Proyectos, Ingeniero de Proyectos, Ingeniero de Mantención son las
únicas personas autorizadas para solicitar un paso a producción. A falta de esta
persona por enfermedad, vacaciones u otro motivo, el Subgerente de área
deberá designar un representante que realizará la solicitud. La designación
deberá ser comunicada a Infraestructura y Servicio al Cliente. En último caso el
comité de subgerentes, deberá resolver cuales son las personas autorizadas.
2. Se deberá entregar obligatoriamente la siguiente documentación, según los
siguientes casos:
a. Base de Datos.
i. Plan de paso a producción.
ii. Plan de reversa del paso a producción.
iii. Plan de contingencia.
iv. Plan de pruebas ejecutado.
v. Protocolo de entrega.
b. Aplication Server.
i. Plan de paso a producción.
ii. Plan de reversa del paso a producción.
iii. Plan de contingencia.
iv. Plan de pruebas ejecutado.
v. Protocolo de entrega.
c. Sitios y páginas web.
i. Plan de paso a producción.
ii. Plan de reversa del paso a producción.
iii. Plan de contingencia.
iv. Plan de pruebas ejecutado.
v. Protocolo de entrega.
d. Servicios y software sobre servidores en operación.
147

i. Plan de paso a producción.
ii. Plan de reversa del paso a producción.
iii. Plan de contingencia.
iv. Documento de especificación de plataforma.
v. Protocolo de entrega.
e. Servidores.
i. Plan de paso a producción.
ii. Plan de reversa del paso a producción.
iii. Plan de contingencia.
iv. Documento de especificación de plataforma.
v. Protocolo de entrega.
f. Productos de software.
i. Plan de paso a producción.
ii. Plan de reversa del paso a producción.
iii. Plan de contingencia.
iv. Procedimiento de instalación para técnicos en terreno.
v. Protocolo de entrega.
g. Otros no especificados.
i. Plan de paso a producción.
ii. Plan de reversa del paso a producción.
iii. Plan de contingencia.
iv. Plan de pruebas ejecutado.
v. Documento de especificación de plataforma.
vi. Procedimiento de instalación.
vii. Protocolo de entrega.
3. Una solicitud de paso a producción podrá ser rechazada en los siguientes casos:
a. No presentación de uno o más documentos mencionados en el punto 2.
b. Incompletitud, no entendimiento, o inconsistencia de la documentación
entregada.
4. Las personas facultadas para rechazar un paso a producción son el Ingeniero de
Soporte, el Administrador de Base de Datos y el Ingeniero de Sistemas.
5. Todo paso a producción que afecte a la plataforma de redes de área local,
servidores y sus servicios en operación deberá ser autorizada por Infraestructura.
6. Horarios para pasos a producción:
a. Base de Datos: Lunes y Miércoles a partir de las 18:00 hrs.
b. Aplication Server: Lunes y Miércoles a partir de las 18:00 hrs.
c. Productos de software: Lunes a Jueves de 12:30 a 14:00 hrs y después
de las 18:00 hrs.
d. Sitios Intranet: Lunes a Jueves a partir de las 18:00 hrs.
e. Sitios y páginas Internet (Extranet) para Chile: Lunes a Jueves a partir de
las 18:00 hrs.
f. Sitios y páginas Internet (Extranet) para resto del mundo: Lunes a Jueves
a cualquier hora del día.
g. Servicios: Domingo a Jueves según mejor ventana de tiempo previamente
acordada con la empresa.
h. Servidores nuevos: Lunes a Jueves a cualquier hora del día.
i. Otros no especificados: Lunes a Jueves según mejor ventana de tiempo
previamente acordada con el cliente.
148

7. No se realizarán pasos a producción los días Viernes, Sábados y Festivos salvo
expresa autorización con la debida justificación.
8. Se define como hora de cierre para los pasos a producción ingresados el mismo
día lo siguiente:
a. Base de Datos: Lunes y Miércoles hasta las 16:30 hrs.
b. Aplication Server: Lunes y Miércoles hasta las 16:30 hrs.
c. Productos de software: Lunes a Jueves hasta las 11:30 hrs. y hasta las
17:00 hrs.
d. Sitios Intranet: Lunes a Jueves hasta las 17:00 hrs.
e. Sitios y páginas Internet (Extranet) para Chile: Lunes a Jueves a hasta las
17:00 hrs.
f. Sitios y páginas Internet (Extranet) para resto del mundo: Una hora antes
de realizar el paso a producción.
g. Servicios: Según planificación.
h. Servidores nuevos: Según planificación.
i. Otros no especificados: Según planificación.
9. En caso de presentarse una contingencia que signifique realizar un paso a
producción fuera de los horarios mencionados en el punto 6 y que comprometa
la continuidad operacional de la empresa, se deberá solicitar autorización para la
realización de la actividad. La contingencia deberá estar debidamente justificada
y podrá ser rechazada si:
a. No se presenta la justificación
b. La justificación es inconsistente o incompleta, o no explica claramente la
contingencia del negocio.
c. No se cumplen los requisitos mínimos de documentación para un paso a
producción.
10. Debido a la dinámica y exigencias del negocio de las empresas, se podrán
realizar pasos a producción extraordinarios durante horarios distintos a los
definidos en este procedimiento. Para ello se solicitará al usuario final o área
cliente una justificación donde se especifiquen claramente los motivos por los
cuales se requiere el paso. Además se deberá solicitar autorización por e-mail,
indicando fecha y hora de la actividad y la justificación del usuario o área cliente.
El paso a producción extraordinario podrá ser rechazado si:
a. No se presenta la justificación del usuario.
b. La justificación es inconsistente o incompleta, o no explica claramente la
necesidad del negocio a satisfacer.
c. Se presentan situaciones de carga en la o las plataformas que se verían
afectadas.
d. No se cumplen los requisitos mínimos de documentación para un paso a
producción.
11. Durante un paso a producción se deberá contar con la presencia del
desarrollador ya sea en el lugar donde se realiza la actividad o por teléfono. Su
labor durante el paso a producción será la de apoyar la actividad según sea
requerido.
12. Todo producto de software y/o servicio y/o servidor y en general cualquier pieza
de software y/o hardware que no haya sido entregada y protocolizada según el
procedimiento mencionado en el documento, facultará a Infraestructura y Soporte
para derivar directamente cualquier requerimiento o contingencia al desarrollador
responsable por dichas piezas.
149


PROCEDIMIENTO

1. La solicitud de paso a producción se registrará a través de la aplicación de
service desk, adjuntando la documentación mencionada y los artefactos a pasar
a producción.
2. El Coordinador asignará el requerimiento según lo siguiente:
a. Base de Datos: Administrador de base de datos.
b. Aplication Server: Administrador de base de datos o Ingeniero de
Sistemas.
c. Productos de software: Coordinación de técnicos de terreno.
d. Sitios Intranet: Ingeniero de Sistemas.
e. Sitios y páginas Internet (Extranet) para Chile: Ingeniero de Sistemas.
f. Sitios y páginas Internet (Extranet) para resto del mundo: Ingeniero de
Sistemas.
g. Servicios: Ingeniero de Sistemas.
h. Servidores nuevos: Ingeniero de Sistemas.
i. Otros no especificados: Ingeniero de Sistemas.
3. Los administradores, recibirán y revisarán la información entregada por el
desarrollador y podrán rechazar la solicitud. De no haber objeciones o rechazo,
se procederá como sigue:
a. Base de Datos: El DBA procederá a programar la fecha y hora del paso a
producción y notificará al desarrollador de la actividad.
b. Aplication Server: Administrador de base de datos o Ingeniero de
Sistemas, según sea el caso procederá a programar la fecha y hora del
paso a producción y notificará al desarrollador de la actividad.
c. Productos de software: La coordinación solicitará a un técnico en terreno
probar el procedimiento de instalación del software, en caso de que se
presentasen dudas o inconvenientes, el técnico reportará a la
coordinación el problema y se rechazará la solicitud, también informará al
desarrollador las causas del rechazo. Para está actividad el técnico en
terreno contará con un tiempo de 30 minutos a contar de la asignación del
requerimiento. Si no se presentan inconvenientes y una vez probado el
procedimiento de instalación, el Ingeniero de Sistemas procederá a copiar
el software al repositorio de programas de instalación de cada empresa y
se agendará la instalación definitiva para los usuarios.
d. Sitios Intranet: El Ingeniero de Sistemas procederá a programar la fecha y
hora del paso a producción y notificará al desarrollador de la actividad.
e. Sitios y páginas Internet (Extranet) para Chile: El Ingeniero de Sistemas
procederá a programar la fecha y hora del paso a producción y notificará
al desarrollador de la actividad.
f. Sitios y páginas Internet (Extranet) para resto del mundo: El Ingeniero de
Sistemas procederá a programar la fecha y hora del paso a producción y
notificará al desarrollador de la actividad.
g. Servicios: El Ingeniero de Sistemas solicitará autorización al Jefe de
Operaciones, quién podrá autorizar o rechazar la solicitud y convocar a la
“mesa de cambios” según sea el caso. De no haber objeciones se
procederá según los horarios mencionados anteriormente. Si una solicitud
150

es rechazada será informada al desarrollador junto con las
recomendaciones a seguir.
h. Servidores nuevos: El Ingeniero de Sistemas solicitará autorización al Jefe
de Operaciones quién podrá autorizar o rechazar la solicitud y convocar a
la “mesa de cambios” según sea el caso. De no haber objeciones se
procederá según los horarios mencionados anteriormente. Si una solicitud
es rechazada será informada al desarrollador, junto con las
recomendaciones a seguir.
i. Otros no especificados: El Ingeniero de Sistemas solicitará autorización al
Jefe de Operaciones, quién podrá autorizar o rechazar la solicitud y
convocar a la “mesa de cambios” según sea el caso. De no haber
objeciones se procederá según los horarios mencionados anteriormente.
Si una solicitud es rechazada será informada al desarrollador junto con las
recomendaciones a seguir.
4. Finalmente, una vez que se ha realizado el paso a producción, el desarrollador
deberá entregar el protocolo de entrega a Soporte e Infraestructura.


151

ANEXO II: Procedimiento de monitoreo de un servidor

OBJETIVOS

Establecer el procedimiento de monitoreo y eliminación de procesos inactivos en el
servidor.

Nivelar la carga de procesos relacionados con iAS del servidor.

ALCANCE

Aplicable a todo el personal que realiza administración de servicios y servidores.

RESPONSABILIDADES

Ingeniero de Sistemas Ejecuta este procedimiento.
Administrador de Base de Datos: Apoya las actividades de este procedimiento.

EQUIPOS Y MATERIALES

Se requiere conexión vía telnet al servidor.

NORMAS GENERALES

1. La revisión y eliminación de procesos debe realizarse 1 vez a la semana a
cualquier hora del día.

PROCEDIMIENTO

1. Conectarse al servidor mediante telnet, utilizar la cuenta oracle.
2. Verificar la carga del servidor mediante el comando: sudo topas, este comando
solicitara el password de la cuenta la primera vez que sea ejecutado.
3. El comando topas nos muestra el estado general de carga del servidor y los
procesos más consumidores. Para el caso del servidor los parámetros básicos
normales de operación son los siguientes:
a. User <= 10.
b. Runqueue <= 1.
c. Waitqueue <= 2% .
d. Utilización de CPU por proceso < 1% (lista de procesos).

152


4. En caso de presentarse anormalidades se debe proceder como sigue:
a. Caso 1: Dos o más procesos poseen un uso de CPU mayor al 20% y son
antiguos
i. Verificar que el proceso sea f60webm o f60runm.
ii. Verificar antigüedad del proceso con el comando ps –fea | grep
PID, donde PID es el identificador de procesos.
iii. Si el proceso tiene una antigüedad superior a un día, entonces se
debe hacer un kill -9 PID, donde PID es el identificador de
procesos.
b. Caso 2: Dos o más procesos poseen un uso de CPU mayor al 20% y no
son antiguos, vale decir se encuentra dentro del mismo día.
i. Verificar que el proceso sea f60webm o f60runm.
ii. Verificar antigüedad del proceso con el comando ps –fea | grep
PID, donde PID es el identificador de procesos.
iii. Identificar junto con el DBA la operación de base de datos o form
involucrado.
iv. Una vez identificado, informar al Coordinador de Sistemas para su
corrección.
5. Verificar la antigüedad de procesos mediante el comando ps –fea. En AIX el
comando produce la siguiente salida:

153


El PID corresponde al segundo campo y la antigüedad al quinto campo.

6. Ejecutar el comando kill -9 PID, donde PID es el identificador de procesos, a
todos los procesos que:
a. Sean f60runm o f60webm.
b. Posean una antigüedad superior a un día.

Por ejemplo, el proceso 103490 está activo desde el 2 de Enero (Jan 02), si
estamos en el mes de Febrero este proceso es antiguo, luego se debe hacer un
kill -9 103490, el resultado es:



Hay que notar que el proceso 103490 tenía como proceso padre (segundo
campo) el PID 1, esto significa que el proceso no es un “subproceso” o un thread.

154

Si se hace un kill a un proceso cuyo proceso padre no es el PID 1, entonces al
ejecutar nuevamente ps –fea nos encontraremos con que dicho proceso queda
en estado <defunct>, esto quiere decir que este proceso es un “subproceso” o un
thread. El estado <defunct> puede generar procesos de tipo zombie (hacen
nada) y pueden ser eliminados por el propio scheduler del sistema operativo.


RESUMEN En esta tesis se presenta el diseño general de los procesos de negocio y organización, de un área de tecnologías de información, que operará dentro de un holding de empresas especializadas en los negocios de la industria de la pulpa y el papel, bajo el modelo de servicios compartidos. El holding ha definido la creación de una nueva empresa de servicios, que congregará las funciones de contabilidad, compras, recursos humanos y tecnologías de información. El problema abordado en este trabajo corresponde a la definición de la manera en que se prestarán los servicios de TI a las empresas filiales. La hipótesis es mostrar que, mediante la estructuración e implantación de procesos basados en estándares, orientados a la provisión de servicios de tecnologías de información, se pueden lograr beneficios y oportunidades importantes, tales como: la consolidación, la optimización de procesos a través de la reingeniería, la estandarización de aplicaciones y la reducción de los costos de operación. La metodología de solución corresponde a una visión desde la re-ingeniería de procesos, utilizando para las definiciones, elementos de los modelos CMMi e ITIL y abordando tres grandes ciclos de las actividades de tecnologías de información: planeación estratégica, ingeniería de software, soporte y provisión de servicios. Para cada uno de estos ciclos, se definieron actividades de carácter operativo considerando la distribución geográfica. En el caso de la gestión, el esquema propuesto es de centralización. Además, se plantea una estrategia para la mejora de los procesos de software, cuyo objetivo final es la adopción y evaluación en CMMi. Producto de la definición e implantación de los servicios, procesos y organización propuestos en esta tesis, se ha logrado una disminución de un 11.7% en los costos de TI para una planta industrial promedio de 500 usuarios, paradójicamente los costos de proyectos de software han aumentado un 15%, debido a la transparentación de costos que antes eran ocultos. Otro resultado importante, es que con la adopción de un esquema de servicio compartido con un marco de procesos basado en estándares, se cuenta con una base que permite la implementación de soluciones tecnológicas transversales al holding, generando sinergia, economías de escala y simplificación en la operación.

A mi familia

por permitirme discutir con ellos alguna de las ideas presentadas en esta tesis. comprensión y por permitirme dedicar tiempo y recursos para desarrollar mis estudios y este trabajo. en desmedro de ellos. A mis colegas de trabajo.AGRADECIMIENTOS A mi familia. por su constante apoyo. . cariño.

......... 64 2...........2......................................... 2 3........................................ 61 2.....2 Gestión de problemas ....................... HIPÓTESIS ...........3...1 ISO 9000:2000 ................. 39 2...............................................2 Actividades Propias del Proyecto ..1 Gestión de incidencias ......4 Procesos de entrega del servicio.............................. 64 2......................................................................... 68 2.....1........... 9 1..................................................... 10 1...................................................5 Proceso de Mantención de Software .............................................. LA INDUSTRIA DE LA PULPA Y EL PAPEL ..2 Administración de proyectos con metodologías tradicionales ..............................................1.....3..................................................................................2 ISO 9126 para Ingeniería de Software .............................................................................................................................................2 Estrategia del Proyecto ................................................... 66 2.......................................................................... 21 2............................................... Modelamiento y Diseño de Procesos ................................... 58 2........................................ 54 2...2 Proceso de Planificación Estratégica..................4........ SITUACIÓN INICIAL ............... 7 CAPÍTULO 2 – REVISIÓN TEÓRICA Y METODOLOGÍA ..............................................2 Proceso de Desarrollo y Administración de Requerimientos ...... 9 1............ 13 1.............................3........................1 Servicios TIC ...............2 Modelo de costos de los servicios ......................3 Niveles de Servicio ................................ 80 i ........... 14 1................... DEFINICIÓN DEL PROBLEMA .....2............................................. 42 2.... 51 2...............1 Administración de proyectos con metodologías ágiles ................................................................ 46 2.......................................................1 Proceso para la planeación estratégica .......................3. 1 1.................................................2 IDEF (Integrated DEFinition Methods) ... METODOLOGÍA .............4..........................................................................................................................1...........................................................................2.. 76 2.............................................................................................................................................. DISEÑO DE PROCESOS ............2........ 24 CAPÍTULO 3 – DISEÑO DE SERVICIOS Y PROCESOS......................................................................................................INTRODUCCIÓN ................................. 71 2...........2...................3................................. 47 2........3 Modelos y Prácticas para Procesos de Software ............1 SADT (Structured Analysis and Design Technique) ........ 21 2.................... 26 1......................... 23 2..........................................2 Proceso para la elaboración del presupuesto ...............2.... 12 1...................................................2.................................................5 Control y distribución de software y hardware ....................................................................2 Normas ISO ............................................................................................... 77 2...........................................1................................................4 UML (Unified Modeling Language) ............. 26 1....3..................... 31 2.................................................................4 ITIL (IT Infraestructure Library)...............1 Administración de Proyectos ......TABLA DE CONTENIDOS CAPÍTULO 1 ........................................5 Criterios de Selección de Herramientas....... 9 1..1.......................................................................................................................... 39 2..................................................................................................................... 19 1...........................3 Proceso de Desarrollo de Software ..1 Análisis...........................................1......4..2 Gestión del nivel de servicio........... 46 2........................................3............................................................1................... 1 2.............................................................3.......................................................................................................... 74 2.1 Actividades de Gestión del Proyecto ...................................................................................................................1 Enfoque de Trabajo .......................... 22 2...... 76 2.......................... 20 2........ 19 1......................3 Procesos de soporte al servicio..................... 28 1.... 17 1......................................................3................................................... 26 1.....................2................................................ 16 1........ 18 1................................................................................................................... 22 2...........3 Gestión de finanzas TI ............................................................1 CMMi (Capability Maturity Model Integration) ................................................................................................................................................................................................ REVISIÓN TEÓRICA ....................................................... 18 1....................................................................................................2...........................................................2.......................................3 Ciclos de Trabajo ..1.................................... 6 4....................1 Gestión de disponibilidad y continuidad........................................................................ 48 2...................1 Proceso de planeación estratégica TIC para las filiales ......3 Selección de Herramientas Metodológicas ........................................................................... 39 2......................2 Procesos de software..................................4 Proceso de Pruebas de Software ....... 10 1...............................3 Gestión de inventario y configuración . DISEÑO DE SERVICIOS ....................................................................................................................4 Gestión del cambio ..........2..........................................

......... 109 2.................. 121 2................................................................................ .....................................................................................................................7 Metas Estratégicas Derivadas del Negocio............1 Subgerencia Relación Comercial Cliente......3 Monitoreo y Control de Servicios............1 Misión ......................................4............. 113 1................................................... 108 2..1 Primer nivel organizacional . TRANSICIÓN Y CAMBIO ................................................................1 Actividades de Capacitación ..............4 Principios Guías.............. 123 2........4..................................... 120 2.........................................2 Subgerencia Servicio al Cliente...........................................................13 Riesgos .................................. 107 2...................................5 Metas de Corto Plazo.............3 Valores ................................................................................................................................................................................................ 120 2..............................................................15..............................................2 Gestión de capacidad de los recursos y servicios...... 120 2..................5........................................... 95 CAPÍTULO 4 – ORGANIZACIÓN ... 86 2.......1....................... 120 2...........11 Supuestos...... 100 1......5...................................................................................................................................................................................................2......................................................................... 90 2.......................................................................................................................................................................................................................................................... 108 2................................................2 Administración de la Seguridad ............................................1...........................2.... 123 2................................. 98 1............................................................................................... MARCO DEL PROCESO DE MEJORA DE SOFTWARE .....................4 SEPG (Software Engineering Process Group) ......................2 Actividades de definición de los procesos TI ....................................................................................................15............................. 119 2................................................................................................... 93 2......................................................................................... 110 2.. 102 1......................................... 113 1......................................................................................................................................................................................... 101 1........................................15.............................. PLAN ESTRATÉGICO DE MEJORA DEL PROCESO DE SOFTWARE .......................... 93 2............................................................................. 114 1........12 Auspicio ......................................... 116 CAPÍTULO 6 – ESTRATEGIA PARA LA MEJORA DEL SOFTWARE ..................2..... 81 2. 113 1....1 Alcance Organizacional .............................2 Visión ...... 118 1.....................................................................................2 Segundo........................1 Gestión de infraestructura ...................................................................................15.......................1.................... 123 2..........................................................................................................4 Subgerencia de Proyectos ..... TRANSICIÓN Y CAMBIO ............................................ 81 2.........................2 Etapa de transición y cambio .....5.....................................................................................................5 Subgerencia de Infraestructura ...................................................... 109 2............................................................................................4 Gestión de capacidad ....................................................................... PLAN DE IMPLEMENTACIÓN.....2....................................1 Etapa previa al cambio..................................5...................................................................5 Gestión de proveedores ...........4................1................. 97 1.. 118 2.. 119 2.......... 120 2....................................... 97 1........1 Administración de la Infraestructura ..........................................................................................................................4 Actividades de Operación .......2 Subgerencia de Relación Comercial.................................................... 119 2............ 114 1......................................................................................................................................... 94 2................................ 82 2.....................................................1 Gestión de capacidad del negocio .... 90 2......................2 Comité Ejecutivo ........................................................1 Gerencia de Servicios TIC ............................................... 124 2..3 Subgerencia de Servicio al Cliente .....................................................4................................................................................................. 124 ii ...... 104 1................... 115 1......2 Gestión de seguridad ........................... 121 2..................... 122 2.......................................................................... 114 1....................... 111 CAPÍTULO 5 – IMPLEMENTACIÓN........8 Objetivo ............3 Actividades de definición de la estructura organizacional ...............5... ESTRUCTURA ORGANIZACIONAL............................................1................2........................................................3 Etapa de entrega del servicio . DEFINICIÓN DE CARGOS ............5 Procesos de gestión de la infraestructura y seguridad ......... 122 2............15 Organización para la Mejora del Proceso .......1..................3 Subgerencia de Proyectos ......3 Jefe del Proyecto SPI....... 120 2..............5......................... 92 2.....14 Barreras.....................................6 Metas de Largo Plazo ..........................................................1.................................................. 119 2.................................10 Principios Guía del SPI ..........................................4 Subgerencia de Infraestructura ........................ 119 2..................................................9 Beneficios Esperados .................. tercer y cuarto nivel organizacional .......................................4........4..........

.................................. 4 TABLA 2: SITUACIÓN INICIAL DE LOS PROCESOS DE SOPORTE .......................................... 129 BIBLIOGRAFÍA ............ 89 TABLA 22: DESCRIPCIÓN DE LOS SERVICIOS DE INFRAESTRUCTURA .......... 43 TABLA 14: CRITERIOS PARA LA PRESUPUESTACIÓN .................................................................................................................................................... 37 TABLA 11: NIVELES DE SERVICIO PARA LA MANTENCIÓN DE SOFTWARE DE CORTO PLAZO .....2 Roadmap .............. 83 TABLA 17: INDICADORES DE CAPACIDAD DE SERVIDORES Y PC.................................2........................................................ 33 TABLA 8: IMPORTANCIA DE LOS SERVICIOS SEGÚN LA SEGMENTACIÓN DE USUARIOS .................................................... 125 2...................................... 128 CAPÍTULO 7 .............................................................. 134 ANEXO I: COMPARACIÓN ENTRE LAS PLATAFORMAS ............................................................................................. 126 2.......................................................................................................................... 127 2......................................... 128 iii ................................................................................. 126 2....... 33 TABLA 9: NIVELES DE SERVICIO PARA LOS SERVICIOS FIJOS ...1 Medición de Metas de Corto Plazo .......... 94 TABLA 25: PLAN GLOBAL DE DIFUSIÓN Y CAMBIO ...................... 44 TABLA 15: CRITERIOS PARA DETALLAR EL PRESUPUESTO ........ 122 TABLA 27: COSTOS DEL PROYECTO DE MEJORA DEL PROCESO DE SOFTWARE .......................................................CONCLUSIONES .........................................................................................................................16 Criterios de Éxito........................................... 34 TABLA 10: NIVELES DE SERVICIO PARA SERVICIOS VARIABLES ........... 37 TABLA 12: NIVELES DE SERVICIO PARA SERVICIOS DE VALOR AGREGADO .....................................3 Medición de Metas Estratégicas Derivadas del Negocio ........................................................................NET Y J2EE .....17...............................................................5 Grupos de Trabajo Técnicos (TWG)............16...... 85 TABLA 19: INDICADORES DE CAPACIDAD DE EQUIPOS DE COMUNICACIÓN ......................................... 127 TABLA 28: ROADMAP DEL PROYECTO DE MEJORA DEL PROCESO DE SOFTWARE .................................. 18 TABLA 4: EL CATÁLOGO DE SERVICIOS ......17.............................................................................................................................15........... 88 TABLA 21: OLA PARA SERVICIOS FIJOS ......................................................... 131 ANEXOS . 30 TABLA 7: ASIGNACIÓN DE VALORES A LA IMPORTANCIA DE UN SERVICIO .......................................................15................................................................................... 135 ANEXO II: EJEMPLOS DE NORMAS Y PROCEDIMIENTOS ............. 117 TABLA 26: RIESGOS DEL PROYECTO DE MEJORA DEL PROCESO DE SOFTWARE ............................. 126 2................................................ 44 TABLA 16: COMPONENTES TECNOLÓGICOS DE LOS SERVICIOS ........................................ 85 TABLA 20: DIFERENCIAS ENTRE SLA Y OLA ........................................................................................... 27 TABLA 5: CRITERIOS PARA LA APLICABILIDAD DE COSTOS A LOS SERVICIOS ...................1 Costos Estimados ................................................................................................................................................................................. 84 TABLA 18: INDICADORES DE CAPACIDAD PARA IMPRESORAS .............. 38 TABLA 13: EJEMPLO DE UN PRESUPUESTO ..........16............................................................................................17 Planificación ................................... 140 ÍNDICE DE TABLAS TABLA 1: SITUACIÓN INICIAL DE LOS PROCESOS DE SOFTWARE .....................2 Medición de Metas de Largo Plazo .................................................................... 126 2......................6 Consultores Externos ............................................................................................................................ 127 2............................................................................................................... 5 TABLA 3: LOS NIVELES DE MADUREZ Y LAS ÁREAS DE PROCESO DE CMMI ............................................. 92 TABLA 23: VARIABLES DE MONITOREO DE UN SERVIDOR .................................................................................16......................................................................................................................................................................................................................................................................................................................................................... 29 TABLA 6: CRITERIOS PARA APLICAR PRORRATEO A LOS COSTOS DE LOS SERVICIOS ......................... 94 TABLA 24: ACTIVIDADES DE OPERACIÓN HABITUAL DE LA INFRAESTRUCTURA ......................... 124 2............................................................................

.............................................................................................................................................................. 48 FIGURA 13: ADMINISTRACIÓN DE PROYECTOS CON METODOLOGÍAS TRADICIONALES .............. 91 FIGURA 34: ORGANIGRAMA GENERAL................................................ÍNDICE DE FIGURAS FIGURA 1: ESTRUCTURA DE EMPRESAS DEL HOLDING ....................................... 14 FIGURA 6: REPRESENTACIÓN GRÁFICA DEL MODELO DE LAS 5 FUERZAS DE PORTER ...................................................................................................................................................................................................................................................................................... 32 FIGURA 9: LÍNEA DE TIEMPO DE UN INCIDENTE .................. 107 ÍNDICE DE ECUACIONES ECUACIÓN 1: TIEMPO DE NO DISPONIBILIDAD DE LOS SERVICIOS FIJOS .................................................................................. 68 FIGURA 23: PROCESO DE GESTIÓN DE INVENTARIO Y CONFIGURACIÓN ........................... 73 FIGURA 26: DESCOMPOSICIÓN DEL PRODUCTO DE SOFTWARE PARA EL CONTROL DE VERSIONES ....................... 99 FIGURA 36: ORGANIGRAMA GENERAL........................................ 91 FIGURA 33: JERARQUIZACIÓN DE LAS ACTIVIDADES DE INFRAESTRUCTURA ............................................................. 61 FIGURA 20: PROCESO DE MANTENCIÓN DEL SOFTWARE............................... 105 FIGURA 40: ORGANIGRAMA ALTERNATIVO DE LA SUBGERENCIA DE PROYECTOS ...................................... 79 FIGURA 30: PROCESO DE GESTIÓN DE LAS FINANZAS ...................... 103 FIGURA 39: ORGANIGRAMA SUBGERENCIA DE PROYECTOS ............................................................................................................ 40 FIGURA 11: PROCESO DE ELABORACIÓN DEL PRESUPUESTO .................................................... 3 FIGURA 3: REPRESENTACIÓN GRÁFICA DE IDEF0 ..................... 16 FIGURA 8: SEGMENTACIÓN DE LOS USUARIOS ................................................................................................................................ 70 FIGURA 24: PROCESO DE PASO A PRODUCCIÓN .................... 15 FIGURA 7: LA CADENA DE VALOR ......................................... OPCIÓN 3 ............................................................................................................................................................................................................................................................................................................................. 75 FIGURA 27: PROCESO DE GESTIÓN DE LA DISPONIBILIDAD Y LA CONTINUIDAD ............ 50 ECUACIÓN 5: PORCENTAJE DE AVANCE DEL PROYECTO ............................................................................... 55 FIGURA 16: PROCESO DE DESARROLLO DE SOFTWARE CON METODOLOGÍAS TRADICIONALES ................................................... 77 FIGURA 28: CICLO DE GESTIÓN DEL NIVEL DE SERVICIO .. 101 FIGURA 38: ORGANIGRAMA SUBGERENCIA DE SERVICIO AL CLIENTE .......................... 11 FIGURA 4: REPRESENTACIÓN GRÁFICA DEL MODELO DE CICLOS DE TRABAJO ......................... 45 FIGURA 12: ADMINISTRACIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES .................................................................................................................................................................................... 53 FIGURA 15: PROCESO DE DESARROLLO DE SOFTWARE CON METODOLOGÍA ÁGIL .................................. 12 FIGURA 5: MODELO DE PLANEACIÓN ESTRATÉGICA ...................................... 105 FIGURA 41: ORGANIGRAMA SUBGERENCIA DE INFRAESTRUCTURA ................................ 98 FIGURA 35: ORGANIGRAMA GENERAL.................................... 56 FIGURA 17: PROCESO DE PRUEBAS CON METODOLOGÍA ÁGIL ........................................................................... OPCIÓN 2 . 49 FIGURA 14: PROCESO DE DESARROLLO Y ADMINISTRACIÓN DE REQUERIMIENTOS ....................... 63 FIGURA 21: PROCESO DE GESTIÓN DE INCIDENCIAS .................................................................................................................................................................................................................................................. 72 FIGURA 25: PROCESO DE GESTIÓN DEL CAMBIO PARA EQUIPOS DE ESCRITORIO ............................... 50 ECUACIÓN 4: PORCENTAJE DE PRODUCTOS ENTREGADOS FUERA DE PLAZO ..................... 2 FIGURA 2: ORGANIGRAMAS DE LAS ÁREAS DE SISTEMAS ....................................... 81 FIGURA 31: PROCESO DE GESTIÓN DE PROVEEDORES .................... 32 ECUACIÓN 3: PORCENTAJE DE PRODUCTOS ENTREGADOS DENTRO DE PLAZO ............................. 32 ECUACIÓN 2: PORCENTAJE DE DISPONIBILIDAD DEL SERVICIO FIJO ............................................... 100 FIGURA 37: ORGANIGRAMA SUBGERENCIA RELACIÓN COMERCIAL CLIENTE .............................................. 87 FIGURA 32: ACTIVIDADES GENERALES DE UN PROYECTO DE INFRAESTRUCTURA ..................................................... 59 FIGURA 18: PROCESO DE PRUEBAS CON METODOLOGÍAS TRADICIONALES ............................................................................................................................... 78 FIGURA 29: PROCESO DE GESTIÓN DEL NIVEL DE SERVICIO ............................................................ 34 FIGURA 10: PROCESO DE PLANEACIÓN ESTRATÉGICA DE TI .......... 50 iv ........................................ 60 FIGURA 19: DIAGRAMA DE DESCOMPOSICIÓN PARA EL TESTING ...................................................................................................... 66 FIGURA 22: PROCESO DE GESTIÓN DE PROBLEMAS .... OPCIÓN 1 ..............................

aparentemente. se cuenta con sistemas antiguos que incorporan prácticas y procesos que se encuentran obsoletos. Las preocupaciones del sector radican principalmente en [12. c) Necesidad de focalizarse en el negocio. Las grandes líneas de productos del sector son: maderas. tal como se puede observar en la figura 1. sin embargo la tendencia es la incorporación de tecnologías que faciliten la gestión de la información. h) Mantener una relación armoniosa con el medio ambiente. Geográficamente. en un mercado en que los precios son extremadamente volátiles. la automatización y la operación de las plantas productivas. las empresas se ven obligadas a invertir fuertemente para mantenerse en pie. papel para corrugar.27]: a) Necesidad de asegurar los suministros de insumos al menor costo posible.3% anual [27]. La industria de la pulpa y el papel La industria de la pulpa y el papel es un sector que se encuentra en plena madurez. d) Generar economías de escala. las Tecnologías de Información juegan. Brasil y México. 1 . Las empresas del sector se caracterizan por ser altamente dependientes de la logística. con plantas productoras en Argentina. los márgenes se han visto deteriorados producto de los excesos de capacidad existentes. Sin embargo. siendo la eficiencia en costos uno de los grandes objetivos de negocio. g) Necesidad de focalizarse en el cliente más que en el proceso productivo. papel de diario y cartulinas. celulosa. En general. En este contexto. Uruguay. b) Necesidad de focalizarse en la generación de valor para los clientes y accionistas.Introducción 1. papel para impresión y escritura.Capítulo 1 . Los crecimientos de capacidad de las grandes empresas se realizan mediante la adquisición de compañías más pequeñas. orientado a la producción de commodities. Desde el punto de vista de los productos existe una tendencia a focalizarse más que en diversificarse [27]. f) El aumento en la dependencia de las Tecnologías de Información (TI). pese a que el crecimiento promedio del mercado es entre un 2. Perú. e) Necesidad de integrarse con la cadena de suministros. El presente trabajo. existiendo una tendencia continua a la globalización [12].5% . un rol secundario. las empresas y sus plantas productivas están distribuidas a lo largo de Chile y en el extranjero. se desarrolla en un holding que está compuesto por seis filiales que a su vez congregan a empresas especializadas en los distintos negocios de la industria de la pulpa y el papel. papel tissue.

Varias subgerencias con dos áreas dependientes: soporte. Hay 458 aplicaciones distintas. que se encuentran distribuidos geográficamente en Chile y en el extranjero. identificándose tres tipos genéricos: 1. Cada área informática posee su propia organización. define y mantiene los sistemas corporativos y administra la red de datos corporativa. 2 . Situación Inicial Cada filial posee un área de informática propia e independiente. Estas aplicaciones son soportadas por 357 servidores.Figura 1: Estructura de empresas del holding 2. de los cuales 60% están relacionadas con el apoyo a la administración de los negocios y un 40% apoyan la operación de plantas productivas. A nivel de la matriz. mantención y desarrollo de software. 2. mantención de software y desarrollo de software. con tres áreas dependientes: soporte. Una subgerencia. licenciamiento de software y servicios centralizados. Además. existe una gerencia de informática que entrega a las filiales los lineamientos base en cuanto a políticas de seguridad.

Las áreas de desarrollo y mantención se encargan del ámbito del software. Siendo responsabilidad de la coordinación la realización de proyectos informáticos con terceros. No se presentan unidades que gestionen la relación con el cliente.3. Una subgerencia con dos áreas dependientes: soporte y coordinación. d) Desarrollar aplicaciones propias y con terceros. cuyo objetivo final es la obtención del presupuesto anual de TI. administrar la infraestructura informática y asegurar la continuidad de los servicios. Figura 2: Organigramas de las áreas de Sistemas El área de soporte es la encargada de entregar el soporte a usuarios. Las líneas punteadas indican que existe una relación de dependencia implícita. sistemas y aplicaciones. La representación de esta organización se visualiza en la figura 2. b) Mantener y operar la infraestructura informática. e) Mantener la seguridad informática. f) Entregar soporte a la gestión (captura de requerimientos y análisis de sistemas). a través de un proceso informal y medianamente definido. 3 . Las funciones realizadas por las unidades informáticas son equivalentes entre sí y son: a) Realizar la planificación estratégica de TI para la filial. c) Entregar soporte a los usuarios.

se presenta un resumen de la situación con los procesos que han sido identificados. Además. se depende exclusivamente del desarrollador. lo que provoca que se presenten diferencias respecto al enfoque de solución y a la manera como es construido el software. Las pruebas de software son prácticamente nulas. Para el caso de soporte. En la tabla 2. Respecto a la mantención de software. previa aprobación en caso que signifique un gasto. En la tabla 1. Tabla 1: Situación inicial de los procesos de software La administración y desarrollo de requisitos consiste solamente en la recepción directa desde el usuario y la aprobación por parte de un comité. Tampoco existe documentación técnica del software. Desde el punto de vista de los procesos. se presenta un resumen de la situación para procesos básicos de software. 4 . no existe una definición para la asignación de tareas y manejo de prioridades. no se manejan conceptos de calidad y la gestión de proyectos depende del enfoque y voluntad de cada jefe de proyecto.g) Entregar consultoría tecnológica. los procesos definidos no son estándares en la organización. existe un desarrollo propio e incipiente con grandes diferencias entre las divisiones del holding. presentándose distintos niveles de profundización y formalización en las filiales. el proceso consiste en la recepción formal de un requerimiento de cambio. En el caso de las metodologías de desarrollo.

b) Algunos procesos no se encuentran debidamente institucionalizados y. b) Los que imponen reglas y soluciones. no son llevadas a cabo producto de la falta de tiempo de las personas encargadas de definirlos y documentarlos y a la falta de auspicio por parte de la alta dirección. en general. g) Existe resistencia de las personas para adoptar procesos estructurados y normas. 5 . Pese a estas patologías. además del compromiso y dedicación a las labores que les han sido encomendadas. no son gestionados como tal. estas son: a) Las herramientas de software utilizadas para el soporte del proceso no son adecuadas para el tamaño del negocio. aquellos en los que el cliente define los aspectos técnicos de informática. c) Los procedimientos se enfocan en lo que hay que hacer más que en cómo hacerlo. una fortaleza que destaca es el conocimiento de los negocios que tiene el personal de informática. c) Los que son guiados por el cliente. sin embargo. existen patologías en cuanto a la implementación. Además. se distinguen: a) Los que se encuentran orientados al cliente. f) Existen iniciativas de formalización de procesos. d) Los procesos de administración de la infraestructura son descentralizados y siguen criterios que no son comunes dentro de las divisiones de negocio. existen diferencias en cuanto al enfoque con que cada unidad informática afronta a sus clientes y usuarios.Tabla 2: Situación inicial de los procesos de soporte En resumen. si bien hay procesos definidos. e) No existe claridad respecto a la responsabilidad y roles de las personas sobre los procesos. vale decir.

recursos humanos. hay un sentido altamente jerárquico respecto a las responsabilidades. que entregará los servicios a las empresas del holding. el holding se caracteriza por tener un carácter conservador desde el punto de vista adopción de nuevas tecnologías. siendo el objetivo general de este trabajo el diseñar los procesos y la estructura organizacional del área que prestará los servicios compartidos de informática a todas las filiales del holding. se encuentra abierto a los estándares que apoyen la mejora de procesos y aseguren la calidad de sus productos. En general. 3. Específicamente. los objetivos a satisfacer son: a) Diseñar la estructura organizacional de tecnologías de información en la empresa de servicios compartidos del holding matriz. Para este proyecto. La nueva empresa no deberá generar utilidades y se deberá regir por acuerdos de servicio y costos con las filiales. Sin embargo. Para resolver este punto. no definiéndose un marco para los procesos de desarrollo de software. tecnologías de información y comunicaciones (TIC) y compras. se ha contratado a otra empresa consultora especialista en procesos TI que apoyará la definición de los procesos y estructura organizacional. el holding matriz ha contratado una consultora que se encargará de los procesos de contabilidad. sin poder ellas optar por otro proveedor o mantener un servicio propio. no se han realizado definiciones respecto al proceso de desarrollo de software.Culturalmente. como 6 . recursos humanos y compras [5]. el holding matriz ha definido la utilización del modelo ITIL para la provisión de servicios. plantearemos el uso. utilizando como marco de referencia modelos y estándares de calidad y buenas prácticas existentes en la industria. Tal como se mencionó. Todas las filiales del holding serán atendidas por esta nueva empresa. tomando como marco de referencia modelos de servicio y calidad estándares de la industria. transición y organización del área de tecnologías de información bajo el paradigma de servicios compartidos. En el caso de Tecnologías de Información. Tampoco se podrán proveer servicios fuera del conglomerado de empresas y se deberá operar con procesos y aplicaciones estándares de la industria. teniendo como marco de referencia para la provisión de servicios el estándar ITIL. c) Definir el plan de transición que implementará el cambio organizacional. Definición del Problema El holding matriz ha definido la creación de una nueva empresa que proveerá a todas las filiales los servicios de: contabilidad. El holding matriz ha definido que este trabajo sea realizado en conjunto por personal propio y de la consultora. Sin embargo. Esta tesis se concentra en la definición global de procesos. b) Definir los procesos de negocio del área de tecnologías de información que prestará los servicios. donde la mayoría de las decisiones son tomadas por Gerentes y Subgerentes.

tales como [5]: 1.marco de referencia. Optimización de los procesos a través de la reingeniería. compañías con servicios compartidos han reducido los costos asociados a la prestación de servicios de soporte al negocio entre un 25% y un 45% 7 . orientados a la provisión de servicios de tecnologías de información bajo servicios compartidos. se ha convertido en un estándar global como modelo de organización de las unidades de apoyo al negocio para las corporaciones. cultura organizacional y paradigma. estándares y transversales. hay al menos 10 empresas operando bajo el esquema y varias otras en diferentes grados de implementación y avance [5]. Reducción de los costos de operación de las unidades de apoyo al negocio. 4. estandarización y consolidación de los mismos generando economías de escala para minimizar los costos operativos1. puede resultar contraproducente e incluso no beneficioso para la empresa y el cambio a implementar. de algún modelo o estándar de calidad de software existente en la industria. Simplificar la operación y el control. 3. Promover la mejora continua. con la posibilidad de generar sinergias. Hipótesis El concepto de servicios compartidos. Minimizar los costos de operación de las actividades de apoyo al negocio. se pueden lograr beneficios y oportunidades importantes. La hipótesis de trabajo es mostrar que mediante la estructuración e implantación de procesos basados en estándares. En Chile. Crecimiento por adquisiciones y fusiones. en esta etapa. sustentado en: a) Estandarización y optimización de procesos. b) Aplicaciones informáticas estandarizadas. c) Focalización en las actividades propias de cada empresa del holding. que considera los siguientes focos tácticos. 2. por lo que una adopción completa de algún modelo. organización. Simplificación de la operación y el control. 4. b) Mejores condiciones para la implementación de soluciones tecnológicas. En esta tesis. 1 De acuerdo a Ernst & Young. a partir de: a) La implementación de un modelo único de operación. no se contempla la implementación y/o certificación de modelos y/o estándares de calidad. a los cuales se contribuiría directamente [5]: a) b) c) d) e) Incrementar la calidad de los productos y servicios. Este proyecto supone una transformación fuerte en términos de procesos. en particular las tecnologías de información. Incremento de la calidad de los productos y servicios. Este trabajo surge como respuesta a la necesidad de responder a la estrategia de negocio del holding matriz.

se utilizarán los siguientes mecanismos de evaluación: 1. A nivel de procesos: Comparación cualitativa entre la situación inicial versus la situación con los procesos implantados.Para evaluar el cumplimiento de la hipótesis propuesta. 3. 8 . A nivel de servicio: Comparación cualitativa de la situación inicial versus la situación con el servicio compartido de tecnologías de información en funcionamiento. A nivel de costos: Comparación entre los costos en tecnologías de información de la situación inicial y los obtenidos después de la implementación de los procesos para una planta industrial promedio con 500 usuarios. 2. y el cumplimiento de los objetivos propuestos para esta tesis. La evaluación de estos puntos será abordada en el capítulo 7.

Capítulo 2 – Revisión Teórica y Metodología 1. La administración superior no entiende los puntos clave del proceso. b) Un modelo organizacional orientado al mejoramiento continúo.1 Análisis. Las herramientas no están bien integradas y el control de cambios no es riguroso. c) Una estructura confiable de diagnostico de procesos y evaluación de su capacidad. Existe un grupo de procesos que lidera las mejoras y las promueve. pero hay riesgos mayores cuando hay que enfrentar nuevos desafíos. ni estimación de costos. que define 5 niveles y provee [30]: a) Una guía para el desarrollo evolutivo de procesos. Modelamiento y Diseño de Procesos Un proceso es un conjunto de compromisos. Nivel 5 (Optimizante): El mejoramiento continúo realimenta a los procesos. No existe un marco para enfrentar el mejoramiento. Se realizan análisis rigurosos de tipo causa-efecto y prevención de defectos. acciones y decisiones necesarias para satisfacer un requerimiento de un cliente. Revisión Teórica 1. Nivel 4 (Administrado): Los procesos son medidos y se han establecido un conjunto mínimo de medidas de calidad y productividad. Nivel 3 (Definido): Los procesos están definidos e institucionalizados. Nivel 2 (Repetible): Los procesos dependen de los individuos y se establecen controles básicos para los proyectos. Los procesos pueden ser calificados mediante un modelo de madurez. ni planificación y programación de procesos. 9 . 30]: Nivel 1 (Inicial): No hay procedimientos formales. Un proceso de negocio es un conjunto de tareas lógicamente relacionadas que utilizan recursos de la organización para el cumplimiento de los objetivos de negocio [31]. La recolección de información es automatizada. No hay mecanismos de administración que aseguren que se siguen procedimientos. Los niveles del modelo de madurez se categorizan en [7. La evidencia numérica es usada para justificar la aplicación de tecnología a las tareas críticas. Se basa en redes de compromisos en torno a un ciclo de trabajo. Se busca hacer el trabajo en forma similar.

Los métodos se clasifican de acuerdo al tipo de modelamiento que se quiera realizar [32]: IDEFØ: Es un método diseñado para modelar las decisiones. que representan las actividades del sistema.2 IDEF (Integrated DEFinition Methods) Es un conjunto de métodos para el modelamiento de procesos. los que están compuestos de [15]: a) b) c) d) e) f) Diagramas de actividades. diagramas de contexto y de flujo de datos de nivel 0 hasta el nivel que sea requerido. Por lo tanto no resulta adecuado para el modelamiento de procesos. 1. pero si para los sistemas [15]. 1. así como también los agentes (proveedores o receptores de datos externos al sistema). Condiciones de activación. Diagramas de datos.1. El problema de este modelo es que es una caja negra. de los cuales se han revisado los principales. los procesos poseen entradas y salidas pero no se especifica la forma de hacer las cosas. Se centra en los datos y no en el proceso. 10 . SADT es una técnica de análisis y diseño de sistemas que ha sido ampliamente utilizada. para especificar completamente el sistema. Los archivos de datos son especificados.1 SADT (Structured Analysis and Design Technique) Desarrollada a finales de la década del 70. Actualmente son mantenidos por Knowledge Based Systems Inc. a partir de 1970. fue desarrollado. Esquema jerárquico del sistema.Para el diseño y modelamiento de procesos. Glosario de definiciones y términos utilizados.1. es derivado de SADT. Se utiliza descomposición funcional para la jerarquización del sistema. Provee de un conjunto de procedimientos que permiten al analista descomponer las funciones del software o el sistema. Textos y diagramas explicativos para los diagramas. por el Departamento de Defensa de EEUU. en particular. empresa dedicada a la investigación de tecnologías. acciones y actividades de una organización o sistema. existen una diversidad de métodos y técnicas.

la precedencia y las relaciones de 2 Fuente: http://www.com/idef0. IDEFØ produce una representación organizada de las funciones y actividades y es independiente del tiempo y la organización. el cuadro representa a la función o actividad del sistema u organización. determinar cuáles problemas son causados por falta de información y especificar qué información será administrada en la implementación. posee una sintaxis diseñada para soportar construcciones semánticas necesarias para desarrollar esquemas conceptuales.Figura 3: Representación gráfica de IDEF02 En la figura 3. las de la derecha las salidas. IDEF3 captura el comportamiento. IDEF3: Es un método que provee los mecanismos para capturar y documentar procesos. Un esquema conceptual es una definición integrada de un dato de la organización independiente de su representación computacional. controles y mecanismos se les denomina ICOM.html [consulta: 22 de Marzo de 2006] 11 . IDEF1: Es un método de modelamiento de la información. IDEF1X: Es un método para diseñar bases de datos relacionales. Al conjunto de entradas.idef. Captura lo que se hace o no se hace y utiliza la noción de descomposición funcional para modelar las actividades o funciones. Generalmente se utiliza para identificar qué información es la que actualmente es gestionada por la organización. La descripción de los detalles y la temporalidad de los procesos se especifica utilizando IDEF3. las flechas de la izquierda son las entradas. salidas. Un modelo de información representa la estructura y semántica de la información dentro del sistema u organización modelada. Las flechas por sobre el cuadro corresponden a controles sobre la función y las flechas por debajo corresponden a los mecanismos.

Universidad de Chile. El submodelo de métodos contiene los diagramas de taxonomía para los métodos y los diagramas de contratos y clientes. Figura 4: Representación gráfica del modelo de ciclos de trabajo3 3 Fuente: VARAS. 1.3 Ciclos de Trabajo El modelo de ciclos de trabajo fue desarrollado por la empresa Action Tech en torno a la semántica de compromisos y cumplimiento [31]. modificación y mantención de ontologías. Departamento de Ingeniería Industrial. Los procesos son redes de acciones y compromisos. se muestra la representación gráfica de este modelo. El submodelo de clases contiene los diagramas de tipos. de acuerdo a las promesas (condiciones de satisfacción) [31].1.causalidad entre situaciones y eventos. Permite expresar el conocimiento sobre como un sistema. el ejecutor realiza las acciones para cumplir sus promesas. El método contempla dos modalidades: flujo de procesos y redes de estado-transición de objetos. consiste en dos submodelos: el de clases y el de métodos. luego el cliente y el ejecutor negocian la realización (promesas mutuas). el cliente realiza la acción de satisfacción. El ciclo parte desde un cliente con una petición a un ejecutor. IDEF4: Es un método de diseño orientado a objetos que apoya la correcta aplicación de la programación orientada a objetos. Por último. IDEF4 provee un marco para el desarrollo de software con orientación a objetos. SAMUEL. herencia. IDEF5: Es un método específicamente diseñado para apoyar la creación. Conceptualmente. Apuntes del curso “Tecnologías de Información y Rediseño de Procesos”. protocolos e instanciación. declarando el termino del trabajo. los procesos o la organización trabaja. En la figura 4. La primera modalidad captura el conocimiento de cómo los componentes funcionan en una organización. 12 . la segunda resume las transiciones permitidas para un objeto a través de un proceso particular. 2003.

A la relación entre dos estados se le llama transición. 8.1. los de colaboración destacan la organización estructural de los objetos que envían y reciben mensajes. especificar. Diagrama de secuencia y de colaboración: Se utilizan para modelar aspectos dinámicos de un sistema. construir y documentar todos los artefactos de un sistema de software [10]. Diagrama de casos de uso: Un caso de uso especifica el comportamiento de un sistema o parte del mismo. dispositivos. componentes de software. congela un instante en el tiempo de ejecución. etc. Ambos diagramas son semánticamente equivalentes. procesos de negocio. relaciones y semántica. 7. esquemas de bases de datos. Un caso de uso representa un requerimiento funcional del sistema. Diagrama de clases: Es la representación de los bloques de construcción más importantes del sistema y sus relaciones. casos de uso. Diagrama de actividades: Se usan para modelar los aspectos dinámicos de un sistema. Diagrama de despliegue: Describe la arquitectura física del sistema durante la ejecución. 4. 5.1. Cubre aspectos conceptuales. que conforma un conjunto de interfaces y proporciona la realización de dicho conjunto. e indica. Las representaciones son realizadas mediante diagramas. que es una descripción de un conjunto de objetos que comparten los mismos atributos. organizados respecto de las acciones. operaciones. Diagrama de objetos: Los diagramas de objetos modelan las instancias de los elementos contenidos en los diagramas de clases. La característica de UML es que es orientado a objetos. Diagrama de componentes: Muestra las relaciones entre los componentes de un sistema. como procesos de negocio y elementos concretos: clases. 2. en términos de: procesadores. Son usados para especificar: métodos.4 UML (Unified Modeling Language) UML es un leguaje gráfico para visualizar. Muestran los objetos y sus relaciones en un momento concreto. La unidad básica es la clase. existiendo varios tipos [10]: 1. 6. 3. Consiste en un conjunto de objetos y sus relaciones. 13 . El diagrama corresponde a una descripción de un conjunto de secuencias de acciones donde cada secuencia representa la interacción de los elementos externos del sistema con el propio sistema. mostrando el flujo de control entre actividades. incluyendo los mensajes que se pueden enviar entre ellos. que cuando ocurre un evento. es decir la interacción de la parte física y reemplazable de un sistema. Este tipo de diagrama es una especialización de los diagramas de estado. el objeto pasa del estado anterior al siguiente. Diagrama de estados: Describen gráficamente los eventos y los estados de los objetos. Los diagramas de secuencia destacan el orden temporal de los mensajes.

la estructura de los elementos de hardware y software que ejecuta cada uno de ellos. b) El análisis del medio externo e interno. 1. consiste en: a) La definición y declaración de la misión y la visión. d) La programación y evaluación de los programas de acción propuestos y fijación de las prioridades para la asignación de los recursos. Figura 5: Modelo de planeación estratégica4 4 Fuente: JORRAT. MICHAEL. e) La asignación de recursos y la elaboración del presupuesto. Un proceso de formación de la estrategia es un conjunto de actividades tendientes a definir la estrategia de un negocio. Departamento de Ingeniería Industrial. Universidad de Chile. incluyendo la estrategia del negocio.2 Proceso de Planificación Estratégica Para abordar los procesos de planificación estratégica es necesario realizar la distinción entre estrategia y el proceso de formación de la estrategia. La figura 5 presenta el aspecto general del proceso. 2000. Apuntes del curso “Evaluación de Proyectos”. Un proceso de planeación estratégica. a un conjunto bien coordinado de programas de acción que apuntan a asegurar una ventaja sostenible en el largo plazo. las prioridades y asignación de recursos y los programas de acción generales [11]. 14 . describen la topología del sistema. Entenderemos por estrategia de negocio. c) La formulación de los planes y programas generales de acción.Además.

amenaza de nuevos participantes. en la producción de bienes y servicios [11]. el análisis de factores externos. el que esencialmente postula que hay cinco fuerzas que conforman la estructura de una industria: intensidad de la rivalidad de los competidores. Para el análisis del medio externo se utiliza ampliamente el modelo de las cinco fuerzas de Porter. el examen sistemático de los modos que tiene un negocio para lograr una ventaja competitiva. En la figura 7. Apuntes del curso “Evaluación de Proyectos”. el marketing y ventas. 2000. costos y requerimientos de inversión. Estas cinco fuerzas delimitan. Universidad de Chile. La cadena de valor es la caracterización de las actividades realizadas por una unidad estratégica de negocios [11]. que constituyen factores básicos que explican la expectativa de rentabilidad de largo plazo y por lo tanto. Las actividades de apoyo. etc. apoyan las actividades primarias y establecen una infraestructura para el funcionamiento de una empresa. 15 . Otras herramientas son. es decir. las operaciones. amenaza de sustitutos. Departamento de Ingeniería Industrial. Las actividades primarias son aquéllas relacionadas con el movimiento físico de materias primas y productos terminados. Figura 6: Representación gráfica del modelo de las 5 fuerzas de Porter5 Para el análisis interno. precios. poder de negociación de los compradores y el poder de negociación de los proveedores. por ejemplo: el análisis financiero.Existen herramientas que facilitan el proceso de planeación estratégica. es ampliamente utilizado el concepto de cadena de valor [11]. las actividades primarias de la cadena son la logística de entrada y salida. Las actividades de apoyo son 5 Fuente: Fuente: JORRAT. el servicio. MICHAEL. el atractivo de la industria [11]. Las tareas son clasificadas en actividades primarias y actividades de apoyo. representado en la figura 6. como su nombre lo índica.

el desarrollo de tecnología. Figura 7: La cadena de valor6 En el ámbito de la informática. la planeación estratégica consiste en la identificación e implementación de la tecnología requerida por el negocio para la consecución de su misión. tiene relación con la manera con que son gestionados los recursos de TI. existen diversas metodologías. Para este proyecto. 6 Fuente: Fuente: JORRAT.3 Modelos y Prácticas para Procesos de Software Existen dos modelos. Si bien. el portafolio de proyectos. el manejo de recursos humanos y la infraestructura de la firma. objetivos y estrategias [8]. el resultado de la planeación en informática. Departamento de Ingeniería Industrial. 2000. Apuntes del curso “Evaluación de Proyectos”. se escogerá uno de los modelos.representadas por las adquisiciones. 16 . apoyan la formulación de la estrategia informática desde la perspectiva de entender el negocio para conseguir el alineamiento de las iniciativas tecnológicas. MICHAEL. ampliamente utilizados en la industria. 1. el objetivo final en esta etapa es concentrarse en los procesos globales más que en el detalle. el presupuesto y el plan de infraestructura. la arquitectura informática del negocio. proveen una guía para mejorar los procesos de la organización y por lo tanto tienen el efecto de producir mejoras en la calidad de los productos y servicios. Por lo tanto. Las herramientas mencionadas anteriormente. Universidad de Chile. que entregan un marco de referencia para los procesos de software: CMMi e ISO. el que será tomado como marco de referencia para definir procesos básicos de producción de software. Ambos.

17 . proveedores y desarrollo integrado de procesos y productos [30]. 1. adquisición y mantención de productos y servicios [7]. Incorporación de medidas y análisis de métricas. desarrollado por la Universidad de Carnegie-Mellon. A continuación se presenta una breve descripción de ambos. Desde el punto de vista técnico.3. CMMi define cuatro disciplinas: ingeniería de software. la calidad y productividad aumenta y el re-trabajo junto con el riesgo van disminuyendo. b) Permitir la integración entre varias funciones y ámbitos de la ingeniería. Provee 5 niveles de madurez donde cada nivel es una capa en la fundación para un proceso de mejoramiento continuo.1 CMMi (Capability Maturity Model Integration) El modelo. c) Emplear principios de ingeniería de sistemas para el desarrollo de software. Incorporación de la gestión de riesgos. En la tabla 3 se presenta un resumen del modelo. Ayuda a la organización a examinar la efectividad de sus procesos y establece las prioridades de mejoramiento [30]. los principales beneficios son: a) b) c) d) Focalización en la gestión y desarrollo de los requisitos. ingeniería de sistemas. Desde el punto de vista del negocio. Provee una terminología común y una metodología integrada para la auditoria de los procesos [30]. comenzando por prácticas y áreas de proceso básicas de administración y progresando a través de un camino predefinido y probado de niveles sucesivos [30]. tiene como propósito proveer una guía para mejorar el proceso de una organización y la capacidad para administrar el desarrollo. Focalización en el diseño y desarrollo.Los modelos entregan un marco sobre el cual se pueden obtener las definiciones para afrontar los procesos de software. CMMi. Cabe señalar que en la medida que se avanza en madurez. beneficia a la organización en: a) Reducir la integración de sistemas y el tiempo de pruebas.

b) ISO 9001.Tabla 3: Los niveles de madurez y las áreas de proceso de CMMi7 1.2 Normas ISO ISO es una organización mundial de cuerpos de estandarización a nivel mundial. Apuntes del curso “Introducción a CMMi”. Su misión es proveer estandarización internacional para facilitar el intercambio de bienes y servicios [1]. las que son revisadas a continuación. satisfacer los compromisos entre la organización y sus clientes y lograr mejoramiento en el desempeño de una empresa [1]. Para el caso de los procesos de Tecnologías de Información. referente a las directrices para la mejora del desempeño. Departamento de Ciencias de la Computación. Dentro de los beneficios esperados de la adopción de este modelo.2. que describe los requisitos.1 ISO 9000:2000 Es un conjunto de normas utilizadas para establecer la gestión de calidad de una organización. que describe los fundamentos y la terminología.3. Universidad de Chile. se encuentran: mejor control de la gestión.3. 2004. pueden ser aplicables dos normas: ISO 9000:2000 de carácter general e ISO 9126 para ingeniería de software. FERNANDO. aumento de la eficacia y una mejor percepción de los problemas de calidad [1]. 18 . 1. 7 Fuente: PINTO. Se compone de 3 partes: a) ISO 9000. c) ISO 9004. mayor facilidad para eliminar y percibir los problemas de procedimiento.

evaluación de productos y medidas de calidad [33]. adherencia. que contempla los siguientes atributos: entendibilidad. 2. Promueve un enfoque desde la perspectiva de la calidad. define una serie de requisitos que se orientan a la elaboración y mantención de procedimientos relacionados con el producto y el proceso. Si bien. que contempla los atributos de rendimiento y uso de recursos.2 ISO 9126 para Ingeniería de Software Esta norma está compuesta de 4 secciones: 1. e) Mantenibilidad. Las métricas internas miden el software como tal. mediante la implantación de un sistema de gestión de calidad y la obtención como resultado final del manual de calidad. que provee el modelo de calidad que clasifica al software en seis grandes atributos de calidad [1]: a) Funcionalidad. ISO 9126-3:2003. b) Confiabilidad que contempla los siguientes atributos: madurez. que provee métricas internas para la medición de las seis características de calidad definidas en ISO 9126-1. ISO 9126-2:2003. cambiabilidad. seguridad. recuperabilidad. que contempla los siguientes atributos: pertinencia. por su carácter general. que provee métricas para medir el uso de calidad de los procesos de ingeniería de software [33]. Las métricas externas. aceptación de uso. que provee métricas externas para la medición de las seis características de calidad definidas en ISO 9126-1. que contempla los atributos: adaptabilidad. en el uso bajo un contexto específico [33].2. c) Usabilidad. 1. ISO 9126-1:2001. bajo los procesos de requisitos. f) Portabilidad. estabilidad. que contempla los atributos: analizabilidad. operatividad. interoperabilidad. adecuación. la norma es aplicable a procesos de software. miden el comportamiento de un sistema computacional que incluye el software y las mediciones de la calidad.3. d) Eficiencia. precisión. para conseguir efectividad en el negocio y eficiencia en el uso de los sistemas de información [26]. 1. 4. tolerancia a fallos. Se basa en la experiencia 19 .4 ITIL (IT Infraestructure Library) ITIL fue desarrollado a fines de 1980 por la Oficina de Comercio (OGC) del Reino Unido y es un conjunto de las mejores prácticas comúnmente aceptadas por la industria para la provisión y administración de servicios de tecnologías de información.ISO 9000. 3. ISO 9126-4:2004. aprendibilidad. Lo que se alcanza. no define guías ni opciones que provean una referencia para ese tipo de procesos. reemplazabilidad. demostrabilidad. instanciabilidad.

es importante señalar los criterios de selección: a) Debe ser un modelo o estándar de la industria. La gestión e implementación puede ser llevada a cabo con metodologías orientadas al desarrollo. vale decir: gestión de incidencias. gestión de los niveles de servicio. redes y servicios. mantención y adquisición de software. no define ni compromete prácticas para el proceso de producción de software. se especificará más adelante el modelo o estándar a utilizar. se debe seleccionar uno o una combinación de ellos. d) Debe ser ampliamente utilizada. Define cuatro áreas de macro procesos que a su vez definen procesos de negocio para la función de tecnologías de información. 2. gestión del cambio. gestión de problemas. gestión de la capacidad y la gestión de proveedores. gestión del inventario y la configuración. 3. estos son [26]: 1. Para el caso del proceso de desarrollo de software. las que han de ser seleccionadas o definidas según cada organización. Service Delivery: El objetivo de este macro proceso es definir y entregar los procesos relacionados con la entrega del servicio de informática. en lo posible un estándar. sin embargo. e) Debe proveer los elementos semánticos y gráficos para modelar las decisiones. gestión de la continuidad. control y distribución de hardware y software. acciones y actividades. c) Debe capturar el detalle y las relaciones de flujos de trabajo entre las diferentes etapas del proceso y proveer una estructura para priorizar acciones. lo que ha convertido a este framework en un estándar de facto de la industria [26]. Infraestructure & Security Management: El objetivo de este macro proceso es definir y entregar los procesos relacionados con la administración de la infraestructura y la seguridad de aplicaciones.5 Criterios de Selección de Herramientas Para efectos de este trabajo y dentro del conjunto de métodos presentados para el modelamiento de procesos. Pero. Los criterios de selección de la herramienta a utilizar son los siguientes: a) La herramienta debe estar orientada al modelamiento de procesos de negocio.colectiva de organizaciones gubernamentales y comerciales a nivel mundial. Service Support: El objetivo de este macro proceso es definir y entregar los procesos relacionados con el soporte al servicio de informática. 1. 4. gestión de las finanzas TI. Application Management: El objetivo de este macro proceso es definir y entregar un ciclo de vida del software que permita el alineamiento con el negocio. 20 . b) Debe ser de fácil comprensión y lectura para una persona que no se encuentre capacitada en su uso. vale decir: gestión de la disponibilidad.

se utiliza ampliamente el enfoque de re-ingeniería. mejoramiento de procesos. contingentes al grado de cambio socio-tecnológico requerido. sin que las empresas clientes sufran un alto impacto en el servicio que actualmente están recibiendo. b) Es la reconfiguración del negocio usando TI como eje central. una serie de definiciones. Pero. Otra definición. el criterio es utilizar una combinación de las herramientas comúnmente utilizadas de planificación. ¿Qué es el cambio de los procesos de negocio? Existen. 21 . La re-ingeniería es definida como el rediseño radical de los procesos de negocio transversales a una organización con el objetivo de obtener ganancias o ahorros en uno o más órdenes de magnitud. c) Debe estar orientado al proceso de producción de software. por ejemplo: reingeniería de procesos de negocio. 2. innovación de procesos y rediseño de procesos de negocio. es claro que se deben tomar elementos que permitan su aplicación al ámbito de la informática. transformación del negocio. en ese sentido. planteando procesos que sean acordes a la cultura y realidad de la empresa y que estén basados en modelos y/o estándares de la industria. Por último.b) Debe promover la mejora continua de procesos y productos. Siendo el desafío el transformar a la organización inicial de TI desde unidades no sinérgicas distribuidas a una unidad de servicios con orientación al cliente. para los procesos de planeación estratégica. c) Es el análisis y diseño de workflows y procesos basados en equipos dentro o entre organizaciones. en particular. existe una serie de conceptos que son utilizados indistintamente para representar el fenómeno de cambio de los procesos del negocio. usualmente apoyado por tecnologías de información. que ayudan a entender este fenómeno [15]: a) Es el rediseño y replanteamiento radical de los procesos de negocio para alcanzar mejoras dramáticas de rendimiento. d) Debe proveer un mecanismo de evaluación de madurez de los procesos. Metodología 2. ve a la re-ingeniería como una transformación organizacional general [14].1 Enfoque de Trabajo Este trabajo. Para afrontar proyectos que significan cambios en los procesos de negocio. distinguiendo el alcance desde la mejora de procesos hasta el diseño de nuevos procesos. consiste en el cambio y redefinición de los procesos de negocio del área de tecnologías de información del holding de empresas. Existen varias aproximaciones para afrontar el cambio de los procesos en la organización. d) Es una iniciativa estratégica de la organización para (re)diseñar los procesos de negocio para alcanzar ventajas competitivas.

estará compuesto por un jefe de proyecto por parte del área de tecnologías de información y que reporta al Gerente de servicios TIC. a) Documentar el proceso actual. La función de este comité es velar por el cumplimiento de los objetivos del proyecto y resolver las diferencias de alto nivel que puedan surgir producto de las definiciones que se tomarán. b) Mejora continua. a) Explorar opciones de diseño. es definir e implementar los procesos y procedimientos de la nueva organización de tecnologías de información.2. 2. b) Diagnosticar patologías. 2. en la que se introducirán cambios. 5. Definición del proceso a ser estudiado. un jefe de proyecto por parte de la empresa consultora y un grupo de dos ingenieros consultores. Evaluación de la situación actual. para realizar este proyecto y en concordancia con las necesidades de la organización. Como este proyecto se desarrollará en una organización en funcionamiento. 3. El equipo extendido de proyecto contempla la participación del Gerente de servicios TIC y el personal que haya sido escogido como Subgerente o Jefe para cada área a definir.2 Estrategia del Proyecto La estrategia del proyecto es la definición de la manera en cómo será enfrentado este trabajo. el Gerente General de la empresa de Servicios Compartidos y el Gerente representante de la empresa de consultoría. por lo tanto. en contraste con la innovación de procesos. Implantación del rediseño propuesto. se plantea el uso de un enfoque de re-ingeniería de procesos. 2. 4. a) Evaluación. que uno de los aspectos importantes de la re-ingeniería es que parte de procesos de negocio que se encuentran en funcionamiento. Esta metodología establece los siguientes pasos generales [14]: 1. Definición y evaluación de las áreas de rediseño. es necesario distinguir entre las actividades propias del proyecto y las actividades de gestión del proyecto. la empresa ha definido la formación de un comité ejecutivo compuesto del Gerente de servicios TIC. Entonces. El equipo de proyecto. que parte de procesos que no existen o no han sido definidos. 22 . Puesta en marcha y operación. b) Diseñar el nuevo proceso. se plantea. c) Diseñar la estructura organizacional asociada al proceso. la estrategia y metodología para el re-diseño de los procesos y la definición de la estructura organizacional. La función del equipo de proyecto.1 Actividades de Gestión del Proyecto Para la dirección general del proyecto.Cabe señalar. a continuación.

Además. Estado de situación después de 1 mes de difundida la organización. tanto interno como externo y un control de riesgos del proyecto. 23 . Sin embargo. La obtención de la información será a través de entrevistas con personal clave de cada área y la obtención de documentación previa según sea el caso. el proyecto se plantea en cuatro fases. En el caso de la difusión de la organización. serán publicados electrónicamente para facilitar la difusión.2. Los comunicados se entregarán mediante un boletín impreso a todo el personal del área de tecnologías de información.2 Actividades Propias del Proyecto En concordancia con el enfoque de re-ingeniería de procesos. En el capítulo 1. se ha presentado un resumen de los puntos más relevantes del levantamiento de la situación inicial. para dar a conocer el contexto global y luego a nivel de cada área. se llevará un control respecto al cumplimiento de compromisos. 2. El plan comunicacional del proyecto se ajustará a lo que sea indicado por el comité ejecutivo. se ha definido el siguiente conjunto mínimo de comunicaciones a la organización: a) b) c) d) e) f) Inicio del proyecto. se ha contemplado una serie de presentaciones. Estado de situación una vez que la nueva organización sea considerada que se encuentra en régimen. o grupos de áreas en caso de que el proceso relacione a más de una. primero a nivel de todo el personal. Además.El seguimiento del proyecto se hará mediante reuniones semanales de coordinación del equipo de proyecto y reuniones mensuales del comité ejecutivo. Se contempla la participación y difusión a las jefaturas. se realizará una reunión plenaria con todo el personal de tecnologías de información. Estado de situación mensual dentro de la etapa de transición. quienes posteriormente deberán capacitar al personal que tienen a cargo. Estado de situación después de 1 mes de ejecución. estas son: Fase 1: Levantamiento Durante esta fase se realiza la evaluación y levantamiento de la situación actual. los cargos serán comunicados personalmente por cada Subgerente de área. Difusión de la nueva organización. Todas las reuniones generaran minutas. Se diagnostican las patologías y se rescatan los procesos o elementos que puedan servir para la nueva organización. Para la difusión de los procesos. las que deberán ser aprobadas. con el objeto de entender la problemática de la organización.

Los resultados de esta etapa son presentados en el capítulo 3. En cambio SADT solamente contempla un enfoque que es respecto a los sistemas. se implementa la nueva estructura organizacional. si no que más bien las relaciones de tipo conversacional que se producen. La elección se basa en que IDEFØ es una herramienta orientada al modelamiento de procesos. Por otro lado.3 Selección de Herramientas Metodológicas De acuerdo a los criterios de selección de herramientas mencionados en el punto 1. se definirán los procesos. para el modelamiento de los procesos se utilizará IDEFØ y eventualmente algunos elementos de UML. cuya intención es dar pie para la definición y adopción de procesos de mejora continua en el futuro. Fase 4: Prestación de Servicios En esta fase el servicio se encuentra en operación. UML entrega un marco general para el modelamiento de sistemas. 24 .Fase 2: Definición. El modelo de ciclos de trabajo no captura el detalle de los procesos. Se presentarán los procesos definidos en esta etapa en forma global. El problema de ISO es que al ser de carácter general no se encuentra orientado para resolver la definición de los procesos de software y debe ser interpretado para ser adaptado a esta realidad. la organización y la planificación estratégica del área TIC. El resultado de esta etapa son los procesos. 2. se utilizará un modelo de acuerdo a la selección que se propondrá más adelante en este capítulo. Junto con lo anterior. Para los procesos de software. Sin embargo. Esta actividad. Análisis y Diseño de Procesos En esta fase. lo que lo hace bastante entendible y completo. con el objeto de clarificar las representaciones. En el caso del software. será realizada en conjunto con la Gerencia TIC y el personal que sea designado como líder de la nueva estructura. se planteará una estrategia para la mejora del proceso de software. Se utilizará como marco de referencia el modelo ITIL.5. En el capítulo 6. Fase 3: Transición La fase de transición consiste en la puesta en marcha. implementación y adopción paulatina de los procesos mediante un plan de transición y cambio. se revisaron dos modelos ampliamente utilizados: ISO 9000 y CMMi. Este será presentado en el capítulo 5. es ampliamente utilizada y de fácil comprensión. la que será presentada en el capítulo 4. en cambio CMMi está pensado para solucionar dicha problemática. procesos y sus relaciones. es necesario definir procesos de mejora continua con el objeto de entregar servicios que sean mejores en el tiempo. servicios y la estructura organizacional.

se preocupa solamente del cumplimiento de una serie de requisitos a alcanzar. c) La formulación de los planes y programas generales de acción. En el caso del proceso de planeación estratégica se han revisado una serie de actividades que tienen relación directa con un negocio. es claro que CMMi posee ventajas para la definición de los procesos de software. b) El análisis de la situación actual de TI. pero no en los procesos. teniendo en consideración los siguientes elementos: a) La definición y declaración de la misión y la visión. se está entregando un servicio a un conjunto de empresas dentro de un marco global de una cartera de servicios. puede ser un negocio. un área de informática. Por lo tanto. lo que hay que plantear es una metodología que permita al servicio TIC apoyar a las empresas clientes en la elaboración de un plan informático. En contraste. la arquitectura informática del negocio. 25 .CMMi provee de un método de evaluación de madurez. En el caso de ISO 9126. por ello. porque en este caso. proveyendo una guía. el presupuesto y el plan de infraestructura. argumentando que una mejor evaluación de los atributos de calidad implica tener procesos mejores. e) La asignación de recursos y elaboración el presupuesto. solamente se concentra en los atributos para productos de software. es decir: la estrategia de gestión de recursos de TI. cumpliendo con los criterios de selección mencionados anteriormente. d) La programación y evaluación de los planes de acción propuestos y la fijación las prioridades para la asignación de los recursos. se utilizará como marco de referencia para la definición de los procesos básicos de software. Si bien. CMMi establece una guía para los procesos y su institucionalización. estos no son definidos por el estándar. el enfoque a considerar es el de apoyo. que si está enfocado a software. el portafolio de proyectos. en cambio ISO 9000. En definitiva. sin embargo.

las mantenciones de corto plazo. etc. incluso. sistemas de apoyo. quien luego realizará el cobro respectivo a la empresa cliente. con terceros proveedores [5].Capítulo 3 – Diseño de Servicios y Procesos 1. lo que define finalmente la oferta y por lo tanto el catálogo de servicios. Por ejemplo: el uso de la mesa de ayuda. los servicios pueden ser clasificados de la siguiente manera: a) Servicio fijo. servicios que son requeridos por el usuario sin ser permanentes su consumo en el tiempo. la propia gestión de las tecnologías de información. etc. si una persona es contratada. están basados en la definición comercial que ha tomado la empresa. etc. es decir. Esta clasificación tiene por objetivo facilitar el entendimiento de los usuarios respecto a los servicios ofrecidos por TI. Para cada tipo de servicio. el PC será provisto por el servicio compartido. son todos los servicios informáticos requeridos para que un usuario pueda realizar sus labores habituales dentro de su organización. pueden ser creados o contratados a terceros. impresoras.1 Servicios TIC El catálogo de servicios. se pueden definir agrupaciones y subservicios. pero no tendría sentido ya que tendería a confundir a los clientes más que aclararlos. estos eventualmente. La idea general. Por ejemplo. Si bien. Otra opción. puede ser una categorización de carácter técnico. El objetivo es entregar a los clientes una visión de la oferta de servicios TIC. previa evaluación técnico-económica. es el conjunto de servicios que se proveerán a las filiales. los servicios que agregan valor y producen el cambio dentro de una organización. es decir. de manera tal. b) Servicios variables. Por ejemplo: PC. es decir. que los clientes finales no se tengan que preocupar de la contratación y la gestión. Diseño de Servicios 1. las mantenciones que significan una evolución en el software que está en funcionamiento. La disponibilidad de los servicios será abordada en la sección de niveles de servicio. teléfono. su definición y su disponibilidad. c) Servicios de valor agregado. es que los servicios sean entregados integralmente. 26 . Por ejemplo: los proyectos que implementan software nuevo. Los servicios que se presentan en la tabla 4. pueden haber servicios que sean requeridos y que no estén dentro del catálogo. Para simplificar.

2004.Tabla 4: El catálogo de servicios8 8 Fuente: Documento Interno. Empresa Forestal Chilena. Catálogo de Servicios para un holding de empresas forestales. 27 .

La diferencia es que una inversión es para bienes nuevos. cada tipo de costo se puede agrupar de manera tal de establecer un marco para el modelo: 1. Las inversiones agruparan los siguientes tipos de costo: a) Licencias de software. c) Instalación de redes de datos y telefonía nuevas. e) Mantención de hardware. b) Arriendo de equipos.2 Modelo de costos de los servicios El objetivo es establecer un marco agregado para los costos. 28 . luz. realizada por única vez y considerada contablemente como un activo de la organización. f) Pueden existir servicios de carácter corporativo y que pueden ser recibidos por varias empresas simultáneamente. revisaremos cuales son las componentes sujetas a costo. c) Los servicios de comunicaciones son contratados a terceros y se rigen de acuerdo a lo que ofrece el mercado. servidores. Luego. con la finalidad de simplificar el entendimiento a los clientes finales. f) Viajes. como parte de la garantía del software. Los gastos contendrán los siguientes tipos de costo: a) Consultoría. b) Obras civiles. notebook. que corresponde al costo hora-hombre de realizar una actividad para una filial. Distinguiremos los costos entre gasto e inversión. 2. Para definir el modelo de costo de los servicios. d) Hardware. electricidad. Entonces. etc. c) Servicios de terceros bajo contrato permanente ya sea de carácter temporal o indefinido. para cada tipo de servicio. En cambio. d) Mantención de redes de datos y telefonía. e) Los servicios básicos (agua. esta puede ser interna o contratada a terceros. considerando que: a) Los PC. el gasto es de carácter permanente o temporal y se realiza sobre servicios y bienes ya adquiridos. respecto a la facturación de los servicios recibidos durante un periodo. h) Los costos de los servicios pueden ser de carácter mensual o por única vez.) son de costo de la empresa que recibe el servicio. b) Los servicios de impresión poseen un costo fijo y un costo variable. g) Pueden existir servicios de carácter particular y que pueden ser recibidos por una empresa. d) El costo de las mantenciones correctivas es asumido por el servicio. viáticos y alimentación. impresoras y equipos de redes pueden ser arrendados a terceros. los costos se pueden desglosar de manera tal de definir su aplicabilidad de acuerdo a la tabla 5.1.

las componentes mencionadas pueden o no presentarse. es decir. 29 . es decir. aquellos que se proveen con la infraestructura tecnológica propia de la filial o son dirigidos puntualmente a esta. es necesario diferenciar entre servicios que son provistos corporativamente.Tabla 5: Criterios para la aplicabilidad de costos a los servicios Cabe señalar que dependiendo de la naturaleza del contrato de servicio. Para el cálculo del costo final. aquellos en que se utiliza una infraestructura tecnológica común y por lo tanto podrían ser prorrateados y servicios que son costeados localmente para cada filial.

Tabla 6: Criterios para aplicar prorrateo a los costos de los servicios Con esto. b) Por número total de trabajadores que tienen computador. es decir. se ha establecido un modelo que permite el entendimiento y la asignación de los costos a los distintos servicios definidos. no considerando equipos servidores. se presenta cada servicio con una propuesta para el criterio de prorrateo.El factor de prorrateo puede ser calculado según las siguientes opciones: a) Por número total de trabajadores de la filial. La elección de una u otra opción dependerá del ámbito del servicio que se está prorrateando. El tipo de costeo es directo. solo PC y notebooks. c) Por número total de computadores. 30 . cuando el costo es generado directamente por la filial. En la tabla 6.

su capacidad de reclamo ante la gerencia. no todos requieren los mismos niveles de servicio. operación y productivos de las filiales. estos componentes permiten identificar cuatro segmentos distintos de usuarios: a) Usuario Normal: Es una persona que no necesariamente posee una alta jerarquía dentro de la empresa y que frente a una pérdida de servicio TI. 31 . Para determinar los distintos segmentos. tiene llegada con la alta dirección o posee una alta capacidad de reclamo. El problema es encontrar el indicador adecuado. agrupa a usuarios de tipo administrativo. conviene definir niveles de servicio respecto a la disponibilidad global de los servicios entregados. Bajo este paradigma. facturación. pero que frente a una pérdida de servicio TI. el impacto sobre el negocio es bajo. Tal como se aprecia en la figura 8. d) Usuario VIP: Es una persona que posee una alta jerarquía dentro de las filiales y que posee una alta capacidad de reclamo y que frente a perdidas de servicio TI produce un alto impacto en el negocio. ni considerar elementos técnicos dentro de la evaluación. b) La sensibilidad de una persona y/o la llegada sobre la alta dirección de la empresa cliente. b) Usuario Crítico: Es una persona que no necesariamente posee una alta jerarquía dentro de las empresas. En general. c) Usuario Especial: Es una persona que no necesariamente posee una alta jerarquía y que frente a perdidas de servicio no produce impacto en el negocio. es necesario entender la problemática desde el punto de vista del cliente final. vale decir. existen dos criterios que se pueden utilizar: a) El impacto sobre el negocio de una persona que frente a una pérdida de servicio deja de realizar sus labores o traba procesos productivos o del negocio. sin embargo. sin haber términos medios. produce un alto impacto sobre el negocio. Para resolver lo anterior. Esta categoría. agrupa a Gerentes y Subgerentes. Esta categoría. dentro de un determinado tiempo y que resguarden la posibilidad de falla del servicio. agrupa a usuarios que tienen directa relación con los procesos de ventas. Esta categoría. es decir. frente a pérdidas de servicio. Esta categoría. tomando en cuenta que por la naturaleza de los procesos de negocio de las filiales. evalúan en términos absolutos lo que reciben. las personas perciben los servicios de informática desde el punto de vista del resultado.1. se puede utilizar la agrupación de servicios propuesta en el catálogo de servicios y definir una segmentación de los usuarios.3 Niveles de Servicio Para definir los niveles de servicio. agrupa a usuarios que serán identificados respecto a su comportamiento de reclamo.

¿cómo se calcula la importancia relativa del servicio? En principio. es más importante que funcione la impresora de etiquetas a que funcione Internet. esto es impracticable en el corto plazo. el porcentaje de disponibilidad del servicio fijo es: n NDi  I i   % DSF  1     100 t i 1   Ecuación 2: Porcentaje de disponibilidad del servicio fijo Pero. sea NDi la no disponibilidad del servicio i dentro de un horizonte de tiempo t . Por ello. sin embargo.Figura 8: Segmentación de los usuarios Para el caso de los servicios fijos. medido en horas. Por ejemplo. Cada servicio que compone el servicio fijo. 32 . la idea es definir un único indicador de disponibilidad que capture el comportamiento global de los servicios recibidos por el usuario. será la suma de cada no disponibilidad ponderada por la importancia relativa da cada servicio. e I i la importancia relativa del servicio i . la importancia de cada servicio debería ser idealmente asignada por cada usuario. que en principio es asignada por el usuario. se asignará arbitrariamente una importancia relativa en relación a la segmentación de los usuarios. Luego. tiene una no disponibilidad dentro de un periodo de tiempo y una importancia relativa. Entonces. es decir: n TND   NDi  I i i 1 Ecuación 1: Tiempo de no disponibilidad de los servicios fijos Donde 0  I i  1 y n es la cantidad de servicios que componen el servicio fijo. para un operador de etiquetaje de productos. El tiempo de no disponibilidad del servicio fijo (TND).

la que se muestra en la tabla 8. Finalmente. los niveles de servicio para los servicios fijos y para cada segmento de usuarios se han definido de acuerdo a la tabla 9. esto se puede ser en la tabla 7. se debe asignar la importancia de cada servicio respecto a la segmentación de usuarios definida. media-alta. El criterio de asignación de la importancia es respecto al grado de uso estimado por cada tipo de usuario. Donde el nivel alto toma el máximo valor de importancia y el nivel nulo toma el mínimo valor.Para simplificar la escala de importancia. según el comportamiento habitual observado empíricamente dentro de las empresas. se definen cinco niveles: alta. media y media-baja tomaran valores intermedios. La importancia media-alta. Tabla 8: Importancia de los servicios según la segmentación de usuarios Para el caso del Usuario Especial. por lo tanto el valor medio es el que mejor podría representar la importancia de los servicios para este tipo de usuario. el supuesto es que las componentes de servicio tienen una importancia media ya que a priori no es posible establecer un patrón de comportamiento previo de los reclamos. media. el valor medio del rango establecido para I i . Tabla 7: Asignación de valores a la importancia de un servicio Ahora. siendo la importancia media. 33 . media-baja y nula.

La videoconferencia y los dispositivos de configuración móvil se considerarán como servicios a pedido. Figura 9: Línea de tiempo de un incidente 34 . oportunidad y fluidez. se debe distinguir entre los que son a pedido y los orientados al soporte a usuarios y de aplicaciones. cuyos niveles de servicio serán los que sean contratados de acuerdo al requerimiento de la filial. se considerará el service desk. En resumen. sea resuelto en el menor tiempo posible. que aseguren al cliente final que el servicio que está recibiendo se encuentre dentro de márgenes razonables de agilidad. Por lo tanto. el soporte en terreno y las mantenciones de corto plazo. sea contestado en el menor tiempo posible y que una vez que es registrado por el service desk. se puede construir una línea de tiempo de acuerdo a la figura 9. el problema es escoger cuales son los indicadores de servicio adecuados. Para este caso. como servicios orientados al soporte a usuarios y de aplicaciones. el interés principal es que el requerimiento o incidente. soporte en terreno y el mantenimiento.Tabla 9: Niveles de servicio para los servicios fijos En el caso de los servicios variables. Desde el punto de vista del cliente. Existe una serie de indicadores estándares para el service desk. tanto desde el punto de vista del servicio como del proceso.

f) T2: como el intervalo de tiempo entre la recepción y la solución del requerimiento. c) Usuario Especial: Esta categoría. sin embargo debe considerarse. g) T3: como el intervalo de tiempo de resolución del requerimiento por parte de un técnico o especialista. ya que el supuesto es que el usuario crítico corresponde a personas que están ligadas directamente con la operación de las fábricas. que agilice los tiempos de atención y modifique prioridades. es el que tiene mayor prioridad de atención y por lo tanto el mejor nivel de servicio. e) T1: como el intervalo de tiempo entre la recepción y asignación del incidente o requerimiento. para el caso en que se detecte que este usuario pueda establecer un reclamo frente a la alta dirección. b) ta: como el tiempo en el que se asigno un incidente a un técnico o especialista. según los siguientes supuestos: a) Usuario Normal: Como el perfil es de tipo administrativo. Como no todos los incidentes o requerimientos pueden ser resueltos en TMAX para todo el universo de usuarios. por lo tanto es el que tiene más baja prioridad de atención y niveles de servicio inferiores a las otras categorías. se puede definir niveles de servicio escalonados de acuerdo al tipo de usuario que recibe la atención. d) Usuario VIP: A pesar de que este segmento posee una alta jerarquía y una alta capacidad de reclamo y que frente a perdidas de servicio TI produce un alto impacto. debe tener niveles de servicio y prioridad equivalentes al usuario normal. un método de excepción. b) Usuario Crítico: Como produce un alto impacto sobre el negocio frente a una pérdida de servicio. la idea es apuntar a que un grupo de requerimientos sea resuelto antes de un cierto periodo de tiempo.Se distingue entonces: a) t0: como el tiempo donde se inicia el proceso de soporte y que es gatillado por la recepción y atención de una llamada en el service desk. a nivel del proceso. definiremos dos indicadores: 35 . su capacidad de reclamo es limitada. Para reflejar la resolución de requerimientos de soporte antes de un periodo de tiempo. c) tr: como el tiempo de resolución del requerimiento o incidente. d) ts: como el máximo tiempo que un usuario puede esperar a que su requerimiento sea resuelto sin reclamar. por lo tanto es más impactante para el negocio una pérdida de servicio para ese tipo de personas. Considerando la segmentación propuesta para los servicios fijos. h) TMAX: como el intervalo de tiempo máximo en el que un usuario puede esperar sin reclamar. una pérdida de servicio no tiene impacto sobre el negocio. que para un usuario VIP. se le asigna la segunda prioridad de atención y los mismos niveles de servicio que un usuario crítico.

(%LLC). b) %RNR8. es la cantidad de requerimientos que son resueltos telefónicamente. porcentaje de llamadas abandonadas (%LLA) y el porcentaje de llamadas contestadas. que corresponde al porcentaje de requerimientos no resueltos antes de 4 horas. g) Porcentaje de nivel de servicio. de acuerdo a la segmentación de usuarios propuesta y a la definición comercial de la empresa. sobre el total de requerimientos para el tipo de usuario normal y especial.a) %RNR4. El supuesto para estos indicadores. por lo tanto se puede definir el porcentaje de resolución. f) Porcentaje de llamadas abandonadas. c) Llamadas abandonadas. sobre el total de llamadas contestadas. es que un día de trabajo tiene 8 horas. Entonces. sobre el total de requerimientos para el tipo de usuario VIP y crítico. 36 . que corresponde al tiempo promedio en contestar una llamada por el grupo de agentes del service desk. que corresponde al porcentaje de llamadas contestadas sobre el total de llamadas recibidas. por lo tanto el objetivo de %RNR4 es incentivar la resolución de requerimientos antes de 4 horas y %RNR8 antes de 8 horas. los niveles de servicio se muestran en la tabla 10. los que están relacionados directamente con la percepción del usuario respecto al servicio son: porcentaje de nivel de servicio. que corresponde al total de llamados recibidos por la central telefónica del service desk. que corresponde al porcentaje de llamadas que se abandonaron sobre el total de llamadas. que corresponde a las llamadas perdidas o no contestadas por los agentes del service desk. que corresponde a la duración promedio de una llamada. d) Tiempo medio antes de contestar. e) Tiempo medio de conversación. que corresponde a la cantidad de llamadas contestadas antes de un periodo de tiempo. que impacta directamente en la percepción y el proceso. Un indicador adicional. que corresponde a las llamadas contestadas por los agentes del service desk. los indicadores habituales son [22]: a) Llamadas recibidas. ambos indicadores serán de carácter semanal ya que la idea es privilegiar la resolución. Para efectos de cálculo. De estos indicadores. sobre el total de llamadas. b) Llamadas contestadas. como la cantidad de llamadas resueltas por el service desk. Para el service desk. el tiempo medio antes de contestar (TMC). h) Porcentaje de llamadas contestadas. que corresponde al porcentaje de requerimientos no resueltos antes de 8 horas.

los niveles de servicio son los indicados en la tabla 11. Es por ello que se propone utilizar indicadores de cumplimiento mensual. es decir: a) %RMNR_1m. ya que este tipo de actividad la mayor parte del tiempo no es de carácter operativo. que corresponde al porcentaje de requerimientos no resueltos antes de 3 meses. La definición de la empresa. el que consideraremos con un horizonte de tiempo no mayor a 3 meses. b) %RMNR_2m. que corresponde al porcentaje de requerimientos no resueltos antes de 2 meses.Tabla 10: Niveles de servicio para servicios variables Hay que notar. sobre el total de requerimientos y de acuerdo a la prioridad del usuario. no son aplicables los indicadores mencionados. por lo tanto. no así los relacionados con el soporte en terreno. Tabla 11: Niveles de servicio para la mantención de software de corto plazo 37 . sobre el total de requerimientos y de acuerdo a la prioridad del usuario. c) %RMNR_2m. Para el caso del mantenimiento de corto plazo. sobre el total de requerimientos y de acuerdo a la prioridad del usuario. que los niveles del service desk. que corresponde al porcentaje de requerimientos de mantenimiento no resueltos antes de 1 mes. es apuntar a que el 80% de los requerimientos sea resuelto en menos de un mes. son uniformes para todo tipo de usuario. el 90% antes de dos meses y el 95% antes de tres meses.

que corresponde al porcentaje de cumplimiento de compromisos para un proyecto o consultoría particular. de carácter particular y corresponde a los días de atraso de un proyecto o consultoría particular respecto a su planificación aprobada. de carácter particular. sobre la cantidad total de proyectos o consultorías en ejecución. se pueden distinguir niveles de servicios asociados a la globalidad.Respecto a los servicios de valor agregado. es decir. Responde a la pregunta: ¿Cómo es la gestión general de la cartera de proyectos? b) %CC_PG. Bajo este enfoque. que corresponde al promedio del porcentaje de cumplimiento de compromisos para la cartera de proyectos o consultorías realizadas dentro del año. Responde a la pregunta: ¿Cuánto es el atraso del proyecto? Entonces. de carácter global. Tabla 12: Niveles de servicio para servicios de valor agregado 38 . definiremos los siguientes indicadores: a) %PA. hay que considerar la capacidad de cumplimiento y de gestión y la obtención de resultados dentro de los plazos comprometidos. para un cliente y dentro del año. para el lado del cliente. al conjunto o cartera de proyectos y/o consultorías que es realizado durante un año para una determinada empresa y a la particularidad. Este tipo de servicio contempla proyectos y consultoría. Entonces. donde el cumplimiento de los compromisos juega un rol relevante respecto a la percepción del servicio. es decir. sobre la cantidad total de compromisos a la fecha de cálculo del indicador. de carácter global. Para reflejar el cumplimiento antes de un periodo de tiempo. los niveles de servicio son los indicados en la tabla 12. más que definir métricas relacionadas con el proyecto o con el software. el enfoque es diferente. a lo que se espera recibir para un proyecto y/o consultoría puntual. Responde a la pregunta: ¿Cómo es el cumplimiento de compromisos del proyecto o consultoría? d) DA. Responde a la pregunta: ¿Cómo es el cumplimiento de compromisos del servicio? c) %CC_P. que corresponde al porcentaje de proyectos o consultorías atrasadas respecto a la planificación que fue aprobada por el servicio y por el cliente. de acuerdo las expectativas y definición de la empresa.

Diseño de Procesos Para el desarrollo de los siguientes puntos y debido a la profundidad. objetivos y estrategias [8]. memoria.2. que cada plan debe ser acorde a las necesidades de cada filial. la velocidad de los avances tecnológicos incorpora. extensión y cantidad de temas que pueden ser tratados. Esto sugiere. Se distinguen dos planeaciones según el horizonte de tiempo: una de carácter estratégico.1. El carácter multinacional. una componente temporal que debe ser contrastada con la capacidad de cambio de las empresas en el tiempo y su habilidad para adoptar e incorporar nuevas tecnologías a los procesos de negocio. En cambio. la de carácter táctico. El enfoque de diseño de los procesos es de carácter general. objetivos y estrategias. el horizonte de largo plazo será el que considere tecnología que se encuentre ampliamente probada y desarrollada. se propone un proceso que sigue los siguientes pasos: 39 . orientado a alinearse con los periodos de planificación anual de las filiales. la planificación estratégica en TI se refiere a la identificación e implementación de la tecnología requerida por el negocio para la consecución de su misión. o trabajo posterior. Un elemento importante a considerar. es decir cuatro a cinco años. Por lo tanto. será entendida como la identificación de la tecnología requerida por el negocio para la consecución de su misión. además. Tomando en consideración lo mencionado en el aspecto teórico de la planeación estratégica. el carácter conservador del holding respecto a la adopción tecnológica lo sitúan como una empresa netamente seguidora más que adoptadora. teniendo en consideración la posibilidad de generar sinergia e intercambio tecnológico entre diferentes empresas. tendrá relación con el plan de implementación de dichas tecnologías dentro de periodos anuales.1 Proceso de planeación estratégica TIC para las filiales 2. se han considerado los aspectos más relevantes que pueden ser mejorados como parte de un primer diseño de los procesos de TI. sin embargo. Por otro lado. La planeación de largo plazo. que tendrá relación con la determinación de los lineamientos tecnológicos de largo plazo y otra de carácter más táctico. la cantidad de filiales y la distribución de las localizaciones del holding agregan una complejidad importante a este proceso. sugiriendo guías ya que algunos temas por si mismos pueden ser abordados en forma independiente como tema de tesis. es la velocidad de cambio de la tecnología.1 Proceso para la planeación estratégica Típicamente. 2.

con horizonte de tiempo de largo plazo.1. 4. El comité tendrá como función realizar la planeación informática. Figura 10: Proceso de planeación estratégica de TI De la figura 10. que impacten la componente de tecnologías de información. c) Definición del portafolio de proyectos. 5. d) Plan de infraestructura. producto de nuevas necesidades o adecuaciones de procesos de negocio propios. Análisis de la situación actual de TI. 2. con horizonte de tiempo de largo plazo. 40 . las actividades de planeación deben ser abordadas conjuntamente con la empresa. Elaboración del presupuesto. Programación y asignación de prioridades y recursos. 3. con horizonte de tiempo de largo plazo. 6. Formulación de los planes y programas generales de acción: a) Estrategia de gestión de recursos de TI. En la figura 10 se muestra la representación del flujo del proceso. b) Arquitectura informática del negocio. Definición de la situación deseada de TI. priorizar y aprobar el presupuesto y dirimir respecto a los gastos adicionales que surjan. por ello es necesaria la creación de un comité de TI que este compuesto de representantes de alto nivel de la empresa y del servicio TIC. Definición y declaración de la misión y la visión de TI.

análisis de la situación actual de TI. b) Plan anual de mejora e implantación de la arquitectura informática del negocio. las definiciones y políticas respecto a: la compra y/o arriendo de equipos. Como resultado del análisis de la situación actual. el servicio de TI. la descripción general de productos y servicios ofrecidos. el que incluye. tecnología a utilizar. La visión corresponde a lo que se espera y quiere del servicio de TI desde la perspectiva de la empresa que recibe el servicio [11]. la contratación de servicios y recursos humanos. que permita tener una supervivencia sostenible en el tiempo [11]. 41 . es decir. la definición de la situación deseada de TI. La formulación de los planes y programas generales de acción junto con la programación y asignación de prioridades y recursos. la que incluye. c) Estrategia general de infraestructura. c) Definición del portafolio de proyectos de software. El siguiente paso. idealmente considerando soluciones probadas y estándares para la definición de tecnología a utilizar. d) Plan de infraestructura. el que incluye la descripción de los proyectos con una valorización previa. b) La infraestructura. con el objetivo de establecer en el mediano plazo procesos de mejora continua.Profundizando. es decir. servidores y servicios deseados. corresponde a la determinación y diagnostico de: a) La arquitectura informática del negocio. plan de mantenimiento y recambio de tecnología. de excelencia. la declaración de la misión consiste en la expresión del propósito del negocio. Este plan general. tanto internos como externos. vale decir. en este caso. servicios que se requerirán dentro del periodo. d) El estado de los proyectos y mantenciones en curso. tecnologías utilizadas y el diagnostico de procesos. o de asesoramiento. soporte a usuarios e infraestructura. proyectos. c) Los recursos utilizados para el desarrollo y mantención de software. d) Procesos de TI que serán mejorados o abordados. la definición del ámbito actual y los cambios esperados en el futuro. cantidad y tipo de equipos. gestión de TI. arquitectura de red. determinación anual de los recursos requeridos para realizar el plan anual de proyectos e infraestructura. es decir. corresponde a la definición en detalle y con carácter anual de: a) Plan táctico de gestión de recursos de TI. b) La arquitectura informática deseada. debe incluir: a) Estrategia general de recursos de TI. el plan informático con horizonte de tiempo de largo plazo debe recoger las necesidades actuales y futuras que hayan sido previstas. cobertura geográfica y la selección de una forma de conseguir una posición ya sea de liderazgo. e) El gasto realizado para el funcionamiento del servicio de TI.

El presupuesto debe ser especificado en dólares. es decir. compra de nuevas licencias y mantención anual de licencias. etc. los servicios permanentes prestados por terceros.1. el presupuesto es la estimación de los recursos de dinero para llevar a cabo los planes de acción definidos en la planeación estratégica. por lo tanto no pueden ser costo de la empresa que recibe el servicio. deben ser especificadas todas las actividades y los flujos mensuales. Además. notebooks. f) Servicios Informáticos. el arriendo de PC. móvil y las redes de comunicación WAN. que considera los costos de la telefonía fija. servidores. los que son determinados respecto a la planeación anual de las actividades. c) Licencias de Software. b) Mantención de Software. El tipo de cambio presupuestado es entregado anualmente por el área de finanzas. toda actividad relacionada con proyectos que signifiquen la adquisición. que considera los recursos para las mantenciones evolutivas y adaptativas. Las correctivas no son consideradas ya que se define como una garantía permanente al software instalado. es decir. d) Mantención de Hardware y Redes. impresoras. El presupuesto de informática se puede dividir según la siguiente clasificación: a) Proyectos. repuestos y mano de obra tendientes a reparar un producto de hardware o una red de comunicaciones. En la tabla 13. g) Comunicaciones. es decir. 42 .2 Proceso para la elaboración del presupuesto Derivado de la planeación estratégica de TI de la filial. e) Arriendo de Equipos.2. que considera partes y piezas. adecuación e implantación de software nuevo o infraestructura nueva. se presenta un ejemplo de un presupuesto. donde se consideran. el que debe ser tomado como referencia para la elaboración del presupuesto.

Para resolver este punto. 43 . en la tabla 14 se presenta una propuesta de criterios que pueden ser utilizados.Tabla 13: Ejemplo de un presupuesto El problema de la elaboración del presupuesto es la estimación de los recursos económicos a considerar.

quienes. es importante detallar los ítems que se considerarán dentro del presupuesto ya que es considerado como el plan anual de actividades y servicios de TI. dentro del marco de la planeación anual. 44 .Tabla 14: Criterios para la presupuestación Además. Tabla 15: Criterios para detallar el presupuesto El presupuesto debe ser presentado al comité de TI de la empresa. en la tabla 15 se proponen los criterios. fijarán el detalle de las prioridades y definirán los recursos.

5. 3. En la figura 11 se muestra la representación del flujo del proceso. Clasificar las actividades de acuerdo a la guía proporcionada anteriormente. 4. 2. contrastando con las necesidades de cada área de la empresa. Figura 11: Proceso de elaboración del presupuesto 45 . Estimar los costos para cada una de las actividades y servicios. el proceso propuesto es: 1. 6. Revisar. Completar la planilla de presupuesto. considerando los tiempos de las actividades y servicios. Esta actividad puede ser en conjunto con los jefes de cada área. Obtener la aprobación del comité de TI. El comité determinará el detalle de las prioridades y recursos que proveerá la empresa. De la planeación estratégica.Entonces. determinar las actividades y servicios que serán abordados dentro del periodo. junto con el comité de TI el presupuesto.

2. Desarrollo y Administración de Requerimientos. 3 y 4. c) Si se requieren resultados en corto tiempo y existe compromiso y voluntad para que el usuario final y la administración sea parte del equipo de desarrollo. 2. se pueden definir los siguientes elementos de juicio para apoyar la decisión [2]: a) Los métodos ágiles tienen una mejor efectividad que los tradicionales cuando se presentan requisitos cambiantes o mal definidos.2 Procesos de software Los procesos de software pueden ser caracterizados y cubiertos por cinco macro procesos: a) b) c) d) e) Administración de Proyectos. b) Si los tiempos de desarrollo del proyecto son ajustados. se puede utilizar metodología ágil con una buena posibilidad de éxito del proyecto. Administración integrada de proveedores. ¿Cuales son los criterios para escoger entre uno u otro tipo de metodología? Para responder a la pregunta. Desarrollo de Software. La idea es generar el proceso básico de administración de proyectos. Pruebas de Software. se está aplicando nueva tecnología y hay poca experiencia del equipo de desarrollo. Administración de acuerdos con proveedores. es recomendable que para proyectos de mediano y largo plazo se utilicen métodos tradicionales debido a que: 46 . Monitoreo y control de proyectos. de acuerdo al tipo de metodología de desarrollo de software. se presentará la definición general de estos procesos tomando como marco de referencia algunos elementos de la guía proporcionada por CMMi.2. d) Si bien la metodología ágil puede ser utilizada en todo tipo de proyectos. Equipos integrados. Administración cuantitativa de proyectos. Administración integrada de proyectos. Mantención de Software. la metodología ágil puede ser aplicada. En esta sección. En la industria se encuentran dos grandes visiones metodológicas para el desarrollo de software: los métodos ágiles y los métodos tradicionales. Administración de riesgos. identificándose las siguientes como parte de este proceso: a) b) c) d) e) f) g) h) Planificación de proyectos. Pero.1 Administración de Proyectos La administración de proyectos bajo CMMi abarca una serie de áreas de procesos de los niveles de madurez 2.

que en la práctica no existe un proceso de administración de proyectos. b. b) El seguimiento del proyecto no siempre es realizado y cuando se hace. La cantidad de personas del equipo de proyecto es mayor a la de un proyecto de corto plazo. e) Agendar la revisión de errores y defectos del software [16]. Por lo tanto. por lo que la falta de formalidad del método ágil puede ser interpretada por la organización como mala gestión y desorden del proyecto. 2. b) Determinar los costos de la iteración. tiene que ver con el ciclo: planeación. Entonces.1 Administración de proyectos con metodologías ágiles Las metodologías ágiles son caracterizadas por iteraciones de corta duración. control y monitoreo para el startup del proyecto y las iteraciones posteriores [29]. a) Determinar las actividades y su duración. Cabe notar. el énfasis de esta definición. debe ser respecto a la planificación. Otro punto importante. se destacan los siguientes puntos: a) Los proyectos son planificados en tiempo mediante una carta Gantt y los recursos son costeados. de la situación inicial.a. c) Determinar los casos de prueba para el testing [16].1.2. la actividad la ejecuta el superior inmediato del jefe de proyecto. Planificar la iteración. Guiar la iteración. b) Evaluar y mitigar riesgos durante la iteración [16]. que por el tamaño de la organización y la escasez de recursos. resolver problemas. de acuerdo a la voluntad del jefe de proyecto. a) Monitorear y controlar la iteración. Se ha señalado. 47 . se proponen las siguientes actividades para la administración de proyectos de este tipo: 1. por lo tanto la administración de proyectos de este tipo. d) Agendar la iteración. c) Agendar y realizar la revisión de lo que se hizo durante la iteración. la planeación. por lo tanto un control de proyectos mediante el seguimiento de actividades puede ser aplicado. Se entiende que un proyecto de corto plazo es para resolver algo puntual. es necesario contar con una función que concentre el seguimiento e información de control y monitoreo de los proyectos y que permita establecer a nivel del portafolio. La cultura organizacional es de carácter tradicional. priorización y coordinación de los recursos asignados a los proyectos. es que el servicio de TI puede tercerizar la ejecución de los proyectos. utilizando algunos elementos conceptuales del desarrollo de software ágil. c. 2. Sin embargo. manteniendo un jefe de proyecto interno. monitoreo y control de los proyectos. tema que será discutido en el proceso de gestión de proveedores. es por ello que cobra relevancia la administración de los proveedores. tampoco hay una participación directa del cliente.

b) Definir el ciclo de vida del proyecto [17]. incremental. espiral. Guiar el proyecto.3. alcances y ámbito del proyecto [25].2 Administración de proyectos con metodologías tradicionales Para este tipo de proyectos. el desarrollo puede ser abordado mediante métodos tradicionales. Figura 12: Administración de proyectos con metodologías ágiles 2. c) Definir la metodología de desarrollo. Las actividades propuestas son: 1. b) Mantener actualizado el avance de las actividades.2. d) Identificar riesgos. c) Realizar seguimiento y priorización de las actividades de corrección de errores y defectos [16]. a) Establecer los objetivos. a) Revisar objetivos [16]. etc. En la figura 12 se muestra la representación del flujo del proceso. Planificar el proyecto.1. por ejemplo: cascada. 48 .

Esto sugiere. la utilización de los mismos indicadores de cumplimiento vistos en el diseño de los servicios de valor agregado. 3. lo anterior no es suficiente para determinar el estado de avance real de un proyecto o un desarrollo de software.d) Definir y estimar las actividades. b) Obtener el compromiso con el proyecto. f) Identificar los riesgos del proyecto. recursos y costos [25]. c) Revisar y mitigar los riesgos [25]. Sin embargo. la medición de los días de atraso respecto a la planeación original y el grado de cumplimiento de compromisos. a) Identificar a los terceros relevantes [25]. 2. e) Definir el plan comunicacional del proyecto. que las variables de monitoreo y control deben estar ligadas a los niveles de servicio comprometidos con las empresas. 49 . Comunicar el estado del proyecto [17]. a) Realizar reuniones de seguimiento y revisión. Para resolver la problemática. Figura 13: Administración de proyectos con metodologías tradicionales Hay que notar. Monitorear el proyecto de acuerdo al plan establecido. es decir. En la figura 13 se muestra la representación del flujo del proceso. d) Revisar y realizar acciones correctivas. Obtener el compromiso de la organización para el plan del proyecto. 4. b) Revisar los compromisos. hay que distinguir que cada actividad del proyecto debe producir productos tangibles o entregables bajo una cierta temporalidad definida.

es un riesgo del proyecto que ha de ser mitigado. todas aquellas actividades que produjeron el producto de acuerdo a lo planeado. ¿qué ocurre con las actividades con atraso? Si una actividad está atrasada respecto a lo planificado quiere decir que. si n es el número total de actividades del proyecto. Porcentaje de avance del proyecto: es decir. Porcentaje de productos entregados en t ri  t i : es decir. todas aquellas actividades que produjeron el producto por sobre el tiempo planificado. sobre el total de productos definidos: P % PE p  j n i 1 j  100 donde j es tal que tr j  t j i P Ecuación 3: Porcentaje de productos entregados dentro de plazo 2. Porcentaje de productos entregados en t ri  t i : es decir. con un plazo planificado de realización t i y tri es el tiempo real transcurrido para la realización de la actividad i .Entonces. o la planeación no fue la correcta. 50 . Pi es la cantidad de productos entregables para una actividad i . se proponen las siguientes métricas para el control y seguimiento: 1. si eso es así. es decir todas aquellas actividades que se encuentren sin atraso respecto ti a lo planificado: % AP  t 1   ri  100 n i ti Ecuación 5: Porcentaje de avance del proyecto Pero. de manera tal que ti t ri  1 . la ponderación entre la cantidad t total de actividades y el factor de cumplimiento de tiempo ri . o que la actividad presenta un problema que debe ser corregido. sobre el total de productos definidos: P % PE a  j n i 1 j  100 donde j es tal que tr j  t j i P Ecuación 4: Porcentaje de productos entregados fuera de plazo 3.

c) Analizar y validar requerimientos. el propósito del desarrollo de requerimientos es producir y analizar los requerimientos de clientes. esto no tiene sentido. la idea es tener un indicador de avance. Respecto a lo propuesto en el punto 3. la actividad de registro de tiempo puede no ser ajustada a la realidad ya sea por olvido. está sujeto a variabilidad. La realización de las actividades de un proyecto depende de las personas. con el sentido de que este tipo de iniciativas permiten tener un mejor control del proceso del proyecto. que los indicadores planteados en los puntos 1 y 2 son de carácter expost y miden cumplimiento. ¿Cuánto tiempo se demora un recurso en desarrollarlo de manera tal que la cantidad de defectos sea inferior a una cierta tasa preestablecida? ¿Cuál es la varianza de ese proceso? Se puede considerar una métrica que clasifique piezas de software en base a complejidad. por ello el indicador propuesto en el punto 3 cobra relevancia desde el punto de vista operativo. Ambos procesos distinguen las siguientes etapas [7]: Caso: Desarrollo de Requerimientos. por lo tanto. pero hay que tener en cuenta que un indicador debe considerar al menos temporalidad y complejidad. a la automatización y sistematización del proceso de captura de los datos. una serie de indicadores de productividad que permitan obtener mejores estimaciones para la planificación. b) Desarrollar requerimientos de productos. 2. esto puede ser mitigado o modelado de acuerdo a la historia del comportamiento productivo de los recursos humanos. por ejemplo puntos de función y que mediante mediciones. La problemática puede ser resuelta desde varios aspectos. La administración de requerimientos. entregando una noción de la situación de avance. productos y componentes de productos. Hay que notar. lo que finalmente establecerá un criterio de productividad para los recursos.2. a) Desarrollar requerimientos de clientes. es la gestión de los requerimientos de los productos del proyecto y los componentes del producto y la identificación de las inconsistencias entre esos requerimientos. 51 . establezca una tasa de tiempo para el desarrollo. que la planificación es una estimación de tiempo y actividades de lo que se hará en el proyecto y como tal. entonces se pueden plantear dos preguntas: Para un producto de software con un cierto nivel de complejidad. en relación al tiempo respecto a lo planeado. los planes del proyecto y los productos de trabajo [7]. de manera tal de que la información sea obtenida oportunamente. El problema con esta métrica es que depende del recurso. por lo tanto mejores estimaciones y un mejor servicio entregado al cliente. y segundo. sin embargo si la planificación es mala. Se puede definir.Cabe señalar.2 Proceso de Desarrollo y Administración de Requerimientos De acuerdo a CMMi. es decir. debe ser de carácter dinámico ya que debe adaptarse de acuerdo a las situaciones y necesidades que se vayan dando durante la ejecución del proyecto. primero a la toma de conciencia de las personas que son medidas. resistencia al control de tiempo y los temores propios de una medición de productividad para una persona.

que lo documentado respecto al requerimiento. es imprescindible la participación de las áreas que transformaran los requerimientos en software. a) Validar con usuario. Obtener compromiso con los requerimientos. visión y alcance [17]. Administrar los cambios a los requerimientos. 3. Identificar inconsistencias entre el trabajo del proyecto y los requerimientos. se realiza. corresponde a lo solicitado [17]. a) Determinar los objetivos. c) Determinar si es un proyecto o un mantenimiento. El requerimiento es recepcionado por un encargado de TIC. El enfoque de este proceso. es decir: el desarrollo de los requerimientos del cliente.Caso: Administración de Requerimientos. b) Determinar la evaluación técnica. Evaluar la solicitud. 5. será abocarse a la problemática de levantar el requerimiento del cliente ya que es la falencia principal de la organización. la idea es tener un proceso estándar para el levantamiento de requerimientos. b) Determinar la situación actual y lo deseado. c) Determinar los procesos de negocio y sus requerimientos [17]. que intenta interpretar y evaluar el requerimiento. d) Determinar los requerimientos funcionales respecto al software. Presentar al comité de informática para aprobación. b) Solicitar y obtener compromiso del usuario [17]. el proceso se puede definir de la siguiente manera: 1. Desarrollar el requerimiento. 6. Independiente de la metodología del proyecto y del tipo de solicitud. Los elementos relevantes son los relacionados con el levantamiento. No se genera documentación. la obtención de una comprensión de los requerimientos el análisis y la validación de los requerimientos y la obtención de compromisos con los requerimientos. Obtener compromiso. corresponde a la recepción y aprobación. En términos prácticos. Mantener la trazabilidad bidireccional de los requerimientos. a) b) c) d) e) Obtener una comprensión de los requerimientos. Comprender el requerimiento. es el usuario quien especifica el requerimiento. 4. la etapa de requerimientos. Luego. mediante reuniones y revisión de a pares [17]. se presenta para aprobación a un comité y de ser aprobado. Además. b) Determinar el impacto [17]. a) Determinar la evaluación económica. c) Elaborar el documento de requerimientos. Como se vio anteriormente. 52 . e) Determinar los requerimientos técnicos del software. 2. de acuerdo a sus propias palabras. Recepción de una solicitud de cambio o de levantamiento de requerimientos. a) Analizar el requerimiento. Entonces.

En la figura 14 se muestra la representación del flujo del proceso. lo importante es que estos sean realizados. Si el cambio es menor. 53 . En la práctica. es que se considera una solicitud de cambio como una solicitud de mantención de software. entendiendo que dicho compromiso. obteniéndose el compromiso y luego sometido a aprobación en el comité. haya un cambio en los requerimientos. ¿Cómo manejar los cambios de los requerimientos? La posibilidad de cambios siempre se encuentra presente. debe evaluarse el impacto y comunicar al comité la nueva evaluación. Para las solicitudes de cambio. que para ser evaluada y presentada al comité. Bajo ese escenario. se sigue el flujo normal de evaluación. no puede ser modificada. la propuesta es realizar el ciclo completo de requerimientos. antes de obtener el compromiso con el usuario. más que concentrarse en los cambios. pueden presentarse situaciones en las que por cambios en el negocio. el ingreso debe ser realizado a través de la mesa de ayuda. idealmente en el levantamiento de requerimientos. La diferencia con un requerimiento normal. es la aceptación de la especificación de una cierta funcionalidad. Figura 14: Proceso de desarrollo y administración de requerimientos Pero. con la diferencia que solamente es validado por el Service Manager. en cualquier etapa.

f) Definir la infraestructura. es decir el diseño y la construcción. Para el caso de metodologías ágiles. 2. el proceso general es definido como sigue: 1. c) Localizar la causa del error. b) Definir los tests unitarios a aplicar [16]. es parte de la evaluación técnica determinar la adecuación al software. 3. e) Realizar los tests unitarios. d) Corregir el error. c) Construir el software [16]. se propone: 1. es un modelo estándar. d) Analizar el código.3 Proceso de Desarrollo de Software El proceso de desarrollo de software consiste en establecer la manera en que serán desarrolladas las aplicaciones en la empresa. o sean ambiguas. La realización de entrevistas con todos los involucrados. La utilización de diagramas UML de casos de uso para la especificación ya que son simples. b) Crear actividades de desarrollo para implementar la arquitectura [16]. b) Reproducir el error. Respecto a las técnicas para el levantamiento y especificación de requerimientos. a) Escoger un patrón arquitectónico de software [16]. 2. c) Determinar y diseñar las interfaces.Una vez establecidos los requerimientos. Evitar el uso de palabras o redacciones que puedan estar sujetas a varias interpretaciones. Corregir errores. a) Realizar testing con el usuario y encontrar errores [16]. 3. 2. se propone el uso de una matriz de trazabilidad entre la funcionalidad de software versus los requerimientos. a) Determinar el tiempo para desarrollar la actividad. considerando típicamente las fases que siguen al análisis de requerimientos. d) Identificar los objetivos de rendimiento de la aplicación. evita ambigüedades y es entendible por usuarios no técnicos. esta definición también va asociada a qué tecnología utilizar para el desarrollo de software.2. 54 . Ejecutar las actividades de desarrollo. e) Definir un prototipo arquitectónico de la aplicación [16]. Para ello. f) Verificar y corregir código. utilizando preguntas abiertas para obtener un panorama general del requerimiento y preguntas especificas para el detalle. CMMi establece como parte de su área de proceso de solución técnica la guía para afrontar esta problemática. Definir una arquitectura de software para la solución.

d) Realizar la aceptación del producto [16]. c) Determinar y diseñar las interfaces. d) Determinar los requerimientos y escenarios operacionales [17]. c) Corregir errores en caso de que se presenten. 55 . f) Identificar los objetivos de rendimiento de la aplicación. 4. b) Instalar la aplicación. Definir y seleccionar las componentes del producto. mediante diagramas [17]. Figura 15: Proceso de desarrollo de software con metodología ágil Para el caso de métodos tradicionales. a) Construir el instalador de la aplicación [16].e) Realizar testing del usuario y volver a iterar en caso de ser necesario [16]. Entregar el producto. 2. Desarrollar el diseño. En la figura 15 se muestra la representación del flujo del proceso. el proceso general es definido como sigue: 1. a) Crear alternativas detalladas de diseño de la aplicación [17]. b) Diseñar y seleccionar la arquitectura del sistema. e) Crear pruebas de concepto de la aplicación.

Implementar el diseño a) Escribir y revisar la documentación [17]. c) Corregir errores en caso de que se presenten. 3. b) Corregir el software en caso de presentarse errores. d) Realizar la aceptación del producto para su entrega [17]. b) Instalar la aplicación. En la figura 16 se muestra la representación del flujo del proceso.a) Revisar el diseño. 4. g) Verificar y corregir código. f) Realizar los tests unitarios. c) Definir los tests unitarios a aplicar. d) Construir el software [17]. h) Integrar los cambios. Integrar el producto a) Construir el instalador de la aplicación [17]. b) Crear y definir el tiempo de las actividades de desarrollo para implementar el diseño y la arquitectura [17]. Figura 16: Proceso de desarrollo de software con metodologías tradicionales 56 . e) Analizar el código.

Cabe señalar, que las actividades de ensamblaje y entrega de producto, son abordadas en CMMi bajo el proceso de integración del producto, en contraste con el método ágil, el que realiza la entrega dentro de su propio ciclo de desarrollo. Posteriormente se presentan las etapas de validación y verificación, donde el testing del software es realizado, lo que será revisado en el siguiente punto. En resumen, el proceso de desarrollo de software contempla las siguientes grandes etapas: 1. Definir la metodología de proyecto a utilizar: ágil o tradicional, de acuerdo a los criterios propuestos en la sección de administración de proyectos. 2. Seguir los procesos definidos anteriormente de acuerdo a la elección metodológica. Respecto a la definición de la tecnología a utilizar para el desarrollo de software, en la industria hay dos herramientas comúnmente utilizadas para el diseño y construcción de software empresarial, por una parte .NET de Microsoft y por otra J2EE de Sun Microsystems. Para optar por uno u otro, hay que tener en cuenta las siguientes consideraciones: 1. En la empresa existe software en ambas plataformas, sin embargo, las aplicaciones son en su mayoría .NET, donde el ambiente Windows es predominante. 2. Las aplicaciones J2EE corresponden a software propietario, adquirido a terceros, cuyo ciclo de desarrollo y mantenimiento se ve cubierto por los acuerdos de licenciamiento y soporte existentes. 3. Ambos entornos de programación presentan ventajas y desventajas, siendo las principales: a) J2EE presenta una mejor portabilidad de plataforma que .NET. b) J2EE es una tecnología más madura que .NET. c) .NET posee soporte para múltiples lenguajes de programación, con una arquitectura equivalente a la planteada bajo J2EE. d) .NET está especialmente orientado a la creación de servicios web, con una arquitectura clara y sencilla de clases para crear y distribuir estos servicios. e) Microsoft con su suite Visual Studio, establece una serie de prácticas de desarrollo de software que pueden ser aplicadas con métodos tradicionales y ágiles, en cambio Sun solo ofrece la plataforma, donde las prácticas son abordadas mediante entornos de programación de terceros. Entonces, .NET es la elección natural, debido a la predominancia histórica de las aplicaciones de este tipo dentro de la empresa y sus filiales y al soporte multilenguaje, lo que se traduce en mayor flexibilidad para la diversidad que existe actualmente. J2EE tiene mayor madurez pero es un único lenguaje, las aplicaciones actuales bajo esta plataforma son propietarias y por lo tanto no representan el problema para el proceso de desarrollo interno. Por otro lado, el intentar migrar las aplicaciones actuales a J2EE 57

sería demasiado costoso y por lo tanto carente de sentido ya que no aportaría valor a la empresa. Como valor agregado, el proceso de desarrollo establecido por Microsoft para la plataforma .NET contempla un framework para metodologías ágiles y otro orientado a métodos tradicionales, usando CMMi. De ambos, se tomaron los aspectos más relevantes para definir los procesos señalados anteriormente. 2.2.4 Proceso de Pruebas de Software Independiente del enfoque utilizado para desarrollar el software, las pruebas son consideradas como una etapa que debe ser realizada dentro del proceso de software. Dentro de la organización no existe un proceso formal de pruebas y tal como se menciono en el capítulo 1, son realizadas de acuerdo a la voluntad del programador o del jefe de proyecto. La idea del proceso de pruebas, es definir un marco de referencia simple, que permita la aplicación de metodologías de testing en forma permanente. El proceso de pruebas está directamente relacionado con las actividades de desarrollo y mantención de software y por lo tanto los artefactos de software son una entrada para este proceso. En CMMi se definen dos áreas de proceso que abordan la problemática, por una parte, la verificación, cuyo objetivo es asegurar que los productos de trabajo cumplan con los requerimientos especificados [30] y por otra la validación, cuyo objetivo es demostrar que un producto cumple con su uso propuesto cuando es instalado en el entorno propuesto [30]. Una manera práctica de abordar la verificación es realizar la revisión de pares [30], es decir, quien realizó el trabajo le cuenta la solución a un par, de acuerdo a un procedimiento documentado con el objetivo final de encontrar y anticipar errores y defectos. El proceso se puede definir de la siguiente manera: 1. Planificar la verificación. a) Establecer el ambiente de pruebas. b) Seleccionar los productos de trabajo que se verificaran. c) Establecer los casos de prueba de acuerdo a los requisitos del producto. d) Establecer los criterios de éxito de la verificación. 2. Realizar la verificación de acuerdo a los requisitos del producto. a) Identificar a los revisores y agendar la verificación. b) Revisar la visión del producto. c) Revisar el diseño del producto. d) Realizar las pruebas. 3. Registrar los resultados. a) Registrar resultado para cada caso de prueba. b) Registrar el éxito de la verificación y determinar acciones correctivas. 4. Preparar el informe de verificación. En la figura 17 se muestra la representación del flujo del proceso. 58

Figura 17: Proceso de pruebas con metodología ágil

En el caso de la validación, la idea es realizar el testing del software de acuerdo a casos y datos de prueba, se propone un proceso con las siguientes etapas: 1. Planificar el testing. a) Establecer el ambiente de pruebas. b) Seleccionar los productos de trabajo que se verificaran. c) Establecer la estrategia de testing. d) Establecer los casos y datos de prueba. e) Establecer los criterios de éxito de la prueba. 2. Ejecutar. a) Ejecutar el testing de acuerdo a la estrategia. 3. Registrar resultados. a) Registrar resultado para cada caso de prueba. b) Registrar el éxito de la validación y determinar acciones correctivas. 4. Preparar el informe de testing. En la figura 18 se muestra la representación del flujo del proceso.

59

60 . se propone utilizar el enfoque de caja negra.Figura 18: Proceso de pruebas con metodologías tradicionales Respecto a la estrategia de testing. se propone que el enfoque sea por proceso (escenario) de negocio más que orientarse por modulo [9]. el que está orientado a la construcción de los casos de pruebas a partir de las funcionalidades del sistema. junto con el análisis de valores límite para obtener los casos de prueba que se utilizarán en el análisis transaccional. esto se puede visualizar en la figura 19. Se propone utilizar la técnica de clases de equivalencia. realizar el análisis transaccional. Como no existe una definición metodológica respecto a la construcción de los casos de prueba y no existe mucha experiencia dentro de la organización. esto con el fin de garantizar que el proceso modelado dentro del software funcione de acuerdo a los requisitos y dentro de cada proceso.

junto con la administración y desarrollo de los requerimientos. es decir. la problemática es aun peor debido a la diversidad de software existente y a la especialización del personal por división de negocio. Se entenderá como mantención de software al proceso general de cambio de un sistema después de que ha sido entregado. Esto ya ha sido abordado en los procesos anteriores. el enfoque para definir este proceso.2. 2004. c) Mantención para agregar o modificar funcionalidades al software. que integra los procesos de solución técnica. será de acuerdo a solucionar la problemática para la provisión del servicio. Bajo el escenario de un servicio único para todas las filiales. b) Mantención para adaptar el software a un ambiente de operación diferente. 61 . una mantención sigue el mismo ciclo de requerimientos – desarrollo – pruebas. Diplomado en Gestión de Calidad de Software.5 Proceso de Mantención de Software En CMMi. 9 Fuente: Apuntes del curso “Técnicas de Prueba de Software”. por una parte se debe contar con una metodología eficiente de asignación de recursos y por otra. se debe contar con las definiciones adecuadas que permitan discriminar el alcance de una mantención. Por lo tanto. validación. verificación. Uno de los problemas del proceso de mantención es la asignación de tareas y prioridades al personal que realiza las mantenciones y el entendimiento de lo que es una mantención. Esto sugiere dos cosas. la mantención es vista como una etapa más del ciclo de vida del software. por ejemplo modificaciones o cambios de hardware que provoquen cambios en el software. Se definen tres tipos [28]: a) Mantención para reparar fallas de software.Figura 19: Diagrama de descomposición para el testing9 2.

se especializa en los procesos de negocio del cliente. 2. sin embargo. b) Por tipo de tecnología. Una manera rápida de calificar una actividad de mantención de un proyecto. es que en Chile. zona Sur (desde la VII Región hacia el sur). zona Centro (desde la VI Región hacia el norte). que en este caso. Otro antecedente. bodegas. entonces se propone la siguiente división: 1. La problemática es que el personal está especializado por división de negocio por lo que frente a un esquema global. Por lo tanto. Por lo tanto. Mantenimiento no SAP. Por ello se proponen dos opciones de especialización: a) Por proceso de negocio. Por ello. no será dividido por zona geográfica. visual basic. puntos de función. Mantenimiento SAP.Esta definición. es utilizar criterios de tiempo y costo. una mantención será calificada como proyecto. por ejemplo: ventas. vale decir. se determine que el costo de realizar la actividad involucre a una o dos personas por un tiempo superior a tres meses. formando grupos de trabajo por tipo de proceso. El problema de esto es que si una actividad de mantención consume mucho tiempo y recursos. sin embargo. etc. al no haber experiencia previa su uso y a la necesidad de responder rápidamente a los clientes. pero no es tan relevante la componente de negocio. vale decir. la asignación de tareas no es eficiente. no por tipo de proceso. por ejemplo. como elemento adicional diferenciaremos los proyectos de software respecto a proyectos de mantenimiento. c) Argentina y Uruguay. el mercado de las empresas proveedoras ofrece sus servicios por tipo de tecnología. b) Chile. será aquel que cambie un sistema después de haber sido entregado. por ejemplo: web. a) Chile. serán por zonas geográficas. aplicaciones SAP. 62 . puede transformarse en un proyecto. d) Perú y Brasil. La primera división por tipo de tecnología será para diferenciar las aplicaciones SAP del resto y como es de carácter corporativo y centralizado. por la tecnología característica del software. aplicaciones en forms. permite tener un marco global para una mantención. Podrían usarse también medidas de software. la opción b) parece la más adecuada para definir líneas de mantenimiento. etc. la aplicación podría resultar contraproducente en esta etapa. La segunda opción requiere de especialistas en las herramientas tecnológicas utilizadas en el software. sin embargo no establece alcance en cuanto a tiempo o recursos. cuando como resultado de la estimación de recursos. El problema de la primera opción es que requiere de personas con un amplio dominio de las herramientas tecnológicas. Un proyecto de software será todo aquel proyecto que implemente un sistema nuevo y un proyecto de mantención.

5. c) Crear una tarea de mantenimiento. Análisis y clasificación del requerimiento. a) Pruebas funcionales. y se define de la siguiente manera: 1. Modificación del software. el proceso de mantención es presentado en la figura 20. Paso a producción. a) Estimar tiempo y costo. es decir la programación. de acuerdo a la disponibilidad de recursos. 7. 6. b) Determinar si es un proyecto o no. 4. a) Determinar si es una mantención o no. Figura 20: Proceso de mantención del software 63 . donde se realiza el mantenimiento y tiene que ver con el proceso de cambio que es realizado sobre el producto. corresponde a la aplicación y uso de metodologías de desarrollo de software. 3. Pruebas de software. d) Asignar la tarea de mantenimiento. b) Clasificar el requerimiento. Tomando los antecedentes expuestos anteriormente y considerando las definiciones entregadas. Pruebas de aceptación del usuario.e) México. Recepción de un requerimiento de cambio a través del service desk. Estimación y asignación de recursos. 2. b) Aceptación. Desde el punto de vista de los procesos de software.

La ventaja. el proceso de gestión de incidencias se define de la siguiente manera: 1. provee un único punto de acceso. es decir. la gestión está centralizada y por lo tanto su costo es eventualmente menor. primero se debe definir la estructura y alcance que tendrá está unidad. Clasificación de los incidentes y soporte inicial. Existen tres estructuras básicas [22]: a) De tipo centralizado. sin embargo los agentes pueden estar distribuidos en distintas ubicaciones geográficas. el modelo centralizado requiere de una menor cantidad de personal para ser operado. es necesario la definición e implementación de un service desk. Basado en un fuerte componente tecnológico y de telecomunicaciones. Por otro lado. Para capturar y registrar los requerimientos o incidentes de los usuarios y por el tamaño de la organización. e) Distribución de los requerimientos de servicio. 64 . las que eventualmente pueden ser independientes entre sí. el service desk se encuentra distribuido en varias zonas geográficas.3 Procesos de soporte al servicio 2. Detección y registro de incidentes.3.2. es decir. que combina los elementos de las estructuras centralizadas y descentralizadas para proporcionar el servicio. minimizando el impacto en las operaciones del negocio y asegurando el mantenimiento de la disponibilidad y los niveles de servicio [26]. Respecto a las localidades en el extranjero. o por mecanismos de auto atención [19]. de otra zona geográfica. Ya definida la estructura del service desk. se logra fácilmente que el soporte sea específico para la zona. 2. que en los otros modelos no se incurren. Por lo tanto. los que pueden ser reportados directamente al service desk. independiente de su ubicación geográfica. pero en el mediano plazo se puede lograr el objetivo. es que al estar localizado geográficamente. b) De tipo descentralizado. por lo que en principio un modelo descentralizado podría ser la solución. Esto puede ser más lento que tener un service desk descentralizado. el holding se define como líder en costos. c) Virtual service desk. la elección es por una estructura centralizada en Chile ya permite una mayor optimización y control de los recursos. El virtual service desk se descarta como opción de solución ya que además introduce costos de comunicación y tecnológicos. Gestión de las solicitudes de servicio. La empresa posee filiales en Chile y Sudamérica. por correo. Para ello. el service desk atiende centralizadamente todas las llamadas de usuario de la organización. 3. además puede servir de respaldo en caso de que otro service desk. no se encuentre disponible. la especialización del soporte se puede obtener mediante entrenamiento. Otro elemento a considerar es que estratégicamente.1 Gestión de incidencias La gestión de incidencias tiene por objetivo restaurar la operación de un servicio.

a) Resolver el incidente. Cierre del incidente. b) Llamadas contestadas. h) Porcentaje de llamadas contestadas. que corresponde a la duración promedio de una llamada. d) Verificar que el incidente este resuelto. 5. d) Tiempo medio antes de contestar. 4. que corresponde al total de llamados recibidos por la central telefónica del service desk. g) Porcentaje de nivel de servicio. Solución y recuperación. que corresponde a las llamadas contestadas por los agentes del service desk. En la figura 21 se muestra la representación del flujo del proceso. Investigación y diagnostico del incidente [19]. se propone el uso de los indicadores habituales. c) Determinar si se trata de un problema. que corresponde a las llamadas perdidas o no contestadas por los agentes del service desk. b) Implementar acciones correctivas. c) Implementar acciones de recuperación. es decir: a) Llamadas recibidas. c) Llamadas abandonadas. 65 . b) Cerrar el incidente. a) Verificar la satisfacción del cliente. d) Escalar al siguiente nivel si es necesario. f) Porcentaje de llamadas abandonadas. a) Identificar la solución del incidente. que corresponde a la cantidad de llamadas contestadas antes de un periodo de tiempo. e) Tiempo medio de conversación.a) Determinar tipo de incidente. b) Determinar si es un incidente mayor. que corresponde al porcentaje de llamadas contestadas sobre el total de llamadas recibidas. Para la gestión. b) Determinar impacto y urgencia. sobre el total de llamadas. que corresponde al tiempo promedio en contestar una llamada por el grupo de agentes del service desk. c) Entregar soporte inicial. Los niveles de servicio del service desk. deben ser los mismos que se han definido en la sección de diseño de servicios. 6. que corresponde al porcentaje de llamadas que se abandonaron sobre el total de llamadas.

que es concerniente a la solución de problemas en respuesta a uno o más incidentes.3.Figura 21: Proceso de gestión de incidencias 2. 66 . para convertirla en un error conocido e iniciar la acción de mejora o corrección de la situación [26].2 Gestión de problemas La gestión de problemas es la búsqueda de la causa de una incidencia. Considera dos aspectos [26]: a) Reactivo. que no ha podido ser resuelta por el soporte estándar.

Este comité será integrado por un representante de cada unidad organizacional. Control de errores. En el caso de que un error no pueda ser resuelto.b) Proactivo. serán realizadas por un grupo de solución de problemas (GSP). Registro del problema y clasificación. o ítems de configuración que sufrieron cambios [21]. c) En caso de no encontrar la causa del problema. las provenientes de la infraestructura informática y el software [21]. b) Determinar las actividades para corregir el problema. Además. 3. quién se encargara de coordinar las actividades de corrección al interior de su unidad organizativa. b) Registrar los artefactos. b) Control de errores. Para definir el proceso. se han tomado los aspectos más relevantes de ITIL y que pueden ser de utilidad para la organización. equipos. para el cual deben elaborarse planes y actividades que permitan la corrección temporal o workaround. a) Detección de los incidentes clasificados como problema. a) Investigar y diagnosticar la causa del problema. c) Determinar el impacto y la urgencia en el negocio [21]. La gestión de problemas tiene directa relación con la gestión del cambio ya que los resultados de este proceso generan modificaciones en la infraestructura informática y como tales deben ser controlados y registrados. con el objeto de tener una base de datos con el conocimiento de los problemas. diagnosticar y solucionar el problema. d) Clasificar de acuerdo a lo determinado en el punto c. cuyo objetivo es transformar los problemas en errores conocidos. 67 . mientras la solución es encontrada [21]. a) Registrar los síntomas del problema y los detalles de la solución. define dos tipos de controles [21]: a) Control de problemas. cuyo objetivo es investigar. b) Verificar la eliminación del error [21]. 2. Las soluciones y planes serán registrados. que tiene relación con la identificación y solución de problemas y errores conocidos antes de que un incidente vuelva a ocurrir. escalar al proveedor en caso de ser necesario y realizar seguimiento. Investigación y diagnostico del problema. elaborar planes y actividades que permitan una solución temporal [21]. Cierre del problema. La definición es la siguiente: 1. el problema es calificado como un error conocido. considerando aspectos de infraestructura y software. 4. cuyo objetivo es resolver estructuralmente los errores conocidos a través del proceso de gestión de cambio. Las etapas del proceso. a) Implantar la corrección del problema mediante el proceso de gestión del cambio [21]. actividad que es parte del proceso. b) Detección de problemas desde otras fuentes. es decir.

3 Gestión de inventario y configuración La gestión de inventario y configuración provee la información sobre la estructura de tecnologías de información de una organización. 68 . Establece el control de la infraestructura. equipos de comunicación y servidores ya que su número y características son utilizados como dato para la facturación de algunos servicios. En la figura 22 se muestra la representación del flujo del proceso. impresoras. a) Analizar tendencias de problemas y determinar focos de acción preventiva [21]. notebooks. la evolución de los ítems de configuración en el tiempo y sus relaciones [26]. la que es utilizada por otros procesos y para la gestión [26]. Figura 22: Proceso de gestión de problemas 2. b) Revisar los problemas mayores y las acciones tomadas para su solución. 5.c) Verificar la satisfacción del cliente.3. d) Cerrar el registro del problema. Para el servicio de TI es imprescindible tener un inventario actualizado de equipos. Análisis proactivo y revisión de problemas. a través del monitoreo y mantención de la información de los recursos necesarios para la distribución del servicio. con el objeto de prevenir que vuelva a ocurrir [21]. principalmente PC.

Activar los seguros comprometidos. las fechas de inicio y termino del periodo de arriendo. c) Equipos de comunicación: 69 . la recopilación y mantención de los datos no puede ser realizada manualmente. Mantener la información. el registro de los cambios y configuración. hurto. el lugar físico donde se encuentra. tarjetas de red disponibles. modelo y tamaño del disco duro.  Características técnicas: CPU. un identificador que permita determinar si el equipo está sujeto a servicio técnico y el número del contrato de arriendo. las que no necesariamente pueden concordar con las fechas de recepción y devolución. Además. es necesario controlar los eventos que signifiquen perdidas o siniestros. PC y Servidores:  Marca y modelo del equipo. RAM. Validar que la información registrada sea la correcta. es decir registrar los cambios para la configuración. Otros datos de utilidad para mantener en el inventario son: características técnicas del equipo. deba al menos poseer la siguiente funcionalidad: 1. Por ello.  Marco y modelo del printserver según corresponda.  Software instalado. en el sentido de que todo evento sobre el equipamiento debe ser registrado en la medida que ocurra. modificación y baja del equipo. o por registro manual según sea el caso. presencia de arreglos de discos. es decir. Debido a la envergadura de la empresa. 4. mediante software ad-hoc. se propone que la herramienta. o siniestro de los equipos. robos. perdidas o siniestros.El principal problema con el inventario. es por ello que necesariamente se debe contar con una herramienta que permita mantener actualizada la información relevante para el inventario. ubicación y eventos tales como: hurtos. b) Impresoras:  Marca y modelo. El proceso requiere de cierta disciplina por parte de las personas que participan en el proceso. realizadas cada cierto tiempo. Recopilar la información de los equipos. La información puede ser mantenida a través del mismo software. puede modelarse en los siguientes pasos: 1. como el equipamiento es arrendado. en caso de robo. es tener la información actualizada y mantener el control sobre el ciclo de vida del equipo. sistema operativo instalado. otro hardware instalado. 2. la incorporación. Permitir la recopilación automática de los siguientes datos: a) Notebooks. quién lo tiene asignado. El proceso de inventario y configuración. En la figura 23 se muestra la representación del flujo del proceso. 3.  Cantidad de bandejas. mediante auditorias manuales.

Figura 23: Proceso de gestión de inventario y configuración 70 . es decir: hurtos. Marca y modelo. para cada equipo: a) Número de contrato de arriendo.  Tipo de equipo: switch. f) Fecha de recepción del equipo. e) Ubicación física.  Cantidad de puertas utilizadas y disponibles. robos. d) A qué persona o empresa se encuentra asignado. hub. 3. c) Número de serie. h) Fecha de finalización del periodo de arriendo. perdidas o siniestros. 2. firewall. j) Eventos. g) Fecha de inicio del periodo de arriendo. etc. i) Fecha de devolución del equipo. la que entenderemos por: planta o edificio y área del edificio o planta donde se encuentra. Permitir la edición y adición manual de los siguientes datos. b) Número de servicio. Permitir la emisión de informes de inventario.

2.3.4 Gestión del cambio El objetivo de la gestión del cambio es minimizar la interrupción de servicios ante cambios. Es decir, se deben asegurar los métodos y procedimientos estándares que se utilizarán para el manejo de los cambios en la infraestructura tecnológica. La gestión se debe realizar desde que se pidió hasta que finalizo [26]. La infraestructura debe ser separada en ambientes de desarrollo, ambiente de pruebas y ambiente de producción, el que definiremos, como el conjunto de hardware y software que es utilizado por la empresa para la ejecución de sus sistemas informáticos y para el cual se debe registrar y establecer una línea base, de manera tal que los cambios sean registrados sobre dicha configuración. El problema con el manejo de cambios, es que existe un escaso control sobre la plataforma de producción, por lo tanto, para esta etapa, el enfoque será la definición de un proceso de paso a producción, el que tiene como requisito previo, que el ambiente de producción sea cerrado y controlado por el personal que administre la infraestructura. El paso a producción es el proceso mediante el cual se instala en ambiente productivo las piezas de software y hardware requeridas para que una aplicación funcione. Entonces, hay que distinguir que un paso a producción tendrá características, actividades y alcances distintos de acuerdo a lo que se desea instalar. Para ello, se puede realizar una clasificación, de acuerdo al tipo de software que se coloca en productivo y al hardware. En el caso del software se distinguen los siguientes tipos: a) Aplicaciones que se instalan o modifican en equipos de usuarios, actividad que ha de ser realizada por técnicos de terreno. b) Servicios que se instalan o modifican en servidores en funcionamiento, cuya realización está a cargo de los administradores de la plataforma. c) Scripts de bases de datos, es decir: procedimientos almacenados, tablas, definiciones, etc., cuya realización está a cargo del administrador de la base de datos. d) Aplicaciones web, cuya realización está a cargo de los administradores de la plataforma. e) Otros, es decir, software no clasificado dentro de las categorías anteriores y cuya realización debe ser sancionada de acuerdo a los elementos que la integran. Para el caso del hardware, se distinguen los siguientes tipos: a) Hardware nuevo que es instalado en ambiente productivo. b) Modificación a hardware existente en ambiente productivo. Los criterios de realización del paso a producción dependerán de la disponibilidad de una ventana de tiempo para realizar la actividad y a las restricciones propias impuestas por políticas de la administración de la infraestructura, por ejemplo: restricciones de horarios o días, disponibilidad de recursos, etc. 71

Es importante señalar, que como elementos principales de la actividad, se debe definir el plan de paso a producción, el plan de reversa y un plan de contingencia para el caso en que se presenten problemas. Si hay hardware comprometido, además deben ser especificados los componentes nuevos o sujetos a cambio. En resumen, el proceso de paso a producción significa: 1. Que el desarrollador registra una solicitud de paso a producción, la que debe contener los programas, planes y justificación para poder ser realizada. 2. La solicitud es derivada por la coordinación del service desk, revisada y clasificada, de acuerdo al tipo de software o las actividades relacionadas con el hardware. 3. El paso a producción es agendado de acuerdo a las ventanas de tiempo disponibles, considerando las restricciones que existan en ese momento. Sin embargo, pueden haber excepciones, para afrontar incidentes, que signifiquen perdida de servicio, con posibilidad de detener procesos de negocio, o que tengan carácter de urgencia. 4. El paso a producción es realizado, en caso de presentarse problemas se escala con el desarrollador. 5. El resultado del paso a producción es informado al desarrollador. En la figura 24 se muestra la representación del flujo del proceso.

Figura 24: Proceso de paso a producción

72

Respecto a los equipos de escritorio, notebooks, impresoras y dispositivos que sean utilizados por los usuarios, pero que no son parte de la plataforma de producción, también se debe tener el control respecto a la configuración y sus cambios. Estos provendrán de incidentes de servicio y en general serán realizados por técnicos de terreno. Eventualmente, podría haber compra de hardware o software por lo que un ciclo de aprobación debe ser considerado. Entonces, se puede definir un proceso que aborde esta actividad, de acuerdo a lo siguiente: 1. Recepcionar el incidente de cambio. a) Determinar si es un cambio que requiere compra de hardware o software. b) Registrar elementos sujetos a cambio. 2. En caso de que el cambio signifique la compra de hardware o software, cotizar la realización del cambio e informar al cliente, quién deberá autorizar o no la compra. 3. Realizar el cambio. a) Coordinar con el usuario la fecha y hora del cambio. b) Registrar los cambios realizados. 4. Cerrar el incidente. a) Verificar satisfacción del usuario. En la figura 25 se muestra la representación del flujo del proceso.

Figura 25: Proceso de gestión del cambio para equipos de escritorio

73

se de de de Para mantener el orden y en concordancia con lo señalado en el proceso de paso a producción. construcción. diseño.5 Control y distribución de software y hardware El objetivo del proceso es la protección del ambiente productivo y sus servicios. las etapas de planeación. la problemática es definir que se va a considerar como control de versiones de software y cuáles son los aspectos relevantes para el registro de los cambios. Entonces. modificación y eliminación. respecto a sus fechas de creación. diseño. configuración y comprobación del hardware y el software para crear un repositorio de versiones para el ambiente productivo [26]. Luego. o diferencias por correcciones producto de defectos o errores. zzz . donde xxx corresponde al número de release o entrega. por parte de uno o más autores. Para el caso del software. configuración y comprobación ya fueron abordadas anteriormente. por lo que el enfoque para este proceso es respecto al control de versiones de los artefactos de software.2. se puede definir. un control versiones de carácter jerárquico desde el producto de software hasta los archivos código fuente que lo componen.3. Un cambio de funcionalidad es una nueva entrega. c) A nivel de módulos funcionales del software. un producto de software está compuesto de módulos propios que componen de archivos de código fuente y librerías externas. El proceso debe considerar las etapas de planeación. Se relaciona directamente con la gestión del cambio [26]. 74 . las que pueden ser terceros o construidas dentro de la empresa. a través del uso de procedimientos formales y revisiones. El número de revisión se incrementará respecto a la entrega de las modificaciones realizadas en el software con el objeto de corregir defectos pero sin cambio de funcionalidad. construcción. es liberado para su instalación en ambiente de producción. de acuerdo a diferencias de funcionalidad. se propone categorizar el código fuente según el tipo de tecnología. yyy. por parte de uno o más autores. por lo tanto una nueva versión. b) A nivel de cambios dentro del código fuente. yyy corresponde al número de revisión y zzz corresponde al número de sub-revisión. Respecto a la numeración de las versiones. es decir. Entenderemos por entrega al evento en que una pieza o producto de software. se propone utilizar un correlativo con el formato xxx. es decir un conjunto de archivos de código fuente que componen un módulo. modificaciones. El número de sub-revisión corresponderá a la entrega de modificaciones menores sobre una revisión del software y que no signifiquen cambio de funcionalidad. como se muestra en la figura 26. d) A nivel del producto de software. que implementa un grupo de requerimientos. En general. El control de versiones de software puede llevarse a cabo sobre los siguientes aspectos: a) A nivel de archivos del código fuente.

configuración y comprobación. c) Soportar múltiples usuarios y con capacidad de administrar la concurrencia sobre un archivo de código fuente. es el propio ciclo de gestión del cambio el que realiza el registro de la planeación. sobre todo si una pieza de código es modificada por más de una persona. d) Manejar el historial de versiones del código fuente y productos de software. f) Tener mecanismos de seguridad y roles que permitan salvaguardar el código fuente de accesos no autorizados. Las funcionalidades mínimas requeridas son: a) Permitir y llevar la trazabilidad de los cambios realizados sobre el código fuente.Es indispensable contar con un software para el control de las versiones. mantención. construcción. b) Permitir la jerarquización del código fuente de acuerdo a lo propuesto en la figura 26. e) Soportar el esquema de numeración de versiones propuesto anteriormente. 75 . Figura 26: Descomposición del producto de software para el control de versiones En el caso del hardware. sin embargo el diseño no es parte del proceso y por lo tanto se entenderá que es abordado como parte del diseño del ambiente operacional de un proyecto ya sea de software. o infraestructura.

Pero. contempla determinar los elementos críticos del negocio. se debe: 1. por lo tanto el resultado final para el cliente puede ser desastroso. que contemplen la recuperación y las acciones a tomar frente a la no disponibilidad de un servicio no es suficiente. Si el plan no satisface los requerimientos del negocio frente a la no disponibilidad. las plantas industriales de la empresa.2. disponen de poca holgura de tiempo. con el objeto de que frente a la contingencia.1 Gestión de disponibilidad y continuidad El objetivo de la gestión de la disponibilidad es asegurar que los servicios de TI tengan una disponibilidad sostenida en el tiempo. la gestión de disponibilidad y continuidad.4. En ese sentido. a un costo justificable y en satisfacción con los objetivos del negocio [26]. prevenir y monitorear los servicios. a) Determinar las funciones críticas del negocio. Por otro lado. Definir los niveles de servicios. Como proceso. si un servicio está disponible entonces no habría nada que hacer. reducir las vulnerabilidades. Las actividades mencionadas son transversales a los procesos que se han estudiado en esta tesis y por lo tanto son prácticas que han de ser adoptadas por las personas para el éxito de la organización TIC. Pero. b) Determinar los requerimientos de disponibilidad. es decir. entonces. Por ello. ¿Es suficiente hacer nada para mantener la continuidad de un servicio? De acuerdo a la experiencia práctica. la continuidad asegura que los servicios provistos por TI puedan ser recuperados dentro de los márgenes de tiempo requeridos y acordados con el negocio [26]. sino que también a nivel de la empresa cliente. la formalización e institucionalización del proceso. ¿Qué ocurre frente a la disponibilidad? A priori. desarrollar planes para gestionar la disponibilidad y la continuidad y formalizar con la organización tanto cliente como del servicio TIC [26]. administrar. no solo es a nivel del servicio TIC. en el que se revisen y aprueben los planes.4 Procesos de entrega del servicio 2. por la naturaleza y velocidad de sus procesos. Se debe considerar que las personas que ejecuten el plan deben estar entrenadas en las actividades que tengan que realizar. riesgos y producir planes de recuperación que estén integrados al negocio. 76 . alrededor de 3 horas antes de parar. la idea es asegurar la continuidad del negocio frente a un desastre o falla mayor. deben realizarse actividades para mantener la continuidad. No hacerlo significa no estar gestionando la disponibilidad y los niveles de servicio requeridos por el negocio. El desarrollo de planes para asegurar la disponibilidad y la continuidad. Específicamente. la que debe incorporar como parte de sus procesos de operación. los planes que sean definidos por la gestión de disponibilidad. es relevante la participación de un comité con representantes del cliente y del servicio TIC. entonces debe ser reformulado. solamente actúen. es que. Un elemento importante a considerar.

2. Proponer un plan para la disponibilidad [26]. a) Identificar los componentes de servicio más relevantes. b) Diseñar los servicios de acuerdo a los requisitos de disponibilidad. c) Definir riesgos y su mitigación. d) Definir el plan de recuperación. e) Definir el plan para la no disponibilidad. 3. Determinar las actividades para mantener la continuidad.10 a) Determinar las actividades de administración de la infraestructura. b) Determinar las variables relevantes para monitorear la continuidad. c) Establecer umbrales que permitan la prevención proactiva. 4. Formalizar el plan, capacitar, e institucionalizar mediante acuerdos de nivel de servicio operativos [26]. 5. Ejecutar los planes en caso de ser requerido. En la figura 27 se muestra la representación del flujo del proceso.

Figura 27: Proceso de gestión de la disponibilidad y la continuidad

2.4.2 Gestión del nivel de servicio De acuerdo a la figura 28, la gestión del nivel de servicio consiste en mantener y mejorar la calidad del servicio TI, a través de un ciclo continuo de acuerdos, monitoreo y reportes periódicos de estado de los servicios [26]. Para ello, la existencia de un comité

10

El detalle de estos temas, será revisado en la Gestión de Infraestructura.

77

de representantes de la empresa cliente y del servicio TIC es fundamental, para el consenso, definición, acuerdo, revisión y optimización de los niveles de servicio.

Figura 28: Ciclo de gestión del nivel de servicio11

De acuerdo a lo definido por la empresa, los acuerdos de nivel de servicio deben ser establecidos mediante contratos. Sin embargo, un acuerdo de nivel de servicio o SLA (Service Leve Agreement) no debe ser considerado solamente como un contrato formal, es más bien un consenso entre un proveedor y un receptor de servicios y que cubre los siguientes aspectos [3,23]: a) El acuerdo de servicios, vale decir la definición de lo que se entrega y sus niveles de satisfacción. b) La prevención de conflictos, de acuerdo a la promesa del proveedor versus la expectativa del cliente. c) La distinción entre el proceso para entregar el servicio y el proceso de negocio de la empresa que recibe el servicio. d) Las expectativas del cliente. Pero, ¿Qué elementos se deben considerar para especificar formalmente un nivel de servicio? Primero, debe establecerse un compromiso para la efectividad del servicio frente a los requerimientos del negocio. Segundo, los servicios deben especificarse claramente, se manera tal que sus indicadores tengan sentido para el cliente. Los costos del servicio deben ser claros y diferenciados de acuerdo a los distintos servicios que se están entregando. Finalmente, los acuerdos deben ser comunicados a toda la organización cliente y no permanecer en conocimiento de un grupo reducido de personas. En términos prácticos, un documento de acuerdo de nivel de servicios debe contener al menos los siguientes puntos [3]: 1. Propósito del servicio.
11

Fuente: Microsoft Corp. 2003. MOF: Service Level Management.

78

2. Descripción del servicio. a) Organización para la entrega del servicio. b) Disponibilidad del servicio. c) Manejo de cambios de servicio. 3. Niveles de servicio objetivos y medidas. a) Definición de la métricas de servicio. b) Definición de la manera en que será monitoreado el servicio. c) Definición de los reportes del servicio. 4. Costos del servicio. 5. Escalamiento. Tomando en consideración lo señalado anteriormente, el proceso de gestión del nivel de servicio se define de la siguiente manera: 1. 2. 3. 4. 5. 6. Levantar los requerimientos de servicio. Definir el catálogo de servicios. Definir los niveles de servicio requeridos por el negocio. Monitorear el cumplimiento de los niveles de servicio. Reportar al cliente los niveles de Servicios. Revisar los acuerdos de nivel de servicio.

En la figura 29 se muestra la representación del flujo del proceso.

Figura 29: Proceso de gestión del nivel de servicio

79

2.4.3 Gestión de finanzas TI El objetivo de la gestión de finanzas es identificar, calcular y gestionar el costo de entregar servicios de tecnologías de información [26]. El proceso lo podemos dividir en tres subprocesos: elaboración del presupuesto, contabilización, facturación y cobro de los servicios. Anteriormente, se definió el proceso de presupuesto y el marco para el costeo de los servicios. La tarificación para el cobro, corresponderá a determinar el precio final que se facturará a los clientes. En este caso, como el objetivo es que la utilidad de la empresa de servicios debe ser igual a cero, la tarifa será el costo de los servicios percibidos por las empresas. Para simplificar y evitar el re cálculo diario de las tarifas, el costo de los servicios fijos, variables y de valor agregado, será calculado anualmente de acuerdo a la oferta de mercado disponible en ese momento. Las variaciones, que pueden representar pérdidas o utilidad serán absorbidas o invertidas para el siguiente periodo fiscal. Respecto a la contabilización, facturación y cobro de los servicios, la empresa utilizará las normas establecidas internamente por el holding, las que no se mencionan por encontrarse fuera del alcance de esta tesis. Como proceso, la gestión de finanzas se puede definir de la siguiente manera: 1. 2. 3. 4. Recepción y contabilización de facturas de proveedores. Prorrateo (si corresponde) de las facturas de proveedores. Aprobación de pago facturas de proveedores. Recopilación y valorización de las horas hombre trabajadas en servicios sujetos a ese ítem de costo. 5. Elaboración de ítems de facturación para cada empresa que percibió servicios. 6. Facturación, de acuerdo a las normas establecidas internamente. 7. Cobranzas, de acuerdo a las normas establecidas internamente.

En la figura 30 se muestra la representación del flujo del proceso.

80

El proceso involucra.1 Gestión de capacidad del negocio La gestión de la capacidad del negocio tiene relación con asegurar que los requerimientos futuros de servicio.4. 2. el monitoreo del rendimiento de los servicios y la infraestructura que los soporta. el análisis de los resultados del monitoreo. conforme a los requerimientos de la empresa [18]. tiene por objetivo asegurar que la infraestructura tecnológica sea acorde a las demandas y crecimiento del negocio. sean considerados y entendidos y que la capacidad 81 .4 Gestión de capacidad La gestión de capacidad.4. Existen tres ámbitos que han de ser abordados: la gestión de la capacidad del negocio.4.Figura 30: Proceso de gestión de las finanzas 2. la gestión de la capacidad de los servicios y la gestión de la capacidad de los recursos [18]. el tuning de los recursos. el pronóstico de acuerdo a la demanda y la confección de un plan de capacidad. a un costo justificable [26].

la función debe ser cubierta. con la toma de requerimientos del negocio y el aseguramiento de que los niveles de servicio comprometidos son cumplidos. 82 . Evaluar económicamente el requerimiento.4. de asegurar que los niveles de servicio son cumplidos [18]. Implementar de acuerdo a las fechas establecidas. 3. computadores de escritorio (incluyendo notebooks). el servicio TIC. de manera tal. Diseñar la configuración para soportar el servicio.requerida para soportarlos sea planificada e implementada. el uso optimo de los recursos de hardware y software. Identificar los requerimientos de servicio y acordar niveles de servicio. estos son: servidores. de manera tal de mantener y cumplir con los niveles de servicio acordados [18]. patrones de comportamiento y peaks. mediante la relación directa con el cliente. la gestión de capacidad de los recursos. Como parte del diseño organizacional. Derivado de lo anterior. Por otro lado. identificar y entender el uso de recursos. de acuerdo a la planeación que sea establecida [18]. Hay que notar.2 Gestión de capacidad de los recursos y servicios El objetivo de la gestión de capacidad de los servicios es. se presenta dicha división. tiene relación con la identificación y comprensión de la utilización de cada componente de la infraestructura tecnológica. que componen los servicios. 4. la composición tecnológica de cada servicio. con el objeto de definir un marco para las variables que han de ser consideradas para determinar la capacidad. es decir. Por lo tanto. impresoras y dispositivos de comunicaciones y de red. 2. debe proveer los mecanismos para: 1. que existen recursos tecnológicos comunes. de los servicios. En la tabla 16.4. 2. es necesario entender. Lo que asegura.

la variable de decisión.Tabla 16: Componentes tecnológicos de los servicios Para cada uno de los componentes señalados. una serie de indicadores que describan su comportamiento. 18 y 19 se han categorizado los recursos tecnológicos con sus correspondientes indicadores y 83 . En las tablas 17. implica una no disponibilidad. el problema se encuentra en determinar las variables que tienen directa relación con la disponibilidad del recurso tecnológico ya que la falta de capacidad para afrontar una demanda de uso. teniendo en consideración. Entonces. debiera reducirse a la disponibilidad. de acuerdo al tipo de servicio. que los SLA definidos tienen relación con la disponibilidad y cumplimiento de compromisos. los recursos de tecnología son utilizados transversalmente y apoyan la consecución del cumplimiento de compromisos. porque independiente del tipo de servicio. se puede establecer. En estricto rigor.

criterios para determinar la no disponibilidad. Empresa Forestal. 2005. se han agrupado ya que. los indicadores son los mismos. Estudio de rendimiento de un sistema de ejecución de manufactura. 84 . Los servidores y computadores de escritorio. Chile. porque el sistema operativo que utilizan es de similares características. Tabla 17: Indicadores de capacidad de servidores y PC12 12 Fuente: Documento Interno.

a la necesidades del negocio. hay que distinguir entre la proyección o pronóstico de uso frente a la predicción.Tabla 18: Indicadores de capacidad para impresoras Tabla 19: Indicadores de capacidad de equipos de comunicación Respecto a la planeación de capacidad para afrontar una demanda de uso. La primera. tiene relación con la estimación del uso en el corto plazo. La segunda. se pueda predecir el comportamiento y por lo tanto. para que frente a escenarios de carga distintos. que permitan la adecuación del servicio. el establecimiento de planes. 85 . con el objeto de determinar acciones correctivas en el día a día y entregar tendencias de lo que está ocurriendo con el servicio. se refiere al análisis del comportamiento del servicio y a la obtención de un modelo lo suficientemente repetible.

Cláusula de arbitraje. Desde el punto de vista del proceso.4. Por ello la administración de proveedores. Modalidad de las comunicaciones para efectos del contrato. Condiciones de término del contrato. para la homologación. forma de pago y reajuste de los servicios. los que se construyen de acuerdo al caso particular y que no se abordarán por encontrarse fuera del alcance de esta tesis. se puede realizar mediante técnicas de regresión lineal. Cláusula de revisión de los servicios. mantener un inventario de proveedores y su impacto o relación con los servicios. b) Firmar el contrato.La proyección de la carga de trabajo. 2. El marco general definido por la empresa. Declaración de confidencialidad de la información. evaluar y controlar el desempeño de acuerdo a criterios establecidos y cuantificables. 86 . Declaración de capacidad e idoneidad del tercero para proveer el servicio. se debe asegurar la calidad de la relación. Se propone la utilización de la suavización exponencial ya que es simple y presenta menor varianza respecto a las otras técnicas. es que la relación sea de largo plazo y con carácter de socio estratégico. Administrar el contrato. Especificación. contempla que un contrato de servicios de terceros debe contener al menos: a) b) c) d) e) f) g) h) i) j) k) l) m) n) Objeto del contrato. 2. La predicción de la carga de trabajo. Responsabilidad por accidentes y daños y seguros. Garantías. es determinada mediante modelos de simulación o modelos analíticos basados en redes de colas (queuing networks). Una de las premisas básicas de la empresa para su relación con los proveedores. En particular. a) Acordar servicios y tarifas. las actividades propuestas son: 1. tiene que ver con el ordenamiento y homologación de los contratos de servicio que se encuentran distribuidos a través de todas las filiales y el cumplimiento de los niveles de servicio y contratos acordados. Niveles de Servicio. promedios móviles y suavización exponencial. precio.5 Gestión de proveedores El objetivo de la gestión de proveedores es garantizar un uso eficiente de los proveedores de servicios internos y externos de TI. higiene y seguridad de la empresa. Vigencia del contrato. Declaración de cumplimiento de las normas de comportamiento. de acuerdo a los niveles de servicios comprometidos con el negocio [26]. Oferta comercial del servicio. Establecer el contrato.

se estableció un marco del proceso para la administración de proveedores. a) Registrar el cumplimiento de acuerdo a las métricas propuestas en el diseño de servicios. 87 . cada área de la organización es un receptor y proveedor de servicios de una o más áreas. c) Elaborar ranking de proveedores de acuerdo a su comportamiento. b) Comunicar a la organización el grado de cumplimiento. OLA). Por otro lado. ITIL plantea además la gestión de proveedores internos. b) Realizar seguimiento al cumplimiento del servicio. c) Solicitar modificaciones a los servicios de acuerdo a lo que se estipule en el contrato. Gestionar el cumplimiento de los contratos de los proveedores. d) Terminar el contrato de los proveedores que no tengan buen comportamiento de cumplimiento de contrato.a) Realizar seguimiento a los niveles de servicio acordados. de manera tal que los servicios entregados por la organización se encuentren dentro de los niveles comprometidos con los clientes. El objetivo final es establecer niveles de servicio operacionales (Operational Level Agreement. En la figura 31 se muestra la representación del flujo del proceso. donde el supuesto era que los proveedores son externos. es decir. Figura 31: Proceso de Gestión de Proveedores Con lo anterior. 3.

sobre el cual se pueden realizar operaciones de incorporación. pensando en que el cumplimiento promedio particular de los niveles asegura el cumplimiento global. Los OLA definidos. 3. definiremos tres tipos de OLA: 1. de acuerdo a la tabla 20. Pero. Entonces. para los servicios fijos es necesario especificar OLA particulares. OLA de Reparación. OLA de Cambio. OLA de Incorporación. como el nivel de servicio con que se realizan las reparaciones o reposiciones a los servicios. 13 Fuente: Microsoft Corp. como el nivel de servicio con que se cambian las configuraciones del servicio. Tabla 20: Diferencias entre SLA y OLA13 Para el caso de los servicios variables y de valor agregado se puede utilizar el mismo indicador de SLA como OLA.En principio. son presentados en la tabla 21. ya que están orientados al cumplimiento de compromisos de personas. como el nivel de servicio con que se incorporaran elementos nuevos al servicio. 2. Sin embargo. MOF: Service Level Management. cambio y reparación de elementos de servicio. 88 . los OLA debieran ser los mismos indicadores definidos en los SLA. 2003. existen diferencias entre ambos conceptos que deben ser consideradas. entre el cliente y el servicio. pensando en que en algunos casos se trata de hardware.

Tabla 21: OLA para servicios fijos 89 .

Las actividades propuestas. y el segundo a la creación y/o mejoramiento de las soluciones. 2. Los procesos de soporte técnico y deployment. actividades diarias de soporte y mantenimiento de la infraestructura. en los que se aborda el (la) [26]: a) Diseño de la infraestructura y planificación estratégica. e) Realizar pruebas. c) Determinar el plan de pruebas. por lo tanto no se revisará. que a diferencia del software. 3. Realización del proyecto de infraestructura. han sido abordados anteriormente. son más simples ya que no hay construcción de aplicaciones. El primero. Levantamiento de necesidades. es decir. En la figura 32 se muestra la representación del flujo del proceso. relacionado con la implementación y puesta en marcha de las soluciones tecnológicas y del negocio. a) Realizar la ingeniería de detalle. 90 . Aprobación de la solución por parte del comité de TI. b) Construir la solución. b) Deployment. el desarrollo de proyectos de infraestructura. consistente en la estructuración y apoyo a otros procesos para garantizar la entrega del servicio. Respecto al diseño y planificación. Determinar la solución y la evaluación técnico-económica. basado en una estrategia de largo plazo. solo parametrización de productos. c) Operación.5 Procesos de gestión de la infraestructura y seguridad 2. 4. existen dos aspectos a considerar.1 Gestión de infraestructura La gestión de la infraestructura está definida como un conjunto de procesos. pero complejos en cuanto a la integración a la plataforma. primero el relacionado con los modelos de administración y arquitectura que sean más adecuados a las necesidades del negocio. es decir la creación y/o mejoramiento de soluciones a través del tiempo.5.2. como parte del escalamiento en la gestión de incidencias y de problemas y el segundo como el proceso de paso a producción definido en la gestión del cambio. d) Gestionar los riesgos del proyecto. 5. para un proyecto de infraestructura son: 1. d) Soporte técnico. es decir. Puesta en productivo (integración a la plataforma).

De acuerdo a la figura 33. 2005.Figura 32: Actividades generales de un Proyecto de Infraestructura Desde el punto de vista del modelo de gestión. es útil considerar una jerarquización de los elementos que se pueden abordar. administración de seguridad y administración de infraestructura. los elementos de gestión se encuentran divididos. en actividades de operación. de manera tal de establecer las capas fundamentales sobre las que se desarrolla la gestión de la infraestructura. Figura 33: Jerarquización de las actividades de Infraestructura14 14 Fuente: Microsoft Corp. control y monitoreo. MOF: Network Administration. desde lo operativo a lo táctico. 91 .

es decir. Administración de tipo “follow the sun”. no se vean afectados los procesos de negocio y los servicios básicos de red de la empresa cliente. que frente a perdidas de servicio. Los servicios localizados deben permitir autonomía de manera tal. La ventaja de una gestión centralizada. donde la administración y la operación es transferida entre cada unidad de acuerdo a horarios diurnos de trabajo. Datacenter distribuido y administración centralizada. es que se mantiene el control general de la plataforma. es decir datacenters distribuidos entre distintas localidades geográficas en el mundo.1 Administración de la Infraestructura Para administrar la infraestructura. un criterio para decidir entre lo que se encontrará centralizado y lo que será particular a cada localidad.2. La centralización debe ocurrir cuando más de dos empresas tengan necesidades equivalentes y no haya impedimento para la operación normal. Datacenter distribuido y administración distribuida. Para ello. 92 .5. Los servicios de infraestructura son los relacionados con las funcionalidades básicas de red y aplicaciones. Datacenter distribuido y administración centralizada / delegada. de acuerdo a la disponibilidad de servicios requerida por los negocios. que frente a pérdidas del servicio WAN. El modelo más apropiado es tener una gestión centralizada y datacenters distribuidos. licencias y consolidación. Tabla 22: Descripción de los servicios de infraestructura Respecto a la arquitectura de provisión de servicios y considerando que el holding es distribuido geográficamente. las que son descritas en la tabla 22. puede haber operaciones que requieran la intervención local. se producen ahorros ya sea por cantidad de personas. no se paralice una empresa. conviene definir. en vez de delegar la administración la actividad puede ser ejecutada por un técnico en terreno y supervisada por un administrador central. Sin embargo.1. existen cinco modelos básicos de administración [20]: a) b) c) d) e) Datacenter centralizado y administración centralizada.

Las variables de monitoreo pueden ser clasificadas en las que son propias del servicio y las que son propias del servidor en donde es ejecutado dicho servicio. una definición de las variables típicas de monitoreo de un servidor bajo ambiente Windows y sus umbrales de operación. d) El uso de software para proteger el equipamiento.1. por ejemplo: antivirus. e) La política de respaldo y recuperación de la información. respecto a: a) La arquitectura y diseño técnico de las soluciones de hardware.1. para gestionar la capacidad. en la tabla 23. etc. 2. b) Equipamiento a utilizar de acuerdo al tipo de aplicación. disponibilidad y recuperación. con el fin de normar y establecer lineamientos y entradas claras al proceso de planeación estratégica. en cuanto a reglas de tráfico. de acuerdo a los procedimientos de operación que se definan. Cabe señalar.5. se presenta. por lo tanto son una entrada a dicho proceso. priorización. 93 .5. antispyware. que las variables definidas constituyen una descomposición de servicios. que es requerida. c) La administración de las comunicaciones. no se revisarán las variables de los servicios. para los proyectos de software. ambiente.3 Monitoreo y Control de Servicios El monitoreo y control de servicios corresponderá a la revisión periódica de indicadores relacionados con los servicios de infraestructura [24]. 2. a modo de ejemplo. generando alarmas dirigidas al administrador cuando algún indicador se encuentre fuera de rango por un cierto periodo de tiempo. El administrador deberá realizar las acciones que reestablezcan la operación normal. en el proceso de gestión de seguridad.2 Administración de la Seguridad La administración de seguridad se revisará más adelante. Sin embargo. o software. Para ello es conveniente utilizar software que permita realizar la actividad automáticamente. Por la extensión del tema. la administración de la infraestructura define las políticas y estándares.Finalmente.

Empresa Forestal. MOF: System Administration. soporte y mantenimiento de los servicios. Para los 15 Fuente: Documento Interno.1. Chile.4 Actividades de Operación La operación de la infraestructura corresponde a las actividades diarias de administración. debe estar asociada a procedimientos con el fin de asegurar que sean prácticas que se realicen a través del tiempo. 2002. 2005.5.Tabla 23: Variables de monitoreo de un servidor15 2. Tabla 24: Actividades de operación habitual de la infraestructura16 Cada una de las actividades mencionadas. En la tabla 24. 16 Fuente: Microsoft Corp. se proponen las actividades que debieran ser habituales. Estudio de rendimiento de un sistema de ejecución de manufactura. 94 .

se propone el siguiente marco: 1. a) Acordar una visión compartida de la seguridad y el compromiso de los terceros relevantes. control. se puede establecer un marco para la gestión de la seguridad y cuyo resultado sea el establecer la visión.5. para la gestión de seguridad. Establecer un proceso de monitoreo y auditoria de la seguridad. 4. b) Identificar debilidades de los sistemas periódicamente. el proceso. b) Identificar los requerimientos de seguridad de la organización. En ese sentido. Establecer un proceso de gestión de riesgos de seguridad. a) Identificar ataques potenciales y problemas de seguridad. Dentro del holding. Para el caso de las aplicaciones. que debe ser parte de la administración de la infraestructura. se propone abordar los siguientes puntos como agenda inicial: 1. c) Implementar los mecanismos de control. 2. c) Entregar reportes periódicos de los problemas encontrados. a) Determinar los mecanismos de control de la seguridad. c) Identificar los niveles de seguridad para los datos de la organización. De todas maneras. gestión e implantación de las políticas de seguridad definidas para las aplicaciones (software) e infraestructura [26]. mediante la definición de políticas y la implementación de dispositivos firewall. b) no SAP. deben incorporar las políticas de seguridad como un requisito funcional más y deben entregar herramientas de administración de perfiles para acceder a las funcionalidades y los datos. las revisiones y las políticas. 3. las que se pueden encontrar en los sitios web de dichas compañías. d) Implementar revisiones periódicas de la política de seguridad.2 Gestión de seguridad El objetivo de este proceso es la definición. a) SAP. Establecer una política de seguridad para la organización. El desarrollo de las políticas y los mecanismos de control han de ser definidos una vez que el área respectiva comience a funcionar. Definir la política de seguridad de aplicaciones. Establecer un proceso de respuesta frente a incidentes.productos Microsoft y Oracle. es continuo en el tiempo. 2. 2. existen guías ya definidas. Como primer paso. b) Revisar periódicamente los riesgos de seguridad. la seguridad solo ha sido abordada desde el punto de vista de acceso desde redes externas. Por lo tanto no existe desarrollo previo. 95 . los mecanismos de control. Definir y establecer la política de seguridad de la organización. las áreas de mantenimiento y de desarrollo de software. Entonces.

se propone la aplicación del proceso marco definido para la gestión. 96 . Implementar las políticas de seguridad definidas. 3. d) PDA. c) PC y notebooks. e) Impresoras. b) Servidores. Una vez realizadas las actividades. 4. a) Dispositivos de red. Definir la política de seguridad del hardware.c) Shop Floor (Piso planta).

se presentan inconvenientes adicionales a ser considerados. con oficinas comerciales. con oficinas de filiales. con plantas productivas. Gestión de la calidad. Temuco. Soporte a usuarios. la estructura organizacional a definir debe ser capaz de soportar los servicios y procesos mencionados en el capitulo anterior. Un segundo elemento relevante es considerar las funciones básicas de TI. Santiago. Argentina. Servicio al cliente. con plantas productivas. Esto se consigue a través de la segmentación o división del trabajo [11]. Mantención de software. Los focos de localización son: En Chile: a) b) c) d) e) f) g) h) Antofagasta. con oficinas comerciales. 97 . personal y oficinas del holding. Gestión de la infraestructura TI. con plantas productivas. es referente a la integración y multiplicidad de los negocios del holding. En el extranjero: a) b) c) d) e) Perú. Coquimbo. oficinas centrales y de filiales del holding. Talca. con plantas productivas. Los Ángeles. se puede decir que son las siguientes: a) b) c) d) e) f) g) Gestión de la relación comercial con el cliente. con oficinas comerciales. Brasil. Desarrollo de proyectos de software.Capítulo 4 – Organización 1. con una oficina comercial. los que están agrupados por divisiones de negocio y que en su conjunto definen una cadena de valor. con plantas productivas y oficinas comerciales. que en términos generales. Nacimiento. Sin embargo. México. Para este caso. Un primer problema es la distribución geográfica de las plantas. Estructura Organizacional. Uruguay. con oficinas de filiales. Concepción. con plantas productivas. con plantas productivas. Las organizaciones son grupos de personas que buscan el logro de un propósito común. Un tercer punto.

De aquí es que. De acuerdo a la figura 34. las que a nivel de procesos son equivalentes. se propone la opción 2. supone un problema ya que en un esquema de servicios. En el caso de soporte. a continuación. se tienen seis subgerencias: calidad. infraestructura y calidad. opción 1 Un problema de esta organización es por un lado. servicio al cliente. proyectos. vale decir. Figura 34: Organigrama general. Esto lleva a concluir. las decisiones son tomadas por Gerentes y Subgerentes. plantea tener 5 unidades funcionales: calidad. lo esperado es que las personas sean capaces de tomar sus propias decisiones de acuerdo a un marco de atribuciones funcionales. Esto nos lleva a las siguientes opciones de organización para el primer nivel. existen limitantes en cuanto al enfoque con que las decisiones son tomadas. e infraestructura. La unidad o subgerencia de software se hace cargo de los proyectos de software y las 98 . Opción 2: 1 Gerencia y 5 Subgerencias funcionales Esta opción. relación comercial con el cliente. básicamente porque es un servicio que impacta directamente al usuario final en cuanto a la satisfacción de requerimientos básicos relacionados con herramientas informáticas. infraestructura y mantención. La manera de funcionamiento del holding es altamente jerarquizada. servicio al cliente.Culturalmente. 1. software. tiene relación con las funciones básicas de tecnologías de información. proyectos de software. mantención de software.1 Primer nivel organizacional El primer nivel de gestión. con el benefició de que todo el ciclo de vida del producto de software se mantiene bajo una sola responsabilidad. presentada en la figura 35. relación comercial con el cliente. que podría ser mejor tener una sola unidad que se haga cargo. soporte. que desde el punto de vista funcional gestione los proyectos de software y realice las mantenciones. bajo esta opción. Opción 1: 1 Gerencia y 6 Subgerencias funcionales. vale decir: relación comercial con el cliente. servicio al cliente. es claro que puede ser integrada bajo la función de servicio al cliente. la cantidad de subgerencias y por otra el tener dos unidades organizativas para atacar el problema de los procesos de software: proyectos y mantención. Por lo tanto. desde la perspectiva de orientación al cliente y la oportunidad del servicio.

Todo esto nos lleva a la opción 3. Una manera de resolver el problema. La decisión. se puede decir que la mantención es un servicio que impacta directamente la expectativa del usuario. facturar servicios y administrar contratos. sería razonable incorporar el mantenimiento de corto plazo como parte de la función de servicio al cliente. 99 . opción 2 Sin embargo. se basa en que sería más aprovechable esperar a que la organización se encuentre en régimen por uno o dos años. es necesario incorporar la función de finanzas TI. Una restricción que ha impuesto la empresa. es pensar en que el mantenimiento surge como un requerimiento de cambio. Bajo este enfoque. En ese sentido. e incorpore los proyectos de mantención (mantenciones de largo plazo) como unidad especializada. Por otro lado. el ciclo de vida del producto se mantiene bajo una sola responsabilidad. en el capítulo 6.mantenciones. es no incorporar en esta etapa una unidad funcional de calidad. esta organización tiene el siguiente problema. En todo caso. por ejemplo. Figura 35: Organigrama general. para un producto de software que se encuentra en funcionamiento y que la línea de tiempo para realizar las adecuaciones es de corto plazo. por la integración con la mesa de ayuda (que recibe el requerimiento) y por el directo impacto sobre el usuario final. pero semánticamente no sería entendido por los clientes. debiera ser tratada bajo ciertas condiciones que manejen dicha variable. por parte de un usuario. lidere los proyectos de manera integral. antes de pensar en abordar el tema durante el proceso de cambio. que se describe a continuación. por lo tanto. es claro que debe ser una unidad funcional aparte. por lo que. tal como se dijo anteriormente. si no que hay otros elementos y entidades de la organización que participan. si hubiera un proyecto en el que no solamente sea software el involucrado. cuya conclusión final plantea la creación de una unidad funcional de calidad. se plantea un plan de mejora de software. sino que también. que considere no solamente los aspectos de software nuevo. ¿de quién es la responsabilidad? La respuesta no es clara. Posiblemente se podría normar la responsabilidad con un procedimiento. Para el caso de proyectos. que en este caso juega el rol de controlar la gestión del área. por lo tanto debe ser parte del staff del Gerente.

esta opción. 1. La agrupación por zonas geográficas. Los Ángeles y Nacimiento. que comprende. es natural pensar agrupar Argentina con Uruguay.2 Segundo. servicio al cliente. opción 3 De las opciones planteadas. se tiene la relación comercial con el cliente. que comprende. 100 . bajo. entonces. Aparentemente. e infraestructura. Talca. resulta más fácil plantear una organización por división de negocio. proyectos. Santiago y las oficinas comerciales del norte del país. sin embargo esto es una limitante ya que el personal debe especializarse y focalizarse en dichas divisiones. Para el extranjero. resulta más conveniente ya que tiene la facilidad de que la función de TI no se ve afectada por la especialización en una división y permite orientarse a los clientes y los procesos que son transversales al holding de empresas. Básicamente. la que más ventajas tiene.Opción 3: 1 Gerencia y 4 Subgerencias funcionales De acuerdo a la figura 36. la especialización por negocio no es beneficiosa. Temuco. lo que desde el punto de vista de gestión de recursos limita la posibilidad de redistribuir en caso de ser necesario. en términos de simpleza y agrupación de funciones. las funciones se han agrupado y simplificado. tercer y cuarto nivel organizacional Los siguientes niveles organizacionales tienen un carácter táctico-operativo. Concepción. b) Chile Zona Sur. Por lo tanto es la que se utilizará para la organización de TI. No existe la función de calidad. Figura 36: Organigrama general. Otra opción es aprovechar la distribución geográfica del holding. que son los que finalmente entregan el servicio a las empresas. Podemos distinguir las siguientes zonas: a) Chile Zona Centro. Perú con Brasil y México aparte. es la opción 3.

lo que se puede visualizar en la figura 37. incorporando jefaturas de zonas: centro. 1. Toma de requerimientos y expectativas de los clientes. Entrega a los clientes de los planes y servicios de TIC con la calidad requerida y acordada con el Negocio.1 Subgerencia Relación Comercial Cliente En el caso de esta subgerencia. es decir relación comercial y servicio al cliente. se incorpora un recurso de staff de la subgerencia. la agrupación se ha realizado por zona geográfica. En el caso de proyectos e infraestructura. se planteará geográficamente. e internacional. 101 .En consecuencia. Por lo tanto la especialización puede plantearse por procesos y/o tecnologías relevantes.2. sur. Administración de los Niveles de Servicios. encargado de la planificación global y gestión del servicio. Además. la organización para las subgerencias que tienen directa relación con los usuarios. se pueden considerar como unidades centrales de apoyo y servicios. Figura 37: Organigrama subgerencia relación comercial cliente Las funciones que debe desempeñar esta unidad son las siguientes: a) b) c) d) Planificación del Servicio TIC.

i) Actuar como representante del negocio en la evaluación de impactos de cambios que se produzcan en la infraestructura TIC y sus servicios. l) Análisis de impacto al negocio ante desastres que afecten los servicios TI. h) Identificar. n) Representar al servicio. b) Definir. 1. m) Invocación de planes de contingencia y la relación con las unidades de negocio ante un desastre que afecte los servicios TI. consta del analista de demanda y divisiones por zonas geográficas. a través de un catálogo de servicios. especificar. o) Evaluar el desempeño de los proveedores de TI respecto de su impacto en el servicio TI. negociar y recopilar los acuerdos de nivel operacional con las unidades de TI. g) La planificación de los servicios y del seguimiento de este plan. El área de mantención. e) Definir.2. k) Proveer información necesaria de la prestación del servicio TI a control de gestión TI. c) Velar por mantener una relación equilibrada entre las demandas de los clientes y el costo del servicio. d) Definir. que entrega los servicios de soporte de primer. junto con el Gerente TI. salvo SAP que es de carácter corporativo. seguir y reportar los acuerdos de nivel de servicio con los clientes.2 Subgerencia Servicio al Cliente Servicio al cliente cuenta con la mesa de ayuda (service desk). 102 . se encarga de las mantenciones de corto plazo. En la figura 38 se muestra la representación de la subgerencia. evaluar y canalizar los requerimientos de los clientes respecto de nuevos servicios o funcionalidades de los sistemas de información.Las responsabilidades son: a) Ser el representante de TI ante las filiales del holding. Se hace la distinción entre aplicaciones SAP y el resto ya que SAP es el ERP de carácter corporativo. por lo tanto se ha incorporado esta figura a la estructura. segundo nivel y aplicaciones. f) La mejora continua de los servicios. capturar. Soporte consta de técnicos de terreno que atienden los requerimientos de los usuarios que les hayan sido derivados desde la mesa de ayuda. negociar. j) Mantener el inventario y configuración de los ítem relacionados a los acuerdos de nivel de servicio y planificación. ser el representante de las filiales del holding ante la gerencia de servicio TI. Nuevamente. el primer criterio para organizar es la zona geográfica ya que se tiene un directo impacto sobre los usuarios. mantener y difundir los servicios.

d) Responsable del seguimiento.Figura 38: Organigrama subgerencia de servicio al cliente Las funciones de la subgerencia son: a) b) c) d) e) Atención de usuarios (Service Desk). Mantención de corto plazo de aplicaciones. b) Responsable de recomendar y asesorar a la unidad de relación comercial con el cliente de los niveles de servicios que pueden ser acordados para la atención. Las responsabilidades son: a) Proveer de un punto único de contacto entre el servicio y sus usuarios. Control y distribución de software y hardware. soporte a usuarios y mantenimiento de aplicaciones. el cual atienda los requerimientos de soporte referente a los servicios TI. c) Responsable de proveer mecanismos de escalamiento eficiente que permitan el cumplimiento de los niveles de servicios establecidos para la atención de incidencias. mantenimiento de aplicaciones y seguridad informática. e) Reporta los niveles de servicios alcanzados por la unidad a la unidad de relación comercial con el cliente. Administración de incidencias. Administración de servicios y soporte local. 103 . f) Difundir los servicios TI ante los usuarios. control y cumplimiento de los niveles de servicios relativos al soporte a usuario.

g) Responsable del soporte local de los servicios TI en cada una de las empresas del holding. De acuerdo a la figura 39. unidad encargada de realizar proyectos relacionados con software middleware. etc. gestión de procesos de plantas. gestión de la información. q) Ser el apoyo local de Proyectos e Infraestructura. vale decir que integra distintos tipos de sistemas o capas dentro de una arquitectura. cuya labor es la 104 . cumpliendo los niveles de servicios establecidos. se encarga de los proyectos sobre el ERP de la compañía. unidad encargada de realizar proyectos SAP. unidad encargada de realizar proyectos que no caben en las categorías de especialización definidas. control automático. mantenimiento de aplicaciones. vale decir. para ello se definen los Project Manager o Gestores de Proyectos. m) Responsable de proveer información necesaria de la prestación del servicio a los usuarios a control de gestión TI. o) Responsable de la implementación. sin embargo. i) Responsable de la mejora continua del servicio de atención de usuarios. es necesario colocar un nivel que agrupe a los jefes de proyecto según su especialización. e) SAP. 1. el criterio de división es respecto a tecnologías y/o procesos asociados. d) Inteligencia del negocio. soporte local. h) Responsable de encontrar soluciones de fondo ante incidencias repetitivas o cuya causa raíz es desconocida. por ejemplo: sitios webs. unidad encargada de realizar proyectos relacionados con la automatización de plantas productivas. dado el tamaño del holding. b) Integración.3 Subgerencia de Proyectos Para la subgerencia de proyectos. c) Automatización. l) Responsable de mantener el inventario y configuración de los ítem relacionados a la atención de usuarios. minado de datos. soporte de usuarios. Se distinguen los siguientes: a) Software general. f) Mantenimiento. la estructura es de Jefes de Proyecto con su respectivo equipo de Ingenieros de Proyecto. etc. unidad encargada de realizar los proyectos de mantención. visual basic. n) Responsable de canalizar las solicitudes de cambio a través del servicio de atención a usuarios. etc. k) Responsable de la planificación del servicio de mantenimiento de aplicaciones y del seguimiento de este plan. unidad encargada de realizar proyectos de tipo data warehouse. de acuerdo a los procedimientos establecidos de la plataforma tecnológica de uso de los usuarios. mantenimiento de aplicaciones. j) Responsable de la planificación del servicio de atención y soporte de usuarios y del seguimiento de este plan. p) Gestionar los proveedores TI relacionados con las funciones de la unidad de Servicio al Cliente. aplicaciones forms. vale decir: sistemas de ejecución de manufactura.2.

se contempla una unidad de control y planificación. Figura 40: Organigrama alternativo de la subgerencia de proyectos Para el servicio que se ha definido. dejando la componente técnica al jefe de proyecto. sea capaz de gestionar y controlar los proyectos. Con esto se logra una mejor movilidad de recursos dedicados a la gestión.gestión y control global de la cartera de proyectos del área de especialización. dejando esta mejora para una implementación posterior. no separar la especialización de la gestión debido al carácter jerárquico de la organización. se plantea una variante para el nivel de Project Manager. Para ello se puede definir un spool. Además. la que se encarga de realizar el seguimiento global de los proyectos y la asignación de recursos al portafolio. Figura 39: Organigrama subgerencia de proyectos En la figura 40. que es desligar la especialización respecto de las actividades de gestión. la empresa ha pedido. que independiente de la especialidad. 105 .

Desarrollo e implementación de soluciones de software de soporte a la Inteligencia de Negocio y Automatización.Las funciones de esta subgerencia son: a) b) c) d) e) f) Selección de paquetes de software. p) Definir y utilizar los estándares que regirán el desarrollo e implementación de software. l) Establecer acciones preventivas con el fin de evitar desviaciones en el plan de proyecto y/o correctivas si existe una desviación de lo planificado versus lo real. m) Entregar una visión del avance real de los proyectos a la gerencia TI y usuarios involucrados. g) Minimizar los riesgos de la planificación proporcionando confiabilidad respecto de las estimaciones y de la programación de actividades. 106 . Definir la arquitectura de aplicaciones. q) Realizar mantenciones de software de largo plazo. Soporte especializado ante problemas. g) Planificación y gestión integral de Proyectos. b) Asegurar la administración y el control de los requerimientos de software a lo largo del ciclo de vida de los proyectos de implementación y desarrollo. Desarrollo de software. d) Establecer las normas generales que rigen la Administración de Configuraciones de Software. n) Asegurar a la organización el cumplimiento del Proceso de Desarrollo e Implementación de Software. j) Normar la contratación de subcontratistas de software. h) Asegurar la participación y compromiso de los grupos involucrados. k) Establecer las normas generales para realizar el seguimiento y control de software y las responsabilidades de cada uno de los involucrados. bajo la modalidad de proyectos. Las responsabilidades son: a) Establecer las normas generales para la Administración de Requerimientos de proyectos y las responsabilidades de cada uno de los entes involucrados. f) Establecer las normas generales para la planificación general de proyectos de software y las responsabilidades de cada uno de los entes involucrados. e) Establecer y mantener la integridad y consistencia de los productos de software a través de todo el ciclo de vida de los proyectos de software. Implementación de paquetes de Software. c) Asegurar la participación y compromiso de los grupos involucrados. i) Establecer las normas generales para la administración de los subcontratistas y proyectos de software subcontratados y las responsabilidades de cada uno de los entes involucrados. asegurando una eficiente administración de estos y los proyectos que le son asignados. o) Establecer las normas generales para garantizar la calidad de los productos de software y las responsabilidades de cada uno de los entes involucrados en el desarrollo y la implementación de estos.

que se encarga de la administración de redes WAN y LAN. por ejemplo. c) Ingeniería. Si se requiere la intervención directa a algún equipo se utiliza como apoyo el técnico de terreno de soporte. Sin embargo. b) Redes. que se encarga de la operación de los sistemas. hay notar que las actividades de administración y operación son desarrolladas centralizadamente. unidad que realiza la ingeniería de sistemas y la administración de servidores. vale decir: a) Operaciones. b) Administración y operación de la plataforma computacional y software del negocio. De acuerdo a lo propuesto en la figura 41.2. pero el personal puede ir rotando con el fin de que tengan conocimiento general de las plataformas. además de la telefonía. d) Gestión de cambios de la infraestructura TI. 107 . d) Seguridad. Figura 41: Organigrama subgerencia de infraestructura Las funciones definidas para la subgerencia son las siguientes: a) Diseño y planificación de plataforma computacional. Debido a lo anterior. las responsabilidades si podrían ser de ese modo. acceso a servidores y perimetral. Se encuentra dividida en: bases de datos. la administración de sistemas. ejecución de procesos batch. para la subgerencia de infraestructura se considera una división clásica. puede ser dividida en las mismas zonas geográficas. que define y aplica las políticas de seguridad en cuanto a aplicaciones. c) Pasos a producción de aplicaciones e infraestructura TI. sistemas unix y sistemas windows. etc.1.4 Subgerencia de Infraestructura Primero. no vale la pena pensar en una organización basada en la distribución geográfica.

sistemas operativos y aplicativos de negocio. g) Entregar un soporte y asesoramiento especializado para la adquisición y utilización de la infraestructura TI que dan soporte a los servicios. disponible a ser usada como un soporte fundamental para la provisión de servicios en beneficio del negocio.1 Gerencia de Servicios TIC Gerente de Servicios TIC Es el responsable máximo de la entrega del servicio TIC a cada una de las empresas del holding. h) Gestión. l) Provisión. j) Proveer las capacidades y disponibilidades necesarias en la infraestructura y aplicaciones de TI para el cumplimiento de los SLA. e) Proveer una plataforma TI estable y segura. Sintonía de la plataforma computacional. c) Definición de los estándares de Implementación apropiados para las soluciones de infraestructura TI en el ambiente productivo. mantención y administración de la infraestructura de telecomunicaciones acorde a las exigencias de los aplicativos de negocio. i) Gestión. Administración de servidores. Definición de Cargos De la estructura organizacional definida en el punto 1 de este capítulo. 2. se presenta la definición de los cargos. Resolución de incidentes de la plataforma computacional central o crítica. Asesoría especializada. seguimiento y control de la seguridad informática. Administración de la seguridad. 2.e) f) g) h) i) j) k) Administración de bases de datos. redes. b) Diseñar y Planificar la infraestructura de soporte a los servicios TI. k) Responsable de la existencia de planes de recuperación ante desastre que puedan afectar los servicios TI soportados por la plataforma computacional. soporte a soluciones y escalamiento de los recursos computacionales servidores. d) Implementación de las soluciones desarrolladas o adquiridas para el negocio y/o TI. f) Mantener y operar de manera eficiente y efectiva los procedimientos operacionales de la infraestructura TI. 108 . Diseño y planificación de la infraestructura de telecomunicaciones. Las responsabilidades son: a) El monitoreo. seguimiento y control de los proveedores de infraestructura y servicios bases computacionales. asegurando que todos los servicios y componentes de TI reúnan los objetivos y requerimientos que satisfacen al negocio. con una mínima interrupción de los procesos de negocio.

revisión y funcionamiento del proceso de incidencias y problemas y del soporte local. Jefe de Soporte Zonal Responsable de los procesos y funcionamiento del soporte de segundo nivel. Service Manager Responsable de la entrega del servicio TIC. 2. acorde a los requerimientos del negocio y a un costo justificable.Jefe de Finanzas y Control de Gestión Responsable del control. Jefe de Soporte y Mesa de Ayuda Responsable de la implantación. investigados y evitados. planificación. tiene a cargo la facturación y cobro de los servicios. Canaliza los requerimientos de los clientes de manera eficiente y efectiva a través de la organización de servicios TIC. seguimiento y control del servicio TIC ante los clientes.3 Subgerencia de Servicio al Cliente Subgerente de Servicio al Cliente Responsable del funcionamiento eficaz y eficiente del área de servicio al cliente. 2. Revisa aspectos contables. soporte y seguimiento del presupuesto TIC. sean solucionados. incluyendo el seguimiento y solución de problemas y errores conocidos.2 Subgerencia de Relación Comercial Subgerente Relación Comercial Es el responsable de la definición. Se preocupa de que los incidentes no solucionados por el service desk. 109 . Responsable del soporte al seguimiento de los niveles de servicio. su planificación y resultados en el ámbito de la zona o empresas que representa. Ingeniero de Planificación y Gestión del Servicio Apoya las funciones del Subgerente y de cada uno de los Service Manager en la planificación de la entrega del servicio.

Ingeniero de Soporte Responsable de entregar apoyo y coordinar los procesos y funcionamiento del soporte de segundo nivel.4 Subgerencia de Proyectos Subgerente de Proyectos Responsable del funcionamiento del área de proyectos. sean solucionados. Analista de Aplicaciones Responsable del soporte al análisis. Jefe de Mantención Responsable del servicio de mantención de aplicaciones.Técnico de Terreno de Soporte Responsable de entregar apoyo a los procesos y funcionamiento del soporte de segundo nivel. Jefe de Mantención Zonal/SAP Responsable del control y planificación del proceso de mantención de aplicaciones. recursos y procesos de manera eficiente. 2. Project Manager Responsable de la gestión de proyectos de desarrollo. Se preocupa de que los incidentes que no soluciona el service desk. e implementación de aplicaciones y paquetes comerciales. Analista de Demanda Responsable del soporte a la gestión. sean solucionados. Ingeniero de Mantención Responsable del análisis. incluyendo el seguimiento y solución de problemas y errores conocidos. diseño. modificación y construcción de aplicaciones de negocio o implantación de paquetes comerciales. investigados y evitados. 110 . Se preocupa de que los incidentes que no soluciona el service desk. se encarga de gestionar las personas. incluyendo el seguimiento y solución de problemas y errores conocidos. asignación y control del mantenimiento de las aplicaciones. diseño y construcción de aplicaciones de negocio o implantación de paquetes comerciales. investigados y evitados.

e implementación de software. Ingeniero de Proyectos Responsable de la ejecución de los procesos de desarrollo. diseño y funcionamiento de la infraestructura informática de la organización. 2. diseño y construcción de aplicaciones. 111 . coordinación.5 Subgerencia de Infraestructura Subgerente de Infraestructura Responsable de la definición. mantención. planificación. Jefe de Ingeniería Responsable de la coordinación con proveedores y diseño de la plataforma de la organización. Coordina y diseña la infraestructura. Gestiona personas. Ingeniero de Control y Planificación Responsable de apoyar las labores de asignación de recursos. recursos y procesos de manera eficiente. Se preocupa de la implementación de paquetes comerciales. arquitectura y plataforma SAP.Jefe de Proyectos Responsable del análisis. Jefe de Redes Responsable de la coordinación con proveedores y diseño de la infraestructura de redes de la organización. seguimiento y control de los procesos de desarrollo e implementación de software. establece políticas y documentación necesaria. Jefe de Seguridad Informática Responsable de la definición y seguimiento de las políticas de seguridad al interior de la organización. Ayuda a los clientes a identificar problemas y soluciones. Jefe de Operaciones Responsable de la operación de la plataforma informática.

Ingeniero de Sistemas Responsable del diseño. 112 . mantenimiento y control de los activos informáticos. planes y estrategias de implementación de una plataforma de acuerdo a las necesidades de la organización. Realiza labores de optimización.Analista de Seguridad Responsable de ejecutar las actividades necesarias para cumplir con las políticas de seguridad. Operador de Sistemas Responsable de la operación. Administrador de Base de Datos Administra y coordina los cambios sobre la plataforma de base de datos de la organización. Realiza labores de optimización. Administrador de Red Administra y coordina los cambios sobre la plataforma de redes de la organización.

son transversales a las empresas y por lo tanto requieren de un trabajo de colaboración más que jerárquico entre las diferentes unidades. para finalmente entrar en régimen en la etapa de entrega del servicio. Otro elemento a considerar es que la alta dirección ha pedido. la estructura organizacional y la planeación operativa para la transición. Como marco general. Esto es contrapuesto con un esquema de servicios ya que es él cliente quien define lo que necesita y en muchas ocasiones no hay tiempo para recurrir al Gerente o Subgerente para que valide o decida sobre una determinada acción. c) Entrega del servicio. El holding. Los servicios entregados por la filial de servicios compartidos. que durante el periodo de transición. donde prácticamente todas las decisiones son validadas o tomadas por los Gerentes o Subgerentes de área. sin embargo. las filiales que reciben servicios de TI no sufran impacto por el cambio. un primer aspecto a considerar es la cultura organizacional. 1. corresponde al conjunto de actividades de capacitación y definición de la estructura organizacional y los procesos TI. transición y cambio debe considerar aspectos culturales.Capítulo 5 – Implementación. transición y cambio Para la implementación del servicio. es necesario convencer a las personas para que adopten un nuevo enfoque para la atención de los requerimientos de los usuarios. 113 . Durante la etapa previa se definen los procesos.1 Etapa previa al cambio La etapa previa al cambio. Por lo tanto. se distinguen las siguientes grandes etapas: a) Previa al cambio. se caracteriza por su carácter jerárquico. Este problema. de operación actual y actividades a desarrollar en el tiempo. se va implantando la nueva estructura organizacional y los procesos definidos. Durante la transición. b) Transición y cambio. transición y cambio 1. el plan de implementación. A continuación se presenta el detalle de cada etapa. Plan de implementación. se ve aminorado por la definición y el marco de los procesos.

d) Curso y taller de servicio al cliente.1. el área de recursos humanos de la empresa ha definido una serie de cursos y talleres tendientes a entregar herramientas a las personas para desenvolverse bajo el nuevo paradigma. se distinguen dos aspectos: las relacionadas con el desarrollo de competencias y habilidades personales y las relacionadas con el entendimiento del modelo que se está implementando. orientado a todo el personal y con el objetivo de dar a conocer el modelo ITIL desde una perspectiva general. b) Taller de negociación. c) Taller de manejo de conflictos. Para atacar el primer aspecto. el enfoque es realizar la definición en conjunto con el gerente de servicios TIC y la empresa consultora. 1. cuyo objetivo es entregar elementos y técnicas de resolución de conflictos. mediante talleres.2 Actividades de definición de los procesos TI Tal como se revisó en el capítulo 2. 114 . se contempla la necesidad de los siguientes cursos y talleres: a) Curso de ITIL. la definición de los procesos es hecha mediante el enfoque de re-ingeniería.1.3 Actividades de definición de la estructura organizacional Respecto a la estructura organizacional. Contempla la participación de los subgerentes y jefes de área en la definición de los procesos. Posteriormente. estos son: a) Talleres de integración. b) Talleres de procesos. orientado a todo el personal TIC.1 Actividades de Capacitación Dentro de las actividades de capacitación al personal.1. cuyo objetivo es lograr que las personas de la gerencia de servicios TIC se conozcan entre sí. orientado a todo el personal TIC. Para el segundo aspecto. cuyo objetivo es capacitar y practicar en los aspectos y técnicas modernas de la negociación. 1. orientado a Subgerentes y a jefes de área. será validado por cada Subgerente designado para cada área. cuyo objetivo es incorporar a los Subgerentes y a jefes de área en las definiciones de los procesos TI. con el objetivo de dar a conocer y aplicar los conceptos y claves de la orientación al cliente.1.

2. entonces deberán terminar las mantenciones que tienen asignadas y luego asumir y/o recibir las nuevas actividades. por el hecho de introducir cambios de personas en trabajos que ya están en curso y por lo tanto las empresas pueden verse más afectadas de lo que podría esperarse. Un criterio de traspaso. c) Personas que realizan funciones de administración de servidores. el objetivo es no incorporar riesgos que signifiquen atraso o inestabilidad a esos proyectos. entonces deberá entregar su función en el proyecto. por lo tanto deberán permanecer en ellos hasta que finalicen. El problema de esto. servicios y bases de datos. En primera instancia. si una persona está en un proyecto. 115 . Que una persona se mantenga realizando las mismas funciones. Otro criterio para minimizar la inestabilidad. las puede asumir. Para afrontar esto. luego no tiene nada que traspasar. a la persona que asumirá el rol en la nueva organización. si tienen que entregar funciones anexas al proyecto y la persona que las recibe. producto de la consolidación de funciones y servicios. el problema de la etapa de transición y cambio es el traspaso de funciones del personal sin causar un gran impacto sobre el servicio actual. d) Personas que realizan soporte a usuarios. es necesario definir una estrategia de traspaso y un plan de difusión del servicio. distinguiéndose dos situaciones: a) La función es nueva. Para las personas que participan en proyectos en curso. Se pueden distinguir dos casos: 1. entonces deberá hacer entrega de esas funciones. de la estructura organizacional antigua. es realizar un big bang. Que una persona no se mantenga realizando las mismas funciones. hacer traspasos ordenados independientes de las funciones y criticidades actuales. Sin embargo. b) La función se venía realizando con la estructura antigua y por lo tanto tiene que recibir y entregar. En el caso de las personas que realizan mantenciones de software. por lo tanto solo debe entregar. pero si podría recibir. Entonces se tendrán los siguientes casos: a) Personas que participan en proyectos en curso. las funciones críticas para mantener operativos los servicios que reciben las filiales. es considerar.2 Etapa de transición y cambio Operativamente. Por ejemplo. es que provoca inestabilidad en los servicios.1. si son asignadas a funciones nuevas. el plan de traspaso debe considerar la función actual que es realizada por una persona y la función futura a la que será destinada. es decir. b) Personas que realizan las mantenciones de software.

c) Descripción de los servicios ofertados. d) Formalización de inicio de la nueva modalidad de servicios. El objetivo es llegar a este estado un año después de iniciado el proceso de transición y cambio. deberán entregar las funciones actuales y asumir las nuevas. difusión y cambio. 116 . se distribuirá un folleto explicativo al personal de las empresas. en donde los procesos se encuentran adoptados y en funcionamiento. breve descripción de los procesos que se utilizarán. servicios y bases de datos y que son asignadas a nuevas funciones. entonces. a diferencia de los casos anteriores. Además. consiste en una serie de reuniones en donde se presentará y se dará a conocer la nueva modalidad de servicio a los representantes de las filiales. siendo deseable completar este proceso en un periodo de a lo más un año. el personal asignado a cada subgerencia. En la tabla 25. administración de servidores. 1. El plan de difusión del servicio. la etapa de entrega del servicio. Los traspasos se han de realizar de acuerdo a los criterios señalados anteriormente en el tiempo que sea necesario. la estrategia de cambio es un proceso que comienza primero con la línea de subgerentes asumiendo sus funciones y luego. Entonces. es el estado de régimen de la organización. hasta completar toda la organización. acceso a los servicios. el Subgerente de Relación Comercial y el Service Manager de la empresa a la cual se realizará la presentación. Cada subgerente. en una segunda etapa. Se darán a conocer los siguientes puntos: a) Breve introducción de la empresa de servicios compartidos. La presentación del servicio será realizada por: el Gerente de servicios TIC. generando así. coordinara con su par en la estructura antigua el detalle de las actividades que puedan ser traspasadas.Para las personas que realizan funciones de soporte a usuarios.3 Etapa de entrega del servicio Finalmente. se presenta el plan global de transición. Esta actividad será ejecutada una vez que los subgerentes asuman sus funciones. un plan de traspaso que será dado a conocer a la organización TIC. b) Presentación de la nueva modalidad de servicios: estructura organizacional TIC.

Tabla 25: Plan global de difusión y cambio 117 .

filiales y gerencia sobre la importancia del SPI y los avances que se produzcan en el proyecto. En este capítulo. Los esfuerzos realizados se contrastaran con las evaluaciones. b) Existan comunicaciones continuas hacia la organización. 118 . adquisición y mantención de productos y servicios. La mejora continua estará dada por: la evaluación periódica del nivel alcanzado. establecer prioridades de mejoramiento y apoyar la implantación de las mejoras. dejando en claro las expectativas reales de la iniciativa. se presenta el plan del proyecto SPI cuyos objetivos son alcanzar en el tiempo los distintos niveles de madurez CMMi. proveyendo facilidades para ayudar a las organizaciones a examinar la efectividad de sus procesos. tanto formales como informales de CMMi. disminuir el costo empresa de los proyectos y mantenciones de software. las recomendaciones serán incorporadas e institucionalizadas con el objeto de incentivar la mejora continua del proceso. Marco del Proceso de Mejora de Software El objetivo de este capítulo es diseñar el plan de acción estratégico para la mejora del proceso de software (SPI) para proyectos de desarrollo y el proceso de mantención del área de tecnologías de información. proporciona una guía para mejorar el proceso de una organización y la capacidad para administrar el desarrollo.Capítulo 6 – Estrategia para la Mejora del Software 1. La motivación de esta iniciativa se basa en principios guías y en la oportunidad de entregar mejores servicios a los clientes. estandarizar las prácticas y procesos de software para el área. incorporando los hallazgos de estas actividades a las empresas y el avance en los niveles de madurez CMMi. El plan de acción. pensando en la evaluación bajo CMMi en el mediano y largo plazo. c) Convencer a las filiales para incorporar como propio el proceso de mejora de software. integrara todas las actividades de mejora del proceso de software mediante la adopción del modelo CMMi para la disciplina de Ingeniería en Software. se espera: a) Se disponga de los recursos apropiados y adecuados para el proyecto. dentro de un marco de trabajo futuro. El compromiso de la alta gerencia es crítico para esta iniciativa. d) Se provea de un esquema de incentivos y reconocimiento para aquellas personas que muestren adherencia a las mejoras del proceso y en general a la participación y aporte en el proyecto. Este modelo. El éxito del SPI se medirá mediante la evaluación exitosa en los niveles de madurez de CMMi.

Calidad: Creemos que la calidad de nuestros productos está directamente relacionada con la calidad de nuestros procesos. La mejora continua del proceso de software es esencial para el éxito. 2. 119 . Plan Estratégico de Mejora del Proceso de Software 2. Los esfuerzos en la mejora de procesos son administrados con un eficiente uso de recursos.2.1 Misión Promover la mejora de procesos continúa a través de las filiales del holding. proveer la guía hacia el camino de la excelencia en cada una de las áreas de proceso. La satisfacción de nuestros clientes es crítica y de suma importancia para los negocios. 4. al mínimo costo.4 Principios Guías 1. que permitan a la organización aumentar y mantener su nivel de madurez en el tiempo. 2. propiciamos un ambiente que permite al personal crecer y desarrollarse profesionalmente. Madurez del Proceso de Software: Creemos que el modelo CMMi es un método práctico de identificación y evaluación para medir la madurez del proceso de software. Creemos en el trabajo en equipo y el compromiso de las personas. 3. 2. Procesos comunes y estándares son indispensables para el crecimiento organizacional. 2.2 Visión El servicio compartido de tecnologías de información pondrá todos sus esfuerzos en institucionalizar los procesos de software mediante estándares documentados y proveer productos fiables y servicios a tiempo.3 Valores Personas: Nuestra gente es la fortaleza de nuestra área.

Aumentar la productividad. 2. Mejorar la moral de los empleados. 2. Disminuir la cantidad de defectos los productos de software.9 Beneficios Esperados 1. 3.6 Metas de Largo Plazo Desarrollar e institucionalizar la cultura de ingeniería de software basada en la mejora continua de los procesos. conforme a los estándares internacionales de la industria.7 Metas Estratégicas Derivadas del Negocio Alinearse con la política de calidad del holding matriz respecto a los procesos productivos. 2.5 Metas de Corto Plazo Obtener evaluación satisfactoria en CMMi nivel 2 en un plazo no superior a 2 años. soluciones técnicas.2. 2. 2. 5. administración de 120 . Mejorar el tiempo del ciclo del producto.10 Principios Guía del SPI El proyecto SPI pretende atacar las distintas etapas del proceso de software que vale la pena mejorar. 2. Estandarizar las prácticas y procesos de software del área de tecnologías de información de la empresa de servicios compartidos.8 Objetivo El objetivo de esta iniciativa es disminuir los costos para los procesos de desarrollo y mantención de software. 4. Mantener el liderazgo en costos y la producción de productos de alta calidad. Disminuir el costo empresa de los proyectos y mantenciones de software. Alcanzar los distintos niveles de madurez CMMi cada 2 años. vale decir: issues del negocio. realizando evaluaciones cada 1 año. Reducir los esfuerzos de retrabajo para las mantenciones.

La organización debe ser capaz de explicar a los terceros relevantes porque una actividad determinada o un entregable son importantes.12 Auspicio Se cuenta con el auspicio del Gerente de TI y del Gerente General de la empresa de servicios compartidos. estos son: a) La creación de una Subgerencia de Calidad. documento. de quienes se tiene el compromiso de facilitar los recursos humanos. Los procesos deben ser concisos. tanto humanos.proyectos y calidad. bajo este paradigma se asumen una serie de supuestos críticos para el éxito. la mejora continua y liderará esta iniciativa a través del tiempo. agregar valor y deben ser usables. tendrá la facultad para programar y disponer de dicho tiempo. de quienes se tiene el compromiso de alinear y comunicar al holding de empresas respecto a la importancia y alcances del proyecto. 2. técnicos y financieros. 2. d) Se debe definir un modelo de incentivos y reconocimientos al personal que participe activamente en el proyecto. Se cuenta con el auspicio de los subgerentes del área de tecnologías de información. que se hará cargo de los procesos. será el canal de comunicación hacia niveles más altos de la organización. El Subgerente de calidad o el jefe de proyecto que este designe. políticas y prácticas definidas bajo el proyecto SPI.11 Supuestos Para el desarrollo de este plan es necesario contar con los recursos. c) Cada integrante del proyecto deberá destinar 1 hora diaria a las actividades de SPI. que permitan llevar a un buen término el proyecto SPI. 121 . Además. o artefacto existente en la organización. b) CMMi será utilizado como base para todas las definiciones de proceso. Se privilegiará la reutilización de cualquier práctica.

Históricamente. la capacitación interna en temas de tecnologías de información es bastante baja por lo que puede ser una barrera al momento de integrarlo con los clientes finales. Se debe partir. 122 . sin embargo al no existir experiencia previa se dificulta la medición de beneficios cuantitativos del proyecto y por lo tanto su justificación en el directorio de la empresa.2. es el grado conservador del holding respecto a la adopción de nuevas tecnologías y a que no se ha tomado conciencia de que el servicio de informática es un real apoyo para el negocio como generador de beneficios.14 Barreras Una de las principales barreras a enfrentar por este proyecto. por ello no se descarta un enfoque incremental del proyecto. el servicio de informática se considera como un centro de gastos más que un centro generador de beneficios por lo que cualquier iniciativa proveniente del área tiene un alto grado de cuestionamiento. el proyecto debe ser evaluado utilizando los métodos tradicionales. por una evaluación cualitativa hasta obtener algún resultado concreto. Desde el punto de vista financiero. Las barreras pueden ser superadas mediante el apoyo claro para el proyecto SPI de la alta dirección del holding y la capacitación continua en el modelo. Por otro lado. las empresas han tenido su focalización en el negocio desechando actividades que no generan valor. se presenta una matriz de riesgos para el proyecto SPI: Tabla 26: Riesgos del proyecto de mejora del proceso de software 2.13 Riesgos En la tabla 26.

El sponsor de este proyecto es el Gerente General de la empresa de servicios compartidos.2.15 Organización para la Mejora del Proceso 2. Desde el punto de vista de las filiales. el área involucrada directamente en esta iniciativa es la Gerencia de Tecnologías de Información y Comunicaciones.15. b) Entregar la visión corporativa desde el punto de vista del negocio para el proyecto SPI. con el objeto de transmitirles las prácticas y procedimientos sujetos a mejora continua. d) Comunicar a los niveles altos de la organización el desarrollo de los objetivos y logros del proceso. afectando a los servicios informáticos que se prestan en cada una de las filiales.2 Comité Ejecutivo El comité ejecutivo es el encargado de guiar y gobernar el proyecto SPI.15. e) Supervisar como el proceso se está llevando a cabo. el plan comunicacional deberá incorporar a los clientes finales de cada filial. c) Revisar e integrar la visión. d) Alinear a los Gerentes Generales de las filiales con este proyecto. 123 . Sus responsabilidades son: a) Determinar el tipo de planificación estratégica a utilizar. b) Gerente de Tecnologías de Información y Comunicaciones. misión y plan de negocio al proceso de mejora de software. c) Proponer issues de mejora al comité ejecutivo. cuyas responsabilidades son: a) Establecer y promover en el holding el proyecto SPI. El comité estará integrado por: a) Gerente General de Servicios Compartidos.1 Alcance Organizacional El proyecto SPI tiene alcance sobre el holding completo. esto aportará también la institucionalización del proceso. b) Definir y crear el plan estratégico de acción. c) Jefe de Proyecto SPI. 2. los procesos que les signifiquen participación del proceso de software están dentro del alcance de este proyecto.

15. Planificar las actividades. e) Supervisar los proyectos de mejoramiento. d) Establecer planes tácticos de acción. Cada grupo. Adquirir y coordinar los recursos para capacitación y consultoría.2. b) Establecer la forma de evaluar el proceso. Realizar el seguimiento del progreso del proyecto respecto a lo planificado. b) Project Managers. identificar recursos y esfuerzos. el TWG: a) Desarrollará y documentará nuevos procesos. Informar mensualmente el estado de avance al comité ejecutivo. sus responsabilidades son: a) b) c) d) e) f) g) h) Documentar el plan de acción estratégico. tendrá la responsabilidad de coordinar y liderar el proceso de mejora de software. 2.4 SEPG (Software Engineering Process Group) El SEPG tendrá las siguientes responsabilidades: a) Determinar y definir la organización (procesos y métodos). 2. tendrá un líder que tendrá la responsabilidad de aceptar cada hito del plan de proyecto SPI e implementar las recomendaciones de cada ciclo de mejora. Recopilar semanalmente el estado de avance de los grupos de trabajo y le equipo del proyecto.5 Grupos de Trabajo Técnicos (TWG) Los miembros de los grupos de trabajo técnicos. 124 . Sugerir acciones correctivas al comité ejecutivo cuando se produzcan desviaciones respecto a la planificación.3 Jefe del Proyecto SPI El jefe del proyecto. Revisar los planes de acción de los grupos de trabajo y el equipo del proyecto. El SEPG estará compuesto por: a) Jefe del Proyecto SPI. c) Presentar los resultados del proceso a los diferentes niveles de la organización. revisar y asistir en el piloteo de nuevos procesos de software y de herramientas de mejora.15. b) Evaluará los actuales procesos proponiendo mejoras. f) Evaluar y verificar los avances. En particular.15. tendrán la responsabilidad de producir. c) Documentará y recopilara los artefactos actuales de procesos de la organización.

15. 2. TWG 6: a) Jefe del Proyecto SPI (como facilitador). TWG 4: a) Jefe del Proyecto SPI (como facilitador). TWG 2: a) Jefe del Proyecto SPI (como facilitador). b) Jefe de Proyectos SAP. b) Jefe de Proyectos Software General. c) Ingeniero de Mantención. c) Ingeniero de Proyectos Automatización. c) Ingeniero de Proyectos SAP. b) Jefe de Proyectos de Automatización. Además dado que no existe experiencia en el holding en este tipo de iniciativas. cuyas áreas de proceso serán asignadas de común acuerdo con el líder del proyecto SPI. se utilizarán consultores externos para la evaluación formal en los niveles de madurez CMMi. para el levantamiento y la puesta en marcha del proyecto SPI se contratará la asesoría de una empresa especializada. b) Jefe de Proyectos de Integración. Los TWG están compuestos por: TWG 1: a) Jefe del Proyecto SPI (como facilitador). c) Ingeniero de Proyectos Inteligencia de Negocio. Se definirán 6 TWG. TWG 5: a) Jefe del Proyecto SPI (como facilitador). b) Jefe de Proyectos de Mantención. e) Propondrán mejoras y modificaciones a los procesos. TWG 3: a) Jefe del Proyecto SPI (como facilitador). c) Ingeniero de Proyectos Software General. b) Jefe de Proyectos de Inteligencia de Negocio.6 Consultores Externos Como parte del proyecto SPI.d) Conducirá los pilotos. c) Ingeniero de Proyectos Integración. 125 .

que se medirá el porcentaje de cantidad de procesos actualmente en uso respecto a la cantidad de procesos totales. se tomarán controles a los integrantes del área informática.2.2 Medición de Metas de Largo Plazo Para medir el desarrollo e institucionalización de la cultura de ingeniería de software basada en la mejora continua de los procesos. vale decir. Se considerará logrado el objetivo cuando se obtenga en promedio un 100% de respuestas correctas en los controles.16 Criterios de Éxito El éxito de este proyecto será alcanzado de la siguiente manera: Desde el punto de vista estratégico: a) Obtener satisfactoriamente la evaluación CMMi nivel 2 en un periodo no mayor a 2 años. Si para un proyecto o mantención los puntos de función son iguales. el establecimiento de evaluaciones informales cada año y formales cada año por medio. será medida como el porcentaje del costo del esfuerzo en un proyecto o mantención respecto al costo del esfuerzo de un proyecto o mantención de tamaño similar que haya sido realizado en el pasado. La disminución del costo empresa de los proyectos y mantenciones de software.1 Medición de Metas de Corto Plazo La estandarización de las prácticas y procesos de software. 2.3 Medición de Metas Estratégicas Derivadas del Negocio La medición del alineamiento con la política de calidad del holding respecto a los procesos productivos. Para determinar la similaridad del proyecto o mantención se utilizaran puntos de función.16. 126 . será medida mediante la adopción de los procedimientos por parte de los involucrados.16. d) A mediano plazo. un valor del 100% se considerara exitoso. La medición de realizará anualmente mediante evaluaciones informales. b) Obtener satisfactoriamente la evaluación CMMi en niveles superiores cada 2 años a partir de la fecha de obtención del nivel 2. 2. entonces se consideraran equivalentes. cualquier otro valor será considerado como no exitoso. El porcentaje de disminución de proyectos y mantenciones similares debe ser de al menos un 10%. será medida mediante la obtención de evaluaciones satisfactorias en los niveles de madurez de CMMi.16. 2. c) Institucionalización de las áreas de procesos relacionadas con el desarrollo de software.

Tabla 27: Costos del proyecto de mejora del proceso de software 127 .17 Planificación 2. por el directorio y en segundo lugar los defectos de los productos de software deberán ser eliminados por sobre el 99%. cuyo detalle se encuentra en la tabla 27. 2.17.Para medir el mantenimiento del liderazgo en costos y la producción de productos de alta calidad conforme a los estándares internacionales de la industria.1 Costos Estimados Para el proyecto SPI se estima un costo de US$ 393. por una parte se exigirá al proyecto SPI el mismo ROI que es exigido a la empresa.000. se establecerán dos medidas.

17. se puede visualizar en la tabla 28.2. Tabla 28: Roadmap del proyecto de mejora del proceso de software 128 .2 Roadmap La planeación estimada de actividades.

Es interesante destacar que los marcos de referencia utilizados. respecto a la localización geográfica de las instalaciones. economías de escala. bajo la situación inicial. contribuyendo a identificar las fuentes para minimizar los gastos de operación de las actividades de apoyo al negocio. criticidad y distribución de los procesos propios del negocio. es un primer paso en dicha dirección. lo que permite tener una base de procesos estándar. el gasto promedio mensual en tecnologías de información para una planta industrial con 500 usuarios era de US$ 70. El esquema de servicios compartidos permite que las soluciones tecnológicas sean transversales al holding. pero como son considerados inversiones. lo que representa una disminución promedio de un 11. estandarización y por lo tanto. esto producto de la transparentacíon de los costos del personal propio. lo que compensa la situación. Paradójicamente.17 Las definiciones entregadas en esta tesis se basan en decidir la mejor estrategia de provisión de servicios. 129 . donde la idea era establecer un marco de trabajo para la organización. Sin embargo. En contraste con la situación inicial. 17 Fuente: Reportes de facturación del servicio TIC y presupuestos internos del holding. contribuyendo a la simplificación de la operación y control del negocio y con la posibilidad de adoptarlos completamente. En la situación inicial estos beneficios no se presentaban ya que no era posible un enfoque global que permitiera tomar decisiones pensando en el conjunto y en los procesos de negocio de las distintas empresas del holding. Los procesos TIC fueron definidos bajo el marco de referencia de CMMi e ITIL. En términos cuantitativos. los que son prácticamente equivalentes. desde la planeación estratégica hasta el manejo de la infraestructura informática. Por ello.200. Los procesos fueron abordados con un carácter general. el plan estratégico de mejora del proceso de software presentado en el capítulo 6. de acuerdo a los objetivos planteados. Los servicios son entregados a las empresas y de acuerdo a los niveles de servicio definidos. generando sinergia. en la evaluación económica se exige una tasa de descuento superior.7%.000 promedio mensual. en donde prácticamente no existían procesos formales ni estandarizados. con el servicio compartido TIC bajó aproximadamente a US$ 62. los proyectos de software son aproximadamente un 15% más caros respecto a la situación inicial. pero no establecen mecanismos que promuevan la mejora continua. prácticamente se independizan de estas variables y establecen criterios de diseño de acuerdo a las mejores prácticas. el tipo de industria y al paradigma de servicios compartidos. el incremento de la calidad de los productos y servicios entregados no está asegurado ya que los procesos definidos ordenan la organización.Conclusiones Este proyecto logró el cambio de la estructura organizacional. la posibilidad de disminuir los costos de los proyectos y servicios externos.Capítulo 7 .

este criterio no debe ser usado para la ejecución de proyectos de este tipo. También. en respuesta a la manera en que los procesos han evolucionado. lo que de alguna manera produjo que personas que a pesar de tener mucha experiencia. Además. Por ello. 130 . e implementar procesos. que por sus características y complejidad requiere estudio. la competitividad y por lo tanto. sobre todo. más que impositores de estructuras. productos y servicios en forma oportuna y con la calidad requerida. la definición de sus propios procesos de negocios. produjo una serie de dificultades en la implantación. los procedimientos y el detalle de los procesos que. El primer problema fue la tendencia de la dirección de este proyecto. El uso de modelos y estándares de la industria no garantiza el éxito de una organización. el suponer que todas las personas colaborarían y adoptarían los nuevos modelos. Si bien simplificar el problema puede ser una aproximación para abordarlo y entenderlo. poseer un manejo fluido de la comunicación y ser guías del proceso de adopción. solo fueron elaborados en sus aspectos más relevantes. Un error de este proyecto fue el no haber abordado este punto con el apoyo de profesionales especialistas en selección de personal. en la modificación de hábitos de trabajo. Se pueden modelar. a la dependencia creciente en las tecnologías para la sobrevivencia del negocio y a la necesidad de las organizaciones de proveer a sus clientes. La asignación de personas a funciones debe realizarse con un conocimiento acabado de competencias y perfiles. participación más amplía de las personas y análisis en profundidad. por su extensión. facilita a las áreas de tecnologías de información. produciendo resistencia a la adopción de nuevas formas de trabajar. Una deficiencia en esta componente dificulta este tipo de proyectos. disputas de poder entre áreas y en general. juegan un factor relevante como medios para el cambio. no eran competentes para el cargo en el que fueron designados. los líderes de este tipo de proyectos deben ser buenos negociadores. este tipo de iniciativas puede fracasar. la adopción de estándares probados. pero sin la contribución y aporte de las personas. a minimizar y simplificar el esfuerzo requerido para producir el cambio y en focalizarse en definir la organización antes que los procesos. Ambos modelos son el esfuerzo de la industria.Aún queda trabajo por hacer en la definición de. las llamadas habilidades blandas. El segundo problema fue que la asignación de las personas a cargos claves. se realizo sobre el concepto de carrera funcionaria. asegurando así. Se presentaron problemas de coordinación. desorden respecto a lo que se deseaba alcanzar. adoptar. lo que produjo que áreas completas no operen de acuerdo al marco definido. Por lo tanto. Finalmente. se han de normalizar los dos grandes problemas que aparecieron producto de la implementación de este proyecto. la sustentabilidad a través del tiempo.

Carnegie Mellon University. 131 . 2004. 36p [13] JORRAT. LUIS. Increasing the Success of the Global Information Technology Strategic Planning Process. Accenture. Postítulo en Gestión Informática. 2004. pp 1-3 [4] DOCUMENTO INTERNO. ESC-TR-2002-029). JOHN. University of Technology Eindhoven. [9] GUERRERO. Universidad de Chile. Universidad de Chile. et al. 2001. Documento Interno. JOSÉ. Departamento de Ciencias de la Computación. Ediciones Dolmen. Netherlands. Documento Interno. y FERGUSON J. USA. CMMi for Software Engineering Staged Representation (CMU/SEI-2002-TR-02. IEEE. Apuntes del curso: “Introducción a la Ingeniería de Software”. Diplomado en Gestión de Calidad de Software. [2] BASTARRICA. Apuntes del seminario: “Introducción al UML”.Bibliografía [1] ACHÁ. 639p. Empresa Forestal. 120p. Universidad de Chile. Postítulo en Ingeniería y Calidad de Software. Universidad de Chile. 2000. MARIA CECILIA. 2005. Estudio de rendimiento de un sistema de ejecución de manufactura. JACQUES. Estudio de viabilidad de un servicio compartido para una empresa forestal. Specification of service level agreement. Departamento de Ciencias de la Computación. Departamento de Ciencias de la Computación. Pittsburgh. clarifying concepts on the basis of practical research. Chile. [10] GUERRERO. Apuntes del curso: “Evaluación de Proyectos”. pp 78-83. Empresa Forestal. Universidad de Chile. Empresa Forestal. Proceedings of the 33rd Hawaii International Conference on System Sciences. Chile. 2000. [7] CMMI PRODUCT TEAM. Apuntes del curso: “Técnicas de Pruebas”. [8] CURRY J. Apuntes del curso: “ISO 9000”. 2002. MICHAEL. Catálogo de servicios para un holding de empresas forestales. 2004. IT Strategy in Forest Products. 93p. Chile. [6] DOCUMENTO INTERNO. [5] DOCUMENTO INTERNO. PA: Software Engineering Institute. 2005. 2004. 2000. 2004. [12] HUGHET. 30p. [11] HAX A y MAJLUF N. Diplomado en Gestión de Calidad de Software. Capítulo 1. [3] BOUMAN. Chile. Departamento de Ingeniería Industrial. Gestión de Empresa con una Visión Estratégica. Documento Interno. Departamento de Ciencias de la Computación. 1996. VERONICA. pp 4-5.

The process reengineering life cycle methodology: A case study. pp 9-10 [24] MICROSOFT CORPORATION. [17] MICROSOFT CORPORATION. Visual Studio Team System. Business Process Change: Reengineering. pp 245-290. pp 211-244 [15] MAYER R. Microsoft Framework Solutions for CMMi. Build 100. Microsoft Press. 2003. pp 9-20 [25] OCHOA. MOF: Service Desk. IBM Business Consulting Services. USA. USA. Methods and Technologies. Microsoft Press. GERMÁN. 6th Edition. Software Engineering. 247p [26] OFFICE OF GOVERNMENT COMMERCE. 2004. 2002. et al. Departamento de Ciencias de la Computación. SERGIO. Business Process Change: Reengineering. Concepts. USA. 2002. pp 6-7 [21] MICROSOFT CORPORATION. Microsoft Press. Microsoft Press. Concepts. MOF: System Administration. USA. IDEA Group. V y KETTINGER W. A Framework and a suite of methods for business process reengineering. [27] PICONE. USA. 2002. USA. MOF: Problem Management. UK.4. IAN. 1998. 2005. Pearson Education. USA. USA. 2003. Trends and Directions in the Forest and Paper Industry. USA. 2005. MOF: Incident Management. 2002. Universidad de Chile. MOF: Capacity Management. pp 7-10 [23] MICROSOFT CORPORATION. The Stationery Office. ITIL Service & Support CD.[14] KETTINGER W et al. V y KETTINGER W. USA. pp 11-12 [20] MICROSOFT CORPORATION. Microsoft Press. MOF: Service Level Management. pp 5-6 132 . Capitulo 27. 2003. Visual Studio Team System. USA. En: GROVER. pp 1-9 [19] MICROSOFT CORPORATION. [16] MICROSOFT CORPORATION. Methods and Technologies. 34p [28] SOMMERVILLE. MOF: Network Administration. Versión 1. Microsoft Press. Postítulo en Gestión Informática. Microsoft Framework Solutions for Agile Software Development. 2005. En: GROVER. Microsoft Press. 2000. Apuntes del curso: “Gestión de Proyectos Informáticos”. 2005.0. IDEA Group. [18] MICROSOFT CORPORATION. 1998. USA. pp 9-11 [22] MICROSOFT CORPORATION.

Diplomado en Gestión de Calidad de Software. 554p [32] WWW. 2003. Descripción del modelo IDEF [en línea]. SAMUEL.IDEF.org. Resumen del modelo ISO 9126. Apuntes del curso: “Introducción a CMMi”. 2004. http://www.com. Apuntes del curso: “Introducción a la gestión de calidad”. Departamento de Ciencias de la Computación. [30] PINTO. Apuntes del curso “Tecnologías de Información y Rediseño de Procesos”. Departamento de Ciencias de la Computación. [31] VARAS. PABLO. [Consulta: 23 de Noviembre de 2005] 133 . [en línea]. Diplomado en Gestión de Calidad. 2004.[29] STRAUB.idef. Departamento de Ingeniería Industrial. FERNANDO. Universidad de Chile.COM. http://www.ORG. Universidad de Chile. Universidad de Chile.iso. [Consulta: 22 de Marzo de 2006] [33] WWW.ISO.

ANEXOS 134 .

NET y J2EE 135 .ANEXO I: Comparación entre las plataformas .

similitudes. ventajas y desventajas.ANEXO I: Una comparación entre .mspx 136 . la idea es entregar algunos criterios que permitan al lector tener una visión rápida de las diferencias.NET18 18 Fuente: http://www. Figura 1: Arquitectura .NET y J2EE No es sencillo realizar una comparación de ambas plataformas. Por lo tanto. debido a la cantidad y complejidad de los elementos que las componen (ver figuras 1 y 2).microsoft.com/spanish/msdn/arquitectura/das/guias/AppArchCh5. desde el punto de vista global.

Cabe señalar. aunque con C# se pueden utilizar en el modo de programación unsafe. El código es organizado en clases. SOAP y WSDL. e independiente de la plataforma. estable. que existen una serie de iniciativas para portar . de código abierto. uno de los mas utilizados. el que es ejecutado por un interprete. J2EE es un conjunto de especificaciones y prácticas que permiten el desarrollo de soluciones empresariales multi-capa. provee mecanismos para herencia múltiple. basados en la tecnología Java. . por lo que existen coincidencias con Java. C# es una especie de evolución entre Java y C++. Los lenguajes base de la plataforma con C# y Visual Basic. Considera un único lenguaje de programación. Java. utiliza código intermedio. que interpreta el código intermedio generado por el compilador. clientes y servicios. con la diferencia que el compilador traduce los lenguajes soportados a uno común.html 137 . Esto permite que un programa en un cierto lenguaje pueda utilizar código o componentes escritos en otro lenguaje. esta orientado fuertemente a mantener la consistencia de los tipos de datos. siendo el proyecto Mono. orientado a objetos.NET.Figura 2: Arquitectura J2EE 19 De acuerdo a SUN.utah. No permiten el uso de punteros.    19 Fuente: http://edg. pero no permite la programación de funciones fuera de las clases. que se caracteriza por ser portable robusto. es decir:  Ambos lenguajes son compilados a código intermedio. Al igual que C++. Permite al programador trabajar sobre múltiples lenguajes en un entorno único de desarrollo (Visual Studio). independiente de la plataforma y del sistema operativo para el caso de Java y dependiente del sistema operativo para los lenguajes bajo . Ambos permiten herencia múltiple mediante el uso de interfaces. La ejecución de aplicaciones se realiza utilizando una máquina virtual.NET a ambientes UNIX. el que podría considerarse como su predecesor.gov/strategies/j2ee/j2ee. Se basa en estándares abiertos como CLI.NET es una plataforma de desarrollo de servidores. Al igual que J2EE.

2003. J2EE puede ser adquirido en varias compañías.En el siguiente cuadro. facilitando la integración y portabilidad de las aplicaciones. Posee un nivel de madurez superior a . Como criterio general. . en contraste con . establece una serie de prácticas de desarrollo de software que pueden ser aplicadas con métodos tradicionales y ágiles. lo que permite flexibilidad al programador y una evolución en los entornos de programación. La tecnología Java es abierta y basada en estándares internacionales. las ventajas de . pp 80-81 138 .NET. incluyendo nativamente formatos SOAP. Universidad ICESI. el tiempo de permanencia en el mercado y en la estabilidad. Colombia. WSDL y UDDI.NET en relación a la arquitectura sobre diferentes plataformas. si las aplicaciones de la empresa son predominantemente Windows.NET está orientado a la creación de servicios web.NET: 1. Tabla 1: Comparación entre lenguajes . J2EE presenta las siguientes ventajas respecto a . 20 Fuente: JIMÉNEZ. Finalmente. construidas con el entorno Visual Studio. 2.NET.NET y Java20 Respecto a las plataformas.NET sobre J2EE son: 1. 3. LUZ ELENA. En: Sistemas & Telemática. Microsoft con su suite Visual Studio. Por otro lado. 2.NET soporta múltiples lenguajes de programación. donde las prácticas son abordadas mediante entornos de programación de terceros. 3. El entorno de programación . en cambio J2EE solo ofrece la plataforma. Sin que el programador tenga que generar por si mismo el código XML.NET. Una comparación entre JAVA y . en el que el proveedor es único. la elección de una u otra plataforma dependerá del contexto empresarial y de los costos de implementación. se presenta un resumen con las principales diferencias y coincidencias entre el lenguaje Java y los lenguajes base de .

NET. la diferencia la hará el costo de implementación y mantención entre J2EE y . el que debe ser evaluado de acuerdo al caso particular. tiene menos costo seguir con la mismo. Por otro lado. si la plataforma per-se es UNIX. por supuesto) y resulta ser directa. 139 . frente a una migración. si la plataforma ya está establecida bajo Windows. Lo mismo ocurre con J2EE. En cambio. en entornos nuevos. para Windows.NET ya que la evolución tecnológica no significa mayores costos (salvo licencias.es mejor utilizar . J2EE resulta ser la elección natural.

ANEXO II: Ejemplos de Normas y Procedimientos 140 .

Software no licenciado: No se instala. en relación a Sistemas. software y sistemas debe estar autorizado por el Jefe de Seguridad y/o Gerente. que permitan un adecuado nivel de seguridad y resguardo de la información en caso de fallas o desastre. b. para que el personal disponga de las herramientas. 2. c. previa autorización del Gestor de Proyectos. se deben tener las siguientes consideraciones: a. Acceso a la red Internet. Los programas de respaldo se deberán definir cada 6 meses. Software y Sistemas que se carguen en la plataforma computacional. que apoyen efectivamente su gestión en el logro de los objetivos de las empresas. Para el acceso de los usuarios a los Sistemas de Información se dispondrá de dos niveles de seguridad. Bases de Datos y Servidores. 3. Todas las Aplicaciones. es decir Oracle y SQL Server: Solo se instalan a los clientes con previa autorización del Ingeniero de Soporte. ALCANCE Aplicable al personal del holding y sus filiales. En particular. Se deben realizar los respaldos necesarios. POLÍTICA SOBRE LA SEGURIDAD EN EL ACCESO A LA RED 1. Software licenciado: Autoriza Ingeniero de Soporte teniendo en cuenta el esquema de licenciamiento. Acceso a aplicaciones y sistemas: Autoriza Jefe de Seguridad y/o Gerente. con el objeto de prestar servicios. deben estar debidamente licenciadas y deben ser autorizadas. f. Software de desarrollo: No se instala en equipos de usuario solo en el de personal del servicio TIC y contratistas que realizan desarrollo utilizando equipos de la plataforma computacional del holding y sus filiales. El primero estará dado por el acceso a la red computacional y el segundo por el acceso al sistema propiamente tal. d. Subgerente. tanto preliminares como definitivas. g. El acceso a aplicaciones. e.ANEXO II: Políticas Generales del Servicio TIC OBJETIVOS El servicio TIC es la responsable de normar todos los aspectos relacionados con los sistemas. Subgerente del área respectiva. comunicaciones de red y tecnologías de información del holding y sus filiales. definidos por claves o Contraseña. 141 . En particular con respecto a esta área se debe tener en cuenta los siguientes aspectos: 1. quien deberá entregar su aprobación por escrito. Software no autorizado: No se instala. Software base de datos. con el objeto de ajustarlo a las reales necesidades de las empresas. operando eficientemente sus sistemas de información y de comunicación. creación de cuentas de red y cuentas de correo: Autoriza Jefe directo del usuario.

esta solicitud será canalizada al Service Desk. Las contraseñas de usuario tendrán una expiración no mayor a 3 meses. asignada por el Ingeniero de Soporte. se dispondrá de los correspondientes respaldos de información y de alternativas de acción para reponer las distintas líneas de equipos. frente a fallas en los equipos centrales y. los usuarios dispondrán de una Contraseña. o acciones involuntarias. POLÍTICA DE RESPALDO Y RECUPERACIÓN DE DESASTRE. estos respaldos se almacenarán en diferentes lugares de las instalaciones. teléfono (anexo) e indicar si el usuario tendrá correo o no. el usuario debe poseer una Cuenta de Usuario y una Contraseña. Toda vez que un trabajador abandone la empresa. El servicio TIC. Para acceder a un sistema de información. 2. Se recomienda un cambio de Contraseña con una frecuencia no mayor de 3 meses. especificando el nombre y departamento al cual pertenece el usuario. 3. asignada inicialmente por el administrador de red.2. cada usuario dispondrá de una Contraseña personal e intransferible. Con el objeto de reponer los servicios en el más breve plazo y disminuir el riesgo de pérdida de información. El acceso VPN será a pedido. POLÍTICA DE ACCESO RED COMPUTACIONAL 1. 142 . Cada Jefe de Departamento puede solicitar la creación de cuenta de red para el personal a su cargo. A fin de disminuir el riesgo frente a contingencias mayores. Las Contraseña asociadas a la Administración de Servidores serán cambiadas con una frecuencia no mayor de 3 meses. 3. Las Contraseña tendrán un largo igual o superior a 6 caracteres y no podrá repetirse el mismo Contraseña por 3 periodos. El ingreso a las Salas de Computación de las Plantas. 5. 2. se dispondrá de los respaldos necesarios de las aplicaciones y de los datos. Para acceder a la red computacional. 1. cumplido ese tiempo el sistema de autenticación de red pedirá cambiar el Contraseña al usuario. la que será cambiada la primera vez que utilice su cuenta de red. Para acceder a los servicios computacionales prestados por el servicio TIC. donde se encuentran los servidores y otros elementos de hardware relevantes de la red. 4. es el usuario el responsable de su respaldo mediante las herramientas disponibles actualmente. Se privilegiará mantener convenios de soporte técnico y mantención de los equipos críticos con los proveedores o sus representantes oficiales. Todas las cuentas de red por defecto tendrán acceso a Internet. Para asegurar una adecuada reposición de los sistemas de información y recuperación de los datos. con el objeto de eliminar su acceso a la red computacional y demás privilegios en los sistemas. será restringido sólo a personal autorizado. frente a contingencias graves en las instalaciones físicas. 3. no se hace responsable por el respaldo de PC de usuarios. área. 4. el que es responsable de definir el perfil del usuario. el área de Recursos Humanos informará con anticipación. Además el usuario podrá libre e independientemente cambiar su contraseña cuando lo requiera. El solicitante deberá especificar las excepciones.

siguiendo los mismos pasos de la Política Acceso red Computacional. d. La Contraseña inicial será asignada al momento de la creación de la Cuenta y puede ser cambiada libre e independientemente por el propio usuario. b. El requerimiento de la cuenta de Correo Electrónico debe ser solicitado al Service Desk. Los correos almacenados en el servidor están sujetos a un tamaño máximo de 100 Megabytes. Se debe tener en cuenta los siguientes puntos: a. El Service Desk registrará el requerimiento y asignará la actividad al Coordinador de Service Desk. El usuario realizará un llamado al Service Desk solicitando el acceso a INTERNET. POLÍTICA DE INSTALACIÓN DE SOFTWARE EN ESTACIONES DE TRABAJO 1. Las Cuentas de Correo de contratistas deben tener como descripción la función desempeñada y la identificación de la empresa contratista. Las casillas de correo poseen una limitación de 10 Megabytes para el volumen de información de envió y recepción.4. 4. al Ingeniero de Soporte. 2. El proceso de instalación deberá seguir los siguientes pasos: a. deben ser autorizado por la línea ejecutiva respectiva. POLÍTICA DE REQUERIMIENTO DE CORREO ELECTRÓNICO 1. La contraseña de red expira. El requerimiento de instalación de Software debe ser solicitado al Service Desk. 143 . Cada Cuenta de Correo debe estar asociada a una Cuenta de Red. o ambos si corresponde para informar y proceder con la ejecución de la instalación. En caso que la solicitud sea negativa. 5. enviará un correo al Ingeniero de Soporte para que sancione la solicitud. La Cuenta de usuario será personal e intransferible. c. Se debe configurar la estación cliente con un archivo PST local. se registrará el requerimiento y se procederá al igual que en el procedimiento de instalación de Software. La salida a Internet se realiza a través de un servidor PROXY. El acceso de personas que no pertenezcan al holding y sus filiales. d. 2. se informará al usuario POLÍTICA ACCESO A INTERNET 1. El acceso a Internet está disponible a todo el personal del holding y sus filiales. el Coordinador asignará al Técnico de Terreno. 3. con toda la información necesaria del producto solicitado a instalar. e. b. Si el software no esta licenciado la solicitud se rechaza inmediatamente. excepto la contraseña empleada para crear la cuenta. Recibida la confirmación. por el usuario. El Coordinador. la entrega de los correos tiene que estar direccionada a las carpetas personales. c.

4. se proporcionará el software durante el tiempo que el computador se encuentre en operación. Todo equipo que no pertenezca al holding y sus filiales debe ser chequeado técnicamente por personal autorizado con el objeto de asegurar que no produzcan problemas en el funcionamiento de la red computacional. Disponibilidad de Software. En el caso de que no lo tuviesen. 144 . Configuración estándar de equipos. Operación segura de equipos conectados de terceros. c. La detección de una anomalía en algún equipo conectado a la red. Los equipos deben tener la configuración estándar de los equipos computacionales de la empresa. Esta política se basa en los siguientes principios: a. 2.POLÍTICA DE CONEXIÓN DE EQUIPAMIENTO A LA RED 1. b. 3. El servicio TIC es el responsable de aprobar la incorporación de equipamiento computacional a la red con el objeto de cautelar la confidencialidad. Ingreso seguro a la red. Los equipos conectados a la red deben contener necesariamente antivirus. d. Los equipos deben disponer del software y sus respectivas licencias que permitan asegurar un adecuado funcionamiento y el cumplimiento de leyes de propiedad intelectual. disponibilidad e integridad del recurso de información de la empresa. que atente contra la seguridad. debe ser aislado hasta que se supere los inconvenientes y se logre un re-ingreso seguro.

EQUIPOS Y MATERIALES 1.ANEXO II: Procedimiento de Paso a Producción OBJETIVOS Establecer las normas y procedimiento para los pasos a producción. Disminuir el impacto de los pasos a producción sobre la plataforma informática en operación. ALCANCE Aplicable a todo el personal del holding y sus filiales. RESPONSABILIDADES Project Manager. o cualquier cambio que signifique una modificación en la configuración de uno o más servidores. autoriza o rechaza cualquier tipo de solicitud de paso a producción. Plan de reversa del paso a producción: Conjunto de actividades tendientes a reversar un paso a producción. Tiempo estimado de la actividad. Ingeniero de Sistemas: Ejecuta el paso a producción según la documentación entregada. b. Jefe de Operaciones. Ingeniero de Proyectos. Administrador de base de datos: Ejecuta el paso a producción según la documentación entregada. Actividad a realizar. Tiempo estimado de la actividad. Plan de paso a producción: Conjunto de actividades tendientes a realizar el paso a producción. Jefe de Ingeniería: Aprueba. b. mejoras operacionales. Controlar y documentar la puesta en marcha de hardware. c. servicios. Coordinación Service Desk: Asigna y coordina el requerimiento de paso a producción. software y servidores. El plan deberá poseer al menos la siguiente información: a. 2. Ingeniero de Mantención: Realiza una solicitud de paso a producción y apoya las actividades relacionadas de la solicitud. 145 . Actividad a realizar. Mesa de Cambios: Instancia (reunión) donde son analizados los cambios en la plataforma de servidores derivados de: pasos a producción. Responsable de la actividad. El plan deberá poseer al menos la siguiente información: a.

que muestra paso a paso como realizar la instalación de un producto de software. NORMAS GENERALES 1. ii. v. d. 3. software o el servidor que se encuentra o que se está pasando a producción. iii. iv. v. Plan de contingencia.c. Se deberá entregar obligatoriamente la siguiente documentación. Plan de contingencia: Conjunto de actividades que será aplicado en caso de presentarse problemas con el servicio. c. iii. vacaciones u otro motivo. Sitios y páginas web. 10. iv. o software sobre un servidor. b. Ingeniero de Proyectos. Base de Datos. Plan de contingencia. deberá resolver cuales son las personas autorizadas. Protocolo de entrega. Scripts de base de datos. 11. Sitios o páginas web. Plan de pruebas ejecutado. Responsable de la actividad. Servicios y software sobre servidores en operación. La designación deberá ser comunicada a Infraestructura y Servicio al Cliente. Aplication Server. Plan de reversa del paso a producción. 5. Protocolo de entrega. Servicios. Plan de pruebas ejecutado. Ingeniero de Mantención son las únicas personas autorizadas para solicitar un paso a producción. Equipos computacionales. 8. Protocolo de entrega. 6. 7. Plan de paso a producción. Protocolo de entrega: Certificado de la conformidad del paso a producción. Artefactos de software. Procedimiento de instalación de productos de software: Documento orientado al soporte. v. Plan de pruebas ejecutado: Conjunto de actividades realizadas sobre el software que aseguran y demuestran su buen funcionamiento. 12. i. Plan de contingencia. 146 . Documento de especificación de plataforma: Documento único donde se especifica técnicamente los elementos de un paso a producción de servidor. Plan de paso a producción. i. 4. según los siguientes casos: a. 9. Plan de pruebas ejecutado. A falta de esta persona por enfermedad. Plan de reversa del paso a producción. En último caso el comité de subgerentes. Plan de reversa del paso a producción. ii. Plan de paso a producción. 2. iii. el Subgerente de área deberá designar un representante que realizará la solicitud. servicio. iv. Se deberán completar las secciones que apliquen a la actividad que se realizará. El Gestor de Proyectos. ii. i.

Plan de paso a producción. servidores y sus servicios en operación deberá ser autorizada por Infraestructura. ii. Plan de reversa del paso a producción. iii. Protocolo de entrega. i. Protocolo de entrega. d. Protocolo de entrega. o inconsistencia de la documentación entregada. Aplication Server: Lunes y Miércoles a partir de las 18:00 hrs. e. i. Documento de especificación de plataforma. Plan de reversa del paso a producción. Plan de pruebas ejecutado. Servidores. Las personas facultadas para rechazar un paso a producción son el Ingeniero de Soporte. ii. Plan de contingencia. iii. f. Otros no especificados. Sitios Intranet: Lunes a Jueves a partir de las 18:00 hrs. iv. 5. iii. Incompletitud. Productos de software: Lunes a Jueves de 12:30 a 14:00 hrs y después de las 18:00 hrs. Documento de especificación de plataforma. i. Plan de paso a producción.3. iv. Todo paso a producción que afecte a la plataforma de redes de área local. i. e. v. vi. vii. Documento de especificación de plataforma. h. iv. Protocolo de entrega. g. Sitios y páginas Internet (Extranet) para resto del mundo: Lunes a Jueves a cualquier hora del día. no entendimiento. 6. Plan de paso a producción. c. Plan de contingencia. Base de Datos: Lunes y Miércoles a partir de las 18:00 hrs. f. 147 . 4. v. iv. v. Sitios y páginas Internet (Extranet) para Chile: Lunes a Jueves a partir de las 18:00 hrs. Una solicitud de paso a producción podrá ser rechazada en los siguientes casos: a. Plan de contingencia. No presentación de uno o más documentos mencionados en el punto 2. Otros no especificados: Lunes a Jueves según mejor ventana de tiempo previamente acordada con el cliente. ii. el Administrador de Base de Datos y el Ingeniero de Sistemas. Procedimiento de instalación para técnicos en terreno. Plan de reversa del paso a producción. ii. Horarios para pasos a producción: a. iii. b. Plan de paso a producción. Servicios: Domingo a Jueves según mejor ventana de tiempo previamente acordada con la empresa. b. Productos de software. Servidores nuevos: Lunes a Jueves a cualquier hora del día. Plan de reversa del paso a producción. Procedimiento de instalación. i. g. v. Plan de contingencia.

Sábados y Festivos salvo expresa autorización con la debida justificación. i. No se cumplen los requisitos mínimos de documentación para un paso a producción. b. Se presentan situaciones de carga en la o las plataformas que se verían afectadas. facultará a Infraestructura y Soporte para derivar directamente cualquier requerimiento o contingencia al desarrollador responsable por dichas piezas. Otros no especificados: Según planificación. Productos de software: Lunes a Jueves hasta las 11:30 hrs. 8. 11. y hasta las 17:00 hrs. En caso de presentarse una contingencia que signifique realizar un paso a producción fuera de los horarios mencionados en el punto 6 y que comprometa la continuidad operacional de la empresa. Sitios y páginas Internet (Extranet) para resto del mundo: Una hora antes de realizar el paso a producción. o no explica claramente la necesidad del negocio a satisfacer. c. No se presenta la justificación b. Servidores nuevos: Según planificación. c. Sitios Intranet: Lunes a Jueves hasta las 17:00 hrs. No se realizarán pasos a producción los días Viernes. No se cumplen los requisitos mínimos de documentación para un paso a producción. 12. 10. o no explica claramente la contingencia del negocio. La contingencia deberá estar debidamente justificada y podrá ser rechazada si: a. h. e. Servicios: Según planificación. La justificación es inconsistente o incompleta. Sitios y páginas Internet (Extranet) para Chile: Lunes a Jueves a hasta las 17:00 hrs. Para ello se solicitará al usuario final o área cliente una justificación donde se especifiquen claramente los motivos por los cuales se requiere el paso. b. c. se deberá solicitar autorización para la realización de la actividad. Debido a la dinámica y exigencias del negocio de las empresas. d. se podrán realizar pasos a producción extraordinarios durante horarios distintos a los definidos en este procedimiento. La justificación es inconsistente o incompleta. Base de Datos: Lunes y Miércoles hasta las 16:30 hrs. f. Aplication Server: Lunes y Miércoles hasta las 16:30 hrs. El paso a producción extraordinario podrá ser rechazado si: a. indicando fecha y hora de la actividad y la justificación del usuario o área cliente. g. Además se deberá solicitar autorización por e-mail. Todo producto de software y/o servicio y/o servidor y en general cualquier pieza de software y/o hardware que no haya sido entregada y protocolizada según el procedimiento mencionado en el documento. Se define como hora de cierre para los pasos a producción ingresados el mismo día lo siguiente: a. Durante un paso a producción se deberá contar con la presencia del desarrollador ya sea en el lugar donde se realiza la actividad o por teléfono. d. Su labor durante el paso a producción será la de apoyar la actividad según sea requerido. 148 . 9. No se presenta la justificación del usuario.7.

Aplication Server: Administrador de base de datos o Ingeniero de Sistemas. f. g. Sitios y páginas Internet (Extranet) para resto del mundo: Ingeniero de Sistemas. e. b. b. en caso de que se presentasen dudas o inconvenientes. Servidores nuevos: Ingeniero de Sistemas. La solicitud de paso a producción se registrará a través de la aplicación de service desk. recibirán y revisarán la información entregada por el desarrollador y podrán rechazar la solicitud. quién podrá autorizar o rechazar la solicitud y convocar a la “mesa de cambios” según sea el caso. Base de Datos: El DBA procederá a programar la fecha y hora del paso a producción y notificará al desarrollador de la actividad. Aplication Server: Administrador de base de datos o Ingeniero de Sistemas. Sitios y páginas Internet (Extranet) para resto del mundo: El Ingeniero de Sistemas procederá a programar la fecha y hora del paso a producción y notificará al desarrollador de la actividad. 2. Los administradores. De no haber objeciones o rechazo. Productos de software: La coordinación solicitará a un técnico en terreno probar el procedimiento de instalación del software. e. Si no se presentan inconvenientes y una vez probado el procedimiento de instalación. según sea el caso procederá a programar la fecha y hora del paso a producción y notificará al desarrollador de la actividad. Servicios: Ingeniero de Sistemas. El Coordinador asignará el requerimiento según lo siguiente: a. Si una solicitud 149 . Sitios y páginas Internet (Extranet) para Chile: El Ingeniero de Sistemas procederá a programar la fecha y hora del paso a producción y notificará al desarrollador de la actividad. Sitios Intranet: Ingeniero de Sistemas. g. Otros no especificados: Ingeniero de Sistemas. el Ingeniero de Sistemas procederá a copiar el software al repositorio de programas de instalación de cada empresa y se agendará la instalación definitiva para los usuarios. también informará al desarrollador las causas del rechazo. h. Sitios y páginas Internet (Extranet) para Chile: Ingeniero de Sistemas. c. d. se procederá como sigue: a. De no haber objeciones se procederá según los horarios mencionados anteriormente. c. el técnico reportará a la coordinación el problema y se rechazará la solicitud. i. adjuntando la documentación mencionada y los artefactos a pasar a producción. f. Productos de software: Coordinación de técnicos de terreno.PROCEDIMIENTO 1. Sitios Intranet: El Ingeniero de Sistemas procederá a programar la fecha y hora del paso a producción y notificará al desarrollador de la actividad. Base de Datos: Administrador de base de datos. d. 3. Servicios: El Ingeniero de Sistemas solicitará autorización al Jefe de Operaciones. Para está actividad el técnico en terreno contará con un tiempo de 30 minutos a contar de la asignación del requerimiento.

De no haber objeciones se procederá según los horarios mencionados anteriormente. i. Finalmente. Si una solicitud es rechazada será informada al desarrollador junto con las recomendaciones a seguir. Servidores nuevos: El Ingeniero de Sistemas solicitará autorización al Jefe de Operaciones quién podrá autorizar o rechazar la solicitud y convocar a la “mesa de cambios” según sea el caso. el desarrollador deberá entregar el protocolo de entrega a Soporte e Infraestructura. quién podrá autorizar o rechazar la solicitud y convocar a la “mesa de cambios” según sea el caso. 4. Si una solicitud es rechazada será informada al desarrollador.es rechazada será informada al desarrollador junto con las recomendaciones a seguir. De no haber objeciones se procederá según los horarios mencionados anteriormente. una vez que se ha realizado el paso a producción. h. Otros no especificados: El Ingeniero de Sistemas solicitará autorización al Jefe de Operaciones. 150 . junto con las recomendaciones a seguir.

NORMAS GENERALES 1. Runqueue <= 1. este comando solicitara el password de la cuenta la primera vez que sea ejecutado. Para el caso del servidor los parámetros básicos normales de operación son los siguientes: a. d. 2. EQUIPOS Y MATERIALES Se requiere conexión vía telnet al servidor. Utilización de CPU por proceso < 1% (lista de procesos). El comando topas nos muestra el estado general de carga del servidor y los procesos más consumidores. Conectarse al servidor mediante telnet. c. ALCANCE Aplicable a todo el personal que realiza administración de servicios y servidores. Administrador de Base de Datos: Apoya las actividades de este procedimiento. utilizar la cuenta oracle. Nivelar la carga de procesos relacionados con iAS del servidor.ANEXO II: Procedimiento de monitoreo de un servidor OBJETIVOS Establecer el procedimiento de monitoreo y eliminación de procesos inactivos en el servidor. 3. RESPONSABILIDADES Ingeniero de Sistemas Ejecuta este procedimiento. PROCEDIMIENTO 1. Waitqueue <= 2% . Verificar la carga del servidor mediante el comando: sudo topas. User <= 10. b. La revisión y eliminación de procesos debe realizarse 1 vez a la semana a cualquier hora del día. 151 .

Verificar antigüedad del proceso con el comando ps –fea | grep PID. Verificar que el proceso sea f60webm o f60runm. Verificar antigüedad del proceso con el comando ps –fea | grep PID. En caso de presentarse anormalidades se debe proceder como sigue: a. donde PID es el identificador de procesos. 5. iii. donde PID es el identificador de procesos. Verificar que el proceso sea f60webm o f60runm. donde PID es el identificador de procesos. Identificar junto con el DBA la operación de base de datos o form involucrado.4. En AIX el comando produce la siguiente salida: 152 . iv. entonces se debe hacer un kill -9 PID. ii. vale decir se encuentra dentro del mismo día. iii. i. Caso 2: Dos o más procesos poseen un uso de CPU mayor al 20% y no son antiguos. Una vez identificado. Caso 1: Dos o más procesos poseen un uso de CPU mayor al 20% y son antiguos i. Si el proceso tiene una antigüedad superior a un día. ii. informar al Coordinador de Sistemas para su corrección. b. Verificar la antigüedad de procesos mediante el comando ps –fea.

a todos los procesos que: a. Por ejemplo. si estamos en el mes de Febrero este proceso es antiguo. luego se debe hacer un kill -9 103490. esto significa que el proceso no es un “subproceso” o un thread. el resultado es: Hay que notar que el proceso 103490 tenía como proceso padre (segundo campo) el PID 1. Sean f60runm o f60webm. 153 . donde PID es el identificador de procesos. b. 6. el proceso 103490 está activo desde el 2 de Enero (Jan 02). Ejecutar el comando kill -9 PID. Posean una antigüedad superior a un día.El PID corresponde al segundo campo y la antigüedad al quinto campo.

Si se hace un kill a un proceso cuyo proceso padre no es el PID 1. El estado <defunct> puede generar procesos de tipo zombie (hacen nada) y pueden ser eliminados por el propio scheduler del sistema operativo. esto quiere decir que este proceso es un “subproceso” o un thread. 154 . entonces al ejecutar nuevamente ps –fea nos encontraremos con que dicho proceso queda en estado <defunct>.

Sign up to vote on this title
UsefulNot useful