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.
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

i
 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

ii
 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

iii
Í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

iv
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.
1
 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.

2
 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).

3
 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.

4
 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.

5
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

6
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 operativos1.

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%
7
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.

8
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.

9
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.

10
 Figura 3: Representación gráfica de IDEF02

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]
11
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 trabajo3

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.
12
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.

13
 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égica4

4
Fuente: JORRAT, MICHAEL. 2000. Apuntes del curso “Evaluación de Proyectos”. Departamento de Ingeniería
Industrial. Universidad de Chile.
14
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 Porter5

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.
15
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 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, 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.
16
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.

17
 Tabla 3: Los niveles de madurez y las áreas de proceso de CMMi7

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.
18
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
19
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.

20
 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].

21
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.
22
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.

23
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.

24
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.

25
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.

26
 Tabla 4: El catálogo de servicios8

8
Fuente: Documento Interno. 2004. Catálogo de Servicios para un holding de empresas forestales. Empresa Forestal
Chilena.
27
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.

28
 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.

29
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.

30
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.

31
 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 NDi 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
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. Luego, el

porcentaje de disponibilidad del servicio fijo es:

n
 NDi  I i 
% DSF  1     100
 i 1 t 

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.
32
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.

33
 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

34
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:

35
 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.

36
 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

37
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

38
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:

39
 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.

40
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.

41
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.

42
 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.

43
 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.

44
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

45
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:
46
 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.

47
 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.

48
 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.

49
Entonces, si n es el número total de actividades del proyecto, Pi es la cantidad de
productos entregables para una actividad i , con un plazo planificado de realización t i y
tri 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 t ri  t i : es decir, todas aquellas

actividades que produjeron el producto de acuerdo a lo planeado, sobre el total
de productos definidos:

P
j
j

% PE p  n
 100 donde j es tal que tr j  t j
P
i 1
i

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

2. 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
j
j

% PE a  n
 100 donde j es tal que tr j  t j
P
i 1
i

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

3. Porcentaje de avance del proyecto: es decir, la ponderación entre la cantidad

t
total de actividades y el factor de cumplimiento de tiempo ri , de manera tal que
ti
t ri
 1 , es decir todas aquellas actividades que se encuentren sin atraso respecto
ti
a lo planificado:

1 t
% AP    ri  100
n i ti

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.

50
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.

51
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.

52
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.

53
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.

54
 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.

55
 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

56
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
 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.

60
 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.
61
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.
62
 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

63
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.
64
 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.

65
 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.

66
 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].
67
 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.

68
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:
69
  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

70
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
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 xxx. yyy. zzz , 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.
74
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.

75
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.
76
 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. 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

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. 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.

80
 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

81
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.

82
 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

83
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 PC12

12
Fuente: Documento Interno. 2005. Estudio de rendimiento de un sistema de ejecución de manufactura. Empresa
Forestal. Chile.
84
 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.

85
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.

86
 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.

87
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 OLA13

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.
88
Tabla 21: OLA para servicios fijos

89
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.

90
 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 Infraestructura14

14
Fuente: Microsoft Corp. 2005. MOF: Network Administration.
91
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.

92
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.

93
 Tabla 23: Variables de monitoreo de un servidor15

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 infraestructura16

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.
94
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.

95
 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.

96
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.

97
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

98
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.

99
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.

100
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.

101
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.

102
 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.
103
 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

104
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.

105
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.

106
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.

107
 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.

108
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.

109
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.
110
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.

111
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.

112
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.

113
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.

114
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.

115
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.

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

117
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.

118
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.

119
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
120
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.

121
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.

122
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.

123
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.

124
 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.

125
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.

126
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

127
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

128
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.
129
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.

130
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 33rd 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.

131
[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. 6th Edition. USA. Pearson
Education. Capitulo 27, pp 5-6

132
[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]

133
ANEXOS

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

135
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 .NET18

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

136
 19
Figura 2: Arquitectura J2EE

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
137
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 Java20

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
138
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.

139
ANEXO II: Ejemplos de Normas y Procedimientos

140
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.

141
 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.

142
 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.

143
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.

144
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.
145
 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.
146
 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.

147
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.
148
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

149
 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.

150
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).

151
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:

152
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.

153
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.

154