UNIVERSIDAD DE CHILE

FACULTAD DE CIENCIAS FSICAS Y MATEMTICAS

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIN











DISEO DE UN CENTRO DE SERVICIOS COMPARTIDOS DE TECNOLOGAS DE
INFORMACIN PARA UNA EMPRESA PRODUCTORA DE PULPA Y PAPEL



TESIS PARA OPTAR AL GRADO DE MAGSTER EN TECNOLOGAS DE LA
INFORMACIN





CLAUDIO ALEJANDRO BERTON CRDENAS






PROFESOR GUA:
SR. J OS A. PINO URTUBIA.

MIEMBROS DE LA COMISIN:
SR. NELSON BALOIAN TATARYAN.
SR. PATRICIO INOSTROZA FAJ ARDIN.
SRA. ROSA ALARCN CHOQUE.






SANTIAGO DE CHILE
OCTUBRE 2007


RESUMEN

En esta tesis se presenta el diseo general de los procesos de negocio y organizacin,
de un rea de tecnologas de informacin, 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 creacin de una nueva empresa de servicios, que congregar
las funciones de contabilidad, compras, recursos humanos y tecnologas de
informacin. El problema abordado en este trabajo corresponde a la definicin de la
manera en que se prestarn los servicios de TI a las empresas filiales.

La hiptesis es mostrar que, mediante la estructuracin e implantacin de procesos
basados en estndares, orientados a la provisin de servicios de tecnologas de
informacin, se pueden lograr beneficios y oportunidades importantes, tales como: la
consolidacin, la optimizacin de procesos a travs de la reingeniera, la
estandarizacin de aplicaciones y la reduccin de los costos de operacin.

La metodologa de solucin corresponde a una visin desde la re-ingeniera de
procesos, utilizando para las definiciones, elementos de los modelos CMMi e ITIL y
abordando tres grandes ciclos de las actividades de tecnologas de informacin:
planeacin estratgica, ingeniera de software, soporte y provisin de servicios. Para
cada uno de estos ciclos, se definieron actividades de carcter operativo considerando
la distribucin geogrfica. En el caso de la gestin, el esquema propuesto es de
centralizacin. Adems, se plantea una estrategia para la mejora de los procesos de
software, cuyo objetivo final es la adopcin y evaluacin en CMMi.

Producto de la definicin e implantacin de los servicios, procesos y organizacin
propuestos en esta tesis, se ha logrado una disminucin de un 11.7% en los costos de
TI para una planta industrial promedio de 500 usuarios, paradjicamente los costos de
proyectos de software han aumentado un 15%, debido a la transparentacin de costos
que antes eran ocultos. Otro resultado importante, es que con la adopcin de un
esquema de servicio compartido con un marco de procesos basado en estndares, se
cuenta con una base que permite la implementacin de soluciones tecnolgicas
transversales al holding, generando sinergia, economas de escala y simplificacin en la
operacin.



























A mi familia



AGRADECIMIENTOS


A mi familia, por su constante apoyo, cario, comprensin y por permitirme dedicar
tiempo y recursos para desarrollar mis estudios y este trabajo, en desmedro de ellos.

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



i

TABLA DE CONTENIDOS

CAPTULO 1 - INTRODUCCIN ............................................................................................................. 1
1. LA INDUSTRIA DE LA PULPA Y EL PAPEL ................................................................................................. 1
2. SITUACIN INICIAL .............................................................................................................................. 2
3. DEFINICIN DEL PROBLEMA ................................................................................................................. 6
4. HIPTESIS ......................................................................................................................................... 7
CAPTULO 2 REVISIN TERICA Y METODOLOGA ........................................................................ 9
1. REVISIN TERICA ............................................................................................................................. 9
1.1 Anlisis, Modelamiento y Diseo 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 Planificacin Estratgica........................................................................................ 14
1.3 Modelos y Prcticas 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 Ingeniera de Software ....................................................................... 19
1.4 ITIL (IT Infraestructure Library) ................................................................................................. 19
1.5 Criterios de Seleccin de Herramientas.................................................................................... 20
2. METODOLOGA ................................................................................................................................. 21
2.1 Enfoque de Trabajo ................................................................................................................. 21
2.2 Estrategia del Proyecto ............................................................................................................ 22
2.2.1 Actividades de Gestin del Proyecto ................................................................................. 22
2.2.2 Actividades Propias del Proyecto ...................................................................................... 23
2.3 Seleccin de Herramientas Metodolgicas ............................................................................... 24
CAPTULO 3 DISEO DE SERVICIOS Y PROCESOS ....................................................................... 26
1. DISEO DE SERVICIOS ...................................................................................................................... 26
1.1 Servicios TIC ........................................................................................................................... 26
1.2 Modelo de costos de los servicios ............................................................................................ 28
1.3 Niveles de Servicio .................................................................................................................. 31
2. DISEO DE PROCESOS ..................................................................................................................... 39
2.1 Proceso de planeacin estratgica TIC para las filiales ............................................................ 39
2.1.1 Proceso para la planeacin estratgica ............................................................................. 39
2.1.2 Proceso para la elaboracin del presupuesto .................................................................... 42
2.2 Procesos de software............................................................................................................... 46
2.2.1 Administracin de Proyectos ............................................................................................. 46
2.2.1.1 Administracin de proyectos con metodologas giles ................................................ 47
2.2.1.2 Administracin de proyectos con metodologas tradicionales ..................................... 48
2.2.2 Proceso de Desarrollo y Administracin 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 Mantencin de Software ................................................................................. 61
2.3 Procesos de soporte al servicio ................................................................................................ 64
2.3.1 Gestin de incidencias ...................................................................................................... 64
2.3.2 Gestin de problemas ....................................................................................................... 66
2.3.3 Gestin de inventario y configuracin ................................................................................ 68
2.3.4 Gestin del cambio ........................................................................................................... 71
2.3.5 Control y distribucin de software y hardware ................................................................... 74
2.4 Procesos de entrega del servicio.............................................................................................. 76
2.4.1 Gestin de disponibilidad y continuidad ............................................................................. 76
2.4.2 Gestin del nivel de servicio .............................................................................................. 77
2.4.3 Gestin de finanzas TI ...................................................................................................... 80
ii

2.4.4 Gestin de capacidad ....................................................................................................... 81
2.4.4.1 Gestin de capacidad del negocio ............................................................................. 81
2.4.4.2 Gestin de capacidad de los recursos y servicios....................................................... 82
2.4.5 Gestin de proveedores .................................................................................................... 86
2.5 Procesos de gestin de la infraestructura y seguridad .............................................................. 90
2.5.1 Gestin de infraestructura ................................................................................................. 90
2.5.1.1 Administracin de la Infraestructura ........................................................................... 92
2.5.1.2 Administracin de la Seguridad .................................................................................. 93
2.5.1.3 Monitoreo y Control de Servicios ............................................................................... 93
2.5.1.4 Actividades de Operacin .......................................................................................... 94
2.5.2 Gestin de seguridad ........................................................................................................ 95
CAPTULO 4 ORGANIZACIN .......................................................................................................... 97
1. ESTRUCTURA ORGANIZACIONAL. ........................................................................................................ 97
1.1 Primer nivel organizacional ...................................................................................................... 98
1.2 Segundo, tercer y cuarto nivel organizacional ........................................................................ 100
1.2.1 Subgerencia Relacin 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. DEFINICIN DE CARGOS .................................................................................................................. 108
2.1 Gerencia de Servicios TIC ..................................................................................................... 108
2.2 Subgerencia de Relacin Comercial....................................................................................... 109
2.3 Subgerencia de Servicio al Cliente ......................................................................................... 109
2.4 Subgerencia de Proyectos ..................................................................................................... 110
2.5 Subgerencia de Infraestructura .............................................................................................. 111
CAPTULO 5 IMPLEMENTACIN, TRANSICIN Y CAMBIO .......................................................... 113
1. PLAN DE IMPLEMENTACIN, TRANSICIN Y CAMBIO ............................................................................. 113
1.1 Etapa previa al cambio ........................................................................................................... 113
1.1.1 Actividades de Capacitacin ........................................................................................... 114
1.1.2 Actividades de definicin de los procesos TI ................................................................... 114
1.1.3 Actividades de definicin de la estructura organizacional ................................................ 114
1.2 Etapa de transicin y cambio ................................................................................................. 115
1.3 Etapa de entrega del servicio ................................................................................................. 116
CAPTULO 6 ESTRATEGIA PARA LA MEJORA DEL SOFTWARE ................................................ 118
1. MARCO DEL PROCESO DE MEJ ORA DE SOFTWARE ............................................................................. 118
2. PLAN ESTRATGICO DE MEJ ORA DEL PROCESO DE SOFTWARE ........................................................... 119
2.1 Misin .................................................................................................................................... 119
2.2 Visin .................................................................................................................................... 119
2.3 Valores .................................................................................................................................. 119
2.4 Principios Guas ..................................................................................................................... 119
2.5 Metas de Corto Plazo............................................................................................................. 120
2.6 Metas de Largo Plazo ............................................................................................................ 120
2.7 Metas Estratgicas Derivadas del Negocio............................................................................. 120
2.8 Objetivo ................................................................................................................................. 120
2.9 Beneficios Esperados ............................................................................................................ 120
2.10 Principios Gua del SPI ........................................................................................................ 120
2.11 Supuestos............................................................................................................................ 121
2.12 Auspicio ............................................................................................................................... 121
2.13 Riesgos ............................................................................................................................... 122
2.14 Barreras ............................................................................................................................... 122
2.15 Organizacin para la Mejora del Proceso ............................................................................. 123
2.15.1 Alcance Organizacional ................................................................................................ 123
2.15.2 Comit Ejecutivo ........................................................................................................... 123
2.15.3 J efe del Proyecto SPI.................................................................................................... 124
2.15.4 SEPG (Software Engineering Process Group) ............................................................... 124
iii

2.15.5 Grupos de Trabajo Tcnicos (TWG) .............................................................................. 124
2.15.6 Consultores Externos .................................................................................................... 125
2.16 Criterios de xito.................................................................................................................. 126
2.16.1 Medicin de Metas de Corto Plazo ............................................................................... 126
2.16.2 Medicin de Metas de Largo Plazo ............................................................................... 126
2.16.3 Medicin de Metas Estratgicas Derivadas del Negocio ................................................ 126
2.17 Planificacin ........................................................................................................................ 127
2.17.1 Costos Estimados ......................................................................................................... 127
2.17.2 Roadmap ...................................................................................................................... 128
CAPTULO 7 - CONCLUSIONES ........................................................................................................ 129
BIBLIOGRAFA ................................................................................................................................... 131
ANEXOS ............................................................................................................................................. 134
ANEXO I: COMPARACIN ENTRE LAS PLATAFORMAS .NET Y J 2EE ......................................................... 135
ANEXO II: EJ EMPLOS DE NORMAS Y PROCEDIMIENTOS ......................................................................... 140


NDICE DE TABLAS

TABLA 1: SITUACIN INICIAL DE LOS PROCESOS DE SOFTWARE ........................................................................ 4
TABLA 2: SITUACIN INICIAL DE LOS PROCESOS DE SOPORTE .......................................................................... 5
TABLA 3: LOS NIVELES DE MADUREZ Y LAS REAS DE PROCESO DE CMMI ...................................................... 18
TABLA 4: EL CATLOGO 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: ASIGNACIN DE VALORES A LA IMPORTANCIA DE UN SERVICIO .......................................................... 33
TABLA 8: IMPORTANCIA DE LOS SERVICIOS SEGN LA SEGMENTACIN DE USUARIOS ........................................ 33
TABLA 9: NIVELES DE SERVICIO PARA LOS SERVICIOS FIJ OS .......................................................................... 34
TABLA 10: NIVELES DE SERVICIO PARA SERVICIOS VARIABLES ....................................................................... 37
TABLA 11: NIVELES DE SERVICIO PARA LA MANTENCIN DE SOFTWARE DE CORTO PLAZO ................................. 37
TABLA 12: NIVELES DE SERVICIO PARA SERVICIOS DE VALOR AGREGADO ........................................................ 38
TABLA 13: EJ EMPLO DE UN PRESUPUESTO .................................................................................................. 43
TABLA 14: CRITERIOS PARA LA PRESUPUESTACIN ...................................................................................... 44
TABLA 15: CRITERIOS PARA DETALLAR EL PRESUPUESTO ............................................................................. 44
TABLA 16: COMPONENTES TECNOLGICOS 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 COMUNICACIN ........................................................ 85
TABLA 20: DIFERENCIAS ENTRE SLA Y OLA ............................................................................................... 88
TABLA 21: OLA PARA SERVICIOS FIJ OS ....................................................................................................... 89
TABLA 22: DESCRIPCIN DE LOS SERVICIOS DE INFRAESTRUCTURA ............................................................... 92
TABLA 23: VARIABLES DE MONITOREO DE UN SERVIDOR ............................................................................... 94
TABLA 24: ACTIVIDADES DE OPERACIN HABITUAL DE LA INFRAESTRUCTURA .................................................. 94
TABLA 25: PLAN GLOBAL DE DIFUSIN Y CAMBIO ........................................................................................ 117
TABLA 26: RIESGOS DEL PROYECTO DE MEJ ORA DEL PROCESO DE SOFTWARE .............................................. 122
TABLA 27: COSTOS DEL PROYECTO DE MEJ ORA DEL PROCESO DE SOFTWARE ............................................... 127
TABLA 28: ROADMAP DEL PROYECTO DE MEJ ORA DEL PROCESO DE SOFTWARE ............................................ 128




iv

NDICE DE FIGURAS

FIGURA 1: ESTRUCTURA DE EMPRESAS DEL HOLDING ..................................................................................... 2
FIGURA 2: ORGANIGRAMAS DE LAS REAS DE SISTEMAS ................................................................................ 3
FIGURA 3: REPRESENTACIN GRFICA DE IDEF0 ........................................................................................ 11
FIGURA 4: REPRESENTACIN GRFICA DEL MODELO DE CICLOS DE TRABAJ O .................................................. 12
FIGURA 5: MODELO DE PLANEACIN ESTRATGICA ...................................................................................... 14
FIGURA 6: REPRESENTACIN GRFICA DEL MODELO DE LAS 5 FUERZAS DE PORTER ........................................ 15
FIGURA 7: LA CADENA DE VALOR ................................................................................................................ 16
FIGURA 8: SEGMENTACIN DE LOS USUARIOS ............................................................................................. 32
FIGURA 9: LNEA DE TIEMPO DE UN INCIDENTE ............................................................................................. 34
FIGURA 10: PROCESO DE PLANEACIN ESTRATGICA DE TI .......................................................................... 40
FIGURA 11: PROCESO DE ELABORACIN DEL PRESUPUESTO ......................................................................... 45
FIGURA 12: ADMINISTRACIN DE PROYECTOS CON METODOLOGAS GILES .................................................... 48
FIGURA 13: ADMINISTRACIN DE PROYECTOS CON METODOLOGAS TRADICIONALES ........................................ 49
FIGURA 14: PROCESO DE DESARROLLO Y ADMINISTRACIN DE REQUERIMIENTOS ............................................ 53
FIGURA 15: PROCESO DE DESARROLLO DE SOFTWARE CON METODOLOGA GIL ............................................. 55
FIGURA 16: PROCESO DE DESARROLLO DE SOFTWARE CON METODOLOGAS TRADICIONALES ........................... 56
FIGURA 17: PROCESO DE PRUEBAS CON METODOLOGA GIL ........................................................................ 59
FIGURA 18: PROCESO DE PRUEBAS CON METODOLOGAS TRADICIONALES ...................................................... 60
FIGURA 19: DIAGRAMA DE DESCOMPOSICIN PARA EL TESTING ..................................................................... 61
FIGURA 20: PROCESO DE MANTENCIN DEL SOFTWARE ................................................................................ 63
FIGURA 21: PROCESO DE GESTIN DE INCIDENCIAS ..................................................................................... 66
FIGURA 22: PROCESO DE GESTIN DE PROBLEMAS ...................................................................................... 68
FIGURA 23: PROCESO DE GESTIN DE INVENTARIO Y CONFIGURACIN ........................................................... 70
FIGURA 24: PROCESO DE PASO A PRODUCCIN ........................................................................................... 72
FIGURA 25: PROCESO DE GESTIN DEL CAMBIO PARA EQUIPOS DE ESCRITORIO .............................................. 73
FIGURA 26: DESCOMPOSICIN DEL PRODUCTO DE SOFTWARE PARA EL CONTROL DE VERSIONES ...................... 75
FIGURA 27: PROCESO DE GESTIN DE LA DISPONIBILIDAD Y LA CONTINUIDAD .................................................. 77
FIGURA 28: CICLO DE GESTIN DEL NIVEL DE SERVICIO ................................................................................ 78
FIGURA 29: PROCESO DE GESTIN DEL NIVEL DE SERVICIO ........................................................................... 79
FIGURA 30: PROCESO DE GESTIN DE LAS FINANZAS ................................................................................... 81
FIGURA 31: PROCESO DE GESTIN DE PROVEEDORES ................................................................................. 87
FIGURA 32: ACTIVIDADES GENERALES DE UN PROYECTO DE INFRAESTRUCTURA ............................................. 91
FIGURA 33: J ERARQUIZACIN DE LAS ACTIVIDADES DE INFRAESTRUCTURA ..................................................... 91
FIGURA 34: ORGANIGRAMA GENERAL, OPCIN 1 .......................................................................................... 98
FIGURA 35: ORGANIGRAMA GENERAL, OPCIN 2 .......................................................................................... 99
FIGURA 36: ORGANIGRAMA GENERAL, OPCIN 3 ........................................................................................ 100
FIGURA 37: ORGANIGRAMA SUBGERENCIA RELACIN 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

ECUACIN 1: TIEMPO DE NO DISPONIBILIDAD DE LOS SERVICIOS FIJ OS ........................................................... 32
ECUACIN 2: PORCENTAJ E DE DISPONIBILIDAD DEL SERVICIO FIJ O ................................................................. 32
ECUACIN 3: PORCENTAJ E DE PRODUCTOS ENTREGADOS DENTRO DE PLAZO ................................................. 50
ECUACIN 4: PORCENTAJ E DE PRODUCTOS ENTREGADOS FUERA DE PLAZO ................................................... 50
ECUACIN 5: PORCENTAJ E DE AVANCE DEL PROYECTO ................................................................................ 50

1

Captulo 1 - Introduccin

1. La i ndustria de l a pul pa y el papel

La industria de la pulpa y el papel es un sector que se encuentra en plena madurez,
orientado a la produccin de commodities, en un mercado en que los precios son
extremadamente voltiles, 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 mrgenes se han visto deteriorados producto de los
excesos de capacidad existentes.

Los crecimientos de capacidad de las grandes empresas se realizan mediante la
adquisicin de compaas ms pequeas, existiendo una tendencia continua a la
globalizacin [12].

Desde el punto de vista de los productos existe una tendencia a focalizarse ms que en
diversificarse [27]. Las grandes lneas de productos del sector son: maderas, celulosa,
papel para impresin y escritura, papel para corrugar, papel tissue, papel de diario y
cartulinas.

Las empresas del sector se caracterizan por ser altamente dependientes de la logstica,
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 generacin de valor para los clientes y
accionistas.
c) Necesidad de focalizarse en el negocio.
d) Generar economas de escala.
e) Necesidad de integrarse con la cadena de suministros.
f) El aumento en la dependencia de las Tecnologas de Informacin (TI). En
general, se cuenta con sistemas antiguos que incorporan prcticas y procesos
que se encuentran obsoletos.
g) Necesidad de focalizarse en el cliente ms que en el proceso productivo.
h) Mantener una relacin armoniosa con el medio ambiente.

En este contexto, las Tecnologas de Informacin juegan, aparentemente, un rol
secundario, sin embargo la tendencia es la incorporacin de tecnologas que faciliten la
gestin de la informacin, la automatizacin y la operacin 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.

Geogrficamente, las empresas y sus plantas productivas estn distribuidas a lo largo
de Chile y en el extranjero, con plantas productoras en Argentina, Uruguay, Per, Brasil
y Mxico.
2




Figura 1: Estructura de empresas del holding

2. Situaci n Inici al

Cada filial posee un rea de informtica propia e independiente. A nivel de la matriz,
existe una gerencia de informtica que entrega a las filiales los lineamientos base en
cuanto a polticas de seguridad, licenciamiento de software y servicios centralizados.
Adems, define y mantiene los sistemas corporativos y administra la red de datos
corporativa.

Hay 458 aplicaciones distintas, de los cuales 60% estn relacionadas con el apoyo a la
administracin de los negocios y un 40% apoyan la operacin de plantas productivas.
Estas aplicaciones son soportadas por 357 servidores, que se encuentran distribuidos
geogrficamente en Chile y en el extranjero.

Cada rea informtica posee su propia organizacin, identificndose tres tipos
genricos:

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

3. Una subgerencia con dos reas dependientes: soporte y coordinacin. Siendo
responsabilidad de la coordinacin la realizacin de proyectos informticos con
terceros.

La representacin de esta organizacin se visualiza en la figura 2. Las lneas punteadas
indican que existe una relacin de dependencia implcita.



Figura 2: Organigramas de las reas de Sistemas

El rea de soporte es la encargada de entregar el soporte a usuarios, administrar la
infraestructura informtica y asegurar la continuidad de los servicios. Las reas de
desarrollo y mantencin se encargan del mbito del software. No se presentan
unidades que gestionen la relacin con el cliente.

Las funciones realizadas por las unidades informticas son equivalentes entre s y son:

a) Realizar la planificacin estratgica de TI para la filial, a travs de un proceso
informal y medianamente definido, cuyo objetivo final es la obtencin del
presupuesto anual de TI.
b) Mantener y operar la infraestructura informtica.
c) Entregar soporte a los usuarios, sistemas y aplicaciones.
d) Desarrollar aplicaciones propias y con terceros.
e) Mantener la seguridad informtica.
f) Entregar soporte a la gestin (captura de requerimientos y anlisis de sistemas).
4

g) Entregar consultora tecnolgica.

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 situacin para procesos bsicos de software.



Tabla 1: Situacin inicial de los procesos de software

La administracin y desarrollo de requisitos consiste solamente en la recepcin directa
desde el usuario y la aprobacin por parte de un comit. En el caso de las metodologas
de desarrollo, se depende exclusivamente del desarrollador, lo que provoca que se
presenten diferencias respecto al enfoque de solucin y a la manera como es
construido el software. Las pruebas de software son prcticamente nulas. Respecto a la
mantencin de software, el proceso consiste en la recepcin formal de un requerimiento
de cambio, previa aprobacin en caso que signifique un gasto, no existe una definicin
para la asignacin de tareas y manejo de prioridades. Tampoco existe documentacin
tcnica del software. Adems, no se manejan conceptos de calidad y la gestin de
proyectos depende del enfoque y voluntad de cada jefe de proyecto.

Para el caso de soporte, los procesos definidos no son estndares en la organizacin,
presentndose distintos niveles de profundizacin y formalizacin en las filiales. En la
tabla 2, se presenta un resumen de la situacin con los procesos que han sido
identificados.

5



Tabla 2: Situacin inicial de los procesos de soporte

En resumen, si bien hay procesos definidos, existen patologas en cuanto a la
implementacin, estas son:

a) Las herramientas de software utilizadas para el soporte del proceso no son
adecuadas para el tamao 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 ms que en cmo
hacerlo.
d) Los procesos de administracin 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 formalizacin 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 direccin.
g) Existe resistencia de las personas para adoptar procesos estructurados y
normas.

Adems, existen diferencias en cuanto al enfoque con que cada unidad informtica
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 tcnicos de informtica.

Pese a estas patologas, una fortaleza que destaca es el conocimiento de los negocios
que tiene el personal de informtica, adems del compromiso y dedicacin a las labores
que les han sido encomendadas.
6


Culturalmente, hay un sentido altamente jerrquico respecto a las responsabilidades,
donde la mayora de las decisiones son tomadas por Gerentes y Subgerentes.

En general, el holding se caracteriza por tener un carcter conservador desde el punto
de vista adopcin de nuevas tecnologas. Sin embargo, se encuentra abierto a los
estndares que apoyen la mejora de procesos y aseguren la calidad de sus productos.

3. Defi nicin del Probl ema

El holding matriz ha definido la creacin de una nueva empresa que proveer a todas
las filiales los servicios de: contabilidad, recursos humanos, tecnologas de informacin
y comunicaciones (TIC) y compras.

Todas las filiales del holding sern atendidas por esta nueva empresa, sin poder ellas
optar por otro proveedor o mantener un servicio propio. Tampoco se podrn proveer
servicios fuera del conglomerado de empresas y se deber operar con procesos y
aplicaciones estndares 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 Tecnologas de
Informacin, se ha contratado a otra empresa consultora especialista en procesos TI
que apoyar la definicin 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 provisin de servicios el
estndar ITIL, no definindose un marco para los procesos de desarrollo de software.

Esta tesis se concentra en la definicin global de procesos, transicin y organizacin del
rea de tecnologas de informacin bajo el paradigma de servicios compartidos, siendo
el objetivo general de este trabajo el disear los procesos y la estructura organizacional
del rea que prestar los servicios compartidos de informtica a todas las filiales del
holding, tomando como marco de referencia modelos de servicio y calidad estndares
de la industria.

Especficamente, los objetivos a satisfacer son:

a) Disear la estructura organizacional de tecnologas de informacin 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 tecnologas de informacin que
prestar los servicios, utilizando como marco de referencia modelos y estndares
de calidad y buenas prcticas existentes en la industria.
c) Definir el plan de transicin que implementar el cambio organizacional.

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

marco de referencia, de algn modelo o estndar de calidad de software existente en la
industria.

En esta tesis, no se contempla la implementacin y/o certificacin de modelos y/o
estndares de calidad. Este proyecto supone una transformacin fuerte en trminos de
procesos, organizacin, cultura organizacional y paradigma, por lo que una adopcin
completa de algn 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 tcticos, a los cuales se
contribuira directamente [5]:

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

4. Hi ptesis

El concepto de servicios compartidos, se ha convertido en un estndar global como
modelo de organizacin de las unidades de apoyo al negocio para las corporaciones,
en particular las tecnologas de informacin. En Chile, hay al menos 10 empresas
operando bajo el esquema y varias otras en diferentes grados de implementacin y
avance [5].

La hiptesis de trabajo es mostrar que mediante la estructuracin e implantacin de
procesos basados en estndares, orientados a la provisin de servicios de tecnologas
de informacin 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) Estandarizacin y optimizacin de procesos.
b) Mejores condiciones para la implementacin de soluciones tecnolgicas,
estndares y transversales, con la posibilidad de generar sinergias.
2. Simplificacin de la operacin y el control, a partir de:
a) La implementacin de un modelo nico de operacin.
b) Aplicaciones informticas estandarizadas.
c) Focalizacin en las actividades propias de cada empresa del holding.
3. Reduccin de los costos de operacin de las unidades de apoyo al negocio.
4. Optimizacin de los procesos a travs de la reingeniera, estandarizacin y
consolidacin de los mismos generando economas de escala para minimizar los
costos operativos
1
.


1
De acuerdo a Ernst & Young, compaas con servicios compartidos han reducido los costos asociados a la
prestacin de servicios de soporte al negocio entre un 25% y un 45%
8


Para evaluar el cumplimiento de la hiptesis propuesta, se utilizarn los siguientes
mecanismos de evaluacin:

1. A nivel de procesos: Comparacin cualitativa entre la situacin inicial versus la
situacin con los procesos implantados, y el cumplimiento de los objetivos
propuestos para esta tesis.
2. A nivel de servicio: Comparacin cualitativa de la situacin inicial versus la
situacin con el servicio compartido de tecnologas de informacin en
funcionamiento.
3. A nivel de costos: Comparacin entre los costos en tecnologas de informacin
de la situacin inicial y los obtenidos despus de la implementacin de los
procesos para una planta industrial promedio con 500 usuarios.


La evaluacin de estos puntos ser abordada en el captulo 7.


9

Captulo 2 Revisin Terica y Metodologa

1. Revisin Terica
1.1 Anlisis, Modelamiento y Diseo 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 lgicamente
relacionadas que utilizan recursos de la organizacin 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 gua para el desarrollo evolutivo de procesos.
b) Un modelo organizacional orientado al mejoramiento contino.
c) Una estructura confiable de diagnostico de procesos y evaluacin de su
capacidad.

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

Nivel 1 (Inicial): No hay procedimientos formales, ni estimacin de costos, ni
planificacin y programacin de procesos. No hay mecanismos de administracin que
aseguren que se siguen procedimientos. Las herramientas no estn bien integradas y el
control de cambios no es riguroso. La administracin superior no entiende los puntos
clave del proceso.

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

Nivel 3 (Definido): Los procesos estn 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
mnimo de medidas de calidad y productividad.

Nivel 5 (Optimizante): El mejoramiento contino realimenta a los procesos. La
recoleccin de informacin es automatizada. La evidencia numrica es usada para
justificar la aplicacin de tecnologa a las tareas crticas. Se realizan anlisis rigurosos
de tipo causa-efecto y prevencin de defectos.

10

Para el diseo y modelamiento de procesos, existen una diversidad de mtodos y
tcnicas, de los cuales se han revisado los principales.

1.1.1 SADT (Structured Analysis and Design Technique)

Desarrollada a finales de la dcada del 70, SADT es una tcnica de anlisis y diseo 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
estn 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 jerrquico del sistema.
e) Glosario de definiciones y trminos utilizados.
f) Condiciones de activacin.

Se utiliza descomposicin funcional para la jerarquizacin 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 tambin 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 mtodos 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 investigacin de tecnologas.

Los mtodos se clasifican de acuerdo al tipo de modelamiento que se quiera realizar
[32]:

IDEF: Es un mtodo diseado para modelar las decisiones, acciones y actividades de
una organizacin o sistema, es derivado de SADT.

11



Figura 3: Representacin grfica de IDEF0
2


En la figura 3, el cuadro representa a la funcin o actividad del sistema u organizacin,
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 funcin y las flechas por debajo
corresponden a los mecanismos. Al conjunto de entradas, salidas, controles y
mecanismos se les denomina ICOM.

IDEF produce una representacin organizada de las funciones y actividades y es
independiente del tiempo y la organizacin. Captura lo que se hace o no se hace y
utiliza la nocin de descomposicin funcional para modelar las actividades o funciones.
La descripcin de los detalles y la temporalidad de los procesos se especifica utilizando
IDEF3.

IDEF1: Es un mtodo de modelamiento de la informacin. Un modelo de informacin
representa la estructura y semntica de la informacin dentro del sistema u
organizacin modelada. Generalmente se utiliza para identificar qu informacin es la
que actualmente es gestionada por la organizacin, determinar cules problemas son
causados por falta de informacin y especificar qu informacin ser administrada en la
implementacin.

IDEF1X: Es un mtodo para disear bases de datos relacionales, posee una sintaxis
diseada para soportar construcciones semnticas necesarias para desarrollar
esquemas conceptuales. Un esquema conceptual es una definicin integrada de un
dato de la organizacin independiente de su representacin computacional.

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

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

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

El mtodo contempla dos modalidades: flujo de procesos y redes de estado-transicin
de objetos. La primera modalidad captura el conocimiento de cmo los componentes
funcionan en una organizacin, la segunda resume las transiciones permitidas para un
objeto a travs de un proceso particular.

IDEF4: Es un mtodo de diseo orientado a objetos que apoya la correcta aplicacin de
la programacin orientada a objetos. IDEF4 provee un marco para el desarrollo de
software con orientacin a objetos. Conceptualmente, consiste en dos submodelos: el
de clases y el de mtodos. El submodelo de clases contiene los diagramas de tipos,
herencia, protocolos e instanciacin. El submodelo de mtodos contiene los diagramas
de taxonoma para los mtodos y los diagramas de contratos y clientes.

IDEF5: Es un mtodo especficamente diseado para apoyar la creacin, modificacin y
mantencin de ontologas.

1.1.3 Ciclos de Trabajo

El modelo de ciclos de trabajo fue desarrollado por la empresa Action Tech en torno a la
semntica de compromisos y cumplimiento [31]. Los procesos son redes de acciones y
compromisos. El ciclo parte desde un cliente con una peticin a un ejecutor, luego el
cliente y el ejecutor negocian la realizacin (promesas mutuas), el ejecutor realiza las
acciones para cumplir sus promesas, declarando el termino del trabajo. Por ltimo, el
cliente realiza la accin de satisfaccin, de acuerdo a las promesas (condiciones de
satisfaccin) [31]. En la figura 4, se muestra la representacin grfica de este modelo.



Figura 4: Representacin grfica del modelo de ciclos de trabajo
3


3
Fuente: VARAS, SAMUEL. 2003. Apuntes del curso Tecnologas de Informacin y Rediseo de Procesos.
Departamento de Ingeniera Industrial. Universidad de Chile.
13

1.1.4 UML (Unified Modeling Language)

UML es un leguaje grfico 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 caracterstica de UML es que es orientado a objetos. Las representaciones son
realizadas mediante diagramas, existiendo varios tipos [10]:

1. Diagrama de clases: Es la representacin de los bloques de construccin ms
importantes del sistema y sus relaciones. La unidad bsica es la clase, que es
una descripcin de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semntica.

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

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 descripcin de un
conjunto de secuencias de acciones donde cada secuencia representa la
interaccin 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 colaboracin: Se utilizan para modelar aspectos
dinmicos 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 colaboracin
destacan la organizacin estructural de los objetos que envan y reciben
mensajes. Ambos diagramas son semnticamente equivalentes.

5. Diagrama de estados: Describen grficamente los eventos y los estados de los
objetos. A la relacin entre dos estados se le llama transicin, 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 dinmicos de un
sistema, mostrando el flujo de control entre actividades. Este tipo de diagrama es
una especializacin de los diagramas de estado, organizados respecto de las
acciones. Son usados para especificar: mtodos, casos de uso, procesos de
negocio.

7. Diagrama de componentes: Muestra las relaciones entre los componentes de un
sistema, es decir la interaccin de la parte fsica y reemplazable de un sistema,
que conforma un conjunto de interfaces y proporciona la realizacin de dicho
conjunto.

8. Diagrama de despliegue: Describe la arquitectura fsica del sistema durante la
ejecucin, en trminos de: procesadores, dispositivos, componentes de software.
14

Adems, describen la topologa del sistema, la estructura de los elementos de
hardware y software que ejecuta cada uno de ellos.

1.2 Proceso de Planificacin Estratgica

Para abordar los procesos de planificacin estratgica es necesario realizar la distincin
entre estrategia y el proceso de formacin de la estrategia. Entenderemos por
estrategia de negocio, a un conjunto bien coordinado de programas de accin que
apuntan a asegurar una ventaja sostenible en el largo plazo. Un proceso de formacin
de la estrategia es un conjunto de actividades tendientes a definir la estrategia de un
negocio, las prioridades y asignacin de recursos y los programas de accin generales
[11]. Un proceso de planeacin estratgica, consiste en:

a) La definicin y declaracin de la misin y la visin.
b) El anlisis del medio externo e interno.
c) La formulacin de los planes y programas generales de accin, incluyendo la
estrategia del negocio.
d) La programacin y evaluacin de los programas de accin propuestos y fijacin
de las prioridades para la asignacin de los recursos.
e) La asignacin de recursos y la elaboracin del presupuesto.

La figura 5 presenta el aspecto general del proceso.



Figura 5: Modelo de planeacin estratgica
4



4
Fuente: JORRAT, MICHAEL. 2000. Apuntes del curso Evaluacin de Proyectos. Departamento de Ingeniera
Industrial. Universidad de Chile.
15

Existen herramientas que facilitan el proceso de planeacin estratgica. Para el anlisis
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 negociacin de los
compradores y el poder de negociacin de los proveedores. Estas cinco fuerzas
delimitan, precios, costos y requerimientos de inversin, que constituyen factores
bsicos 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 anlisis financiero,
el anlisis de factores externos, etc.



Figura 6: Representacin grfica del modelo de las 5 fuerzas de Porter
5


Para el anlisis interno, es decir, el examen sistemtico 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 caracterizacin de las actividades realizadas por una unidad
estratgica de negocios [11]. Las tareas son clasificadas en actividades primarias y
actividades de apoyo. Las actividades primarias son aqullas relacionadas con el
movimiento fsico de materias primas y productos terminados, en la produccin 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 logstica 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 Evaluacin de Proyectos. Departamento de
Ingeniera Industrial. Universidad de Chile.
16

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



Figura 7: La cadena de valor
6



En el mbito de la informtica, la planeacin estratgica consiste en la identificacin e
implementacin de la tecnologa requerida por el negocio para la consecucin de su
misin, objetivos y estrategias [8].

Las herramientas mencionadas anteriormente, apoyan la formulacin de la estrategia
informtica desde la perspectiva de entender el negocio para conseguir el alineamiento
de las iniciativas tecnolgicas. Por lo tanto, el resultado de la planeacin en informtica,
tiene relacin con la manera con que son gestionados los recursos de TI, la arquitectura
informtica del negocio, el portafolio de proyectos, el presupuesto y el plan de
infraestructura.

1.3 Modelos y Prcticas 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 gua para
mejorar los procesos de la organizacin 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 bsicos de produccin de software. Si bien, existen
diversas metodologas, el objetivo final en esta etapa es concentrarse en los procesos
globales ms que en el detalle.


6
Fuente: Fuente: JORRAT, MICHAEL. 2000. Apuntes del curso Evaluacin de Proyectos. Departamento de
Ingeniera Industrial. Universidad de Chile.
17

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

1.3.1 CMMi (Capability Maturity Model Integration)

El modelo, desarrollado por la Universidad de Carnegie-Mellon, tiene como propsito
proveer una gua para mejorar el proceso de una organizacin y la capacidad para
administrar el desarrollo, adquisicin y mantencin de productos y servicios [7]. Ayuda a
la organizacin a examinar la efectividad de sus procesos y establece las prioridades de
mejoramiento [30]. Provee una terminologa comn y una metodologa integrada para la
auditoria de los procesos [30]. Desde el punto de vista del negocio, CMMi, beneficia a la
organizacin en:

a) Reducir la integracin de sistemas y el tiempo de pruebas.
b) Permitir la integracin entre varias funciones y mbitos de la ingeniera.
c) Emplear principios de ingeniera de sistemas para el desarrollo de software.

Desde el punto de vista tcnico, los principales beneficios son:

a) Focalizacin en la gestin y desarrollo de los requisitos.
b) Focalizacin en el diseo y desarrollo.
c) Incorporacin de la gestin de riesgos.
d) Incorporacin de medidas y anlisis de mtricas.

CMMi define cuatro disciplinas: ingeniera de software, ingeniera de sistemas,
proveedores y desarrollo integrado de procesos y productos [30]. Provee 5 niveles de
madurez donde cada nivel es una capa en la fundacin para un proceso de
mejoramiento continuo, comenzando por prcticas y reas de proceso bsicas de
administracin y progresando a travs de un camino predefinido y probado de niveles
sucesivos [30]. Cabe sealar que en la medida que se avanza en madurez, la calidad y
productividad aumenta y el re-trabajo junto con el riesgo van disminuyendo. En la tabla
3 se presenta un resumen del modelo.

18



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


1.3.2 Normas ISO

ISO es una organizacin mundial de cuerpos de estandarizacin a nivel mundial. Su
misin es proveer estandarizacin internacional para facilitar el intercambio de bienes y
servicios [1]. Para el caso de los procesos de Tecnologas de Informacin, pueden ser
aplicables dos normas: ISO 9000:2000 de carcter general e ISO 9126 para ingeniera
de software, las que son revisadas a continuacin.

1.3.2.1 ISO 9000:2000

Es un conjunto de normas utilizadas para establecer la gestin de calidad de una
organizacin, satisfacer los compromisos entre la organizacin y sus clientes y lograr
mejoramiento en el desempeo de una empresa [1]. Se compone de 3 partes:

a) ISO 9000, que describe los fundamentos y la terminologa.
b) ISO 9001, que describe los requisitos.
c) ISO 9004, referente a las directrices para la mejora del desempeo.

Dentro de los beneficios esperados de la adopcin de este modelo, se encuentran:
mejor control de la gestin, mayor facilidad para eliminar y percibir los problemas de
procedimiento, aumento de la eficacia y una mejor percepcin de los problemas de
calidad [1].


7
Fuente: PINTO, FERNANDO. 2004. Apuntes del curso Introduccin a CMMi. Departamento de Ciencias de la
Computacin. Universidad de Chile.
19

ISO 9000, define una serie de requisitos que se orientan a la elaboracin y mantencin
de procedimientos relacionados con el producto y el proceso. Lo que se alcanza,
mediante la implantacin de un sistema de gestin de calidad y la obtencin como
resultado final del manual de calidad.

Si bien, la norma es aplicable a procesos de software, por su carcter general, no
define guas ni opciones que provean una referencia para ese tipo de procesos.

1.3.2.2 ISO 9126 para Ingeniera 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, precisin,
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, aceptacin 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,
adecuacin, reemplazabilidad.

2. ISO 9126-2:2003, que provee mtricas externas para la medicin de las seis
caractersticas de calidad definidas en ISO 9126-1. Las mtricas externas, miden
el comportamiento de un sistema computacional que incluye el software y las
mediciones de la calidad, en el uso bajo un contexto especfico [33].

3. ISO 9126-3:2003, que provee mtricas internas para la medicin de las seis
caractersticas de calidad definidas en ISO 9126-1. Las mtricas internas miden
el software como tal, bajo los procesos de requisitos, evaluacin de productos y
medidas de calidad [33].

4. ISO 9126-4:2004, que provee mtricas para medir el uso de calidad de los
procesos de ingeniera 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 prcticas comnmente aceptadas por la industria para
la provisin y administracin de servicios de tecnologas de informacin. Promueve un
enfoque desde la perspectiva de la calidad, para conseguir efectividad en el negocio y
eficiencia en el uso de los sistemas de informacin [26]. Se basa en la experiencia
20

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

Define cuatro reas de macro procesos que a su vez definen procesos de negocio para
la funcin de tecnologas de informacin, 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 informtica, vale decir:
gestin de incidencias, gestin de problemas, gestin del inventario y la
configuracin, gestin del cambio, control y distribucin 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 informtica, vale decir:
gestin de la disponibilidad, gestin de la continuidad, gestin de los niveles de
servicio, gestin de las finanzas TI, gestin de la capacidad y la gestin de
proveedores.

3. Infraestructure & Security Management: El objetivo de este macro proceso es
definir y entregar los procesos relacionados con la administracin 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
gestin e implementacin puede ser llevada a cabo con metodologas orientadas
al desarrollo, mantencin y adquisicin de software. Pero, no define ni
compromete prcticas para el proceso de produccin de software, las que han de
ser seleccionadas o definidas segn cada organizacin.

1.5 Criterios de Seleccin de Herramientas

Para efectos de este trabajo y dentro del conjunto de mtodos presentados para el
modelamiento de procesos, se debe seleccionar uno o una combinacin de ellos. Los
criterios de seleccin de la herramienta a utilizar son los siguientes:

a) La herramienta debe estar orientada al modelamiento de procesos de negocio.
b) Debe ser de fcil comprensin 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 estndar.
e) Debe proveer los elementos semnticos y grficos para modelar las decisiones,
acciones y actividades.

Para el caso del proceso de desarrollo de software, se especificar ms adelante el
modelo o estndar a utilizar, sin embargo, es importante sealar los criterios de
seleccin:

a) Debe ser un modelo o estndar de la industria.
21

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

Por ltimo, para los procesos de planeacin estratgica, es claro que se deben tomar
elementos que permitan su aplicacin al mbito de la informtica, en ese sentido, el
criterio es utilizar una combinacin de las herramientas comnmente utilizadas de
planificacin.

2. Metodol oga
2.1 Enfoque de Trabaj o

Este trabajo, consiste en el cambio y redefinicin de los procesos de negocio del rea
de tecnologas de informacin del holding de empresas. Siendo el desafo el
transformar a la organizacin inicial de TI desde unidades no sinrgicas distribuidas a
una unidad de servicios con orientacin al cliente, planteando procesos que sean
acordes a la cultura y realidad de la empresa y que estn basados en modelos y/o
estndares de la industria, sin que las empresas clientes sufran un alto impacto en el
servicio que actualmente estn recibiendo.

Existen varias aproximaciones para afrontar el cambio de los procesos en la
organizacin, en particular, existe una serie de conceptos que son utilizados
indistintamente para representar el fenmeno de cambio de los procesos del negocio,
por ejemplo: reingeniera de procesos de negocio, mejoramiento de procesos,
transformacin del negocio, innovacin de procesos y rediseo de procesos de negocio.
Pero, Qu es el cambio de los procesos de negocio? Existen, una serie de
definiciones, que ayudan a entender este fenmeno [15]:

a) Es el rediseo y replanteamiento radical de los procesos de negocio para
alcanzar mejoras dramticas de rendimiento.
b) Es la reconfiguracin del negocio usando TI como eje central.
c) Es el anlisis y diseo de workflows y procesos basados en equipos dentro o
entre organizaciones.
d) Es una iniciativa estratgica de la organizacin para (re)disear los procesos de
negocio para alcanzar ventajas competitivas, distinguiendo el alcance desde la
mejora de procesos hasta el diseo de nuevos procesos, contingentes al grado
de cambio socio-tecnolgico requerido.

Para afrontar proyectos que significan cambios en los procesos de negocio, se utiliza
ampliamente el enfoque de re-ingeniera. La re-ingeniera es definida como el rediseo
radical de los procesos de negocio transversales a una organizacin con el objetivo de
obtener ganancias o ahorros en uno o ms rdenes de magnitud, usualmente apoyado
por tecnologas de informacin. Otra definicin, ve a la re-ingeniera como una
transformacin organizacional general [14].

22

Cabe sealar, que uno de los aspectos importantes de la re-ingeniera es que parte de
procesos de negocio que se encuentran en funcionamiento, en contraste con la
innovacin de procesos, que parte de procesos que no existen o no han sido definidos.

Como este proyecto se desarrollar en una organizacin en funcionamiento, en la que
se introducirn cambios, se plantea el uso de un enfoque de re-ingeniera de procesos.
Esta metodologa establece los siguientes pasos generales [14]:

1. Definicin del proceso a ser estudiado.
2. Evaluacin de la situacin actual.
a) Documentar el proceso actual.
b) Diagnosticar patologas.
3. Definicin y evaluacin de las reas de rediseo.
a) Explorar opciones de diseo.
b) Disear el nuevo proceso.
c) Disear la estructura organizacional asociada al proceso.
4. Implantacin del rediseo propuesto.
5. Puesta en marcha y operacin.
a) Evaluacin.
b) Mejora continua.

Entonces, para realizar este proyecto y en concordancia con las necesidades de la
organizacin, se plantea, a continuacin, la estrategia y metodologa para el re-diseo
de los procesos y la definicin de la estructura organizacional.

2.2 Estrategia del Proyecto

La estrategia del proyecto es la definicin de la manera en cmo ser enfrentado este
trabajo, por lo tanto, es necesario distinguir entre las actividades propias del proyecto y
las actividades de gestin del proyecto.

2.2.1 Actividades de Gestin del Proyecto

Para la direccin general del proyecto, la empresa ha definido la formacin 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
consultora. La funcin 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 tomarn.

El equipo de proyecto, estar compuesto por un jefe de proyecto por parte del rea de
tecnologas de informacin 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 participacin del Gerente de servicios TIC
y el personal que haya sido escogido como Subgerente o J efe para cada rea a definir.
La funcin del equipo de proyecto, es definir e implementar los procesos y
procedimientos de la nueva organizacin de tecnologas de informacin.
23


El seguimiento del proyecto se har mediante reuniones semanales de coordinacin del
equipo de proyecto y reuniones mensuales del comit ejecutivo. Todas las reuniones
generaran minutas, las que debern ser aprobadas. Adems, 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 mnimo de comunicaciones
a la organizacin:

a) Inicio del proyecto.
b) Estado de situacin despus de 1 mes de ejecucin.
c) Difusin de la nueva organizacin.
d) Estado de situacin despus de 1 mes de difundida la organizacin.
e) Estado de situacin mensual dentro de la etapa de transicin.
f) Estado de situacin una vez que la nueva organizacin sea considerada que se
encuentra en rgimen.

Los comunicados se entregarn mediante un boletn impreso a todo el personal del
rea de tecnologas de informacin. Adems, sern publicados electrnicamente para
facilitar la difusin. En el caso de la difusin de la organizacin, se realizar una reunin
plenaria con todo el personal de tecnologas de informacin, los cargos sern
comunicados personalmente por cada Subgerente de rea.

Para la difusin 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 ms de una. Se
contempla la participacin y difusin a las jefaturas, quienes posteriormente debern
capacitar al personal que tienen a cargo.

2.2.2 Actividades Propias del Proyecto

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

Fase 1: Levantamiento

Durante esta fase se realiza la evaluacin y levantamiento de la situacin actual, con el
objeto de entender la problemtica de la organizacin. Se diagnostican las patologas y
se rescatan los procesos o elementos que puedan servir para la nueva organizacin. La
obtencin de la informacin ser a travs de entrevistas con personal clave de cada
rea y la obtencin de documentacin previa segn sea el caso.

En el captulo 1, se ha presentado un resumen de los puntos ms relevantes del
levantamiento de la situacin inicial.


24

Fase 2: Definicin, Anlisis y Diseo de Procesos

En esta fase, se definirn 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 seleccin que se propondr ms adelante en este captulo.
Los resultados de esta etapa son presentados en el captulo 3.

Esta actividad, ser realizada en conjunto con la Gerencia TIC y el personal que sea
designado como lder de la nueva estructura. El resultado de esta etapa son los
procesos, la organizacin y la planificacin estratgica del rea TIC. Se presentarn los
procesos definidos en esta etapa en forma global.

Fase 3: Transicin

La fase de transicin consiste en la puesta en marcha, implementacin y adopcin
paulatina de los procesos mediante un plan de transicin y cambio. Este ser
presentado en el captulo 5.

J unto con lo anterior, se implementa la nueva estructura organizacional, la que ser
presentada en el captulo 4.

Fase 4: Prestacin de Servicios

En esta fase el servicio se encuentra en operacin. Sin embargo, es necesario definir
procesos de mejora continua con el objeto de entregar servicios que sean mejores en el
tiempo. En el captulo 6, se plantear una estrategia para la mejora del proceso de
software, cuya intencin es dar pie para la definicin y adopcin de procesos de mejora
continua en el futuro.

2.3 Seleccin de Herramientas Metodol gicas

De acuerdo a los criterios de seleccin 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 eleccin se basa
en que IDEF es una herramienta orientada al modelamiento de procesos, es
ampliamente utilizada y de fcil comprensin. 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 ms 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 carcter general no se encuentra
orientado para resolver la definicin de los procesos de software y debe ser interpretado
para ser adaptado a esta realidad, en cambio CMMi est pensado para solucionar dicha
problemtica.

25

CMMi provee de un mtodo de evaluacin 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
evaluacin de los atributos de calidad implica tener procesos mejores, sin embargo,
estos no son definidos por el estndar. En contraste, CMMi establece una gua para los
procesos y su institucionalizacin.

Por lo tanto, es claro que CMMi posee ventajas para la definicin de los procesos de
software, proveyendo una gua, cumpliendo con los criterios de seleccin mencionados
anteriormente, por ello, se utilizar como marco de referencia para la definicin de los
procesos bsicos de software.

En el caso del proceso de planeacin estratgica se han revisado una serie de
actividades que tienen relacin directa con un negocio. Si bien, un rea de informtica,
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 metodologa que
permita al servicio TIC apoyar a las empresas clientes en la elaboracin de un plan
informtico, teniendo en consideracin los siguientes elementos:

a) La definicin y declaracin de la misin y la visin.
b) El anlisis de la situacin actual de TI.
c) La formulacin de los planes y programas generales de accin, es decir: la
estrategia de gestin de recursos de TI, la arquitectura informtica del negocio, el
portafolio de proyectos, el presupuesto y el plan de infraestructura.
d) La programacin y evaluacin de los planes de accin propuestos y la fijacin las
prioridades para la asignacin de los recursos.
e) La asignacin de recursos y elaboracin el presupuesto.
26

Captulo 3 Diseo de Servicios y Procesos

1. Di seo de Servi ci os
1.1 Servicios TIC

El catlogo de servicios, es el conjunto de servicios que se proveern a las filiales. El
objetivo es entregar a los clientes una visin de la oferta de servicios TIC, su definicin
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 contratacin y la gestin, 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 informticos requeridos para que un
usuario pueda realizar sus labores habituales dentro de su organizacin. Por
ejemplo: PC, telfono, 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 organizacin. Por ejemplo: los proyectos que
implementan software nuevo, la propia gestin de las tecnologas de informacin,
las mantenciones que significan una evolucin en el software que est en
funcionamiento, etc.

Esta clasificacin tiene por objetivo facilitar el entendimiento de los usuarios respecto a
los servicios ofrecidos por TI. Otra opcin, puede ser una categorizacin de carcter
tcnico, pero no tendra sentido ya que tendera a confundir a los clientes ms que
aclararlos.

Los servicios que se presentan en la tabla 4, estn basados en la definicin comercial
que ha tomado la empresa. Si bien, pueden haber servicios que sean requeridos y que
no estn dentro del catlogo, estos eventualmente, pueden ser creados o contratados a
terceros, previa evaluacin tcnico-econmica.

Para cada tipo de servicio, se pueden definir agrupaciones y subservicios, lo que define
finalmente la oferta y por lo tanto el catlogo de servicios. La disponibilidad de los
servicios ser abordada en la seccin de niveles de servicio.

27



Tabla 4: El catlogo de servicios
8


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

1.2 Modelo de costos de los servicios

El objetivo es establecer un marco agregado para los costos, con la finalidad de
simplificar el entendimiento a los clientes finales, respecto a la facturacin 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 impresin 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 garanta del software.
e) Los servicios bsicos (agua, luz, electricidad, etc.) son de costo de la empresa
que recibe el servicio.
f) Pueden existir servicios de carcter corporativo y que pueden ser recibidos por
varias empresas simultneamente.
g) Pueden existir servicios de carcter particular y que pueden ser recibidos por una
empresa.
h) Los costos de los servicios pueden ser de carcter mensual o por nica vez.

Distinguiremos los costos entre gasto e inversin. La diferencia es que una inversin es
para bienes nuevos, realizada por nica vez y considerada contablemente como un
activo de la organizacin. En cambio, el gasto es de carcter 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) Instalacin de redes de datos y telefona nuevas.
d) Hardware.
2. Los gastos contendrn los siguientes tipos de costo:
a) Consultora, 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 carcter
temporal o indefinido.
d) Mantencin de redes de datos y telefona.
e) Mantencin de hardware.
f) Viajes, viticos y alimentacin.

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

29



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

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

Para el clculo del costo final, es necesario diferenciar entre servicios que son provistos
corporativamente, es decir, aquellos en que se utiliza una infraestructura tecnolgica
comn y por lo tanto podran ser prorrateados y servicios que son costeados localmente
para cada filial, es decir, aquellos que se proveen con la infraestructura tecnolgica
propia de la filial o son dirigidos puntualmente a esta.



30

El factor de prorrateo puede ser calculado segn las siguientes opciones:

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

La eleccin de una u otra opcin 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 asignacin de
los costos a los distintos servicios definidos.

31

1.3 Ni veles de Servicio

Para definir los niveles de servicio, es necesario entender la problemtica desde el
punto de vista del cliente final. En general, las personas perciben los servicios de
informtica desde el punto de vista del resultado, vale decir, evalan en trminos
absolutos lo que reciben, sin haber trminos medios, ni considerar elementos tcnicos
dentro de la evaluacin. 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 agrupacin de servicios propuesta en el
catlogo de servicios y definir una segmentacin 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 prdida 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 direccin de la
empresa cliente, es decir, su capacidad de reclamo ante la gerencia, frente a
prdidas 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
jerarqua dentro de la empresa y que frente a una prdida de servicio TI, el
impacto sobre el negocio es bajo. Esta categora, agrupa a usuarios de tipo
administrativo.
b) Usuario Crtico: Es una persona que no necesariamente posee una alta jerarqua
dentro de las empresas, pero que frente a una prdida de servicio TI, produce
un alto impacto sobre el negocio. Esta categora, agrupa a usuarios que tienen
directa relacin con los procesos de ventas, facturacin, operacin y productivos
de las filiales.
c) Usuario Especial: Es una persona que no necesariamente posee una alta
jerarqua y que frente a perdidas de servicio no produce impacto en el negocio,
sin embargo, tiene llegada con la alta direccin o posee una alta capacidad de
reclamo. Esta categora, agrupa a usuarios que sern identificados respecto a su
comportamiento de reclamo.
d) Usuario VIP: Es una persona que posee una alta jerarqua 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 categora, agrupa a Gerentes y
Subgerentes.


32



Figura 8: Segmentacin 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 ms importante que funcione
la impresora de etiquetas a que funcione Internet.

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

=
=
n
i
i i
I ND TND
1


Ecuacin 1: Tiempo de no disponibilidad de los servicios fijos

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

100 1 %
1
|
.
|

\
|
=

=
n
i
i i
t
I ND
DSF

Ecuacin 2: Porcentaje de disponibilidad del servicio fijo

Pero, cmo se calcula la importancia relativa del servicio? En principio, la importancia
de cada servicio debera ser idealmente asignada por cada usuario, sin embargo, esto
es impracticable en el corto plazo. Por ello, se asignar arbitrariamente una importancia
relativa en relacin a la segmentacin de los usuarios.
33


Para simplificar la escala de importancia, se definen cinco niveles: alta, media-alta,
media, media-baja y nula. Donde el nivel alto toma el mximo valor de importancia y el
nivel nulo toma el mnimo 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: Asignacin de valores a la importancia de un servicio

Ahora, se debe asignar la importancia de cada servicio respecto a la segmentacin de
usuarios definida, la que se muestra en la tabla 8. El criterio de asignacin de la
importancia es respecto al grado de uso estimado por cada tipo de usuario, segn el
comportamiento habitual observado empricamente dentro de las empresas.



Tabla 8: Importancia de los servicios segn la segmentacin 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 patrn de
comportamiento previo de los reclamos, por lo tanto el valor medio es el que mejor
podra representar la importancia de los servicios para este tipo de usuario.

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




Tabla 9: Niveles de servicio para los servicios fijos

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

Existe una serie de indicadores estndares 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
mrgenes razonables de agilidad, oportunidad y fluidez.

Desde el punto de vista del cliente, el inters 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 lnea de tiempo de acuerdo a la figura 9.



Figura 9: Lnea de tiempo de un incidente



35

Se distingue entonces:

a) t0: como el tiempo donde se inicia el proceso de soporte y que es gatillado por la
recepcin y atencin de una llamada en el service desk.
b) ta: como el tiempo en el que se asigno un incidente a un tcnico o especialista.
c) tr: como el tiempo de resolucin del requerimiento o incidente.
d) ts: como el mximo tiempo que un usuario puede esperar a que su requerimiento
sea resuelto sin reclamar.
e) T1: como el intervalo de tiempo entre la recepcin y asignacin del incidente o
requerimiento.
f) T2: como el intervalo de tiempo entre la recepcin y la solucin del
requerimiento.
g) T3: como el intervalo de tiempo de resolucin del requerimiento por parte de un
tcnico o especialista.
h) TMAX: como el intervalo de tiempo mximo 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 segmentacin propuesta para los servicios fijos, se puede definir
niveles de servicio escalonados de acuerdo al tipo de usuario que recibe la atencin,
segn los siguientes supuestos:

a) Usuario Normal: Como el perfil es de tipo administrativo, una prdida de servicio
no tiene impacto sobre el negocio, su capacidad de reclamo es limitada, por lo
tanto es el que tiene ms baja prioridad de atencin y niveles de servicio
inferiores a las otras categoras.
b) Usuario Crtico: Como produce un alto impacto sobre el negocio frente a una
prdida de servicio, es el que tiene mayor prioridad de atencin y por lo tanto el
mejor nivel de servicio.
c) Usuario Especial: Esta categora, debe tener niveles de servicio y prioridad
equivalentes al usuario normal, sin embargo debe considerarse, a nivel del
proceso, un mtodo de excepcin, que agilice los tiempos de atencin y
modifique prioridades, para el caso en que se detecte que este usuario pueda
establecer un reclamo frente a la alta direccin.
d) Usuario VIP: A pesar de que este segmento posee una alta jerarqua 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 atencin y los mismos niveles de
servicio que un usuario crtico, ya que el supuesto es que el usuario crtico
corresponde a personas que estn ligadas directamente con la operacin de las
fbricas, por lo tanto es ms impactante para el negocio una prdida de servicio
para ese tipo de personas, que para un usuario VIP.

Para reflejar la resolucin de requerimientos de soporte antes de un periodo de tiempo,
definiremos dos indicadores:

36

a) %RNR4, que corresponde al porcentaje de requerimientos no resueltos antes de
4 horas, sobre el total de requerimientos para el tipo de usuario VIP y crtico.
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 da de trabajo tiene 8 horas, por lo tanto
el objetivo de %RNR4 es incentivar la resolucin de requerimientos antes de 4 horas y
%RNR8 antes de 8 horas. Para efectos de clculo, ambos indicadores sern de
carcter semanal ya que la idea es privilegiar la resolucin.

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

a) Llamadas recibidas, que corresponde al total de llamados recibidos por la central
telefnica 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 conversacin, que corresponde a la duracin 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 estn relacionados directamente con la percepcin 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
percepcin y el proceso, es la cantidad de requerimientos que son resueltos
telefnicamente, por lo tanto se puede definir el porcentaje de resolucin, como la
cantidad de llamadas resueltas por el service desk, sobre el total de llamadas
contestadas. Entonces, de acuerdo a la segmentacin de usuarios propuesta y a la
definicin comercial de la empresa, los niveles de servicio se muestran en la tabla 10.

37



Tabla 10: Niveles de servicio para servicios variables

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

Para el caso del mantenimiento de corto plazo, el que consideraremos con un horizonte
de tiempo no mayor a 3 meses, no son aplicables los indicadores mencionados, ya que
este tipo de actividad la mayor parte del tiempo no es de carcter 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 definicin 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 mantencin de software de corto plazo

38

Respecto a los servicios de valor agregado, el enfoque es diferente. Este tipo de
servicio contempla proyectos y consultora, donde el cumplimiento de los compromisos
juega un rol relevante respecto a la percepcin del servicio. Entonces, para el lado del
cliente, ms que definir mtricas relacionadas con el proyecto o con el software, hay
que considerar la capacidad de cumplimiento y de gestin y la obtencin 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
consultoras que es realizado durante un ao para una determinada empresa y a la
particularidad, es decir, a lo que se espera recibir para un proyecto y/o consultora
puntual.

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

a) %PA, de carcter global, que corresponde al porcentaje de proyectos o
consultoras atrasadas respecto a la planificacin que fue aprobada por el
servicio y por el cliente, sobre la cantidad total de proyectos o consultoras en
ejecucin, para un cliente y dentro del ao. Responde a la pregunta: Cmo es
la gestin general de la cartera de proyectos?
b) %CC_PG, de carcter global, que corresponde al promedio del porcentaje de
cumplimiento de compromisos para la cartera de proyectos o consultoras
realizadas dentro del ao. Responde a la pregunta: Cmo es el cumplimiento
de compromisos del servicio?
c) %CC_P, de carcter particular, que corresponde al porcentaje de cumplimiento
de compromisos para un proyecto o consultora particular, sobre la cantidad total
de compromisos a la fecha de clculo del indicador. Responde a la pregunta:
Cmo es el cumplimiento de compromisos del proyecto o consultora?
d) DA, de carcter particular y corresponde a los das de atraso de un proyecto o
consultora particular respecto a su planificacin aprobada. Responde a la
pregunta: Cunto es el atraso del proyecto?

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



Tabla 12: Niveles de servicio para servicios de valor agregado

39

2. Di seo de Procesos

Para el desarrollo de los siguientes puntos y debido a la profundidad, extensin y
cantidad de temas que pueden ser tratados, se han considerado los aspectos ms
relevantes que pueden ser mejorados como parte de un primer diseo de los procesos
de TI. El enfoque de diseo de los procesos es de carcter general, sugiriendo guas
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 pl aneacin estratgica TIC para las filial es

2.1.1 Proceso para la planeacin estratgica

Tpicamente, la planificacin estratgica en TI se refiere a la identificacin e
implementacin de la tecnologa requerida por el negocio para la consecucin de su
misin, objetivos y estrategias [8]. El carcter multinacional, la cantidad de filiales y la
distribucin 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 consideracin la posibilidad de generar sinergia e intercambio tecnolgico
entre diferentes empresas.

Por otro lado, la velocidad de los avances tecnolgicos incorpora, adems, 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 tecnologas a
los procesos de negocio.

Se distinguen dos planeaciones segn el horizonte de tiempo: una de carcter
estratgico, que tendr relacin con la determinacin de los lineamientos tecnolgicos
de largo plazo y otra de carcter ms tctico, orientado a alinearse con los periodos de
planificacin anual de las filiales.

La planeacin de largo plazo, ser entendida como la identificacin de la tecnologa
requerida por el negocio para la consecucin de su misin, objetivos y estrategias. En
cambio, la de carcter tctico, tendr relacin con el plan de implementacin de dichas
tecnologas dentro de periodos anuales.

Un elemento importante a considerar, es la velocidad de cambio de la tecnologa, sin
embargo, el carcter conservador del holding respecto a la adopcin tecnolgica lo
sitan como una empresa netamente seguidora ms que adoptadora. Por lo tanto, el
horizonte de largo plazo ser el que considere tecnologa que se encuentre
ampliamente probada y desarrollada, es decir cuatro a cinco aos.

Tomando en consideracin lo mencionado en el aspecto terico de la planeacin
estratgica, se propone un proceso que sigue los siguientes pasos:

40

1. Definicin y declaracin de la misin y la visin de TI, con horizonte de tiempo de
largo plazo.
2. Anlisis de la situacin actual de TI.
3. Definicin de la situacin deseada de TI, con horizonte de tiempo de largo plazo.
4. Formulacin de los planes y programas generales de accin:
a) Estrategia de gestin de recursos de TI.
b) Arquitectura informtica del negocio, con horizonte de tiempo de largo
plazo.
c) Definicin del portafolio de proyectos.
d) Plan de infraestructura.
5. Programacin y asignacin de prioridades y recursos.
6. Elaboracin del presupuesto.

En la figura 10 se muestra la representacin del flujo del proceso.



Figura 10: Proceso de planeacin estratgica de TI

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

El comit tendr como funcin realizar la planeacin informtica, 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 tecnologas de informacin.

41

Profundizando, la declaracin de la misin consiste en la expresin del propsito del
negocio, en este caso, el servicio de TI, la que incluye, la definicin del mbito actual y
los cambios esperados en el futuro, la descripcin general de productos y servicios
ofrecidos, cobertura geogrfica y la seleccin de una forma de conseguir una posicin
ya sea de liderazgo, de excelencia, o de asesoramiento, que permita tener una
supervivencia sostenible en el tiempo [11]. La visin 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, anlisis de la situacin actual de TI, corresponde a la determinacin y
diagnostico de:

a) La arquitectura informtica del negocio.
b) La infraestructura, vale decir, cantidad y tipo de equipos, tecnologas utilizadas y
el diagnostico de procesos.
c) Los recursos utilizados para el desarrollo y mantencin de software, gestin 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 anlisis de la situacin actual, la definicin de la situacin deseada
de TI, el plan informtico 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 polticas
respecto a: la compra y/o arriendo de equipos, la contratacin de servicios y
recursos humanos, tanto internos como externos.
b) La arquitectura informtica deseada, idealmente considerando soluciones
probadas y estndares para la definicin de tecnologa a utilizar.
c) Estrategia general de infraestructura, es decir, tecnologa a utilizar, arquitectura
de red, servidores y servicios deseados.
d) Procesos de TI que sern mejorados o abordados, con el objetivo de establecer
en el mediano plazo procesos de mejora continua.

La formulacin de los planes y programas generales de accin junto con la
programacin y asignacin de prioridades y recursos, corresponde a la definicin en
detalle y con carcter anual de:

a) Plan tctico de gestin de recursos de TI, es decir, determinacin anual de los
recursos requeridos para realizar el plan anual de proyectos e infraestructura.
b) Plan anual de mejora e implantacin de la arquitectura informtica del negocio.
c) Definicin del portafolio de proyectos de software, el que incluye la descripcin
de los proyectos con una valorizacin previa.
d) Plan de infraestructura, el que incluye, proyectos, plan de mantenimiento y
recambio de tecnologa, servicios que se requerirn dentro del periodo.


42

2.1.2 Proceso para la elaboracin del presupuesto

Derivado de la planeacin estratgica de TI de la filial, el presupuesto es la estimacin
de los recursos de dinero para llevar a cabo los planes de accin definidos en la
planeacin estratgica. El presupuesto de informtica se puede dividir segn la
siguiente clasificacin:

a) Proyectos, es decir, toda actividad relacionada con proyectos que signifiquen la
adquisicin, adecuacin e implantacin de software nuevo o infraestructura
nueva.
b) Mantencin de Software, que considera los recursos para las mantenciones
evolutivas y adaptativas. Las correctivas no son consideradas ya que se define
como una garanta 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 mantencin anual
de licencias.
d) Mantencin 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 Informticos, donde se consideran, los servicios permanentes
prestados por terceros.
g) Comunicaciones, que considera los costos de la telefona fija, mvil y las redes
de comunicacin WAN.

El presupuesto debe ser especificado en dlares. El tipo de cambio presupuestado es
entregado anualmente por el rea de finanzas, el que debe ser tomado como referencia
para la elaboracin del presupuesto. Adems, deben ser especificadas todas las
actividades y los flujos mensuales, los que son determinados respecto a la planeacin
anual de las actividades. En la tabla 13, se presenta un ejemplo de un presupuesto.

43



Tabla 13: Ejemplo de un presupuesto

El problema de la elaboracin del presupuesto es la estimacin de los recursos
econmicos a considerar. Para resolver este punto, en la tabla 14 se presenta una
propuesta de criterios que pueden ser utilizados.

44



Tabla 14: Criterios para la presupuestacin

Adems, es importante detallar los tems que se considerarn 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 planeacin anual, fijarn el detalle de las prioridades y definirn los
recursos.



45

Entonces, el proceso propuesto es:

1. De la planeacin estratgica, determinar las actividades y servicios que sern
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 gua 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 aprobacin del comit de TI.

En la figura 11 se muestra la representacin del flujo del proceso.



Figura 11: Proceso de elaboracin del presupuesto





46

2.2 Procesos de software

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

a) Administracin de Proyectos.
b) Desarrollo y Administracin de Requerimientos.
c) Desarrollo de Software.
d) Pruebas de Software.
e) Mantencin de Software.

En esta seccin, se presentar la definicin general de estos procesos tomando como
marco de referencia algunos elementos de la gua proporcionada por CMMi.

2.2.1 Administracin de Proyectos

La administracin de proyectos bajo CMMi abarca una serie de reas de procesos de
los niveles de madurez 2, 3 y 4, identificndose las siguientes como parte de este
proceso:

a) Planificacin de proyectos.
b) Monitoreo y control de proyectos.
c) Administracin de acuerdos con proveedores.
d) Administracin integrada de proyectos.
e) Administracin de riesgos.
f) Equipos integrados.
g) Administracin integrada de proveedores.
h) Administracin cuantitativa de proyectos.

La idea es generar el proceso bsico de administracin de proyectos, de acuerdo al tipo
de metodologa de desarrollo de software.

En la industria se encuentran dos grandes visiones metodolgicas para el desarrollo de
software: los mtodos giles y los mtodos tradicionales. Pero, Cuales son los criterios
para escoger entre uno u otro tipo de metodologa? Para responder a la pregunta, se
pueden definir los siguientes elementos de juicio para apoyar la decisin [2]:

a) Los mtodos 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
tecnologa y hay poca experiencia del equipo de desarrollo, se puede utilizar
metodologa 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 administracin sea parte del equipo de desarrollo, la
metodologa gil puede ser aplicada.
d) Si bien la metodologa gil puede ser utilizada en todo tipo de proyectos, es
recomendable que para proyectos de mediano y largo plazo se utilicen mtodos
tradicionales debido a que:
47

a. Se entiende que un proyecto de corto plazo es para resolver algo puntual,
por lo tanto un control de proyectos mediante el seguimiento de
actividades puede ser aplicado.
b. La cantidad de personas del equipo de proyecto es mayor a la de un
proyecto de corto plazo.
c. La cultura organizacional es de carcter tradicional, por lo que la falta de
formalidad del mtodo gil puede ser interpretada por la organizacin
como mala gestin y desorden del proyecto.

Se ha sealado, que en la prctica no existe un proceso de administracin de
proyectos. Sin embargo, de la situacin 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
participacin directa del cliente.

Por lo tanto, el nfasis de esta definicin, debe ser respecto a la planificacin,
monitoreo y control de los proyectos. Cabe notar, que por el tamao de la organizacin
y la escasez de recursos, es necesario contar con una funcin que concentre el
seguimiento e informacin de control y monitoreo de los proyectos y que permita
establecer a nivel del portafolio, la planeacin, priorizacin y coordinacin de los
recursos asignados a los proyectos.

Otro punto importante, es que el servicio de TI puede tercerizar la ejecucin de los
proyectos, manteniendo un jefe de proyecto interno, es por ello que cobra relevancia la
administracin de los proveedores, tema que ser discutido en el proceso de gestin de
proveedores.

2.2.1.1 Administracin de proyectos con metodologas giles

Las metodologas giles son caracterizadas por iteraciones de corta duracin, por lo
tanto la administracin de proyectos de este tipo, tiene que ver con el ciclo: planeacin,
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 administracin de proyectos de este tipo:

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

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


En la figura 12 se muestra la representacin del flujo del proceso.



Figura 12: Administracin de proyectos con metodologas giles


2.2.1.2 Administracin de proyectos con metodologas tradicionales

Para este tipo de proyectos, el desarrollo puede ser abordado mediante mtodos
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 metodologa de desarrollo.
49

d) Definir y estimar las actividades, recursos y costos [25].
e) Definir el plan comunicacional del proyecto.
f) Identificar los riesgos del proyecto.
2. Obtener el compromiso de la organizacin 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 revisin.
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 representacin del flujo del proceso.



Figura 13: Administracin de proyectos con metodologas 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 utilizacin de los
mismos indicadores de cumplimiento vistos en el diseo de los servicios de valor
agregado, es decir, la medicin de los das de atraso respecto a la planeacin 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 problemtica, hay que
distinguir que cada actividad del proyecto debe producir productos tangibles o
entregables bajo una cierta temporalidad definida.
50


Entonces, si n es el nmero total de actividades del proyecto,
i
P es la cantidad de
productos entregables para una actividad i , con un plazo planificado de realizacin
i
t y
i
tr es el tiempo real transcurrido para la realizacin de la actividad i , se proponen las
siguientes mtricas para el control y seguimiento:

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

100 %
1
=

=
n
i
i
j
j
p
P
P
PE donde j es tal que
j j
t tr s

Ecuacin 3: Porcentaje de productos entregados dentro de plazo

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

100 %
1
=

=
n
i
i
j
j
a
P
P
PE donde j es tal que
j j
t tr

Ecuacin 4: Porcentaje de productos entregados fuera de plazo

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

100
1
% =

i i
ri
t
t
n
AP

Ecuacin 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 planeacin no fue la correcta, o
que la actividad presenta un problema que debe ser corregido, si eso es as, es
un riesgo del proyecto que ha de ser mitigado.

51

Cabe sealar, que los indicadores planteados en los puntos 1 y 2 son de carcter ex-
post y miden cumplimiento. Respecto a lo propuesto en el punto 3, la idea es tener un
indicador de avance, en relacin al tiempo respecto a lo planeado, sin embargo si la
planificacin es mala, esto no tiene sentido. Hay que notar, que la planificacin es una
estimacin de tiempo y actividades de lo que se har en el proyecto y como tal, debe
ser de carcter dinmico ya que debe adaptarse de acuerdo a las situaciones y
necesidades que se vayan dando durante la ejecucin del proyecto, por ello el indicador
propuesto en el punto 3 cobra relevancia desde el punto de vista operativo, entregando
una nocin de la situacin de avance.

La realizacin 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
planificacin, 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, Cunto tiempo se demora un
recurso en desarrollarlo de manera tal que la cantidad de defectos sea inferior a una
cierta tasa preestablecida? Cul es la varianza de ese proceso?

Se puede considerar una mtrica que clasifique piezas de software en base a
complejidad, por ejemplo puntos de funcin 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 mtrica 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
medicin de productividad para una persona. La problemtica 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 automatizacin y sistematizacin del proceso de captura de los datos, de
manera tal de que la informacin sea obtenida oportunamente.

2.2.2 Proceso de Desarrollo y Administracin de Requerimientos

De acuerdo a CMMi, el propsito del desarrollo de requerimientos es producir y analizar
los requerimientos de clientes, productos y componentes de productos. La
administracin de requerimientos, es la gestin de los requerimientos de los productos
del proyecto y los componentes del producto y la identificacin de las inconsistencias
entre esos requerimientos, los planes del proyecto y los productos de trabajo [7].

Ambos procesos distinguen las siguientes etapas [7]:

Caso: Desarrollo de Requerimientos.

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


Caso: Administracin de Requerimientos.

a) Obtener una comprensin 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 problemtica de levantar el
requerimiento del cliente ya que es la falencia principal de la organizacin. Como se vio
anteriormente, la etapa de requerimientos, corresponde a la recepcin y aprobacin. En
trminos prcticos, 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 aprobacin a un
comit y de ser aprobado, se realiza. No se genera documentacin.

Independiente de la metodologa del proyecto y del tipo de solicitud, la idea es tener un
proceso estndar para el levantamiento de requerimientos. Los elementos relevantes
son los relacionados con el levantamiento, es decir: el desarrollo de los requerimientos
del cliente, la obtencin de una comprensin de los requerimientos el anlisis y la
validacin de los requerimientos y la obtencin de compromisos con los requerimientos.
Adems, es imprescindible la participacin de las reas que transformaran los
requerimientos en software.

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

1. Recepcin de una solicitud de cambio o de levantamiento de requerimientos.
2. Desarrollar el requerimiento.
a) Determinar los objetivos, visin y alcance [17].
b) Determinar la situacin 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 tcnicos del software.
3. Comprender el requerimiento.
a) Analizar el requerimiento, mediante reuniones y revisin 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 evaluacin econmica.
b) Determinar la evaluacin tcnica.
c) Determinar si es un proyecto o un mantenimiento.
6. Presentar al comit de informtica para aprobacin.

53

En la figura 14 se muestra la representacin del flujo del proceso. Para las solicitudes
de cambio, el ingreso debe ser realizado a travs de la mesa de ayuda, se sigue el flujo
normal de evaluacin, con la diferencia que solamente es validado por el Service
Manager, obtenindose el compromiso y luego sometido a aprobacin en el comit. La
diferencia con un requerimiento normal, es que se considera una solicitud de cambio
como una solicitud de mantencin de software.




Figura 14: Proceso de desarrollo y administracin de requerimientos

Pero, Cmo 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 aceptacin de la
especificacin de una cierta funcionalidad, que para ser evaluada y presentada al
comit, no puede ser modificada. En la prctica, 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, ms que
concentrarse en los cambios. Si el cambio es menor, debe evaluarse el impacto y
comunicar al comit la nueva evaluacin.

54

Una vez establecidos los requerimientos, es parte de la evaluacin tcnica determinar
la adecuacin al software. Para ello, se propone el uso de una matriz de trazabilidad
entre la funcionalidad de software versus los requerimientos.

Respecto a las tcnicas para el levantamiento y especificacin de requerimientos, se
propone:

1. La realizacin de entrevistas con todos los involucrados, utilizando preguntas
abiertas para obtener un panorama general del requerimiento y preguntas
especificas para el detalle.
2. La utilizacin de diagramas UML de casos de uso para la especificacin ya que
son simples, es un modelo estndar, evita ambigedades y es entendible por
usuarios no tcnicos.
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 sern
desarrolladas las aplicaciones en la empresa, esta definicin tambin va asociada a qu
tecnologa utilizar para el desarrollo de software.

CMMi establece como parte de su rea de proceso de solucin tcnica la gua para
afrontar esta problemtica, considerando tpicamente las fases que siguen al anlisis de
requerimientos, es decir el diseo y la construccin.

Para el caso de metodologas giles, el proceso general es definido como sigue:

1. Definir una arquitectura de software para la solucin.
a) Escoger un patrn arquitectnico de software [16].
b) Crear actividades de desarrollo para implementar la arquitectura [16].
c) Determinar y disear las interfaces.
d) Identificar los objetivos de rendimiento de la aplicacin.
e) Definir un prototipo arquitectnico de la aplicacin [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 cdigo.
e) Realizar los tests unitarios.
f) Verificar y corregir cdigo.
3. Corregir errores.
a) Realizar testing con el usuario y encontrar errores [16].
b) Reproducir el error.
c) Localizar la causa del error.
d) Corregir el error.
55

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

En la figura 15 se muestra la representacin del flujo del proceso.



Figura 15: Proceso de desarrollo de software con metodologa gil

Para el caso de mtodos tradicionales, el proceso general es definido como sigue:

1. Definir y seleccionar las componentes del producto.
a) Crear alternativas detalladas de diseo de la aplicacin [17].
b) Disear y seleccionar la arquitectura del sistema.
c) Determinar y disear las interfaces.
d) Determinar los requerimientos y escenarios operacionales [17].
e) Crear pruebas de concepto de la aplicacin, mediante diagramas [17].
f) Identificar los objetivos de rendimiento de la aplicacin.
2. Desarrollar el diseo.
56

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

En la figura 16 se muestra la representacin del flujo del proceso.




Figura 16: Proceso de desarrollo de software con metodologas tradicionales
57


Cabe sealar, que las actividades de ensamblaje y entrega de producto, son
abordadas en CMMi bajo el proceso de integracin del producto, en contraste con el
mtodo gil, el que realiza la entrega dentro de su propio ciclo de desarrollo.
Posteriormente se presentan las etapas de validacin y verificacin, 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 metodologa de proyecto a utilizar: gil o tradicional, de acuerdo a los
criterios propuestos en la seccin de administracin de proyectos.
2. Seguir los procesos definidos anteriormente de acuerdo a la eleccin
metodolgica.

Respecto a la definicin de la tecnologa a utilizar para el desarrollo de software, en la
industria hay dos herramientas comnmente utilizadas para el diseo y construccin de
software empresarial, por una parte .NET de Microsoft y por otra J 2EE 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 mayora .NET, donde el ambiente Windows es
predominante.
2. Las aplicaciones J 2EE 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 programacin presentan ventajas y desventajas, siendo las
principales:
a) J 2EE presenta una mejor portabilidad de plataforma que .NET.
b) J 2EE es una tecnologa ms madura que .NET.
c) .NET posee soporte para mltiples lenguajes de programacin, con
una arquitectura equivalente a la planteada bajo J 2EE.
d) .NET est especialmente orientado a la creacin 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
prcticas de desarrollo de software que pueden ser aplicadas con
mtodos tradicionales y giles, en cambio Sun solo ofrece la
plataforma, donde las prcticas son abordadas mediante entornos
de programacin de terceros.

Entonces, .NET es la eleccin natural, debido a la predominancia histrica 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. J 2EE
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 J 2EE
58

sera demasiado costoso y por lo tanto carente de sentido ya que no aportara valor a la
empresa.

Como valor agregado, el proceso de desarrollo establecido por Microsoft para la
plataforma .NET contempla un framework para metodologas giles y otro orientado a
mtodos tradicionales, usando CMMi. De ambos, se tomaron los aspectos ms
relevantes para definir los procesos sealados 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 organizacin no existe un proceso formal de pruebas y tal como se
menciono en el captulo 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 aplicacin de metodologas de testing en forma permanente.

El proceso de pruebas est directamente relacionado con las actividades de desarrollo
y mantencin 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 problemtica,
por una parte, la verificacin, cuyo objetivo es asegurar que los productos de trabajo
cumplan con los requerimientos especificados [30] y por otra la validacin, cuyo objetivo
es demostrar que un producto cumple con su uso propuesto cuando es instalado en el
entorno propuesto [30].

Una manera prctica de abordar la verificacin es realizar la revisin de pares [30], es
decir, quien realiz el trabajo le cuenta la solucin 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 verificacin.
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 verificacin.
2. Realizar la verificacin de acuerdo a los requisitos del producto.
a) Identificar a los revisores y agendar la verificacin.
b) Revisar la visin del producto.
c) Revisar el diseo del producto.
d) Realizar las pruebas.
3. Registrar los resultados.
a) Registrar resultado para cada caso de prueba.
b) Registrar el xito de la verificacin y determinar acciones correctivas.
4. Preparar el informe de verificacin.

En la figura 17 se muestra la representacin del flujo del proceso.
59




Figura 17: Proceso de pruebas con metodologa gil

En el caso de la validacin, 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 validacin y determinar acciones correctivas.
4. Preparar el informe de testing.

En la figura 18 se muestra la representacin del flujo del proceso.

60



Figura 18: Proceso de pruebas con metodologas tradicionales

Respecto a la estrategia de testing, se propone que el enfoque sea por proceso
(escenario) de negocio ms 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 anlisis transaccional, esto se puede visualizar en la
figura 19.

Como no existe una definicin metodolgica respecto a la construccin de los casos de
prueba y no existe mucha experiencia dentro de la organizacin, se propone utilizar el
enfoque de caja negra, el que est orientado a la construccin de los casos de pruebas
a partir de las funcionalidades del sistema. Se propone utilizar la tcnica de clases de
equivalencia, junto con el anlisis de valores lmite para obtener los casos de prueba
que se utilizarn en el anlisis transaccional.

61



Figura 19: Diagrama de descomposicin para el testing9


2.2.5 Proceso de Mantencin de Software

En CMMi, la mantencin es vista como una etapa ms del ciclo de vida del software,
que integra los procesos de solucin tcnica, validacin, verificacin, junto con la
administracin y desarrollo de los requerimientos. Esto ya ha sido abordado en los
procesos anteriores, es decir, una mantencin sigue el mismo ciclo de requerimientos
desarrollo pruebas. Por lo tanto, el enfoque para definir este proceso, ser de acuerdo
a solucionar la problemtica para la provisin del servicio.

Uno de los problemas del proceso de mantencin es la asignacin de tareas y
prioridades al personal que realiza las mantenciones y el entendimiento de lo que es
una mantencin. Bajo el escenario de un servicio nico para todas las filiales, la
problemtica es aun peor debido a la diversidad de software existente y a la
especializacin del personal por divisin de negocio. Esto sugiere dos cosas, por una
parte se debe contar con una metodologa eficiente de asignacin de recursos y por
otra, se debe contar con las definiciones adecuadas que permitan discriminar el alcance
de una mantencin.

Se entender como mantencin de software al proceso general de cambio de un
sistema despus de que ha sido entregado. Se definen tres tipos [28]:

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

9
Fuente: Apuntes del curso Tcnicas de Prueba de Software. 2004. Diplomado en Gestin de Calidad de Software.
62


Esta definicin, permite tener un marco global para una mantencin, sin embargo no
establece alcance en cuanto a tiempo o recursos. El problema de esto es que si una
actividad de mantencin 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 mantencin, ser aquel que cambie un sistema despus de haber sido
entregado.

Una manera rpida de calificar una actividad de mantencin de un proyecto, es utilizar
criterios de tiempo y costo. Podran usarse tambin medidas de software, por ejemplo,
puntos de funcin, sin embargo, al no haber experiencia previa su uso y a la necesidad
de responder rpidamente a los clientes, la aplicacin podra resultar contraproducente
en esta etapa.

Por lo tanto, una mantencin ser calificada como proyecto, cuando como resultado de
la estimacin 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 problemtica es que el personal est especializado por divisin de negocio por lo
que frente a un esquema global, la asignacin de tareas no es eficiente. Por ello se
proponen dos opciones de especializacin:

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

El problema de la primera opcin es que requiere de personas con un amplio dominio
de las herramientas tecnolgicas, sin embargo, se especializa en los procesos de
negocio del cliente. La segunda opcin requiere de especialistas en las herramientas
tecnolgicas 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 tecnologa, no por tipo de proceso. Por lo tanto, la
opcin b) parece la ms adecuada para definir lneas de mantenimiento, que en este
caso, sern por zonas geogrficas.

La primera divisin por tipo de tecnologa ser para diferenciar las aplicaciones SAP del
resto y como es de carcter corporativo y centralizado, no ser dividido por zona
geogrfica, entonces se propone la siguiente divisin:

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

e) Mxico.

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

1. Recepcin de un requerimiento de cambio a travs del service desk.
2. Anlisis y clasificacin del requerimiento.
a) Determinar si es una mantencin o no.
b) Clasificar el requerimiento.
3. Estimacin y asignacin 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. Modificacin 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
programacin. Desde el punto de vista de los procesos de software, corresponde
a la aplicacin y uso de metodologas de desarrollo de software.
5. Pruebas de software.
6. Pruebas de aceptacin del usuario.
a) Pruebas funcionales.
b) Aceptacin.
7. Paso a produccin.




Figura 20: Proceso de mantencin del software
64

2.3 Procesos de soporte al servicio

2.3.1 Gestin de incidencias

La gestin de incidencias tiene por objetivo restaurar la operacin 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 tamao
de la organizacin, es necesario la definicin e implementacin de un service desk.
Para ello, primero se debe definir la estructura y alcance que tendr est unidad.
Existen tres estructuras bsicas [22]:

a) De tipo centralizado, es decir, el service desk atiende centralizadamente todas
las llamadas de usuario de la organizacin, independiente de su ubicacin
geogrfica.
b) De tipo descentralizado, es decir, el service desk se encuentra distribuido en
varias zonas geogrficas, 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 tecnolgico y de telecomunicaciones, provee un nico punto de
acceso, sin embargo los agentes pueden estar distribuidos en distintas
ubicaciones geogrficas.

La empresa posee filiales en Chile y Sudamrica, por lo que en principio un modelo
descentralizado podra ser la solucin. La ventaja, es que al estar localizado
geogrficamente, se logra fcilmente que el soporte sea especfico para la zona,
adems puede servir de respaldo en caso de que otro service desk, de otra zona
geogrfica, no se encuentre disponible. Por otro lado, el modelo centralizado requiere
de una menor cantidad de personal para ser operado, la gestin est centralizada y por
lo tanto su costo es eventualmente menor. El virtual service desk se descarta como
opcin de solucin ya que adems introduce costos de comunicacin y tecnolgicos,
que en los otros modelos no se incurren. Otro elemento a considerar es que
estratgicamente, el holding se define como lder en costos. Por lo tanto, la eleccin es
por una estructura centralizada en Chile ya permite una mayor optimizacin y control de
los recursos. Respecto a las localidades en el extranjero, la especializacin del soporte
se puede obtener mediante entrenamiento. Esto puede ser ms 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 gestin de incidencias se
define de la siguiente manera:

1. Deteccin y registro de incidentes, los que pueden ser reportados directamente
al service desk, por correo, o por mecanismos de auto atencin [19].
2. Gestin de las solicitudes de servicio.
e) Distribucin de los requerimientos de servicio.
3. Clasificacin de los incidentes y soporte inicial.
65

a) Determinar tipo de incidente.
b) Determinar impacto y urgencia.
c) Entregar soporte inicial.
4. Investigacin y diagnostico del incidente [19].
a) Identificar la solucin 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. Solucin y recuperacin.
a) Resolver el incidente.
b) Implementar acciones correctivas.
c) Implementar acciones de recuperacin.
d) Verificar que el incidente este resuelto.
6. Cierre del incidente.
a) Verificar la satisfaccin del cliente.
b) Cerrar el incidente.

En la figura 21 se muestra la representacin del flujo del proceso.

Los niveles de servicio del service desk, deben ser los mismos que se han definido en
la seccin de diseo de servicios. Para la gestin, se propone el uso de los indicadores
habituales, es decir:

a) Llamadas recibidas, que corresponde al total de llamados recibidos por la central
telefnica 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 conversacin, que corresponde a la duracin promedio de una
llamada.
f) Porcentaje de llamadas abandonadas, que corresponde al porcentaje de
llamadas que se abandonaron sobre el total de llamadas.
g) Porcentaje de nivel de servicio, que corresponde a la cantidad de llamadas
contestadas antes de un periodo de tiempo, sobre el total de llamadas.
h) Porcentaje de llamadas contestadas, que corresponde al porcentaje de llamadas
contestadas sobre el total de llamadas recibidas.

66


Figura 21: Proceso de gestin de incidencias


2.3.2 Gestin de problemas

La gestin de problemas es la bsqueda de la causa de una incidencia, que no ha
podido ser resuelta por el soporte estndar, para convertirla en un error conocido e
iniciar la accin de mejora o correccin de la situacin [26].

Considera dos aspectos [26]:

a) Reactivo, que es concerniente a la solucin de problemas en respuesta a uno o
ms incidentes.
67

b) Proactivo, que tiene relacin con la identificacin y solucin de problemas y
errores conocidos antes de que un incidente vuelva a ocurrir.

Adems, 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 travs del proceso de gestin de cambio.

La gestin de problemas tiene directa relacin con la gestin del cambio ya que los
resultados de este proceso generan modificaciones en la infraestructura informtica 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
correccin temporal o workaround, mientras la solucin es encontrada [21].

Las etapas del proceso, sern realizadas por un grupo de solucin 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, quin se encargara de coordinar las actividades de
correccin al interior de su unidad organizativa.

Las soluciones y planes sern 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 ms relevantes de ITIL y que pueden ser de utilidad para la organizacin. La
definicin es la siguiente:

1. Registro del problema y clasificacin.
a) Deteccin de los incidentes clasificados como problema.
b) Deteccin de problemas desde otras fuentes, es decir, las provenientes de
la infraestructura informtica 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. Investigacin 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 solucin temporal [21].
3. Control de errores.
a) Implantar la correccin del problema mediante el proceso de gestin del
cambio [21].
b) Verificar la eliminacin del error [21].
4. Cierre del problema.
a) Registrar los sntomas del problema y los detalles de la solucin.
b) Registrar los artefactos, equipos, o tems de configuracin que sufrieron
cambios [21].
68

c) Verificar la satisfaccin del cliente.
d) Cerrar el registro del problema.
5. Anlisis proactivo y revisin de problemas.
a) Analizar tendencias de problemas y determinar focos de accin preventiva
[21].
b) Revisar los problemas mayores y las acciones tomadas para su solucin,
con el objeto de prevenir que vuelva a ocurrir [21].

En la figura 22 se muestra la representacin del flujo del proceso.



Figura 22: Proceso de gestin de problemas

2.3.3 Gestin de inventario y configuracin

La gestin de inventario y configuracin provee la informacin sobre la estructura de
tecnologas de informacin de una organizacin, la que es utilizada por otros procesos y
para la gestin [26]. Establece el control de la infraestructura, a travs del monitoreo y
mantencin de la informacin de los recursos necesarios para la distribucin del
servicio, la evolucin de los tems de configuracin 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 comunicacin y servidores ya
que su nmero y caractersticas son utilizados como dato para la facturacin de algunos
servicios.

69

El principal problema con el inventario, es tener la informacin actualizada y mantener
el control sobre el ciclo de vida del equipo, es decir, el registro de los cambios y
configuracin, la incorporacin, modificacin y baja del equipo.

Adems, 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 recepcin y devolucin.

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: caractersticas tcnicas del
equipo, el lugar fsico donde se encuentra, quin lo tiene asignado, un identificador que
permita determinar si el equipo est sujeto a servicio tcnico y el nmero del contrato de
arriendo.

El proceso de inventario y configuracin, puede modelarse en los siguientes pasos:

1. Recopilar la informacin de los equipos, mediante software ad-hoc.
2. Mantener la informacin, es decir registrar los cambios para la configuracin,
ubicacin y eventos tales como: hurtos, robos, perdidas o siniestros. La
informacin puede ser mantenida a travs del mismo software, o por registro
manual segn sea el caso.
3. Validar que la informacin 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 representacin del flujo del proceso.

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

1. Permitir la recopilacin automtica de los siguientes datos:
a) Notebooks, PC y Servidores:
Marca y modelo del equipo.
Caractersticas tcnicas: CPU, RAM, modelo y tamao 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 segn corresponda.
Cantidad de bandejas.
c) Equipos de comunicacin:
70

Marca y modelo.
Tipo de equipo: switch, firewall, hub, etc.
Cantidad de puertas utilizadas y disponibles.
2. Permitir la edicin y adicin manual de los siguientes datos, para cada equipo:
a) Nmero de contrato de arriendo.
b) Nmero de servicio.
c) Nmero de serie.
d) A qu persona o empresa se encuentra asignado.
e) Ubicacin fsica, la que entenderemos por: planta o edificio y rea del
edificio o planta donde se encuentra.
f) Fecha de recepcin del equipo.
g) Fecha de inicio del periodo de arriendo.
h) Fecha de finalizacin del periodo de arriendo.
i) Fecha de devolucin del equipo.
j) Eventos, es decir: hurtos, robos, perdidas o siniestros.
3. Permitir la emisin de informes de inventario.




Figura 23: Proceso de gestin de inventario y configuracin





71

2.3.4 Gestin del cambio

El objetivo de la gestin del cambio es minimizar la interrupcin de servicios ante
cambios. Es decir, se deben asegurar los mtodos y procedimientos estndares que se
utilizarn para el manejo de los cambios en la infraestructura tecnolgica. La gestin 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 produccin, el que definiremos, como el conjunto de hardware y software
que es utilizado por la empresa para la ejecucin de sus sistemas informticos y para el
cual se debe registrar y establecer una lnea base, de manera tal que los cambios sean
registrados sobre dicha configuracin.

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

El paso a produccin es el proceso mediante el cual se instala en ambiente productivo
las piezas de software y hardware requeridas para que una aplicacin funcione.
Entonces, hay que distinguir que un paso a produccin tendr caractersticas,
actividades y alcances distintos de acuerdo a lo que se desea instalar. Para ello, se
puede realizar una clasificacin, 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 tcnicos de terreno.
b) Servicios que se instalan o modifican en servidores en funcionamiento, cuya
realizacin est a cargo de los administradores de la plataforma.
c) Scripts de bases de datos, es decir: procedimientos almacenados, tablas,
definiciones, etc., cuya realizacin est a cargo del administrador de la base de
datos.
d) Aplicaciones web, cuya realizacin est a cargo de los administradores de la
plataforma.
e) Otros, es decir, software no clasificado dentro de las categoras anteriores y cuya
realizacin 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) Modificacin a hardware existente en ambiente productivo.

Los criterios de realizacin del paso a produccin dependern de la disponibilidad de
una ventana de tiempo para realizar la actividad y a las restricciones propias impuestas
por polticas de la administracin de la infraestructura, por ejemplo: restricciones de
horarios o das, disponibilidad de recursos, etc.
72


Es importante sealar, que como elementos principales de la actividad, se debe definir
el plan de paso a produccin, el plan de reversa y un plan de contingencia para el caso
en que se presenten problemas. Si hay hardware comprometido, adems deben ser
especificados los componentes nuevos o sujetos a cambio.

En resumen, el proceso de paso a produccin significa:

1. Que el desarrollador registra una solicitud de paso a produccin, la que debe
contener los programas, planes y justificacin para poder ser realizada.
2. La solicitud es derivada por la coordinacin del service desk, revisada y
clasificada, de acuerdo al tipo de software o las actividades relacionadas con el
hardware.
3. El paso a produccin 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 carcter de urgencia.
4. El paso a produccin es realizado, en caso de presentarse problemas se escala
con el desarrollador.
5. El resultado del paso a produccin es informado al desarrollador.

En la figura 24 se muestra la representacin del flujo del proceso.



Figura 24: Proceso de paso a produccin
73


Respecto a los equipos de escritorio, notebooks, impresoras y dispositivos que sean
utilizados por los usuarios, pero que no son parte de la plataforma de produccin,
tambin se debe tener el control respecto a la configuracin y sus cambios. Estos
provendrn de incidentes de servicio y en general sern realizados por tcnicos de
terreno. Eventualmente, podra haber compra de hardware o software por lo que un
ciclo de aprobacin 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
realizacin del cambio e informar al cliente, quin 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 satisfaccin del usuario.

En la figura 25 se muestra la representacin del flujo del proceso.



Figura 25: Proceso de gestin del cambio para equipos de escritorio


74

2.3.5 Control y distribucin de software y hardware

El objetivo del proceso es la proteccin del ambiente productivo y sus servicios, a travs
del uso de procedimientos formales y revisiones. Se relaciona directamente con la
gestin del cambio [26]. El proceso debe considerar las etapas de planeacin, diseo,
construccin, configuracin y comprobacin del hardware y el software para crear un
repositorio de versiones para el ambiente productivo [26].

Para el caso del software, las etapas de planeacin, diseo, construccin, configuracin
y comprobacin 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 cdigo fuente, respecto a sus fechas de creacin,
modificacin y eliminacin, por parte de uno o ms autores.
b) A nivel de cambios dentro del cdigo fuente, es decir, modificaciones, por parte
de uno o ms autores.
c) A nivel de mdulos funcionales del software, es decir un conjunto de archivos de
cdigo fuente que componen un mdulo.
d) A nivel del producto de software, de acuerdo a diferencias de funcionalidad, o
diferencias por correcciones producto de defectos o errores.

Entonces, la problemtica es definir que se va a considerar como control de versiones
de software y cules son los aspectos relevantes para el registro de los cambios.

En general, un producto de software est compuesto de mdulos propios que se
componen de archivos de cdigo fuente y libreras externas, las que pueden ser de
terceros o construidas dentro de la empresa. Luego, se puede definir, un control de
versiones de carcter jerrquico desde el producto de software hasta los archivos de
cdigo fuente que lo componen.

Para mantener el orden y en concordancia con lo sealado en el proceso de paso a
produccin, se propone categorizar el cdigo fuente segn el tipo de tecnologa, como
se muestra en la figura 26.

Respecto a la numeracin de las versiones, se propone utilizar un correlativo con el
formato zzz yyy xxx . . , donde xxx corresponde al nmero de release o entrega, yyy
corresponde al nmero de revisin y zzz corresponde al nmero de sub-revisin.

Entenderemos por entrega al evento en que una pieza o producto de software, que
implementa un grupo de requerimientos, es liberado para su instalacin en ambiente de
produccin. Un cambio de funcionalidad es una nueva entrega, por lo tanto una nueva
versin. El nmero de revisin 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 nmero de sub-revisin corresponder a la entrega de
modificaciones menores sobre una revisin del software y que no signifiquen cambio de
funcionalidad.
75


Es indispensable contar con un software para el control de las versiones, sobre todo si
una pieza de cdigo es modificada por ms de una persona. Las funcionalidades
mnimas requeridas son:

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



Figura 26: Descomposicin del producto de software para el control de versiones

En el caso del hardware, es el propio ciclo de gestin del cambio el que realiza el
registro de la planeacin, construccin, configuracin y comprobacin, sin embargo el
diseo no es parte del proceso y por lo tanto se entender que es abordado como parte
del diseo del ambiente operacional de un proyecto ya sea de software, mantencin, o
infraestructura.






76

2.4 Procesos de entrega del servicio

2.4.1 Gestin de disponibilidad y continuidad

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

Especficamente, la idea es asegurar la continuidad del negocio frente a un desastre o
falla mayor, reducir las vulnerabilidades, riesgos y producir planes de recuperacin que
estn integrados al negocio.

El desarrollo de planes para asegurar la disponibilidad y la continuidad, que contemplen
la recuperacin 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 acten. 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 formalizacin e institucionalizacin del
proceso, no solo es a nivel del servicio TIC, sino que tambin a nivel de la empresa
cliente, la que debe incorporar como parte de sus procesos de operacin, los planes
que sean definidos por la gestin de disponibilidad. En ese sentido, es relevante la
participacin 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 habra nada que hacer. Pero, Es suficiente hacer nada para mantener la
continuidad de un servicio? De acuerdo a la experiencia prctica, 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 prcticas que han de ser adoptadas por
las personas para el xito de la organizacin TIC.

Como proceso, la gestin de disponibilidad y continuidad, contempla determinar los
elementos crticos del negocio, desarrollar planes para gestionar la disponibilidad y la
continuidad y formalizar con la organizacin tanto cliente como del servicio TIC [26],
entonces, se debe:

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

2. Proponer un plan para la disponibilidad [26].
a) Identificar los componentes de servicio ms relevantes.
b) Disear los servicios de acuerdo a los requisitos de disponibilidad.
c) Definir riesgos y su mitigacin.
d) Definir el plan de recuperacin.
e) Definir el plan para la no disponibilidad.
3. Determinar las actividades para mantener la continuidad.
10

a) Determinar las actividades de administracin de la infraestructura.
b) Determinar las variables relevantes para monitorear la continuidad.
c) Establecer umbrales que permitan la prevencin 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 representacin del flujo del proceso.



Figura 27: Proceso de gestin de la disponibilidad y la continuidad


2.4.2 Gestin del nivel de servicio

De acuerdo a la figura 28, la gestin del nivel de servicio consiste en mantener y
mejorar la calidad del servicio TI, a travs de un ciclo continuo de acuerdos, monitoreo y
reportes peridicos de estado de los servicios [26]. Para ello, la existencia de un comit

10
El detalle de estos temas, ser revisado en la Gestin de Infraestructura.
78

de representantes de la empresa cliente y del servicio TIC es fundamental, para el
consenso, definicin, acuerdo, revisin y optimizacin de los niveles de servicio.




Figura 28: Ciclo de gestin del nivel de servicio
11



De acuerdo a lo definido por la empresa, los acuerdos de nivel de servicio deben ser
establecidos mediante contratos. Sin embargo, un acuerdo de nivel de servicio o SLA
(Service Leve Agreement) no debe ser considerado solamente como un contrato formal,
es ms 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 definicin de lo que se entrega y sus niveles
de satisfaccin.
b) La prevencin de conflictos, de acuerdo a la promesa del proveedor versus la
expectativa del cliente.
c) La distincin 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 estn entregando. Finalmente, los acuerdos deben ser comunicados a toda la
organizacin cliente y no permanecer en conocimiento de un grupo reducido de
personas.

En trminos prcticos, un documento de acuerdo de nivel de servicios debe contener al
menos los siguientes puntos [3]:

1. Propsito del servicio.

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

2. Descripcin del servicio.
a) Organizacin para la entrega del servicio.
b) Disponibilidad del servicio.
c) Manejo de cambios de servicio.
3. Niveles de servicio objetivos y medidas.
a) Definicin de la mtricas de servicio.
b) Definicin de la manera en que ser monitoreado el servicio.
c) Definicin de los reportes del servicio.
4. Costos del servicio.
5. Escalamiento.

Tomando en consideracin lo sealado anteriormente, el proceso de gestin del nivel
de servicio se define de la siguiente manera:

1. Levantar los requerimientos de servicio.
2. Definir el catlogo 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 representacin del flujo del proceso.



Figura 29: Proceso de gestin del nivel de servicio

80

2.4.3 Gestin de finanzas TI

El objetivo de la gestin de finanzas es identificar, calcular y gestionar el costo de
entregar servicios de tecnologas de informacin [26]. El proceso lo podemos dividir en
tres subprocesos: elaboracin del presupuesto, contabilizacin, facturacin y cobro de
los servicios.

Anteriormente, se defini el proceso de presupuesto y el marco para el costeo de los
servicios. La tarificacin 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 clculo 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
prdidas o utilidad sern absorbidas o invertidas para el siguiente periodo fiscal.

Respecto a la contabilizacin, facturacin 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 gestin de finanzas se puede definir de la siguiente manera:

1. Recepcin y contabilizacin de facturas de proveedores.
2. Prorrateo (si corresponde) de las facturas de proveedores.
3. Aprobacin de pago facturas de proveedores.
4. Recopilacin y valorizacin de las horas hombre trabajadas en servicios sujetos
a ese tem de costo.
5. Elaboracin de tems de facturacin para cada empresa que percibi servicios.
6. Facturacin, de acuerdo a las normas establecidas internamente.
7. Cobranzas, de acuerdo a las normas establecidas internamente.


En la figura 30 se muestra la representacin del flujo del proceso.

81



Figura 30: Proceso de gestin de las finanzas


2.4.4 Gestin de capacidad

La gestin de capacidad, tiene por objetivo asegurar que la infraestructura tecnolgica
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 anlisis de los resultados del monitoreo, el tuning de los recursos, el
pronstico de acuerdo a la demanda y la confeccin de un plan de capacidad, conforme
a los requerimientos de la empresa [18].

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

2.4.4.1 Gestin de capacidad del negocio

La gestin de la capacidad del negocio tiene relacin con asegurar que los
requerimientos futuros de servicio, sean considerados y entendidos y que la capacidad
82

requerida para soportarlos sea planificada e implementada, de acuerdo a la planeacin
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. Disear la configuracin para soportar el servicio.
3. Evaluar econmicamente el requerimiento.
4. Implementar de acuerdo a las fechas establecidas.

Como parte del diseo organizacional, la funcin debe ser cubierta, mediante la relacin
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 Gestin de capacidad de los recursos y servicios

El objetivo de la gestin 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 gestin de
capacidad de los recursos, tiene relacin con la identificacin y comprensin de la
utilizacin de cada componente de la infraestructura tecnolgica. 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 composicin tecnolgica 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 divisin.

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

83



Tabla 16: Componentes tecnolgicos de los servicios

Para cada uno de los componentes sealados, se puede establecer, una serie de
indicadores que describan su comportamiento, teniendo en consideracin, que los SLA
definidos tienen relacin con la disponibilidad y cumplimiento de compromisos, de
acuerdo al tipo de servicio.

En estricto rigor, la variable de decisin, debiera reducirse a la disponibilidad, porque
independiente del tipo de servicio, los recursos de tecnologa son utilizados
transversalmente y apoyan la consecucin del cumplimiento de compromisos.

Entonces, el problema se encuentra en determinar las variables que tienen directa
relacin con la disponibilidad del recurso tecnolgico 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 tecnolgicos con sus correspondientes indicadores y
84

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



Tabla 17: Indicadores de capacidad de servidores y PC
12



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



Tabla 18: Indicadores de capacidad para impresoras




Tabla 19: Indicadores de capacidad de equipos de comunicacin

Respecto a la planeacin de capacidad para afrontar una demanda de uso, hay que
distinguir entre la proyeccin o pronstico de uso frente a la prediccin. La primera,
tiene relacin con la estimacin del uso en el corto plazo, con el objeto de determinar
acciones correctivas en el da a da y entregar tendencias de lo que est ocurriendo con
el servicio. La segunda, se refiere al anlisis del comportamiento del servicio y a la
obtencin 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 adecuacin del servicio, a la necesidades del negocio.

86

La proyeccin de la carga de trabajo, se puede realizar mediante tcnicas de regresin
lineal, promedios mviles y suavizacin exponencial. Se propone la utilizacin de la
suavizacin exponencial ya que es simple y presenta menor varianza respecto a las
otras tcnicas. La prediccin de la carga de trabajo, es determinada mediante modelos
de simulacin o modelos analticos basados en redes de colas (queuing networks), los
que se construyen de acuerdo al caso particular y que no se abordarn por encontrarse
fuera del alcance de esta tesis.

2.4.5 Gestin de proveedores

El objetivo de la gestin 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 relacin, evaluar y controlar el desempeo de acuerdo a criterios establecidos y
cuantificables, mantener un inventario de proveedores y su impacto o relacin con los
servicios.

Una de las premisas bsicas de la empresa para su relacin con los proveedores, es
que la relacin sea de largo plazo y con carcter de socio estratgico. Por ello la
administracin de proveedores, tiene que ver con el ordenamiento y homologacin de
los contratos de servicio que se encuentran distribuidos a travs de todas las filiales y el
cumplimiento de los niveles de servicio y contratos acordados.

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

a) Objeto del contrato.
b) Especificacin, precio, forma de pago y reajuste de los servicios.
c) Clusula de revisin de los servicios.
d) Declaracin de capacidad e idoneidad del tercero para proveer el servicio.
e) Declaracin de confidencialidad de la informacin.
f) Responsabilidad por accidentes y daos y seguros.
g) Declaracin de cumplimiento de las normas de comportamiento, higiene y
seguridad de la empresa.
h) Garantas.
i) Vigencia del contrato.
j) Condiciones de trmino del contrato.
k) Clusula de arbitraje.
l) Modalidad de las comunicaciones para efectos del contrato.
m) Oferta comercial del servicio.
n) Niveles de Servicio.

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

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

a) Realizar seguimiento a los niveles de servicio acordados.
b) Realizar seguimiento al cumplimiento del servicio.
c) Solicitar modificaciones a los servicios de acuerdo a lo que se estipule en
el contrato.
3. Gestionar el cumplimiento de los contratos de los proveedores.
a) Registrar el cumplimiento de acuerdo a las mtricas propuestas en el
diseo de servicios.
b) Comunicar a la organizacin 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 representacin del flujo del proceso.



Figura 31: Proceso de Gestin de Proveedores

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

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

88

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



Tabla 20: Diferencias entre SLA y OLA
13


Para el caso de los servicios variables y de valor agregado se puede utilizar el mismo
indicador de SLA como OLA, ya que estn 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 incorporacin, cambio y reparacin de elementos de servicio. Entonces,
definiremos tres tipos de OLA:

1. OLA de Incorporacin, 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 Reparacin, como el nivel de servicio con que se realizan las
reparaciones o reposiciones a los servicios.

Los OLA definidos, son presentados en la tabla 21.


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



Tabla 21: OLA para servicios fijos
90

2.5 Procesos de gestin de l a infraestructura y seguridad

2.5.1 Gestin de infraestructura

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

a) Diseo de la infraestructura y planificacin estratgica, es decir la creacin
y/o mejoramiento de soluciones a travs del tiempo, basado en una estrategia
de largo plazo.
b) Deployment, relacionado con la implementacin y puesta en marcha de las
soluciones tecnolgicas y del negocio.
c) Operacin, es decir, actividades diarias de soporte y mantenimiento de la
infraestructura.
d) Soporte tcnico, consistente en la estructuracin y apoyo a otros procesos
para garantizar la entrega del servicio.

Los procesos de soporte tcnico y deployment, han sido abordados anteriormente. El
primero, como parte del escalamiento en la gestin de incidencias y de problemas y el
segundo como el proceso de paso a produccin definido en la gestin del cambio, por
lo tanto no se revisar.

Respecto al diseo y planificacin, existen dos aspectos a considerar, primero el
relacionado con los modelos de administracin y arquitectura que sean ms adecuados
a las necesidades del negocio, y el segundo a la creacin y/o mejoramiento de las
soluciones, es decir, el desarrollo de proyectos de infraestructura, que a diferencia del
software, son ms simples ya que no hay construccin de aplicaciones, solo
parametrizacin de productos, pero complejos en cuanto a la integracin a la
plataforma. Las actividades propuestas, para un proyecto de infraestructura son:

1. Levantamiento de necesidades.
2. Determinar la solucin y la evaluacin tcnico-econmica.
3. Aprobacin de la solucin por parte del comit de TI.
4. Realizacin del proyecto de infraestructura.
a) Realizar la ingeniera de detalle.
b) Construir la solucin.
c) Determinar el plan de pruebas.
d) Gestionar los riesgos del proyecto.
e) Realizar pruebas.
5. Puesta en productivo (integracin a la plataforma).

En la figura 32 se muestra la representacin del flujo del proceso.

91



Figura 32: Actividades generales de un Proyecto de Infraestructura

Desde el punto de vista del modelo de gestin, es til considerar una jerarquizacin de
los elementos que se pueden abordar, de manera tal de establecer las capas
fundamentales sobre las que se desarrolla la gestin de la infraestructura. De acuerdo a
la figura 33, los elementos de gestin se encuentran divididos, desde lo operativo a lo
tctico, en actividades de operacin, control y monitoreo, administracin de seguridad y
administracin de infraestructura.



Figura 33: Jerarquizacin de las actividades de Infraestructura
14


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


2.5.1.1 Administracin de la Infraestructura

Para administrar la infraestructura, existen cinco modelos bsicos de administracin
[20]:

a) Datacenter centralizado y administracin centralizada.
b) Datacenter distribuido y administracin centralizada.
c) Datacenter distribuido y administracin centralizada / delegada.
d) Datacenter distribuido y administracin distribuida.
e) Administracin de tipo follow the sun, es decir datacenters distribuidos entre
distintas localidades geogrficas en el mundo, donde la administracin y la
operacin es transferida entre cada unidad de acuerdo a horarios diurnos de
trabajo.

El modelo ms apropiado es tener una gestin centralizada y datacenters distribuidos,
de acuerdo a la disponibilidad de servicios requerida por los negocios. La ventaja de
una gestin centralizada, es que se mantiene el control general de la plataforma, se
producen ahorros ya sea por cantidad de personas, licencias y consolidacin. Sin
embargo, puede haber operaciones que requieran la intervencin local. Para ello, en
vez de delegar la administracin la actividad puede ser ejecutada por un tcnico en
terreno y supervisada por un administrador central.

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



Tabla 22: Descripcin de los servicios de infraestructura

Respecto a la arquitectura de provisin de servicios y considerando que el holding es
distribuido geogrficamente, conviene definir, un criterio para decidir entre lo que se
encontrar centralizado y lo que ser particular a cada localidad.

La centralizacin debe ocurrir cuando ms de dos empresas tengan necesidades
equivalentes y no haya impedimento para la operacin normal, es decir, que frente a
perdidas de servicio, no se paralice una empresa. Los servicios localizados deben
permitir autonoma de manera tal, que frente a prdidas del servicio WAN, no se vean
afectados los procesos de negocio y los servicios bsicos de red de la empresa cliente.


93

Finalmente, la administracin de la infraestructura define las polticas y estndares, con
el fin de normar y establecer lineamientos y entradas claras al proceso de planeacin
estratgica, respecto a:

a) La arquitectura y diseo tcnico de las soluciones de hardware, para los
proyectos de software.
b) Equipamiento a utilizar de acuerdo al tipo de aplicacin, ambiente, o software.
c) La administracin de las comunicaciones, en cuanto a reglas de trfico,
priorizacin, disponibilidad y recuperacin.
d) El uso de software para proteger el equipamiento, por ejemplo: antivirus,
antispyware, etc.
e) La poltica de respaldo y recuperacin de la informacin.

2.5.1.2 Administracin de la Seguridad

La administracin de seguridad se revisar ms adelante, en el proceso de gestin de
seguridad.

2.5.1.3 Monitoreo y Control de Servicios

El monitoreo y control de servicios corresponder a la revisin peridica de indicadores
relacionados con los servicios de infraestructura [24]. Para ello es conveniente utilizar
software que permita realizar la actividad automticamente, generando alarmas
dirigidas al administrador cuando algn indicador se encuentre fuera de rango por un
cierto periodo de tiempo. El administrador deber realizar las acciones que re-
establezcan la operacin normal, de acuerdo a los procedimientos de operacin 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 extensin
del tema, no se revisarn las variables de los servicios. Sin embargo, a modo de
ejemplo, en la tabla 23, se presenta, una definicin de las variables tpicas de monitoreo
de un servidor bajo ambiente Windows y sus umbrales de operacin.

Cabe sealar, que las variables definidas constituyen una descomposicin de servicios,
que es requerida, para gestionar la capacidad, por lo tanto son una entrada a dicho
proceso.

94



Tabla 23: Variables de monitoreo de un servidor
15



2.5.1.4 Actividades de Operacin

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



Tabla 24: Actividades de operacin habitual de la infraestructura
16


Cada una de las actividades mencionadas, debe estar asociada a procedimientos con
el fin de asegurar que sean prcticas que se realicen a travs del tiempo. Para los

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

productos Microsoft y Oracle, existen guas ya definidas, las que se pueden encontrar
en los sitios web de dichas compaas.

2.5.2 Gestin de seguridad

El objetivo de este proceso es la definicin, control, gestin e implantacin de las
polticas 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 definicin de polticas y la implementacin de
dispositivos firewall. Por lo tanto no existe desarrollo previo.

Como primer paso, se puede establecer un marco para la gestin de la seguridad y
cuyo resultado sea el establecer la visin, los mecanismos de control, las revisiones y
las polticas. En ese sentido, el proceso, que debe ser parte de la administracin 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 polticas de seguridad como un requisito funcional ms y
deben entregar herramientas de administracin de perfiles para acceder a las
funcionalidades y los datos.

Entonces, para la gestin de seguridad, se propone el siguiente marco:

1. Establecer una poltica de seguridad para la organizacin.
a) Acordar una visin compartida de la seguridad y el compromiso de los
terceros relevantes.
b) Identificar los requerimientos de seguridad de la organizacin.
c) Identificar los niveles de seguridad para los datos de la organizacin.
d) Implementar revisiones peridicas de la poltica de seguridad.
2. Establecer un proceso de gestin de riesgos de seguridad.
a) Determinar los mecanismos de control de la seguridad.
b) Revisar peridicamente 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 peridicamente.
c) Entregar reportes peridicos de los problemas encontrados.
4. Establecer un proceso de respuesta frente a incidentes.

El desarrollo de las polticas 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 poltica de seguridad de la organizacin.
2. Definir la poltica de seguridad de aplicaciones.
a) SAP.
b) no SAP.
96

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

Una vez realizadas las actividades, se propone la aplicacin del proceso marco definido
para la gestin.

97

Captulo 4 Organizacin

1. Estructura Organizaci onal.

Las organizaciones son grupos de personas que buscan el logro de un propsito
comn. Esto se consigue a travs de la segmentacin o divisin 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 distribucin geogrfica de las plantas, personal y oficinas del
holding. Los focos de localizacin 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) Concepcin, 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) Mxico, con plantas productivas.

Un segundo elemento relevante es considerar las funciones bsicas de TI, que en
trminos generales, se puede decir que son las siguientes:

a) Gestin de la relacin comercial con el cliente.
b) Servicio al cliente.
c) Desarrollo de proyectos de software.
d) Mantencin de software.
e) Soporte a usuarios.
f) Gestin de la infraestructura TI.
g) Gestin de la calidad.

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


Culturalmente, existen limitantes en cuanto al enfoque con que las decisiones son
tomadas. La manera de funcionamiento del holding es altamente jerarquizada, las
decisiones son tomadas por Gerentes y Subgerentes. Por lo tanto, desde la perspectiva
de orientacin 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 Pri mer ni vel organizacional

El primer nivel de gestin, tiene relacin con las funciones bsicas de tecnologas de
informacin, vale decir: relacin comercial con el cliente, servicio al cliente, proyectos de
software, mantencin de software, soporte, infraestructura y calidad. Esto nos lleva a las
siguientes opciones de organizacin para el primer nivel.

Opcin 1: 1 Gerencia y 6 Subgerencias funcionales.

De acuerdo a la figura 34, bajo esta opcin, se tienen seis subgerencias: calidad,
relacin comercial con el cliente, servicio al cliente, proyectos, infraestructura y
mantencin. En el caso de soporte, es claro que puede ser integrada bajo la funcin de
servicio al cliente, bsicamente porque es un servicio que impacta directamente al
usuario final en cuanto a la satisfaccin de requerimientos bsicos relacionados con
herramientas informticas.



Figura 34: Organigrama general, opcin 1

Un problema de esta organizacin 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 mantencin, las que a nivel de procesos son equivalentes. Esto
lleva a concluir, que podra 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 continuacin, se propone
la opcin 2.


Opcin 2: 1 Gerencia y 5 Subgerencias funcionales

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

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



Figura 35: Organigrama general, opcin 2

Sin embargo, esta organizacin 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 organizacin que participan, de quin es la
responsabilidad? La respuesta no es clara. Posiblemente se podra normar la
responsabilidad con un procedimiento, pero semnticamente no sera 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 lnea de tiempo para realizar las adecuaciones
es de corto plazo. Bajo este enfoque, se puede decir que la mantencin 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, sera razonable
incorporar el mantenimiento de corto plazo como parte de la funcin de servicio al
cliente, por la integracin 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 tambin, lidere los
proyectos de manera integral, e incorpore los proyectos de mantencin (mantenciones
de largo plazo) como unidad especializada.

Una restriccin que ha impuesto la empresa, es no incorporar en esta etapa una unidad
funcional de calidad. La decisin, se basa en que sera ms aprovechable esperar a
que la organizacin se encuentre en rgimen por uno o dos aos, antes de pensar en
abordar el tema durante el proceso de cambio. En todo caso, en el captulo 6, se
plantea un plan de mejora de software, cuya conclusin final plantea la creacin de una
unidad funcional de calidad.

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

Todo esto nos lleva a la opcin 3, que se describe a continuacin.


100

Opcin 3: 1 Gerencia y 4 Subgerencias funcionales

De acuerdo a la figura 36, bajo, esta opcin, las funciones se han agrupado y
simplificado. Bsicamente, se tiene la relacin comercial con el cliente, servicio al
cliente, proyectos, e infraestructura. No existe la funcin de calidad.




Figura 36: Organigrama general, opcin 3

De las opciones planteadas, la que ms ventajas tiene, en trminos de simpleza y
agrupacin de funciones, es la opcin 3. Por lo tanto es la que se utilizar para la
organizacin de TI.
1.2 Segundo, tercer y cuarto ni vel organizacional

Los siguientes niveles organizacionales tienen un carcter tctico-operativo, que son los
que finalmente entregan el servicio a las empresas. Aparentemente, resulta ms fcil
plantear una organizacin por divisin 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 gestin de recursos limita la posibilidad de redistribuir en caso de ser
necesario, entonces, la especializacin por negocio no es beneficiosa.

Otra opcin es aprovechar la distribucin geogrfica del holding. Podemos distinguir las
siguientes zonas:

a) Chile Zona Centro, que comprende, Santiago y las oficinas comerciales del
norte del pas.
b) Chile Zona Sur, que comprende, Talca, Concepcin, Temuco, Los ngeles y
Nacimiento.

Para el extranjero, es natural pensar agrupar Argentina con Uruguay, Per con Brasil y
Mxico aparte.

La agrupacin por zonas geogrficas, resulta ms conveniente ya que tiene la facilidad
de que la funcin de TI no se ve afectada por la especializacin en una divisin y
permite orientarse a los clientes y los procesos que son transversales al holding de
empresas.

101

En consecuencia, la organizacin para las subgerencias que tienen directa relacin con
los usuarios, es decir relacin comercial y servicio al cliente, se plantear
geogrficamente. En el caso de proyectos e infraestructura, se pueden considerar como
unidades centrales de apoyo y servicios. Por lo tanto la especializacin puede
plantearse por procesos y/o tecnologas relevantes.

1.2.1 Subgerencia Relacin Comercial Cliente

En el caso de esta subgerencia, la agrupacin se ha realizado por zona geogrfica,
incorporando jefaturas de zonas: centro, sur, e internacional. Adems, se incorpora un
recurso de staff de la subgerencia, encargado de la planificacin global y gestin del
servicio, lo que se puede visualizar en la figura 37.



Figura 37: Organigrama subgerencia relacin comercial cliente

Las funciones que debe desempear esta unidad son las siguientes:

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



102

Las responsabilidades son:

a) Ser el representante de TI ante las filiales del holding, ser el representante de
las filiales del holding ante la gerencia de servicio TI.
b) Definir, mantener y difundir los servicios, a travs de un catlogo de servicios.
c) Velar por mantener una relacin 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 planificacin 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
informacin.
i) Actuar como representante del negocio en la evaluacin de impactos de
cambios que se produzcan en la infraestructura TIC y sus servicios.
j) Mantener el inventario y configuracin de los tem relacionados a los
acuerdos de nivel de servicio y planificacin.
k) Proveer informacin necesaria de la prestacin del servicio TI a control de
gestin TI.
l) Anlisis de impacto al negocio ante desastres que afecten los servicios TI.
m) Invocacin de planes de contingencia y la relacin 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 desempeo 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 distincin entre
aplicaciones SAP y el resto ya que SAP es el ERP de carcter corporativo, por lo tanto
se ha incorporado esta figura a la estructura.

Soporte consta de tcnicos 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 geogrfica ya que se tiene un directo impacto sobre los
usuarios.

El rea de mantencin, se encarga de las mantenciones de corto plazo, consta del
analista de demanda y divisiones por zonas geogrficas, salvo SAP que es de carcter
corporativo.

En la figura 38 se muestra la representacin de la subgerencia.
103



Figura 38: Organigrama subgerencia de servicio al cliente

Las funciones de la subgerencia son:

a) Atencin de usuarios (Service Desk).
b) Administracin de incidencias.
c) Control y distribucin de software y hardware.
d) Mantencin de corto plazo de aplicaciones.
e) Administracin 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 relacin comercial con
el cliente de los niveles de servicios que pueden ser acordados para la
atencin, 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 atencin de
incidencias.
d) Responsable del seguimiento, control y cumplimiento de los niveles de
servicios relativos al soporte a usuario, mantenimiento de aplicaciones y
seguridad informtica.
e) Reporta los niveles de servicios alcanzados por la unidad a la unidad de
relacin comercial con el cliente.
f) Difundir los servicios TI ante los usuarios.
104

g) Responsable del soporte local de los servicios TI en cada una de las
empresas del holding.
h) Responsable de encontrar soluciones de fondo ante incidencias repetitivas o
cuya causa raz es desconocida.
i) Responsable de la mejora continua del servicio de atencin de usuarios,
soporte local, mantenimiento de aplicaciones.
j) Responsable de la planificacin del servicio de atencin y soporte de usuarios
y del seguimiento de este plan.
k) Responsable de la planificacin del servicio de mantenimiento de
aplicaciones y del seguimiento de este plan.
l) Responsable de mantener el inventario y configuracin de los tem
relacionados a la atencin de usuarios, soporte de usuarios, mantenimiento
de aplicaciones.
m) Responsable de proveer informacin necesaria de la prestacin del servicio a
los usuarios a control de gestin TI.
n) Responsable de canalizar las solicitudes de cambio a travs del servicio de
atencin a usuarios.
o) Responsable de la implementacin, de acuerdo a los procedimientos
establecidos de la plataforma tecnolgica 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 divisin es respecto a tecnologas y/o
procesos asociados. Se distinguen los siguientes:

a) Software general, unidad encargada de realizar proyectos que no caben en
las categoras de especializacin definidas, por ejemplo: sitios webs,
aplicaciones forms, visual basic, etc.
b) Integracin, unidad encargada de realizar proyectos relacionados con
software middleware, vale decir que integra distintos tipos de sistemas o
capas dentro de una arquitectura.
c) Automatizacin, unidad encargada de realizar proyectos relacionados con la
automatizacin de plantas productivas, vale decir: sistemas de ejecucin de
manufactura, control automtico, gestin de procesos de plantas, etc.
d) Inteligencia del negocio, unidad encargada de realizar proyectos de tipo data
warehouse, gestin de la informacin, minado de datos, etc.
e) SAP, unidad encargada de realizar proyectos SAP, vale decir, se encarga de
los proyectos sobre el ERP de la compaa.
f) Mantenimiento, unidad encargada de realizar los proyectos de mantencin.

De acuerdo a la figura 39, la estructura es de J efes de Proyecto con su respectivo
equipo de Ingenieros de Proyecto, sin embargo, dado el tamao del holding, es
necesario colocar un nivel que agrupe a los jefes de proyecto segn su especializacin,
para ello se definen los Project Manager o Gestores de Proyectos, cuya labor es la
105

gestin y control global de la cartera de proyectos del rea de especializacin. Adems,
se contempla una unidad de control y planificacin, la que se encarga de realizar el
seguimiento global de los proyectos y la asignacin 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 especializacin respecto de las actividades de gestin. Para ello se puede
definir un spool, que independiente de la especialidad, sea capaz de gestionar y
controlar los proyectos, dejando la componente tcnica al jefe de proyecto. Con esto se
logra una mejor movilidad de recursos dedicados a la gestin.



Figura 40: Organigrama alternativo de la subgerencia de proyectos

Para el servicio que se ha definido, la empresa ha pedido, no separar la especializacin
de la gestin debido al carcter jerrquico de la organizacin, dejando esta mejora para
una implementacin posterior.


106

Las funciones de esta subgerencia son:

a) Seleccin de paquetes de software.
b) Implementacin de paquetes de Software.
c) Desarrollo de software.
d) Definir la arquitectura de aplicaciones.
e) Soporte especializado ante problemas.
f) Desarrollo e implementacin de soluciones de software de soporte a la
Inteligencia de Negocio y Automatizacin.
g) Planificacin y gestin integral de Proyectos.

Las responsabilidades son:

a) Establecer las normas generales para la Administracin de Requerimientos
de proyectos y las responsabilidades de cada uno de los entes involucrados.
b) Asegurar la administracin y el control de los requerimientos de software a lo
largo del ciclo de vida de los proyectos de implementacin y desarrollo.
c) Asegurar la participacin y compromiso de los grupos involucrados.
d) Establecer las normas generales que rigen la Administracin de
Configuraciones de Software.
e) Establecer y mantener la integridad y consistencia de los productos de
software a travs de todo el ciclo de vida de los proyectos de software.
f) Establecer las normas generales para la planificacin general de proyectos de
software y las responsabilidades de cada uno de los entes involucrados.
g) Minimizar los riesgos de la planificacin proporcionando confiabilidad
respecto de las estimaciones y de la programacin de actividades.
h) Asegurar la participacin y compromiso de los grupos involucrados.
i) Establecer las normas generales para la administracin de los subcontratistas
y proyectos de software subcontratados y las responsabilidades de cada uno
de los entes involucrados.
j) Normar la contratacin de subcontratistas de software, asegurando una
eficiente administracin 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 desviacin de lo planificado versus lo
real.
m) Entregar una visin del avance real de los proyectos a la gerencia TI y
usuarios involucrados.
n) Asegurar a la organizacin el cumplimiento del Proceso de Desarrollo e
Implementacin 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 implementacin de estos.
p) Definir y utilizar los estndares que regirn el desarrollo e implementacin de
software.
q) Realizar mantenciones de software de largo plazo, bajo la modalidad de
proyectos.

107

1.2.4 Subgerencia de Infraestructura

Primero, hay notar que las actividades de administracin y operacin son desarrolladas
centralizadamente. Si se requiere la intervencin directa a algn equipo se utiliza como
apoyo el tcnico de terreno de soporte. Debido a lo anterior, no vale la pena pensar en
una organizacin basada en la distribucin geogrfica. Sin embargo, las
responsabilidades si podran ser de ese modo, por ejemplo, la administracin de
sistemas, puede ser dividida en las mismas zonas geogrficas, 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
divisin clsica, vale decir:

a) Operaciones, que se encarga de la operacin de los sistemas, ejecucin de
procesos batch, etc.
b) Redes, que se encarga de la administracin de redes WAN y LAN, adems
de la telefona.
c) Ingeniera, unidad que realiza la ingeniera de sistemas y la administracin de
servidores. Se encuentra dividida en: bases de datos, sistemas unix y
sistemas windows.
d) Seguridad, que define y aplica las polticas 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) Diseo y planificacin de plataforma computacional.
b) Administracin y operacin de la plataforma computacional y software del
negocio.
c) Pasos a produccin de aplicaciones e infraestructura TI.
d) Gestin de cambios de la infraestructura TI.
108

e) Administracin de bases de datos.
f) Administracin de la seguridad.
g) Administracin de servidores.
h) Sintona de la plataforma computacional.
i) Asesora especializada.
j) Resolucin de incidentes de la plataforma computacional central o crtica.
k) Diseo y planificacin 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) Disear y Planificar la infraestructura de soporte a los servicios TI.
c) Definicin de los estndares de Implementacin apropiados para las
soluciones de infraestructura TI en el ambiente productivo.
d) Implementacin de las soluciones desarrolladas o adquiridas para el negocio
y/o TI, con una mnima interrupcin de los procesos de negocio.
e) Proveer una plataforma TI estable y segura, disponible a ser usada como un
soporte fundamental para la provisin 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 renan los objetivos y requerimientos que satisfacen al
negocio.
g) Entregar un soporte y asesoramiento especializado para la adquisicin y
utilizacin de la infraestructura TI que dan soporte a los servicios.
h) Gestin, seguimiento y control de los proveedores de infraestructura y
servicios bases computacionales.
i) Gestin, seguimiento y control de la seguridad informtica.
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 recuperacin ante desastre que
puedan afectar los servicios TI soportados por la plataforma computacional.
l) Provisin, mantencin y administracin de la infraestructura de
telecomunicaciones acorde a las exigencias de los aplicativos de negocio.

2. Defi nicin de Cargos

De la estructura organizacional definida en el punto 1 de este captulo, se presenta la
definicin de los cargos.
2.1 Gerencia de Servicios TIC

Gerente de Servicios TIC

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


Jefe de Finanzas y Control de Gestin

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

2.2 Subgerencia de Relacin Comercial

Subgerente Relacin Comercial

Es el responsable de la definicin, planificacin, seguimiento y control del servicio TIC
ante los clientes.

Service Manager

Responsable de la entrega del servicio TIC, su planificacin y resultados en el mbito
de la zona o empresas que representa. Canaliza los requerimientos de los clientes de
manera eficiente y efectiva a travs de la organizacin de servicios TIC.

Ingeniero de Planificacin y Gestin del Servicio

Apoya las funciones del Subgerente y de cada uno de los Service Manager en la
planificacin 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 implantacin, revisin 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 solucin de problemas y errores conocidos. Se preocupa
de que los incidentes no solucionados por el service desk, sean solucionados,
investigados y evitados.



110

Tcnico de Terreno de Soporte

Responsable de entregar apoyo a los procesos y funcionamiento del soporte de
segundo nivel, incluyendo el seguimiento y solucin 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 solucin de problemas y errores
conocidos. Se preocupa de que los incidentes que no soluciona el service desk, sean
solucionados, investigados y evitados.

Jefe de Mantencin

Responsable del servicio de mantencin de aplicaciones.

Jefe de Mantencin Zonal/SAP

Responsable del control y planificacin del proceso de mantencin de aplicaciones.

Analista de Demanda

Responsable del soporte a la gestin, asignacin y control del mantenimiento de las
aplicaciones.

Analista de Aplicaciones

Responsable del soporte al anlisis, diseo, modificacin y construccin de
aplicaciones de negocio o implantacin de paquetes comerciales.

Ingeniero de Mantencin

Responsable del anlisis, diseo y construccin de aplicaciones de negocio o
implantacin 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 gestin de proyectos de desarrollo, e implementacin de
aplicaciones y paquetes comerciales.
111

Jefe de Proyectos

Responsable del anlisis, diseo y construccin de aplicaciones. Se preocupa de la
implementacin de paquetes comerciales. Ayuda a los clientes a identificar problemas y
soluciones.

Ingeniero de Proyectos

Responsable de la ejecucin de los procesos de desarrollo, mantencin, e
implementacin de software.

Ingeniero de Control y Planificacin

Responsable de apoyar las labores de asignacin de recursos, seguimiento y control de
los procesos de desarrollo e implementacin de software, arquitectura y plataforma
SAP.

2.5 Subgerencia de Infraestructura

Subgerente de Infraestructura

Responsable de la definicin, planificacin, coordinacin, diseo y funcionamiento de la
infraestructura informtica de la organizacin. Gestiona personas, recursos y procesos
de manera eficiente.

Jefe de Operaciones

Responsable de la operacin de la plataforma informtica. Coordina y disea la
infraestructura, establece polticas y documentacin necesaria.

Jefe de Redes

Responsable de la coordinacin con proveedores y diseo de la infraestructura de
redes de la organizacin.

Jefe de Ingeniera

Responsable de la coordinacin con proveedores y diseo de la plataforma de la
organizacin.

Jefe de Seguridad Informtica

Responsable de la definicin y seguimiento de las polticas de seguridad al interior de la
organizacin.




112

Analista de Seguridad

Responsable de ejecutar las actividades necesarias para cumplir con las polticas de
seguridad.

Operador de Sistemas

Responsable de la operacin, mantenimiento y control de los activos informticos.

Admi nistrador de Red

Administra y coordina los cambios sobre la plataforma de redes de la organizacin.
Realiza labores de optimizacin.

Admi nistrador de Base de Datos

Administra y coordina los cambios sobre la plataforma de base de datos de la
organizacin. Realiza labores de optimizacin.

Ingeniero de Sistemas

Responsable del diseo, planes y estrategias de implementacin de una plataforma de
acuerdo a las necesidades de la organizacin.


113

Captulo 5 Implementacin, transicin y cambio

1. Plan de impl ementaci n, transici n y cambi o

Para la implementacin del servicio, un primer aspecto a considerar es la cultura
organizacional. El holding, se caracteriza por su carcter jerrquico, donde
prcticamente 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 accin. Este
problema, se ve aminorado por la definicin y el marco de los procesos, sin embargo,
es necesario convencer a las personas para que adopten un nuevo enfoque para la
atencin 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 colaboracin ms que jerrquico entre las diferentes unidades.

Otro elemento a considerar es que la alta direccin ha pedido, que durante el periodo
de transicin, las filiales que reciben servicios de TI no sufran impacto por el cambio.
Por lo tanto, el plan de implementacin, transicin y cambio debe considerar aspectos
culturales, de operacin actual y actividades a desarrollar en el tiempo.

Como marco general, se distinguen las siguientes grandes etapas:

a) Previa al cambio.
b) Transicin y cambio.
c) Entrega del servicio.

Durante la etapa previa se definen los procesos, la estructura organizacional y la
planeacin operativa para la transicin. Durante la transicin, se va implantando la
nueva estructura organizacional y los procesos definidos, para finalmente entrar en
rgimen en la etapa de entrega del servicio.

A continuacin se presenta el detalle de cada etapa.
1.1 Etapa previa al cambio

La etapa previa al cambio, corresponde al conjunto de actividades de capacitacin y
definicin de la estructura organizacional y los procesos TI.

114



1.1.1 Actividades de Capacitacin

Dentro de las actividades de capacitacin 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 integracin, cuyo objetivo es lograr que las personas de la
gerencia de servicios TIC se conozcan entre s.
b) Taller de negociacin, cuyo objetivo es capacitar y practicar en los aspectos y
tcnicas modernas de la negociacin, orientado a Subgerentes y a jefes de
rea.
c) Taller de manejo de conflictos, cuyo objetivo es entregar elementos y tcnicas
de resolucin 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 orientacin 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 definicin de los procesos TI

Tal como se revis en el captulo 2, la definicin de los procesos es hecha mediante el
enfoque de re-ingeniera. Contempla la participacin de los subgerentes y jefes de rea
en la definicin de los procesos, mediante talleres.

1.1.3 Actividades de definicin de la estructura organizacional

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

115


1.2 Etapa de transicin y cambio

Operativamente, el problema de la etapa de transicin 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 difusin del servicio.

En primera instancia, el plan de traspaso debe considerar la funcin actual que es
realizada por una persona y la funcin 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 podra recibir, producto de la consolidacin de
funciones y servicios.
2. Que una persona no se mantenga realizando las mismas funciones,
distinguindose dos situaciones:
a) La funcin es nueva, por lo tanto solo debe entregar.
b) La funcin se vena 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 funcin en el proyecto, a la persona
que asumir el rol en la nueva organizacin. El problema de esto, es que provoca
inestabilidad en los servicios, por el hecho de introducir cambios de personas en
trabajos que ya estn en curso y por lo tanto las empresas pueden verse ms afectadas
de lo que podra esperarse.

Otro criterio para minimizar la inestabilidad, es considerar, de la estructura
organizacional antigua, las funciones crticas para mantener operativos los servicios
que reciben las filiales. Entonces se tendrn 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 administracin 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 debern
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 debern terminar las mantenciones que tienen asignadas y
luego asumir y/o recibir las nuevas actividades.

116

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

Entonces, la estrategia de cambio es un proceso que comienza primero con la lnea 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 sealados anteriormente en el tiempo que sea necesario, hasta completar toda
la organizacin, siendo deseable completar este proceso en un periodo de a lo ms un
ao. 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 organizacin TIC.

El plan de difusin 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. Adems, se distribuir un folleto explicativo al personal de las empresas.
Esta actividad ser ejecutada una vez que los subgerentes asuman sus funciones.

La presentacin del servicio ser realizada por: el Gerente de servicios TIC, el
Subgerente de Relacin Comercial y el Service Manager de la empresa a la cual se
realizar la presentacin. Se darn a conocer los siguientes puntos:

a) Breve introduccin de la empresa de servicios compartidos.
b) Presentacin de la nueva modalidad de servicios: estructura organizacional
TIC, breve descripcin de los procesos que se utilizarn, acceso a los
servicios.
c) Descripcin de los servicios ofertados.
d) Formalizacin de inicio de la nueva modalidad de servicios.

En la tabla 25, se presenta el plan global de transicin, difusin y cambio.

1.3 Etapa de entrega del servicio

Finalmente, la etapa de entrega del servicio, es el estado de rgimen de la
organizacin, en donde los procesos se encuentran adoptados y en funcionamiento. El
objetivo es llegar a este estado un ao despus de iniciado el proceso de transicin y
cambio.
117



Tabla 25: Plan global de difusin y cambio
118

Captulo 6 Estrategia para la Mejora del Software

1. Marco del Proceso de Mej ora de Software

El objetivo de este captulo es disear el plan de accin estratgico para la mejora del
proceso de software (SPI) para proyectos de desarrollo y el proceso de mantencin del
rea de tecnologas de informacin, dentro de un marco de trabajo futuro, pensando en
la evaluacin bajo CMMi en el mediano y largo plazo.

El plan de accin, integrara todas las actividades de mejora del proceso de software
mediante la adopcin del modelo CMMi para la disciplina de Ingeniera en Software.
Este modelo, proporciona una gua para mejorar el proceso de una organizacin y la
capacidad para administrar el desarrollo, adquisicin y mantencin 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
implantacin de las mejoras. Los esfuerzos realizados se contrastaran con las
evaluaciones, tanto formales como informales de CMMi, las recomendaciones sern
incorporadas e institucionalizadas con el objeto de incentivar la mejora continua del
proceso.

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

La motivacin de esta iniciativa se basa en principios guas y en la oportunidad de
entregar mejores servicios a los clientes.

El compromiso de la alta gerencia es crtico para esta iniciativa, se espera:

a) Se disponga de los recursos apropiados y adecuados para el proyecto.
b) Existan comunicaciones continuas hacia la organizacin, 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 participacin y aporte en el proyecto.

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

119

2. Plan Estratgico de Mejora del Proceso de Software

2.1 Misin

Promover la mejora de procesos contina a travs de las filiales del holding, proveer la
gua hacia el camino de la excelencia en cada una de las reas de proceso, que
permitan a la organizacin aumentar y mantener su nivel de madurez en el tiempo.

2.2 Visin

El servicio compartido de tecnologas de informacin pondr todos sus esfuerzos en
institucionalizar los procesos de software mediante estndares documentados y proveer
productos fiables y servicios a tiempo, al mnimo 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 mtodo
prctico de identificacin y evaluacin para medir la madurez del proceso de software.

2.4 Principios Guas

1. La satisfaccin de nuestros clientes es crtica y de suma importancia para los
negocios.
2. La mejora continua del proceso de software es esencial para el xito.
3. Procesos comunes y estndares son indispensables para el crecimiento
organizacional.
4. Los esfuerzos en la mejora de procesos son administrados con un eficiente uso
de recursos.


120

2.5 Metas de Corto Plazo

Obtener evaluacin satisfactoria en CMMi nivel 2 en un plazo no superior a 2 aos.

Estandarizar las prcticas y procesos de software del rea de tecnologas de
informacin 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 ingeniera de software basada en la mejora
continua de los procesos.

Alcanzar los distintos niveles de madurez CMMi cada 2 aos, realizando evaluaciones
cada 1 ao.

2.7 Metas Estratgicas Deri vadas del Negocio

Alinearse con la poltica de calidad del holding matriz respecto a los procesos
productivos.

Mantener el liderazgo en costos y la produccin de productos de alta calidad, conforme
a los estndares internacionales de la industria.

2.8 Obj etivo

El objetivo de esta iniciativa es disminuir los costos para los procesos de desarrollo y
mantencin 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 Gua 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 tcnicas, administracin de
121

proyectos y calidad. La organizacin 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-
utilizacin de cualquier prctica, documento, o artefacto existente en la organizacin.

2.11 Supuestos

Para el desarrollo de este plan es necesario contar con los recursos, tanto humanos,
tcnicos y financieros, que permitan llevar a un buen trmino el proyecto SPI, bajo este
paradigma se asumen una serie de supuestos crticos para el xito, estos son:

a) La creacin de una Subgerencia de Calidad, que se har cargo de los
procesos, la mejora continua y liderar esta iniciativa a travs del tiempo.
b) CMMi ser utilizado como base para todas las definiciones de proceso,
polticas y prcticas 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. Adems, ser
el canal de comunicacin hacia niveles ms altos de la organizacin.

Se cuenta con el auspicio de los subgerentes del rea de tecnologas de informacin,
de quienes se tiene el compromiso de facilitar los recursos humanos.








122

2.13 Riesgos

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



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

2.14 Barreras

Una de las principales barreras a enfrentar por este proyecto, es el grado conservador
del holding respecto a la adopcin de nuevas tecnologas y a que no se ha tomado
conciencia de que el servicio de informtica es un real apoyo para el negocio como
generador de beneficios. Histricamente, las empresas han tenido su focalizacin en el
negocio desechando actividades que no generan valor, el servicio de informtica se
considera como un centro de gastos ms que un centro generador de beneficios por lo
que cualquier iniciativa proveniente del rea tiene un alto grado de cuestionamiento. Por
otro lado, la capacitacin interna en temas de tecnologas de informacin 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
mtodos tradicionales, sin embargo al no existir experiencia previa se dificulta la
medicin de beneficios cuantitativos del proyecto y por lo tanto su justificacin en el
directorio de la empresa. Se debe partir, por una evaluacin cualitativa hasta obtener
algn 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 direccin del holding y la capacitacin continua en el modelo.


123

2.15 Organizacin para la Mej ora del Proceso

2.15.1 Alcance Organizacional

El proyecto SPI tiene alcance sobre el holding completo, afectando a los servicios
informticos que se prestan en cada una de las filiales, el rea involucrada directamente
en esta iniciativa es la Gerencia de Tecnologas de Informacin y Comunicaciones.

Desde el punto de vista de las filiales, los procesos que les signifiquen participacin del
proceso de software estn dentro del alcance de este proyecto, el plan comunicacional
deber incorporar a los clientes finales de cada filial, con el objeto de transmitirles las
prcticas y procedimientos sujetos a mejora continua, esto aportar tambin la
institucionalizacin 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 visin 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 planificacin estratgica a utilizar.
b) Definir y crear el plan estratgico de accin.
c) Revisar e integrar la visin, misin y plan de negocio al proceso de mejora de
software.
d) Comunicar a los niveles altos de la organizacin 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 Tecnologas de Informacin y Comunicaciones.
c) J efe de Proyecto SPI.




124

2.15.3 Jefe del Proyecto SPI

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

a) Documentar el plan de accin estratgico.
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 accin 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 planificacin.
h) Adquirir y coordinar los recursos para capacitacin y consultora.

2.15.4 SEPG (Software Engineering Process Group)

El SEPG tendr las siguientes responsabilidades:

a) Determinar y definir la organizacin (procesos y mtodos).
b) Establecer la forma de evaluar el proceso.
c) Presentar los resultados del proceso a los diferentes niveles de la
organizacin.
d) Establecer planes tcticos de accin.
e) Supervisar los proyectos de mejoramiento.
f) Evaluar y verificar los avances.

El SEPG estar compuesto por:

a) J efe del Proyecto SPI.
b) Project Managers.

2.15.5 Grupos de Trabajo Tcnicos (TWG)

Los miembros de los grupos de trabajo tcnicos, tendrn la responsabilidad de producir,
revisar y asistir en el piloteo de nuevos procesos de software y de herramientas de
mejora. Cada grupo, tendr un lder 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
organizacin.
125

d) Conducir los pilotos.
e) Propondrn mejoras y modificaciones a los procesos.

Se definirn 6 TWG, cuyas reas de proceso sern asignadas de comn acuerdo con el
lder del proyecto SPI. Los TWG estn compuestos por:

TWG 1:

a) J efe del Proyecto SPI (como facilitador).
b) J efe de Proyectos de Automatizacin.
c) Ingeniero de Proyectos SAP.

TWG 2:

a) J efe del Proyecto SPI (como facilitador).
b) J efe de Proyectos de Inteligencia de Negocio.
c) Ingeniero de Mantencin.

TWG 3:

a) J efe del Proyecto SPI (como facilitador).
b) J efe de Proyectos SAP.
c) Ingeniero de Proyectos Automatizacin.

TWG 4:

a) J efe del Proyecto SPI (como facilitador).
b) J efe de Proyectos de Integracin.
c) Ingeniero de Proyectos Inteligencia de Negocio.

TWG 5:

a) J efe del Proyecto SPI (como facilitador).
b) J efe de Proyectos Software General.
c) Ingeniero de Proyectos Integracin.

TWG 6:

a) J efe del Proyecto SPI (como facilitador).
b) J efe de Proyectos de Mantencin.
c) Ingeniero de Proyectos Software General.

2.15.6 Consultores Externos

Como parte del proyecto SPI, se utilizarn consultores externos para la evaluacin
formal en los niveles de madurez CMMi. Adems 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 asesora de una empresa especializada.
126


2.16 Criterios de xito

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

Desde el punto de vista estratgico:

a) Obtener satisfactoriamente la evaluacin CMMi nivel 2 en un periodo no
mayor a 2 aos.
b) Obtener satisfactoriamente la evaluacin CMMi en niveles superiores cada 2
aos a partir de la fecha de obtencin del nivel 2.
c) Institucionalizacin de las reas de procesos relacionadas con el desarrollo
de software.
d) A mediano plazo, el establecimiento de evaluaciones informales cada ao y
formales cada ao por medio.

2.16.1 Medicin de Metas de Corto Plazo

La estandarizacin de las prcticas y procesos de software, ser medida mediante la
adopcin 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 medicin de realizar anualmente mediante
evaluaciones informales.

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

2.16.2 Medicin de Metas de Largo Plazo

Para medir el desarrollo e institucionalizacin de la cultura de ingeniera de software
basada en la mejora continua de los procesos, se tomarn controles a los integrantes
del rea informtica. Se considerar logrado el objetivo cuando se obtenga en promedio
un 100% de respuestas correctas en los controles.

2.16.3 Medicin de Metas Estratgicas Derivadas del Negocio

La medicin del alineamiento con la poltica de calidad del holding respecto a los
procesos productivos, ser medida mediante la obtencin de evaluaciones
satisfactorias en los niveles de madurez de CMMi.
127


Para medir el mantenimiento del liderazgo en costos y la produccin de productos de
alta calidad conforme a los estndares internacionales de la industria, se establecern
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
debern ser eliminados por sobre el 99%.

2.17 Planificacin

2.17.1 Costos Estimados

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



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


128

2.17.2 Roadmap

La planeacin estimada de actividades, se puede visualizar en la tabla 28.



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


129

Captulo 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 carcter general,
donde la idea era establecer un marco de trabajo para la organizacin, desde la
planeacin estratgica hasta el manejo de la infraestructura informtica.

Los procesos TIC fueron definidos bajo el marco de referencia de CMMi e ITIL, lo que
permite tener una base de procesos estndar, contribuyendo a la simplificacin de la
operacin y control del negocio y con la posibilidad de adoptarlos completamente. En
contraste con la situacin inicial, en donde prcticamente no existan 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 organizacin,
pero no establecen mecanismos que promuevan la mejora continua. Por ello, el plan
estratgico de mejora del proceso de software presentado en el captulo 6, es un primer
paso en dicha direccin.

El esquema de servicios compartidos permite que las soluciones tecnolgicas sean
transversales al holding, generando sinergia, economas de escala, estandarizacin 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 operacin de las
actividades de apoyo al negocio. En la situacin 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 prcticamente equivalentes.

En trminos cuantitativos, bajo la situacin inicial, el gasto promedio mensual en
tecnologas de informacin 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 disminucin promedio de un 11,7%. Paradjicamente,
los proyectos de software son aproximadamente un 15% ms caros respecto a la
situacin inicial, esto producto de la transparentacon de los costos del personal propio,
pero como son considerados inversiones, en la evaluacin econmica se exige una
tasa de descuento superior, lo que compensa la situacin.
17


Las definiciones entregadas en esta tesis se basan en decidir la mejor estrategia de
provisin de servicios, respecto a la localizacin geogrfica de las instalaciones, el tipo
de industria y al paradigma de servicios compartidos. Es interesante destacar que los
marcos de referencia utilizados, prcticamente se independizan de estas variables y
establecen criterios de diseo de acuerdo a las mejores prcticas, criticidad y
distribucin de los procesos propios del negocio.


17
Fuente: Reportes de facturacin del servicio TIC y presupuestos internos del holding.
130

An queda trabajo por hacer en la definicin de, los procedimientos y el detalle de los
procesos que, por su extensin, solo fueron elaborados en sus aspectos ms
relevantes. Adems, se han de normalizar los dos grandes problemas que aparecieron
producto de la implementacin de este proyecto.

El primer problema fue la tendencia de la direccin de este proyecto, a minimizar y
simplificar el esfuerzo requerido para producir el cambio y en focalizarse en definir la
organizacin antes que los procesos. Tambin, el suponer que todas las personas
colaboraran y adoptaran los nuevos modelos, produjo una serie de dificultades en la
implantacin. Se presentaron problemas de coordinacin, disputas de poder entre reas
y en general, desorden respecto a lo que se deseaba alcanzar.

Si bien simplificar el problema puede ser una aproximacin para abordarlo y entenderlo,
este criterio no debe ser usado para la ejecucin de proyectos de este tipo, que por sus
caractersticas y complejidad requiere estudio, participacin ms ampla de las
personas y anlisis en profundidad.

El segundo problema fue que la asignacin 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 seleccin de personal. La asignacin de
personas a funciones debe realizarse con un conocimiento acabado de competencias y
perfiles.

El uso de modelos y estndares de la industria no garantiza el xito de una
organizacin. Se pueden modelar, adoptar, e implementar procesos, pero sin la
contribucin 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 modificacin de hbitos de trabajo. Una deficiencia en esta
componente dificulta este tipo de proyectos, produciendo resistencia a la adopcin de
nuevas formas de trabajar. Por lo tanto, los lderes de este tipo de proyectos deben ser
buenos negociadores, poseer un manejo fluido de la comunicacin y ser guas del
proceso de adopcin, ms que impositores de estructuras.

Finalmente, la adopcin de estndares probados, facilita a las reas de tecnologas de
informacin, la definicin 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 tecnologas 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 travs del tiempo.



131

Bibliografa

[1] ACH, VERONICA. 2004. Apuntes del curso: ISO 9000. Diplomado en Gestin de
Calidad de Software. Departamento de Ciencias de la Computacin. Universidad de
Chile.

[2] BASTARRICA, MARIA CECILIA. 2004. Apuntes del curso: Introduccin a la
Ingeniera de Software. Posttulo en Ingeniera y Calidad de Software. Departamento
de Ciencias de la Computacin. Universidad de Chile. pp 78-83.

[3] BOUMAN, J ACQUES, 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. Catlogo 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 ejecucin
de manufactura. Documento Interno. Empresa Forestal. Chile. 93p.

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

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

[9] GUERRERO, J OS. 2004. Apuntes del curso: Tcnicas de Pruebas. Diplomado en
Gestin de Calidad de Software. Departamento de Ciencias de la Computacin.
Universidad de Chile.

[10] GUERRERO, LUIS. 2005. Apuntes del seminario: Introduccin al UML. Posttulo
en Gestin Informtica. Departamento de Ciencias de la Computacin. Universidad de
Chile.

[11] HAX A y MAJ LUF N. 1996. Gestin de Empresa con una Visin Estratgica.
Ediciones Dolmen. Chile. Captulo 1.

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

[13] J ORRAT, MICHAEL. 2000. Apuntes del curso: Evaluacin de Proyectos.
Departamento de Ingeniera Industrial. Universidad de Chile.

132

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

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

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

[17] MICROSOFT CORPORATION. 2005. Microsoft Framework Solutions for CMMi.
Visual Studio Team System. Versin 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: Gestin de Proyectos Informticos.
Posttulo en Gestin Informtica. Departamento de Ciencias de la Computacin.
Universidad de Chile. 247p

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

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

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

133

[29] STRAUB, PABLO. 2004. Apuntes del curso: Introduccin a la gestin de calidad.
Diplomado en Gestin de Calidad. Departamento de Ciencias de la Computacin.
Universidad de Chile.

[30] PINTO, FERNANDO. 2004. Apuntes del curso: Introduccin a CMMi. Diplomado
en Gestin de Calidad de Software. Departamento de Ciencias de la Computacin.
Universidad de Chile.

[31] VARAS, SAMUEL. 2003. Apuntes del curso Tecnologas de Informacin y
Rediseo de Procesos. Departamento de Ingeniera Industrial. Universidad de Chile.
554p

[32] WWW.IDEF.COM. Descripcin del modelo IDEF [en lnea]. http://www.idef.com.
[Consulta: 22 de Marzo de 2006]

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


134









ANEXOS


135









ANEXO I: Comparaci n entre l as pl ataformas .NET y J2EE
136

ANEXO I: Una comparacin entre .NET y J2EE

No es sencillo realizar una comparacin 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 visin rpida de las
diferencias, similitudes, ventajas y desventajas, desde el punto de vista global.




Figura 1: Arquitectura .NET
18



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

137



Figura 2: Arquitectura J2EE
19


De acuerdo a SUN, J 2EE es un conjunto de especificaciones y prcticas que permiten
el desarrollo de soluciones empresariales multi-capa, basados en la tecnologa J ava.
Considera un nico lenguaje de programacin, J ava, que se caracteriza por ser portable
robusto, estable, orientado a objetos, e independiente de la plataforma. Al igual que
C++, el que podra considerarse como su predecesor, esta orientado fuertemente a
mantener la consistencia de los tipos de datos, provee mecanismos para herencia
mltiple, pero no permite la programacin de funciones fuera de las clases. La
ejecucin de aplicaciones se realiza utilizando una mquina virtual, que interpreta el
cdigo intermedio generado por el compilador.

.NET es una plataforma de desarrollo de servidores, clientes y servicios. Se basa en
estndares abiertos como CLI, SOAP y WSDL. Permite al programador trabajar sobre
mltiples lenguajes en un entorno nico de desarrollo (Visual Studio). Al igual que
J 2EE, utiliza cdigo intermedio, con la diferencia que el compilador traduce los
lenguajes soportados a uno comn, el que es ejecutado por un interprete. Esto permite
que un programa en un cierto lenguaje pueda utilizar cdigo o componentes escritos en
otro lenguaje. Los lenguajes base de la plataforma con C#y Visual Basic.

C#es una especie de evolucin entre J ava y C++, por lo que existen coincidencias con
J ava, es decir:

- Ambos lenguajes son compilados a cdigo intermedio, independiente de la
plataforma y del sistema operativo para el caso de J ava y dependiente del
sistema operativo para los lenguajes bajo .NET. Cabe sealar, que existen una
serie de iniciativas para portar .NET a ambientes UNIX, siendo el proyecto Mono,
de cdigo abierto, uno de los mas utilizados.
- No permiten el uso de punteros, aunque con C#se pueden utilizar en el modo de
programacin unsafe.
- El cdigo es organizado en clases.
- Ambos permiten herencia mltiple mediante el uso de interfaces.


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

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




Tabla 1: Comparacin entre lenguajes .NET y Java
20


Respecto a las plataformas, las ventajas de .NET sobre J 2EE son:

1. .NET soporta mltiples lenguajes de programacin, lo que permite flexibilidad al
programador y una evolucin en los entornos de programacin, facilitando la
integracin y portabilidad de las aplicaciones.
2. El entorno de programacin .NET est orientado a la creacin de servicios web,
incluyendo nativamente formatos SOAP, WSDL y UDDI, Sin que el programador
tenga que generar por si mismo el cdigo XML.
3. Microsoft con su suite Visual Studio, establece una serie de prcticas de
desarrollo de software que pueden ser aplicadas con mtodos tradicionales y
giles, en cambio J 2EE solo ofrece la plataforma, donde las prcticas son
abordadas mediante entornos de programacin de terceros.

Por otro lado, J 2EE presenta las siguientes ventajas respecto a .NET:

1. La tecnologa J ava es abierta y basada en estndares internacionales.
2. J 2EE puede ser adquirido en varias compaas, en contraste con .NET, en el
que el proveedor es nico.
3. Posee un nivel de madurez superior a .NET en relacin a la arquitectura sobre
diferentes plataformas, el tiempo de permanencia en el mercado y en la
estabilidad.

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

20
Fuente: JIMNEZ, LUZ ELENA. 2003. Una comparacin entre JAVA y .NET. En: Sistemas & Telemtica.
Universidad ICESI. Colombia. pp 80-81
139

es mejor utilizar .NET ya que la evolucin tecnolgica no significa mayores costos
(salvo licencias, por supuesto) y resulta ser directa. Lo mismo ocurre con J 2EE, si la
plataforma ya est establecida bajo Windows, tiene menos costo seguir con la mismo,
frente a una migracin. Por otro lado, en entornos nuevos, si la plataforma per-se es
UNIX, J 2EE resulta ser la eleccin natural. En cambio, para Windows, la diferencia la
har el costo de implementacin y mantencin entre J 2EE y .NET, el que debe ser
evaluado de acuerdo al caso particular.
140









ANEXO II: Ejempl os de Normas y Procedimi entos
141

ANEXO II: Polticas Generales del Servicio TIC

OBJ ETIVOS

El servicio TIC es la responsable de normar todos los aspectos relacionados con los
sistemas, comunicaciones de red y tecnologas de informacin del holding y sus filiales,
con el objeto de prestar servicios, para que el personal disponga de las herramientas,
que apoyen efectivamente su gestin en el logro de los objetivos de las empresas,
operando eficientemente sus sistemas de informacin y de comunicacin.

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 relacin a Sistemas, Bases de
Datos y Servidores, que permitan un adecuado nivel de seguridad y resguardo
de la informacin en caso de fallas o desastre. Los programas de respaldo se
debern 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 J efe
de Seguridad y/o Gerente, Subgerente del rea respectiva. En particular, se
deben tener las siguientes consideraciones:
a. Acceso a aplicaciones y sistemas: Autoriza J efe de Seguridad y/o
Gerente, Subgerente, quien deber entregar su aprobacin por escrito.
b. Acceso a la red Internet, creacin de cuentas de red y cuentas de correo:
Autoriza J efe 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
autorizacin del Gestor de Proyectos.
g. Software base de datos, es decir Oracle y SQL Server: Solo se instalan a
los clientes con previa autorizacin del Ingeniero de Soporte.

ALCANCE

Aplicable al personal del holding y sus filiales.

POLTICA SOBRE LA SEGURIDAD EN EL ACCESO A LA RED

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

2. Para acceder a la red computacional, cada usuario dispondr de una Contrasea
personal e intransferible, asignada inicialmente por el administrador de red, la
que ser cambiada la primera vez que utilice su cuenta de red. Adems el
usuario podr libre e independientemente cambiar su contrasea cuando lo
requiera. Las contraseas de usuario tendrn una expiracin no mayor a 3
meses, cumplido ese tiempo el sistema de autenticacin de red pedir cambiar el
Contrasea al usuario. Las Contrasea asociadas a la Administracin de
Servidores sern cambiadas con una frecuencia no mayor de 3 meses. Las
Contrasea tendrn un largo igual o superior a 6 caracteres y no podr repetirse
el mismo Contrasea por 3 periodos.
3. Para acceder a un sistema de informacin, los usuarios dispondrn de una
Contrasea, asignada por el Ingeniero de Soporte, el que es responsable de
definir el perfil del usuario. Se recomienda un cambio de Contrasea con una
frecuencia no mayor de 3 meses.
4. Toda vez que un trabajador abandone la empresa, el rea de Recursos
Humanos informar con anticipacin, con el objeto de eliminar su acceso a la red
computacional y dems privilegios en los sistemas.
5. El ingreso a las Salas de Computacin de las Plantas, donde se encuentran los
servidores y otros elementos de hardware relevantes de la red, ser restringido
slo a personal autorizado.

POLTICA DE RESPALDO Y RECUPERACIN DE DESASTRE.

1. Con el objeto de reponer los servicios en el ms breve plazo y disminuir el riesgo
de prdida de informacin, frente a contingencias graves en las instalaciones
fsicas, se dispondr de los correspondientes respaldos de informacin y de
alternativas de accin para reponer las distintas lneas de equipos.
2. Se privilegiar mantener convenios de soporte tcnico y mantencin de los
equipos crticos con los proveedores o sus representantes oficiales.
3. Para asegurar una adecuada reposicin de los sistemas de informacin y
recuperacin 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 almacenarn 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.

POLTICA 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 Contrasea.
2. Cada J efe de Departamento puede solicitar la creacin 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,
telfono (anexo) e indicar si el usuario tendr correo o no.
3. Todas las cuentas de red por defecto tendrn acceso a Internet. El acceso VPN
ser a pedido. El solicitante deber especificar las excepciones.
143

4. La Cuenta de usuario ser personal e intransferible. La Contrasea inicial ser
asignada al momento de la creacin de la Cuenta y puede ser cambiada libre e
independientemente por el propio usuario.
5. La contrasea de red expira, excepto la contrasea empleada para crear la
cuenta.

POLTICA DE REQUERIMIENTO DE CORREO ELECTRNICO

1. El requerimiento de la cuenta de Correo Electrnico debe ser solicitado al
Service Desk, siguiendo los mismos pasos de la Poltica 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 descripcin la
funcin desempeada y la identificacin de la empresa contratista.
c. Se debe configurar la estacin 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 limitacin de 10 Megabytes para el
volumen de informacin de envi y recepcin.
e. Los correos almacenados en el servidor estn sujetos a un tamao
mximo de 100 Megabytes.


POLTICA DE INSTALACIN DE SOFTWARE EN ESTACIONES DE TRABAJ O

1. El requerimiento de instalacin de Software debe ser solicitado al Service Desk,
por el usuario. El proceso de instalacin deber seguir los siguientes pasos:
a. El Service Desk registrar el requerimiento y asignar la actividad al
Coordinador de Service Desk, con toda la informacin 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 confirmacin, el Coordinador asignar al Tcnico de Terreno,
al Ingeniero de Soporte, o ambos si corresponde para informar y proceder
con la ejecucin de la instalacin.
d. En caso que la solicitud sea negativa, se informar al usuario

POLTICA 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 instalacin de Software.
3. La salida a Internet se realiza a travs de un servidor PROXY.
4. El acceso de personas que no pertenezcan al holding y sus filiales, deben ser
autorizado por la lnea ejecutiva respectiva.


144

POLTICA DE CONEXIN DE EQUIPAMIENTO A LA RED

1. El servicio TIC es el responsable de aprobar la incorporacin de equipamiento
computacional a la red con el objeto de cautelar la confidencialidad,
disponibilidad e integridad del recurso de informacin de la empresa.
2. Esta poltica 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 tcnicamente 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. Configuracin estndar de equipos. Los equipos deben tener la
configuracin estndar de los equipos computacionales de la empresa.
d. Operacin segura de equipos conectados de terceros.
3. La deteccin de una anomala en algn 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 operacin.



145

ANEXO II: Procedimiento de Paso a Produccin

OBJ ETIVOS

Establecer las normas y procedimiento para los pasos a produccin.

Disminuir el impacto de los pasos a produccin sobre la plataforma informtica en
operacin.

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 Mantencin: Realiza una
solicitud de paso a produccin y apoya las actividades relacionadas de la solicitud.

J efe de Operaciones, J efe de Ingeniera: Aprueba, autoriza o rechaza cualquier tipo de
solicitud de paso a produccin.

Ingeniero de Sistemas: Ejecuta el paso a produccin segn la documentacin
entregada.

Administrador de base de datos: Ejecuta el paso a produccin segn la documentacin
entregada.

Coordinacin Service Desk: Asigna y coordina el requerimiento de paso a produccin.

Mesa de Cambios: Instancia (reunin) donde son analizados los cambios en la
plataforma de servidores derivados de: pasos a produccin, mejoras operacionales, o
cualquier cambio que signifique una modificacin en la configuracin de uno o ms
servidores.

EQUIPOS Y MATERIALES

1. Plan de paso a produccin: Conjunto de actividades tendientes a realizar el paso
a produccin. El plan deber poseer al menos la siguiente informacin:
a. Actividad a realizar.
b. Tiempo estimado de la actividad.
c. Responsable de la actividad.
2. Plan de reversa del paso a produccin: Conjunto de actividades tendientes a
reversar un paso a produccin. El plan deber poseer al menos la siguiente
informacin:
a. Actividad a realizar.
b. Tiempo estimado de la actividad.
146

c. Responsable de la actividad.
3. Plan de contingencia: Conjunto de actividades que ser aplicado en caso de
presentarse problemas con el servicio, software o el servidor que se encuentra o
que se est pasando a produccin.
4. Plan de pruebas ejecutado: Conjunto de actividades realizadas sobre el software
que aseguran y demuestran su buen funcionamiento.
5. Procedimiento de instalacin de productos de software: Documento orientado al
soporte, que muestra paso a paso como realizar la instalacin de un producto de
software.
6. Documento de especificacin de plataforma: Documento nico donde se
especifica tcnicamente los elementos de un paso a produccin de servidor,
servicio, o software sobre un servidor. Se debern completar las secciones que
apliquen a la actividad que se realizar.
7. Protocolo de entrega: Certificado de la conformidad del paso a produccin.
8. Scripts de base de datos.
9. Artefactos de software.
10. Sitios o pginas web.
11. Servicios.
12. Equipos computacionales.

NORMAS GENERALES

1. El Gestor de Proyectos, Ingeniero de Proyectos, Ingeniero de Mantencin son las
nicas personas autorizadas para solicitar un paso a produccin. A falta de esta
persona por enfermedad, vacaciones u otro motivo, el Subgerente de rea
deber designar un representante que realizar la solicitud. La designacin
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 documentacin, segn los
siguientes casos:
a. Base de Datos.
i. Plan de paso a produccin.
ii. Plan de reversa del paso a produccin.
iii. Plan de contingencia.
iv. Plan de pruebas ejecutado.
v. Protocolo de entrega.
b. Aplication Server.
i. Plan de paso a produccin.
ii. Plan de reversa del paso a produccin.
iii. Plan de contingencia.
iv. Plan de pruebas ejecutado.
v. Protocolo de entrega.
c. Sitios y pginas web.
i. Plan de paso a produccin.
ii. Plan de reversa del paso a produccin.
iii. Plan de contingencia.
iv. Plan de pruebas ejecutado.
v. Protocolo de entrega.
d. Servicios y software sobre servidores en operacin.
147

i. Plan de paso a produccin.
ii. Plan de reversa del paso a produccin.
iii. Plan de contingencia.
iv. Documento de especificacin de plataforma.
v. Protocolo de entrega.
e. Servidores.
i. Plan de paso a produccin.
ii. Plan de reversa del paso a produccin.
iii. Plan de contingencia.
iv. Documento de especificacin de plataforma.
v. Protocolo de entrega.
f. Productos de software.
i. Plan de paso a produccin.
ii. Plan de reversa del paso a produccin.
iii. Plan de contingencia.
iv. Procedimiento de instalacin para tcnicos en terreno.
v. Protocolo de entrega.
g. Otros no especificados.
i. Plan de paso a produccin.
ii. Plan de reversa del paso a produccin.
iii. Plan de contingencia.
iv. Plan de pruebas ejecutado.
v. Documento de especificacin de plataforma.
vi. Procedimiento de instalacin.
vii. Protocolo de entrega.
3. Una solicitud de paso a produccin podr ser rechazada en los siguientes casos:
a. No presentacin de uno o ms documentos mencionados en el punto 2.
b. Incompletitud, no entendimiento, o inconsistencia de la documentacin
entregada.
4. Las personas facultadas para rechazar un paso a produccin son el Ingeniero de
Soporte, el Administrador de Base de Datos y el Ingeniero de Sistemas.
5. Todo paso a produccin que afecte a la plataforma de redes de rea local,
servidores y sus servicios en operacin deber ser autorizada por Infraestructura.
6. Horarios para pasos a produccin:
a. Base de Datos: Lunes y Mircoles a partir de las 18:00 hrs.
b. Aplication Server: Lunes y Mircoles a partir de las 18:00 hrs.
c. Productos de software: Lunes a J ueves de 12:30 a 14:00 hrs y despus
de las 18:00 hrs.
d. Sitios Intranet: Lunes a J ueves a partir de las 18:00 hrs.
e. Sitios y pginas Internet (Extranet) para Chile: Lunes a J ueves a partir de
las 18:00 hrs.
f. Sitios y pginas Internet (Extranet) para resto del mundo: Lunes a J ueves
a cualquier hora del da.
g. Servicios: Domingo a J ueves segn mejor ventana de tiempo previamente
acordada con la empresa.
h. Servidores nuevos: Lunes a J ueves a cualquier hora del da.
i. Otros no especificados: Lunes a J ueves segn mejor ventana de tiempo
previamente acordada con el cliente.
148

7. No se realizarn pasos a produccin los das Viernes, Sbados y Festivos salvo
expresa autorizacin con la debida justificacin.
8. Se define como hora de cierre para los pasos a produccin ingresados el mismo
da lo siguiente:
a. Base de Datos: Lunes y Mircoles hasta las 16:30 hrs.
b. Aplication Server: Lunes y Mircoles hasta las 16:30 hrs.
c. Productos de software: Lunes a J ueves hasta las 11:30 hrs. y hasta las
17:00 hrs.
d. Sitios Intranet: Lunes a J ueves hasta las 17:00 hrs.
e. Sitios y pginas Internet (Extranet) para Chile: Lunes a J ueves a hasta las
17:00 hrs.
f. Sitios y pginas Internet (Extranet) para resto del mundo: Una hora antes
de realizar el paso a produccin.
g. Servicios: Segn planificacin.
h. Servidores nuevos: Segn planificacin.
i. Otros no especificados: Segn planificacin.
9. En caso de presentarse una contingencia que signifique realizar un paso a
produccin fuera de los horarios mencionados en el punto 6 y que comprometa
la continuidad operacional de la empresa, se deber solicitar autorizacin para la
realizacin de la actividad. La contingencia deber estar debidamente justificada
y podr ser rechazada si:
a. No se presenta la justificacin
b. La justificacin es inconsistente o incompleta, o no explica claramente la
contingencia del negocio.
c. No se cumplen los requisitos mnimos de documentacin para un paso a
produccin.
10. Debido a la dinmica y exigencias del negocio de las empresas, se podrn
realizar pasos a produccin extraordinarios durante horarios distintos a los
definidos en este procedimiento. Para ello se solicitar al usuario final o rea
cliente una justificacin donde se especifiquen claramente los motivos por los
cuales se requiere el paso. Adems se deber solicitar autorizacin por e-mail,
indicando fecha y hora de la actividad y la justificacin del usuario o rea cliente.
El paso a produccin extraordinario podr ser rechazado si:
a. No se presenta la justificacin del usuario.
b. La justificacin 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 veran
afectadas.
d. No se cumplen los requisitos mnimos de documentacin para un paso a
produccin.
11. Durante un paso a produccin se deber contar con la presencia del
desarrollador ya sea en el lugar donde se realiza la actividad o por telfono. Su
labor durante el paso a produccin ser la de apoyar la actividad segn 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 segn el
procedimiento mencionado en el documento, facultar a Infraestructura y Soporte
para derivar directamente cualquier requerimiento o contingencia al desarrollador
responsable por dichas piezas.
149


PROCEDIMIENTO

1. La solicitud de paso a produccin se registrar a travs de la aplicacin de
service desk, adjuntando la documentacin mencionada y los artefactos a pasar
a produccin.
2. El Coordinador asignar el requerimiento segn 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: Coordinacin de tcnicos de terreno.
d. Sitios Intranet: Ingeniero de Sistemas.
e. Sitios y pginas Internet (Extranet) para Chile: Ingeniero de Sistemas.
f. Sitios y pginas 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, recibirn y revisarn la informacin entregada por el
desarrollador y podrn 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
produccin y notificar al desarrollador de la actividad.
b. Aplication Server: Administrador de base de datos o Ingeniero de
Sistemas, segn sea el caso proceder a programar la fecha y hora del
paso a produccin y notificar al desarrollador de la actividad.
c. Productos de software: La coordinacin solicitar a un tcnico en terreno
probar el procedimiento de instalacin del software, en caso de que se
presentasen dudas o inconvenientes, el tcnico reportar a la
coordinacin el problema y se rechazar la solicitud, tambin informar al
desarrollador las causas del rechazo. Para est actividad el tcnico en
terreno contar con un tiempo de 30 minutos a contar de la asignacin del
requerimiento. Si no se presentan inconvenientes y una vez probado el
procedimiento de instalacin, el Ingeniero de Sistemas proceder a copiar
el software al repositorio de programas de instalacin de cada empresa y
se agendar la instalacin definitiva para los usuarios.
d. Sitios Intranet: El Ingeniero de Sistemas proceder a programar la fecha y
hora del paso a produccin y notificar al desarrollador de la actividad.
e. Sitios y pginas Internet (Extranet) para Chile: El Ingeniero de Sistemas
proceder a programar la fecha y hora del paso a produccin y notificar
al desarrollador de la actividad.
f. Sitios y pginas Internet (Extranet) para resto del mundo: El Ingeniero de
Sistemas proceder a programar la fecha y hora del paso a produccin y
notificar al desarrollador de la actividad.
g. Servicios: El Ingeniero de Sistemas solicitar autorizacin al J efe de
Operaciones, quin podr autorizar o rechazar la solicitud y convocar a la
mesa de cambios segn sea el caso. De no haber objeciones se
proceder segn los horarios mencionados anteriormente. Si una solicitud
150

es rechazada ser informada al desarrollador junto con las
recomendaciones a seguir.
h. Servidores nuevos: El Ingeniero de Sistemas solicitar autorizacin al J efe
de Operaciones quin podr autorizar o rechazar la solicitud y convocar a
la mesa de cambios segn sea el caso. De no haber objeciones se
proceder segn 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 autorizacin al
J efe de Operaciones, quin podr autorizar o rechazar la solicitud y
convocar a la mesa de cambios segn sea el caso. De no haber
objeciones se proceder segn 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 produccin, el desarrollador
deber entregar el protocolo de entrega a Soporte e Infraestructura.


151

ANEXO II: Procedimiento de monitoreo de un servidor

OBJ ETIVOS

Establecer el procedimiento de monitoreo y eliminacin de procesos inactivos en el
servidor.

Nivelar la carga de procesos relacionados con iAS del servidor.

ALCANCE

Aplicable a todo el personal que realiza administracin 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 conexin va telnet al servidor.

NORMAS GENERALES

1. La revisin y eliminacin de procesos debe realizarse 1 vez a la semana a
cualquier hora del da.

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 ms consumidores. Para el caso del servidor los parmetros bsicos
normales de operacin son los siguientes:
a. User <=10.
b. Runqueue <=1.
c. Waitqueue <=2% .
d. Utilizacin de CPU por proceso <1% (lista de procesos).

152


4. En caso de presentarse anormalidades se debe proceder como sigue:
a. Caso 1: Dos o ms procesos poseen un uso de CPU mayor al 20% y son
antiguos
i. Verificar que el proceso sea f60webm o f60runm.
ii. Verificar antigedad del proceso con el comando ps fea | grep
PID, donde PID es el identificador de procesos.
iii. Si el proceso tiene una antigedad superior a un da, entonces se
debe hacer un kill -9 PID, donde PID es el identificador de
procesos.
b. Caso 2: Dos o ms procesos poseen un uso de CPU mayor al 20% y no
son antiguos, vale decir se encuentra dentro del mismo da.
i. Verificar que el proceso sea f60webm o f60runm.
ii. Verificar antigedad del proceso con el comando ps fea | grep
PID, donde PID es el identificador de procesos.
iii. Identificar junto con el DBA la operacin de base de datos o form
involucrado.
iv. Una vez identificado, informar al Coordinador de Sistemas para su
correccin.
5. Verificar la antigedad de procesos mediante el comando ps fea. En AIX el
comando produce la siguiente salida:

153


El PID corresponde al segundo campo y la antigedad 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 antigedad superior a un da.

Por ejemplo, el proceso 103490 est activo desde el 2 de Enero (J an 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 tena como proceso padre (segundo
campo) el PID 1, esto significa que el proceso no es un subproceso o un thread.

154

Si se hace un kill a un proceso cuyo proceso padre no es el PID 1, entonces al
ejecutar nuevamente ps fea nos encontraremos con que dicho proceso queda
en estado <defunct>, esto quiere decir que este proceso es un subproceso o un
thread. El estado <defunct> puede generar procesos de tipo zombie (hacen
nada) y pueden ser eliminados por el propio scheduler del sistema operativo.