UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN DISEÑO DE UN CENTRO DE SERVICIOS COMPARTIDOS DE TECNOLOGÍAS DE INFORMACIÓN PARA UNA EMPRESA PRODUCTORA DE PULPA Y PAPEL TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN TECNOLOGÍAS DE LA INFORMACIÓN CLAUDIO ALEJANDRO BERTON CÁRDENAS PROFESOR GUÍA: SR. JOSÉ A. PINO URTUBIA. MIEMBROS DE LA COMISIÓN: SR. NELSON BALOIAN TATARYAN. SR. PATRICIO INOSTROZA FAJARDIN. SRA. ROSA ALARCÓN CHOQUE. SANTIAGO DE CHILE OCTUBRE 2007
Transcript
UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
DISEÑO DE UN CENTRO DE SERVICIOS COMPARTIDOS DE TECNOLOGÍAS DE INFORMACIÓN PARA UNA EMPRESA PRODUCTORA DE PULPA Y PAPEL
TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN TECNOLOGÍAS DE LA INFORMACIÓN
CLAUDIO ALEJANDRO BERTON CÁRDENAS
PROFESOR GUÍA: SR. JOSÉ A. PINO URTUBIA.
MIEMBROS DE LA COMISIÓN:
SR. NELSON BALOIAN TATARYAN. SR. PATRICIO INOSTROZA FAJARDIN.
SRA. ROSA ALARCÓN CHOQUE.
SANTIAGO DE CHILE OCTUBRE 2007
RESUMEN
En esta tesis se presenta el diseño general de los procesos de negocio y organización, de un área de tecnologías de información, que operará dentro de un holding de empresas especializadas en los negocios de la industria de la pulpa y el papel, bajo el modelo de servicios compartidos. El holding ha definido la creación de una nueva empresa de servicios, que congregará las funciones de contabilidad, compras, recursos humanos y tecnologías de información. El problema abordado en este trabajo corresponde a la definición de la manera en que se prestarán los servicios de TI a las empresas filiales. La hipótesis es mostrar que, mediante la estructuración e implantación de procesos basados en estándares, orientados a la provisión de servicios de tecnologías de información, se pueden lograr beneficios y oportunidades importantes, tales como: la consolidación, la optimización de procesos a través de la reingeniería, la estandarización de aplicaciones y la reducción de los costos de operación. La metodología de solución corresponde a una visión desde la re-ingeniería de procesos, utilizando para las definiciones, elementos de los modelos CMMi e ITIL y abordando tres grandes ciclos de las actividades de tecnologías de información: planeación estratégica, ingeniería de software, soporte y provisión de servicios. Para cada uno de estos ciclos, se definieron actividades de carácter operativo considerando la distribución geográfica. En el caso de la gestión, el esquema propuesto es de centralización. Además, se plantea una estrategia para la mejora de los procesos de software, cuyo objetivo final es la adopción y evaluación en CMMi. Producto de la definición e implantación de los servicios, procesos y organización propuestos en esta tesis, se ha logrado una disminución de un 11.7% en los costos de TI para una planta industrial promedio de 500 usuarios, paradójicamente los costos de proyectos de software han aumentado un 15%, debido a la transparentación de costos que antes eran ocultos. Otro resultado importante, es que con la adopción de un esquema de servicio compartido con un marco de procesos basado en estándares, se cuenta con una base que permite la implementación de soluciones tecnológicas transversales al holding, generando sinergia, economías de escala y simplificación en la operación.
A mi familia
AGRADECIMIENTOS A mi familia, por su constante apoyo, cariño, comprensión y por permitirme dedicar tiempo y recursos para desarrollar mis estudios y este trabajo, en desmedro de ellos. A mis colegas de trabajo, por permitirme discutir con ellos alguna de las ideas presentadas en esta tesis.
i
TABLA DE CONTENIDOS CAPÍTULO 1 - INTRODUCCIÓN ............................................................................................................. 1
1. LA INDUSTRIA DE LA PULPA Y EL PAPEL ................................................................................................. 1 2. SITUACIÓN INICIAL .............................................................................................................................. 2 3. DEFINICIÓN DEL PROBLEMA ................................................................................................................. 6 4. HIPÓTESIS ......................................................................................................................................... 7
CAPÍTULO 2 – REVISIÓN TEÓRICA Y METODOLOGÍA ........................................................................ 9
1. REVISIÓN TEÓRICA ............................................................................................................................. 9 1.1 Análisis, Modelamiento y Diseño de Procesos ........................................................................... 9
1.1.1 SADT (Structured Analysis and Design Technique) ........................................................... 10 1.1.2 IDEF (Integrated DEFinition Methods) ............................................................................... 10 1.1.3 Ciclos de Trabajo .............................................................................................................. 12 1.1.4 UML (Unified Modeling Language) .................................................................................... 13
1.2 Proceso de Planificación Estratégica........................................................................................ 14 1.3 Modelos y Prácticas para Procesos de Software ...................................................................... 16
1.3.1 CMMi (Capability Maturity Model Integration) .................................................................... 17 1.3.2 Normas ISO ...................................................................................................................... 18
1.3.2.1 ISO 9000:2000 .......................................................................................................... 18 1.3.2.2 ISO 9126 para Ingeniería de Software ....................................................................... 19
1.4 ITIL (IT Infraestructure Library) ................................................................................................. 19 1.5 Criterios de Selección de Herramientas.................................................................................... 20
2. METODOLOGÍA ................................................................................................................................. 21 2.1 Enfoque de Trabajo ................................................................................................................. 21 2.2 Estrategia del Proyecto ............................................................................................................ 22
2.2.1 Actividades de Gestión del Proyecto ................................................................................. 22 2.2.2 Actividades Propias del Proyecto ...................................................................................... 23
2.3 Selección de Herramientas Metodológicas ............................................................................... 24
CAPÍTULO 3 – DISEÑO DE SERVICIOS Y PROCESOS ....................................................................... 26
1. DISEÑO DE SERVICIOS ...................................................................................................................... 26 1.1 Servicios TIC ........................................................................................................................... 26 1.2 Modelo de costos de los servicios ............................................................................................ 28 1.3 Niveles de Servicio .................................................................................................................. 31
2. DISEÑO DE PROCESOS ..................................................................................................................... 39 2.1 Proceso de planeación estratégica TIC para las filiales ............................................................ 39
2.1.1 Proceso para la planeación estratégica ............................................................................. 39 2.1.2 Proceso para la elaboración del presupuesto .................................................................... 42
2.2 Procesos de software............................................................................................................... 46 2.2.1 Administración de Proyectos ............................................................................................. 46
2.2.1.1 Administración de proyectos con metodologías ágiles ................................................ 47 2.2.1.2 Administración de proyectos con metodologías tradicionales ..................................... 48
2.2.2 Proceso de Desarrollo y Administración de Requerimientos .............................................. 51 2.2.3 Proceso de Desarrollo de Software ................................................................................... 54 2.2.4 Proceso de Pruebas de Software ...................................................................................... 58 2.2.5 Proceso de Mantención de Software ................................................................................. 61
2.3 Procesos de soporte al servicio ................................................................................................ 64 2.3.1 Gestión de incidencias ...................................................................................................... 64 2.3.2 Gestión de problemas ....................................................................................................... 66 2.3.3 Gestión de inventario y configuración ................................................................................ 68 2.3.4 Gestión del cambio ........................................................................................................... 71 2.3.5 Control y distribución de software y hardware ................................................................... 74
2.4 Procesos de entrega del servicio.............................................................................................. 76 2.4.1 Gestión de disponibilidad y continuidad ............................................................................. 76 2.4.2 Gestión del nivel de servicio .............................................................................................. 77 2.4.3 Gestión de finanzas TI ...................................................................................................... 80
ii
2.4.4 Gestión de capacidad ....................................................................................................... 81 2.4.4.1 Gestión de capacidad del negocio ............................................................................. 81 2.4.4.2 Gestión de capacidad de los recursos y servicios....................................................... 82
2.4.5 Gestión de proveedores .................................................................................................... 86 2.5 Procesos de gestión de la infraestructura y seguridad .............................................................. 90
2.5.1 Gestión de infraestructura ................................................................................................. 90 2.5.1.1 Administración de la Infraestructura ........................................................................... 92 2.5.1.2 Administración de la Seguridad .................................................................................. 93 2.5.1.3 Monitoreo y Control de Servicios ............................................................................... 93 2.5.1.4 Actividades de Operación .......................................................................................... 94
2.5.2 Gestión de seguridad ........................................................................................................ 95
CAPÍTULO 4 – ORGANIZACIÓN .......................................................................................................... 97
1. ESTRUCTURA ORGANIZACIONAL. ........................................................................................................ 97 1.1 Primer nivel organizacional ...................................................................................................... 98 1.2 Segundo, tercer y cuarto nivel organizacional ........................................................................ 100
1.2.1 Subgerencia Relación Comercial Cliente......................................................................... 101 1.2.2 Subgerencia Servicio al Cliente ....................................................................................... 102 1.2.3 Subgerencia de Proyectos .............................................................................................. 104 1.2.4 Subgerencia de Infraestructura ....................................................................................... 107
2. DEFINICIÓN DE CARGOS .................................................................................................................. 108 2.1 Gerencia de Servicios TIC ..................................................................................................... 108 2.2 Subgerencia de Relación Comercial....................................................................................... 109 2.3 Subgerencia de Servicio al Cliente ......................................................................................... 109 2.4 Subgerencia de Proyectos ..................................................................................................... 110 2.5 Subgerencia de Infraestructura .............................................................................................. 111
CAPÍTULO 5 – IMPLEMENTACIÓN, TRANSICIÓN Y CAMBIO .......................................................... 113
1. PLAN DE IMPLEMENTACIÓN, TRANSICIÓN Y CAMBIO ............................................................................. 113 1.1 Etapa previa al cambio ........................................................................................................... 113
1.1.1 Actividades de Capacitación ........................................................................................... 114 1.1.2 Actividades de definición de los procesos TI ................................................................... 114 1.1.3 Actividades de definición de la estructura organizacional ................................................ 114
1.2 Etapa de transición y cambio ................................................................................................. 115 1.3 Etapa de entrega del servicio ................................................................................................. 116
CAPÍTULO 6 – ESTRATEGIA PARA LA MEJORA DEL SOFTWARE ................................................ 118
1. MARCO DEL PROCESO DE MEJORA DE SOFTWARE ............................................................................. 118 2. PLAN ESTRATÉGICO DE MEJORA DEL PROCESO DE SOFTWARE ........................................................... 119
2.1 Misión .................................................................................................................................... 119 2.2 Visión .................................................................................................................................... 119 2.3 Valores .................................................................................................................................. 119 2.4 Principios Guías ..................................................................................................................... 119 2.5 Metas de Corto Plazo............................................................................................................. 120 2.6 Metas de Largo Plazo ............................................................................................................ 120 2.7 Metas Estratégicas Derivadas del Negocio............................................................................. 120 2.8 Objetivo ................................................................................................................................. 120 2.9 Beneficios Esperados ............................................................................................................ 120 2.10 Principios Guía del SPI ........................................................................................................ 120 2.11 Supuestos............................................................................................................................ 121 2.12 Auspicio ............................................................................................................................... 121 2.13 Riesgos ............................................................................................................................... 122 2.14 Barreras ............................................................................................................................... 122 2.15 Organización para la Mejora del Proceso ............................................................................. 123
2.15.5 Grupos de Trabajo Técnicos (TWG) .............................................................................. 124 2.15.6 Consultores Externos .................................................................................................... 125
2.16 Criterios de Éxito.................................................................................................................. 126 2.16.1 Medición de Metas de Corto Plazo ............................................................................... 126 2.16.2 Medición de Metas de Largo Plazo ............................................................................... 126 2.16.3 Medición de Metas Estratégicas Derivadas del Negocio ................................................ 126
ANEXO I: COMPARACIÓN ENTRE LAS PLATAFORMAS .NET Y J2EE ......................................................... 135 ANEXO II: EJEMPLOS DE NORMAS Y PROCEDIMIENTOS ......................................................................... 140
ÍNDICE DE TABLAS TABLA 1: SITUACIÓN INICIAL DE LOS PROCESOS DE SOFTWARE ........................................................................ 4 TABLA 2: SITUACIÓN INICIAL DE LOS PROCESOS DE SOPORTE .......................................................................... 5 TABLA 3: LOS NIVELES DE MADUREZ Y LAS ÁREAS DE PROCESO DE CMMI ...................................................... 18 TABLA 4: EL CATÁLOGO DE SERVICIOS ........................................................................................................ 27 TABLA 5: CRITERIOS PARA LA APLICABILIDAD DE COSTOS A LOS SERVICIOS ..................................................... 29 TABLA 6: CRITERIOS PARA APLICAR PRORRATEO A LOS COSTOS DE LOS SERVICIOS ......................................... 30 TABLA 7: ASIGNACIÓN DE VALORES A LA IMPORTANCIA DE UN SERVICIO .......................................................... 33 TABLA 8: IMPORTANCIA DE LOS SERVICIOS SEGÚN LA SEGMENTACIÓN DE USUARIOS ........................................ 33 TABLA 9: NIVELES DE SERVICIO PARA LOS SERVICIOS FIJOS .......................................................................... 34 TABLA 10: NIVELES DE SERVICIO PARA SERVICIOS VARIABLES ....................................................................... 37 TABLA 11: NIVELES DE SERVICIO PARA LA MANTENCIÓN DE SOFTWARE DE CORTO PLAZO ................................. 37 TABLA 12: NIVELES DE SERVICIO PARA SERVICIOS DE VALOR AGREGADO ........................................................ 38 TABLA 13: EJEMPLO DE UN PRESUPUESTO .................................................................................................. 43 TABLA 14: CRITERIOS PARA LA PRESUPUESTACIÓN ...................................................................................... 44 TABLA 15: CRITERIOS PARA DETALLAR EL PRESUPUESTO ............................................................................. 44 TABLA 16: COMPONENTES TECNOLÓGICOS DE LOS SERVICIOS ...................................................................... 83 TABLA 17: INDICADORES DE CAPACIDAD DE SERVIDORES Y PC...................................................................... 84 TABLA 18: INDICADORES DE CAPACIDAD PARA IMPRESORAS .......................................................................... 85 TABLA 19: INDICADORES DE CAPACIDAD DE EQUIPOS DE COMUNICACIÓN ........................................................ 85 TABLA 20: DIFERENCIAS ENTRE SLA Y OLA ............................................................................................... 88 TABLA 21: OLA PARA SERVICIOS FIJOS ....................................................................................................... 89 TABLA 22: DESCRIPCIÓN DE LOS SERVICIOS DE INFRAESTRUCTURA ............................................................... 92 TABLA 23: VARIABLES DE MONITOREO DE UN SERVIDOR ............................................................................... 94 TABLA 24: ACTIVIDADES DE OPERACIÓN HABITUAL DE LA INFRAESTRUCTURA .................................................. 94 TABLA 25: PLAN GLOBAL DE DIFUSIÓN Y CAMBIO ........................................................................................ 117 TABLA 26: RIESGOS DEL PROYECTO DE MEJORA DEL PROCESO DE SOFTWARE .............................................. 122 TABLA 27: COSTOS DEL PROYECTO DE MEJORA DEL PROCESO DE SOFTWARE ............................................... 127 TABLA 28: ROADMAP DEL PROYECTO DE MEJORA DEL PROCESO DE SOFTWARE ............................................ 128
iv
ÍNDICE DE FIGURAS FIGURA 1: ESTRUCTURA DE EMPRESAS DEL HOLDING ..................................................................................... 2 FIGURA 2: ORGANIGRAMAS DE LAS ÁREAS DE SISTEMAS ................................................................................ 3 FIGURA 3: REPRESENTACIÓN GRÁFICA DE IDEF0 ........................................................................................ 11 FIGURA 4: REPRESENTACIÓN GRÁFICA DEL MODELO DE CICLOS DE TRABAJO .................................................. 12 FIGURA 5: MODELO DE PLANEACIÓN ESTRATÉGICA ...................................................................................... 14 FIGURA 6: REPRESENTACIÓN GRÁFICA DEL MODELO DE LAS 5 FUERZAS DE PORTER ........................................ 15 FIGURA 7: LA CADENA DE VALOR ................................................................................................................ 16 FIGURA 8: SEGMENTACIÓN DE LOS USUARIOS ............................................................................................. 32 FIGURA 9: LÍNEA DE TIEMPO DE UN INCIDENTE ............................................................................................. 34 FIGURA 10: PROCESO DE PLANEACIÓN ESTRATÉGICA DE TI .......................................................................... 40 FIGURA 11: PROCESO DE ELABORACIÓN DEL PRESUPUESTO ......................................................................... 45 FIGURA 12: ADMINISTRACIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES .................................................... 48 FIGURA 13: ADMINISTRACIÓN DE PROYECTOS CON METODOLOGÍAS TRADICIONALES ........................................ 49 FIGURA 14: PROCESO DE DESARROLLO Y ADMINISTRACIÓN DE REQUERIMIENTOS ............................................ 53 FIGURA 15: PROCESO DE DESARROLLO DE SOFTWARE CON METODOLOGÍA ÁGIL ............................................. 55 FIGURA 16: PROCESO DE DESARROLLO DE SOFTWARE CON METODOLOGÍAS TRADICIONALES ........................... 56 FIGURA 17: PROCESO DE PRUEBAS CON METODOLOGÍA ÁGIL ........................................................................ 59 FIGURA 18: PROCESO DE PRUEBAS CON METODOLOGÍAS TRADICIONALES ...................................................... 60 FIGURA 19: DIAGRAMA DE DESCOMPOSICIÓN PARA EL TESTING ..................................................................... 61 FIGURA 20: PROCESO DE MANTENCIÓN DEL SOFTWARE ................................................................................ 63 FIGURA 21: PROCESO DE GESTIÓN DE INCIDENCIAS ..................................................................................... 66 FIGURA 22: PROCESO DE GESTIÓN DE PROBLEMAS ...................................................................................... 68 FIGURA 23: PROCESO DE GESTIÓN DE INVENTARIO Y CONFIGURACIÓN ........................................................... 70 FIGURA 24: PROCESO DE PASO A PRODUCCIÓN ........................................................................................... 72 FIGURA 25: PROCESO DE GESTIÓN DEL CAMBIO PARA EQUIPOS DE ESCRITORIO .............................................. 73 FIGURA 26: DESCOMPOSICIÓN DEL PRODUCTO DE SOFTWARE PARA EL CONTROL DE VERSIONES ...................... 75 FIGURA 27: PROCESO DE GESTIÓN DE LA DISPONIBILIDAD Y LA CONTINUIDAD .................................................. 77 FIGURA 28: CICLO DE GESTIÓN DEL NIVEL DE SERVICIO ................................................................................ 78 FIGURA 29: PROCESO DE GESTIÓN DEL NIVEL DE SERVICIO ........................................................................... 79 FIGURA 30: PROCESO DE GESTIÓN DE LAS FINANZAS ................................................................................... 81 FIGURA 31: PROCESO DE GESTIÓN DE PROVEEDORES ................................................................................. 87 FIGURA 32: ACTIVIDADES GENERALES DE UN PROYECTO DE INFRAESTRUCTURA ............................................. 91 FIGURA 33: JERARQUIZACIÓN DE LAS ACTIVIDADES DE INFRAESTRUCTURA ..................................................... 91 FIGURA 34: ORGANIGRAMA GENERAL, OPCIÓN 1 .......................................................................................... 98 FIGURA 35: ORGANIGRAMA GENERAL, OPCIÓN 2 .......................................................................................... 99 FIGURA 36: ORGANIGRAMA GENERAL, OPCIÓN 3 ........................................................................................ 100 FIGURA 37: ORGANIGRAMA SUBGERENCIA RELACIÓN COMERCIAL CLIENTE ................................................... 101 FIGURA 38: ORGANIGRAMA SUBGERENCIA DE SERVICIO AL CLIENTE ............................................................. 103 FIGURA 39: ORGANIGRAMA SUBGERENCIA DE PROYECTOS ......................................................................... 105 FIGURA 40: ORGANIGRAMA ALTERNATIVO DE LA SUBGERENCIA DE PROYECTOS ............................................ 105 FIGURA 41: ORGANIGRAMA SUBGERENCIA DE INFRAESTRUCTURA ............................................................... 107 ÍNDICE DE ECUACIONES
ECUACIÓN 1: TIEMPO DE NO DISPONIBILIDAD DE LOS SERVICIOS FIJOS ........................................................... 32 ECUACIÓN 2: PORCENTAJE DE DISPONIBILIDAD DEL SERVICIO FIJO ................................................................. 32 ECUACIÓN 3: PORCENTAJE DE PRODUCTOS ENTREGADOS DENTRO DE PLAZO ................................................. 50 ECUACIÓN 4: PORCENTAJE DE PRODUCTOS ENTREGADOS FUERA DE PLAZO ................................................... 50 ECUACIÓN 5: PORCENTAJE DE AVANCE DEL PROYECTO ................................................................................ 50
1
Capítulo 1 - Introducción
1. La industria de la pulpa y el papel La industria de la pulpa y el papel es un sector que se encuentra en plena madurez, orientado a la producción de commodities, en un mercado en que los precios son extremadamente volátiles, las empresas se ven obligadas a invertir fuertemente para mantenerse en pie. Sin embargo, pese a que el crecimiento promedio del mercado es entre un 2.5% - 3% anual [27], los márgenes se han visto deteriorados producto de los excesos de capacidad existentes. Los crecimientos de capacidad de las grandes empresas se realizan mediante la adquisición de compañías más pequeñas, existiendo una tendencia continua a la globalización [12]. Desde el punto de vista de los productos existe una tendencia a focalizarse más que en diversificarse [27]. Las grandes líneas de productos del sector son: maderas, celulosa, papel para impresión y escritura, papel para corrugar, papel tissue, papel de diario y cartulinas. Las empresas del sector se caracterizan por ser altamente dependientes de la logística, siendo la eficiencia en costos uno de los grandes objetivos de negocio. Las preocupaciones del sector radican principalmente en [12,27]:
a) Necesidad de asegurar los suministros de insumos al menor costo posible. b) Necesidad de focalizarse en la generación de valor para los clientes y
accionistas. c) Necesidad de focalizarse en el negocio. d) Generar economías de escala. e) Necesidad de integrarse con la cadena de suministros. f) El aumento en la dependencia de las Tecnologías de Información (TI). En
general, se cuenta con sistemas antiguos que incorporan prácticas y procesos que se encuentran obsoletos.
g) Necesidad de focalizarse en el cliente más que en el proceso productivo. h) Mantener una relación armoniosa con el medio ambiente.
En este contexto, las Tecnologías de Información juegan, aparentemente, un rol secundario, sin embargo la tendencia es la incorporación de tecnologías que faciliten la gestión de la información, la automatización y la operación de las plantas productivas. El presente trabajo, se desarrolla en un holding que está compuesto por seis filiales que a su vez congregan a empresas especializadas en los distintos negocios de la industria de la pulpa y el papel, tal como se puede observar en la figura 1. Geográficamente, las empresas y sus plantas productivas están distribuidas a lo largo de Chile y en el extranjero, con plantas productoras en Argentina, Uruguay, Perú, Brasil y México.
2
Figura 1: Estructura de empresas del holding
2. Situación Inicial Cada filial posee un área de informática propia e independiente. A nivel de la matriz, existe una gerencia de informática que entrega a las filiales los lineamientos base en cuanto a políticas de seguridad, licenciamiento de software y servicios centralizados. Además, define y mantiene los sistemas corporativos y administra la red de datos corporativa. Hay 458 aplicaciones distintas, de los cuales 60% están relacionadas con el apoyo a la administración de los negocios y un 40% apoyan la operación de plantas productivas. Estas aplicaciones son soportadas por 357 servidores, que se encuentran distribuidos geográficamente en Chile y en el extranjero. Cada área informática posee su propia organización, identificándose tres tipos genéricos:
1. Una subgerencia, con tres áreas dependientes: soporte, mantención de software y desarrollo de software.
2. Varias subgerencias con dos áreas dependientes: soporte, mantención y desarrollo de software.
3
3. Una subgerencia con dos áreas dependientes: soporte y coordinación. Siendo responsabilidad de la coordinación la realización de proyectos informáticos con terceros.
La representación de esta organización se visualiza en la figura 2. Las líneas punteadas indican que existe una relación de dependencia implícita.
Figura 2: Organigramas de las áreas de Sistemas El área de soporte es la encargada de entregar el soporte a usuarios, administrar la infraestructura informática y asegurar la continuidad de los servicios. Las áreas de desarrollo y mantención se encargan del ámbito del software. No se presentan unidades que gestionen la relación con el cliente. Las funciones realizadas por las unidades informáticas son equivalentes entre sí y son:
a) Realizar la planificación estratégica de TI para la filial, a través de un proceso informal y medianamente definido, cuyo objetivo final es la obtención del presupuesto anual de TI.
b) Mantener y operar la infraestructura informática. c) Entregar soporte a los usuarios, sistemas y aplicaciones. d) Desarrollar aplicaciones propias y con terceros. e) Mantener la seguridad informática. f) Entregar soporte a la gestión (captura de requerimientos y análisis de sistemas).
4
g) Entregar consultoría tecnológica. Desde el punto de vista de los procesos, existe un desarrollo propio e incipiente con grandes diferencias entre las divisiones del holding. En la tabla 1, se presenta un resumen de la situación para procesos básicos de software.
Tabla 1: Situación inicial de los procesos de software La administración y desarrollo de requisitos consiste solamente en la recepción directa desde el usuario y la aprobación por parte de un comité. En el caso de las metodologías de desarrollo, se depende exclusivamente del desarrollador, lo que provoca que se presenten diferencias respecto al enfoque de solución y a la manera como es construido el software. Las pruebas de software son prácticamente nulas. Respecto a la mantención de software, el proceso consiste en la recepción formal de un requerimiento de cambio, previa aprobación en caso que signifique un gasto, no existe una definición para la asignación de tareas y manejo de prioridades. Tampoco existe documentación técnica del software. Además, no se manejan conceptos de calidad y la gestión de proyectos depende del enfoque y voluntad de cada jefe de proyecto. Para el caso de soporte, los procesos definidos no son estándares en la organización, presentándose distintos niveles de profundización y formalización en las filiales. En la tabla 2, se presenta un resumen de la situación con los procesos que han sido identificados.
5
Tabla 2: Situación inicial de los procesos de soporte En resumen, si bien hay procesos definidos, existen patologías en cuanto a la implementación, estas son:
a) Las herramientas de software utilizadas para el soporte del proceso no son adecuadas para el tamaño del negocio.
b) Algunos procesos no se encuentran debidamente institucionalizados y, en general, no son gestionados como tal.
c) Los procedimientos se enfocan en lo que hay que hacer más que en cómo hacerlo.
d) Los procesos de administración de la infraestructura son descentralizados y siguen criterios que no son comunes dentro de las divisiones de negocio.
e) No existe claridad respecto a la responsabilidad y roles de las personas sobre los procesos.
f) Existen iniciativas de formalización de procesos, sin embargo, no son llevadas a cabo producto de la falta de tiempo de las personas encargadas de definirlos y documentarlos y a la falta de auspicio por parte de la alta dirección.
g) Existe resistencia de las personas para adoptar procesos estructurados y normas.
Además, existen diferencias en cuanto al enfoque con que cada unidad informática afronta a sus clientes y usuarios, se distinguen:
a) Los que se encuentran orientados al cliente. b) Los que imponen reglas y soluciones. c) Los que son guiados por el cliente, vale decir, aquellos en los que el cliente
define los aspectos técnicos de informática. Pese a estas patologías, una fortaleza que destaca es el conocimiento de los negocios que tiene el personal de informática, además del compromiso y dedicación a las labores que les han sido encomendadas.
6
Culturalmente, hay un sentido altamente jerárquico respecto a las responsabilidades, donde la mayoría de las decisiones son tomadas por Gerentes y Subgerentes. En general, el holding se caracteriza por tener un carácter conservador desde el punto de vista adopción de nuevas tecnologías. Sin embargo, se encuentra abierto a los estándares que apoyen la mejora de procesos y aseguren la calidad de sus productos.
3. Definición del Problema El holding matriz ha definido la creación de una nueva empresa que proveerá a todas las filiales los servicios de: contabilidad, recursos humanos, tecnologías de información y comunicaciones (TIC) y compras. Todas las filiales del holding serán atendidas por esta nueva empresa, sin poder ellas optar por otro proveedor o mantener un servicio propio. Tampoco se podrán proveer servicios fuera del conglomerado de empresas y se deberá operar con procesos y aplicaciones estándares de la industria. La nueva empresa no deberá generar utilidades y se deberá regir por acuerdos de servicio y costos con las filiales. Para este proyecto, el holding matriz ha contratado una consultora que se encargará de los procesos de contabilidad, recursos humanos y compras [5]. En el caso de Tecnologías de Información, se ha contratado a otra empresa consultora especialista en procesos TI que apoyará la definición de los procesos y estructura organizacional. El holding matriz ha definido que este trabajo sea realizado en conjunto por personal propio y de la consultora, teniendo como marco de referencia para la provisión de servicios el estándar ITIL, no definiéndose un marco para los procesos de desarrollo de software. Esta tesis se concentra en la definición global de procesos, transición y organización del área de tecnologías de información bajo el paradigma de servicios compartidos, siendo el objetivo general de este trabajo el diseñar los procesos y la estructura organizacional del área que prestará los servicios compartidos de informática a todas las filiales del holding, tomando como marco de referencia modelos de servicio y calidad estándares de la industria. Específicamente, los objetivos a satisfacer son:
a) Diseñar la estructura organizacional de tecnologías de información en la empresa de servicios compartidos del holding matriz, que entregará los servicios a las empresas del holding.
b) Definir los procesos de negocio del área de tecnologías de información que prestará los servicios, utilizando como marco de referencia modelos y estándares de calidad y buenas prácticas existentes en la industria.
c) Definir el plan de transición que implementará el cambio organizacional. Tal como se mencionó, el holding matriz ha definido la utilización del modelo ITIL para la provisión de servicios. Sin embargo, no se han realizado definiciones respecto al proceso de desarrollo de software. Para resolver este punto, plantearemos el uso, como
7
marco de referencia, de algún modelo o estándar de calidad de software existente en la industria. En esta tesis, no se contempla la implementación y/o certificación de modelos y/o estándares de calidad. Este proyecto supone una transformación fuerte en términos de procesos, organización, cultura organizacional y paradigma, por lo que una adopción completa de algún modelo, en esta etapa, puede resultar contraproducente e incluso no beneficioso para la empresa y el cambio a implementar. Este trabajo surge como respuesta a la necesidad de responder a la estrategia de negocio del holding matriz, que considera los siguientes focos tácticos, a los cuales se contribuiría directamente [5]:
a) Incrementar la calidad de los productos y servicios. b) Simplificar la operación y el control. c) Minimizar los costos de operación de las actividades de apoyo al negocio. d) Crecimiento por adquisiciones y fusiones. e) Promover la mejora continua.
4. Hipótesis El concepto de servicios compartidos, se ha convertido en un estándar global como modelo de organización de las unidades de apoyo al negocio para las corporaciones, en particular las tecnologías de información. En Chile, hay al menos 10 empresas operando bajo el esquema y varias otras en diferentes grados de implementación y avance [5]. La hipótesis de trabajo es mostrar que mediante la estructuración e implantación de procesos basados en estándares, orientados a la provisión de servicios de tecnologías de información bajo servicios compartidos, se pueden lograr beneficios y oportunidades importantes, tales como [5]:
1. Incremento de la calidad de los productos y servicios, sustentado en: a) Estandarización y optimización de procesos. b) Mejores condiciones para la implementación de soluciones tecnológicas,
estándares y transversales, con la posibilidad de generar sinergias. 2. Simplificación de la operación y el control, a partir de:
a) La implementación de un modelo único de operación. b) Aplicaciones informáticas estandarizadas. c) Focalización en las actividades propias de cada empresa del holding.
3. Reducción de los costos de operación de las unidades de apoyo al negocio. 4. Optimización de los procesos a través de la reingeniería, estandarización y
consolidación de los mismos generando economías de escala para minimizar los costos operativos1.
1 De acuerdo a Ernst & Young, compañías con servicios compartidos han reducido los costos asociados a la prestación de servicios de soporte al negocio entre un 25% y un 45%
8
Para evaluar el cumplimiento de la hipótesis propuesta, se utilizarán los siguientes mecanismos de evaluación:
1. A nivel de procesos: Comparación cualitativa entre la situación inicial versus la situación con los procesos implantados, y el cumplimiento de los objetivos propuestos para esta tesis.
2. A nivel de servicio: Comparación cualitativa de la situación inicial versus la situación con el servicio compartido de tecnologías de información en funcionamiento.
3. A nivel de costos: Comparación entre los costos en tecnologías de información de la situación inicial y los obtenidos después de la implementación de los procesos para una planta industrial promedio con 500 usuarios.
La evaluación de estos puntos será abordada en el capítulo 7.
9
Capítulo 2 – Revisión Teórica y Metodología
1. Revisión Teórica
1.1 Análisis, Modelamiento y Diseño de Procesos Un proceso es un conjunto de compromisos, acciones y decisiones necesarias para satisfacer un requerimiento de un cliente. Se basa en redes de compromisos en torno a un ciclo de trabajo. Un proceso de negocio es un conjunto de tareas lógicamente relacionadas que utilizan recursos de la organización para el cumplimiento de los objetivos de negocio [31]. Los procesos pueden ser calificados mediante un modelo de madurez, que define 5 niveles y provee [30]:
a) Una guía para el desarrollo evolutivo de procesos. b) Un modelo organizacional orientado al mejoramiento continúo. c) Una estructura confiable de diagnostico de procesos y evaluación de su
capacidad. Los niveles del modelo de madurez se categorizan en [7, 30]: Nivel 1 (Inicial): No hay procedimientos formales, ni estimación de costos, ni planificación y programación de procesos. No hay mecanismos de administración que aseguren que se siguen procedimientos. Las herramientas no están bien integradas y el control de cambios no es riguroso. La administración superior no entiende los puntos clave del proceso. Nivel 2 (Repetible): Los procesos dependen de los individuos y se establecen controles básicos para los proyectos. Se busca hacer el trabajo en forma similar, pero hay riesgos mayores cuando hay que enfrentar nuevos desafíos. No existe un marco para enfrentar el mejoramiento. Nivel 3 (Definido): Los procesos están definidos e institucionalizados. Existe un grupo de procesos que lidera las mejoras y las promueve. Nivel 4 (Administrado): Los procesos son medidos y se han establecido un conjunto mínimo de medidas de calidad y productividad. Nivel 5 (Optimizante): El mejoramiento continúo realimenta a los procesos. La recolección de información es automatizada. La evidencia numérica es usada para justificar la aplicación de tecnología a las tareas críticas. Se realizan análisis rigurosos de tipo causa-efecto y prevención de defectos.
10
Para el diseño y modelamiento de procesos, existen una diversidad de métodos y técnicas, de los cuales se han revisado los principales.
1.1.1 SADT (Structured Analysis and Design Technique) Desarrollada a finales de la década del 70, SADT es una técnica de análisis y diseño de sistemas que ha sido ampliamente utilizada. Provee de un conjunto de procedimientos que permiten al analista descomponer las funciones del software o el sistema, los que están compuestos de [15]:
a) Diagramas de actividades, que representan las actividades del sistema. b) Diagramas de datos. c) Textos y diagramas explicativos para los diagramas. d) Esquema jerárquico del sistema. e) Glosario de definiciones y términos utilizados. f) Condiciones de activación.
Se utiliza descomposición funcional para la jerarquización del sistema, en particular, diagramas de contexto y de flujo de datos de nivel 0 hasta el nivel que sea requerido, para especificar completamente el sistema. Los archivos de datos son especificados, así como también los agentes (proveedores o receptores de datos externos al sistema). El problema de este modelo es que es una caja negra, los procesos poseen entradas y salidas pero no se especifica la forma de hacer las cosas. Se centra en los datos y no en el proceso. Por lo tanto no resulta adecuado para el modelamiento de procesos, pero si para los sistemas [15].
1.1.2 IDEF (Integrated DEFinition Methods) Es un conjunto de métodos para el modelamiento de procesos, fue desarrollado, a partir de 1970, por el Departamento de Defensa de EEUU. Actualmente son mantenidos por Knowledge Based Systems Inc, empresa dedicada a la investigación de tecnologías. Los métodos se clasifican de acuerdo al tipo de modelamiento que se quiera realizar [32]: IDEFØ: Es un método diseñado para modelar las decisiones, acciones y actividades de una organización o sistema, es derivado de SADT.
11
Figura 3: Representación gráfica de IDEF02 En la figura 3, el cuadro representa a la función o actividad del sistema u organización, las flechas de la izquierda son las entradas, las de la derecha las salidas. Las flechas por sobre el cuadro corresponden a controles sobre la función y las flechas por debajo corresponden a los mecanismos. Al conjunto de entradas, salidas, controles y mecanismos se les denomina ICOM. IDEFØ produce una representación organizada de las funciones y actividades y es independiente del tiempo y la organización. Captura lo que se hace o no se hace y utiliza la noción de descomposición funcional para modelar las actividades o funciones. La descripción de los detalles y la temporalidad de los procesos se especifica utilizando IDEF3. IDEF1: Es un método de modelamiento de la información. Un modelo de información representa la estructura y semántica de la información dentro del sistema u organización modelada. Generalmente se utiliza para identificar qué información es la que actualmente es gestionada por la organización, determinar cuáles problemas son causados por falta de información y especificar qué información será administrada en la implementación. IDEF1X: Es un método para diseñar bases de datos relacionales, posee una sintaxis diseñada para soportar construcciones semánticas necesarias para desarrollar esquemas conceptuales. Un esquema conceptual es una definición integrada de un dato de la organización independiente de su representación computacional. IDEF3: Es un método que provee los mecanismos para capturar y documentar procesos. IDEF3 captura el comportamiento, la precedencia y las relaciones de
2 Fuente: http://www.idef.com/idef0.html [consulta: 22 de Marzo de 2006]
12
causalidad entre situaciones y eventos. Permite expresar el conocimiento sobre como un sistema, los procesos o la organización trabaja. El método contempla dos modalidades: flujo de procesos y redes de estado-transición de objetos. La primera modalidad captura el conocimiento de cómo los componentes funcionan en una organización, la segunda resume las transiciones permitidas para un objeto a través de un proceso particular. IDEF4: Es un método de diseño orientado a objetos que apoya la correcta aplicación de la programación orientada a objetos. IDEF4 provee un marco para el desarrollo de software con orientación a objetos. Conceptualmente, consiste en dos submodelos: el de clases y el de métodos. El submodelo de clases contiene los diagramas de tipos, herencia, protocolos e instanciación. El submodelo de métodos contiene los diagramas de taxonomía para los métodos y los diagramas de contratos y clientes. IDEF5: Es un método específicamente diseñado para apoyar la creación, modificación y mantención de ontologías.
1.1.3 Ciclos de Trabajo El modelo de ciclos de trabajo fue desarrollado por la empresa Action Tech en torno a la semántica de compromisos y cumplimiento [31]. Los procesos son redes de acciones y compromisos. El ciclo parte desde un cliente con una petición a un ejecutor, luego el cliente y el ejecutor negocian la realización (promesas mutuas), el ejecutor realiza las acciones para cumplir sus promesas, declarando el termino del trabajo. Por último, el cliente realiza la acción de satisfacción, de acuerdo a las promesas (condiciones de satisfacción) [31]. En la figura 4, se muestra la representación gráfica de este modelo.
Figura 4: Representación gráfica del modelo de ciclos de trabajo3
3 Fuente: VARAS, SAMUEL. 2003. Apuntes del curso “Tecnologías de Información y Rediseño de Procesos”. Departamento de Ingeniería Industrial. Universidad de Chile.
13
1.1.4 UML (Unified Modeling Language) UML es un leguaje gráfico para visualizar, especificar, construir y documentar todos los artefactos de un sistema de software [10]. Cubre aspectos conceptuales, como procesos de negocio y elementos concretos: clases, esquemas de bases de datos, etc. La característica de UML es que es orientado a objetos. Las representaciones son realizadas mediante diagramas, existiendo varios tipos [10]:
1. Diagrama de clases: Es la representación de los bloques de construcción más importantes del sistema y sus relaciones. La unidad básica es la clase, que es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.
2. Diagrama de objetos: Los diagramas de objetos modelan las instancias de los
elementos contenidos en los diagramas de clases. Muestran los objetos y sus relaciones en un momento concreto, congela un instante en el tiempo de ejecución.
3. Diagrama de casos de uso: Un caso de uso especifica el comportamiento de un sistema o parte del mismo. El diagrama corresponde a una descripción de un conjunto de secuencias de acciones donde cada secuencia representa la interacción de los elementos externos del sistema con el propio sistema. Un caso de uso representa un requerimiento funcional del sistema.
4. Diagrama de secuencia y de colaboración: Se utilizan para modelar aspectos
dinámicos de un sistema. Consiste en un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos. Los diagramas de secuencia destacan el orden temporal de los mensajes, los de colaboración destacan la organización estructural de los objetos que envían y reciben mensajes. Ambos diagramas son semánticamente equivalentes.
5. Diagrama de estados: Describen gráficamente los eventos y los estados de los
objetos. A la relación entre dos estados se le llama transición, e indica, que cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.
6. Diagrama de actividades: Se usan para modelar los aspectos dinámicos de un
sistema, mostrando el flujo de control entre actividades. Este tipo de diagrama es una especialización de los diagramas de estado, organizados respecto de las acciones. Son usados para especificar: métodos, casos de uso, procesos de negocio.
7. Diagrama de componentes: Muestra las relaciones entre los componentes de un
sistema, es decir la interacción de la parte física y reemplazable de un sistema, que conforma un conjunto de interfaces y proporciona la realización de dicho conjunto.
8. Diagrama de despliegue: Describe la arquitectura física del sistema durante la
ejecución, en términos de: procesadores, dispositivos, componentes de software.
14
Además, describen la topología del sistema, la estructura de los elementos de hardware y software que ejecuta cada uno de ellos.
1.2 Proceso de Planificación Estratégica Para abordar los procesos de planificación estratégica es necesario realizar la distinción entre estrategia y el proceso de formación de la estrategia. Entenderemos por estrategia de negocio, a un conjunto bien coordinado de programas de acción que apuntan a asegurar una ventaja sostenible en el largo plazo. Un proceso de formación de la estrategia es un conjunto de actividades tendientes a definir la estrategia de un negocio, las prioridades y asignación de recursos y los programas de acción generales [11]. Un proceso de planeación estratégica, consiste en:
a) La definición y declaración de la misión y la visión. b) El análisis del medio externo e interno. c) La formulación de los planes y programas generales de acción, incluyendo la
estrategia del negocio. d) La programación y evaluación de los programas de acción propuestos y fijación
de las prioridades para la asignación de los recursos. e) La asignación de recursos y la elaboración del presupuesto.
La figura 5 presenta el aspecto general del proceso.
Figura 5: Modelo de planeación estratégica4
4 Fuente: JORRAT, MICHAEL. 2000. Apuntes del curso “Evaluación de Proyectos”. Departamento de Ingeniería Industrial. Universidad de Chile.
15
Existen herramientas que facilitan el proceso de planeación estratégica. Para el análisis del medio externo se utiliza ampliamente el modelo de las cinco fuerzas de Porter, representado en la figura 6, el que esencialmente postula que hay cinco fuerzas que conforman la estructura de una industria: intensidad de la rivalidad de los competidores, amenaza de nuevos participantes, amenaza de sustitutos, poder de negociación de los compradores y el poder de negociación de los proveedores. Estas cinco fuerzas delimitan, precios, costos y requerimientos de inversión, que constituyen factores básicos que explican la expectativa de rentabilidad de largo plazo y por lo tanto, el atractivo de la industria [11]. Otras herramientas son, por ejemplo: el análisis financiero, el análisis de factores externos, etc.
Figura 6: Representación gráfica del modelo de las 5 fuerzas de Porter5 Para el análisis interno, es decir, el examen sistemático de los modos que tiene un negocio para lograr una ventaja competitiva, es ampliamente utilizado el concepto de cadena de valor [11]. La cadena de valor es la caracterización de las actividades realizadas por una unidad estratégica de negocios [11]. Las tareas son clasificadas en actividades primarias y actividades de apoyo. Las actividades primarias son aquéllas relacionadas con el movimiento físico de materias primas y productos terminados, en la producción de bienes y servicios [11]. Las actividades de apoyo, como su nombre lo índica, apoyan las actividades primarias y establecen una infraestructura para el funcionamiento de una empresa. En la figura 7, las actividades primarias de la cadena son la logística de entrada y salida, las operaciones, el servicio, el marketing y ventas. Las actividades de apoyo son
5 Fuente: Fuente: JORRAT, MICHAEL. 2000. Apuntes del curso “Evaluación de Proyectos”. Departamento de Ingeniería Industrial. Universidad de Chile.
16
representadas por las adquisiciones, el desarrollo de tecnología, el manejo de recursos humanos y la infraestructura de la firma.
Figura 7: La cadena de valor6 En el ámbito de la informática, la planeación estratégica consiste en la identificación e implementación de la tecnología requerida por el negocio para la consecución de su misión, objetivos y estrategias [8]. Las herramientas mencionadas anteriormente, apoyan la formulación de la estrategia informática desde la perspectiva de entender el negocio para conseguir el alineamiento de las iniciativas tecnológicas. Por lo tanto, el resultado de la planeación en informática, tiene relación con la manera con que son gestionados los recursos de TI, la arquitectura informática del negocio, el portafolio de proyectos, el presupuesto y el plan de infraestructura.
1.3 Modelos y Prácticas para Procesos de Software Existen dos modelos, ampliamente utilizados en la industria, que entregan un marco de referencia para los procesos de software: CMMi e ISO. Ambos, proveen una guía para mejorar los procesos de la organización y por lo tanto tienen el efecto de producir mejoras en la calidad de los productos y servicios. Para este proyecto, se escogerá uno de los modelos, el que será tomado como marco de referencia para definir procesos básicos de producción de software. Si bien, existen diversas metodologías, el objetivo final en esta etapa es concentrarse en los procesos globales más que en el detalle.
6 Fuente: Fuente: JORRAT, MICHAEL. 2000. Apuntes del curso “Evaluación de Proyectos”. Departamento de Ingeniería Industrial. Universidad de Chile.
17
Los modelos entregan un marco sobre el cual se pueden obtener las definiciones para afrontar los procesos de software. A continuación se presenta una breve descripción de ambos.
1.3.1 CMMi (Capability Maturity Model Integration) El modelo, desarrollado por la Universidad de Carnegie-Mellon, tiene como propósito proveer una guía para mejorar el proceso de una organización y la capacidad para administrar el desarrollo, adquisición y mantención de productos y servicios [7]. Ayuda a la organización a examinar la efectividad de sus procesos y establece las prioridades de mejoramiento [30]. Provee una terminología común y una metodología integrada para la auditoria de los procesos [30]. Desde el punto de vista del negocio, CMMi, beneficia a la organización en:
a) Reducir la integración de sistemas y el tiempo de pruebas. b) Permitir la integración entre varias funciones y ámbitos de la ingeniería. c) Emplear principios de ingeniería de sistemas para el desarrollo de software.
Desde el punto de vista técnico, los principales beneficios son:
a) Focalización en la gestión y desarrollo de los requisitos. b) Focalización en el diseño y desarrollo. c) Incorporación de la gestión de riesgos. d) Incorporación de medidas y análisis de métricas.
CMMi define cuatro disciplinas: ingeniería de software, ingeniería de sistemas, proveedores y desarrollo integrado de procesos y productos [30]. Provee 5 niveles de madurez donde cada nivel es una capa en la fundación para un proceso de mejoramiento continuo, comenzando por prácticas y áreas de proceso básicas de administración y progresando a través de un camino predefinido y probado de niveles sucesivos [30]. Cabe señalar que en la medida que se avanza en madurez, la calidad y productividad aumenta y el re-trabajo junto con el riesgo van disminuyendo. En la tabla 3 se presenta un resumen del modelo.
18
Tabla 3: Los niveles de madurez y las áreas de proceso de CMMi7
1.3.2 Normas ISO ISO es una organización mundial de cuerpos de estandarización a nivel mundial. Su misión es proveer estandarización internacional para facilitar el intercambio de bienes y servicios [1]. Para el caso de los procesos de Tecnologías de Información, pueden ser aplicables dos normas: ISO 9000:2000 de carácter general e ISO 9126 para ingeniería de software, las que son revisadas a continuación.
1.3.2.1 ISO 9000:2000 Es un conjunto de normas utilizadas para establecer la gestión de calidad de una organización, satisfacer los compromisos entre la organización y sus clientes y lograr mejoramiento en el desempeño de una empresa [1]. Se compone de 3 partes:
a) ISO 9000, que describe los fundamentos y la terminología. b) ISO 9001, que describe los requisitos. c) ISO 9004, referente a las directrices para la mejora del desempeño.
Dentro de los beneficios esperados de la adopción de este modelo, se encuentran: mejor control de la gestión, mayor facilidad para eliminar y percibir los problemas de procedimiento, aumento de la eficacia y una mejor percepción de los problemas de calidad [1].
7 Fuente: PINTO, FERNANDO. 2004. Apuntes del curso “Introducción a CMMi”. Departamento de Ciencias de la Computación. Universidad de Chile.
19
ISO 9000, define una serie de requisitos que se orientan a la elaboración y mantención de procedimientos relacionados con el producto y el proceso. Lo que se alcanza, mediante la implantación de un sistema de gestión de calidad y la obtención como resultado final del manual de calidad. Si bien, la norma es aplicable a procesos de software, por su carácter general, no define guías ni opciones que provean una referencia para ese tipo de procesos.
1.3.2.2 ISO 9126 para Ingeniería de Software Esta norma está compuesta de 4 secciones:
1. ISO 9126-1:2001, que provee el modelo de calidad que clasifica al software en seis grandes atributos de calidad [1]:
a) Funcionalidad, que contempla los siguientes atributos: pertinencia, precisión,
interoperabilidad, adherencia, seguridad. b) Confiabilidad que contempla los siguientes atributos: madurez,
recuperabilidad, tolerancia a fallos. c) Usabilidad, que contempla los siguientes atributos: entendibilidad,
aprendibilidad, operatividad, aceptación de uso. d) Eficiencia, que contempla los atributos de rendimiento y uso de recursos. e) Mantenibilidad, que contempla los atributos: analizabilidad, cambiabilidad,
estabilidad, demostrabilidad. f) Portabilidad, que contempla los atributos: adaptabilidad, instanciabilidad,
adecuación, reemplazabilidad.
2. ISO 9126-2:2003, que provee métricas externas para la medición de las seis características de calidad definidas en ISO 9126-1. Las métricas externas, miden el comportamiento de un sistema computacional que incluye el software y las mediciones de la calidad, en el uso bajo un contexto específico [33].
3. ISO 9126-3:2003, que provee métricas internas para la medición de las seis
características de calidad definidas en ISO 9126-1. Las métricas internas miden el software como tal, bajo los procesos de requisitos, evaluación de productos y medidas de calidad [33].
4. ISO 9126-4:2004, que provee métricas para medir el uso de calidad de los
procesos de ingeniería de software [33].
1.4 ITIL (IT Infraestructure Library) ITIL fue desarrollado a fines de 1980 por la Oficina de Comercio (OGC) del Reino Unido y es un conjunto de las mejores prácticas comúnmente aceptadas por la industria para la provisión y administración de servicios de tecnologías de información. Promueve un enfoque desde la perspectiva de la calidad, para conseguir efectividad en el negocio y eficiencia en el uso de los sistemas de información [26]. Se basa en la experiencia
20
colectiva de organizaciones gubernamentales y comerciales a nivel mundial, lo que ha convertido a este framework en un estándar de facto de la industria [26]. Define cuatro áreas de macro procesos que a su vez definen procesos de negocio para la función de tecnologías de información, estos son [26]:
1. Service Support: El objetivo de este macro proceso es definir y entregar los procesos relacionados con el soporte al servicio de informática, vale decir: gestión de incidencias, gestión de problemas, gestión del inventario y la configuración, gestión del cambio, control y distribución de hardware y software.
2. Service Delivery: El objetivo de este macro proceso es definir y entregar los
procesos relacionados con la entrega del servicio de informática, vale decir: gestión de la disponibilidad, gestión de la continuidad, gestión de los niveles de servicio, gestión de las finanzas TI, gestión de la capacidad y la gestión de proveedores.
3. Infraestructure & Security Management: El objetivo de este macro proceso es
definir y entregar los procesos relacionados con la administración de la infraestructura y la seguridad de aplicaciones, redes y servicios.
4. Application Management: El objetivo de este macro proceso es definir y entregar
un ciclo de vida del software que permita el alineamiento con el negocio. La gestión e implementación puede ser llevada a cabo con metodologías orientadas al desarrollo, mantención y adquisición de software. Pero, no define ni compromete prácticas para el proceso de producción de software, las que han de ser seleccionadas o definidas según cada organización.
1.5 Criterios de Selección de Herramientas Para efectos de este trabajo y dentro del conjunto de métodos presentados para el modelamiento de procesos, se debe seleccionar uno o una combinación de ellos. Los criterios de selección de la herramienta a utilizar son los siguientes:
a) La herramienta debe estar orientada al modelamiento de procesos de negocio. b) Debe ser de fácil comprensión y lectura para una persona que no se encuentre
capacitada en su uso. c) Debe capturar el detalle y las relaciones de flujos de trabajo entre las diferentes
etapas del proceso y proveer una estructura para priorizar acciones. d) Debe ser ampliamente utilizada, en lo posible un estándar. e) Debe proveer los elementos semánticos y gráficos para modelar las decisiones,
acciones y actividades. Para el caso del proceso de desarrollo de software, se especificará más adelante el modelo o estándar a utilizar, sin embargo, es importante señalar los criterios de selección:
a) Debe ser un modelo o estándar de la industria.
21
b) Debe promover la mejora continua de procesos y productos. c) Debe estar orientado al proceso de producción de software. d) Debe proveer un mecanismo de evaluación de madurez de los procesos.
Por último, para los procesos de planeación estratégica, es claro que se deben tomar elementos que permitan su aplicación al ámbito de la informática, en ese sentido, el criterio es utilizar una combinación de las herramientas comúnmente utilizadas de planificación.
2. Metodología
2.1 Enfoque de Trabajo Este trabajo, consiste en el cambio y redefinición de los procesos de negocio del área de tecnologías de información del holding de empresas. Siendo el desafío el transformar a la organización inicial de TI desde unidades no sinérgicas distribuidas a una unidad de servicios con orientación al cliente, planteando procesos que sean acordes a la cultura y realidad de la empresa y que estén basados en modelos y/o estándares de la industria, sin que las empresas clientes sufran un alto impacto en el servicio que actualmente están recibiendo. Existen varias aproximaciones para afrontar el cambio de los procesos en la organización, en particular, existe una serie de conceptos que son utilizados indistintamente para representar el fenómeno de cambio de los procesos del negocio, por ejemplo: reingeniería de procesos de negocio, mejoramiento de procesos, transformación del negocio, innovación de procesos y rediseño de procesos de negocio. Pero, ¿Qué es el cambio de los procesos de negocio? Existen, una serie de definiciones, que ayudan a entender este fenómeno [15]:
a) Es el rediseño y replanteamiento radical de los procesos de negocio para alcanzar mejoras dramáticas de rendimiento.
b) Es la reconfiguración del negocio usando TI como eje central. c) Es el análisis y diseño de workflows y procesos basados en equipos dentro o
entre organizaciones. d) Es una iniciativa estratégica de la organización para (re)diseñar los procesos de
negocio para alcanzar ventajas competitivas, distinguiendo el alcance desde la mejora de procesos hasta el diseño de nuevos procesos, contingentes al grado de cambio socio-tecnológico requerido.
Para afrontar proyectos que significan cambios en los procesos de negocio, se utiliza ampliamente el enfoque de re-ingeniería. La re-ingeniería es definida como el rediseño radical de los procesos de negocio transversales a una organización con el objetivo de obtener ganancias o ahorros en uno o más órdenes de magnitud, usualmente apoyado por tecnologías de información. Otra definición, ve a la re-ingeniería como una transformación organizacional general [14].
22
Cabe señalar, que uno de los aspectos importantes de la re-ingeniería es que parte de procesos de negocio que se encuentran en funcionamiento, en contraste con la innovación de procesos, que parte de procesos que no existen o no han sido definidos. Como este proyecto se desarrollará en una organización en funcionamiento, en la que se introducirán cambios, se plantea el uso de un enfoque de re-ingeniería de procesos. Esta metodología establece los siguientes pasos generales [14]:
1. Definición del proceso a ser estudiado. 2. Evaluación de la situación actual.
a) Documentar el proceso actual. b) Diagnosticar patologías.
3. Definición y evaluación de las áreas de rediseño. a) Explorar opciones de diseño. b) Diseñar el nuevo proceso. c) Diseñar la estructura organizacional asociada al proceso.
4. Implantación del rediseño propuesto. 5. Puesta en marcha y operación.
a) Evaluación. b) Mejora continua.
Entonces, para realizar este proyecto y en concordancia con las necesidades de la organización, se plantea, a continuación, la estrategia y metodología para el re-diseño de los procesos y la definición de la estructura organizacional.
2.2 Estrategia del Proyecto La estrategia del proyecto es la definición de la manera en cómo será enfrentado este trabajo, por lo tanto, es necesario distinguir entre las actividades propias del proyecto y las actividades de gestión del proyecto.
2.2.1 Actividades de Gestión del Proyecto Para la dirección general del proyecto, la empresa ha definido la formación de un comité ejecutivo compuesto del Gerente de servicios TIC, el Gerente General de la empresa de Servicios Compartidos y el Gerente representante de la empresa de consultoría. La función de este comité es velar por el cumplimiento de los objetivos del proyecto y resolver las diferencias de alto nivel que puedan surgir producto de las definiciones que se tomarán. El equipo de proyecto, estará compuesto por un jefe de proyecto por parte del área de tecnologías de información y que reporta al Gerente de servicios TIC, un jefe de proyecto por parte de la empresa consultora y un grupo de dos ingenieros consultores. El equipo extendido de proyecto contempla la participación del Gerente de servicios TIC y el personal que haya sido escogido como Subgerente o Jefe para cada área a definir. La función del equipo de proyecto, es definir e implementar los procesos y procedimientos de la nueva organización de tecnologías de información.
23
El seguimiento del proyecto se hará mediante reuniones semanales de coordinación del equipo de proyecto y reuniones mensuales del comité ejecutivo. Todas las reuniones generaran minutas, las que deberán ser aprobadas. Además, se llevará un control respecto al cumplimiento de compromisos, tanto interno como externo y un control de riesgos del proyecto. El plan comunicacional del proyecto se ajustará a lo que sea indicado por el comité ejecutivo. Sin embargo, se ha definido el siguiente conjunto mínimo de comunicaciones a la organización:
a) Inicio del proyecto. b) Estado de situación después de 1 mes de ejecución. c) Difusión de la nueva organización. d) Estado de situación después de 1 mes de difundida la organización. e) Estado de situación mensual dentro de la etapa de transición. f) Estado de situación una vez que la nueva organización sea considerada que se
encuentra en régimen. Los comunicados se entregarán mediante un boletín impreso a todo el personal del área de tecnologías de información. Además, serán publicados electrónicamente para facilitar la difusión. En el caso de la difusión de la organización, se realizará una reunión plenaria con todo el personal de tecnologías de información, los cargos serán comunicados personalmente por cada Subgerente de área. Para la difusión de los procesos, se ha contemplado una serie de presentaciones, primero a nivel de todo el personal, para dar a conocer el contexto global y luego a nivel de cada área, o grupos de áreas en caso de que el proceso relacione a más de una. Se contempla la participación y difusión a las jefaturas, quienes posteriormente deberán capacitar al personal que tienen a cargo.
2.2.2 Actividades Propias del Proyecto En concordancia con el enfoque de re-ingeniería de procesos, el proyecto se plantea en cuatro fases, estas son: Fase 1: Levantamiento Durante esta fase se realiza la evaluación y levantamiento de la situación actual, con el objeto de entender la problemática de la organización. Se diagnostican las patologías y se rescatan los procesos o elementos que puedan servir para la nueva organización. La obtención de la información será a través de entrevistas con personal clave de cada área y la obtención de documentación previa según sea el caso. En el capítulo 1, se ha presentado un resumen de los puntos más relevantes del levantamiento de la situación inicial.
24
Fase 2: Definición, Análisis y Diseño de Procesos En esta fase, se definirán los procesos, servicios y la estructura organizacional. Se utilizará como marco de referencia el modelo ITIL. En el caso del software, se utilizará un modelo de acuerdo a la selección que se propondrá más adelante en este capítulo. Los resultados de esta etapa son presentados en el capítulo 3. Esta actividad, será realizada en conjunto con la Gerencia TIC y el personal que sea designado como líder de la nueva estructura. El resultado de esta etapa son los procesos, la organización y la planificación estratégica del área TIC. Se presentarán los procesos definidos en esta etapa en forma global. Fase 3: Transición La fase de transición consiste en la puesta en marcha, implementación y adopción paulatina de los procesos mediante un plan de transición y cambio. Este será presentado en el capítulo 5. Junto con lo anterior, se implementa la nueva estructura organizacional, la que será presentada en el capítulo 4. Fase 4: Prestación de Servicios En esta fase el servicio se encuentra en operación. Sin embargo, es necesario definir procesos de mejora continua con el objeto de entregar servicios que sean mejores en el tiempo. En el capítulo 6, se planteará una estrategia para la mejora del proceso de software, cuya intención es dar pie para la definición y adopción de procesos de mejora continua en el futuro.
2.3 Selección de Herramientas Metodológicas De acuerdo a los criterios de selección de herramientas mencionados en el punto 1.5, para el modelamiento de los procesos se utilizará IDEFØ y eventualmente algunos elementos de UML, con el objeto de clarificar las representaciones. La elección se basa en que IDEFØ es una herramienta orientada al modelamiento de procesos, es ampliamente utilizada y de fácil comprensión. En cambio SADT solamente contempla un enfoque que es respecto a los sistemas. El modelo de ciclos de trabajo no captura el detalle de los procesos, si no que más bien las relaciones de tipo conversacional que se producen. Por otro lado, UML entrega un marco general para el modelamiento de sistemas, procesos y sus relaciones, lo que lo hace bastante entendible y completo. Para los procesos de software, se revisaron dos modelos ampliamente utilizados: ISO 9000 y CMMi. El problema de ISO es que al ser de carácter general no se encuentra orientado para resolver la definición de los procesos de software y debe ser interpretado para ser adaptado a esta realidad, en cambio CMMi está pensado para solucionar dicha problemática.
25
CMMi provee de un método de evaluación de madurez, en cambio ISO 9000, se preocupa solamente del cumplimiento de una serie de requisitos a alcanzar. En el caso de ISO 9126, que si está enfocado a software, solamente se concentra en los atributos para productos de software, pero no en los procesos, argumentando que una mejor evaluación de los atributos de calidad implica tener procesos mejores, sin embargo, estos no son definidos por el estándar. En contraste, CMMi establece una guía para los procesos y su institucionalización. Por lo tanto, es claro que CMMi posee ventajas para la definición de los procesos de software, proveyendo una guía, cumpliendo con los criterios de selección mencionados anteriormente, por ello, se utilizará como marco de referencia para la definición de los procesos básicos de software. En el caso del proceso de planeación estratégica se han revisado una serie de actividades que tienen relación directa con un negocio. Si bien, un área de informática, puede ser un negocio, el enfoque a considerar es el de apoyo, porque en este caso, se está entregando un servicio a un conjunto de empresas dentro de un marco global de una cartera de servicios. En definitiva, lo que hay que plantear es una metodología que permita al servicio TIC apoyar a las empresas clientes en la elaboración de un plan informático, teniendo en consideración los siguientes elementos:
a) La definición y declaración de la misión y la visión. b) El análisis de la situación actual de TI. c) La formulación de los planes y programas generales de acción, es decir: la
estrategia de gestión de recursos de TI, la arquitectura informática del negocio, el portafolio de proyectos, el presupuesto y el plan de infraestructura.
d) La programación y evaluación de los planes de acción propuestos y la fijación las prioridades para la asignación de los recursos.
e) La asignación de recursos y elaboración el presupuesto.
26
Capítulo 3 – Diseño de Servicios y Procesos
1. Diseño de Servicios
1.1 Servicios TIC El catálogo de servicios, es el conjunto de servicios que se proveerán a las filiales. El objetivo es entregar a los clientes una visión de la oferta de servicios TIC, su definición y su disponibilidad. La idea general, es que los servicios sean entregados integralmente, de manera tal, que los clientes finales no se tengan que preocupar de la contratación y la gestión, incluso, con terceros proveedores [5]. Por ejemplo, si una persona es contratada, el PC será provisto por el servicio compartido, quien luego realizará el cobro respectivo a la empresa cliente. Para simplificar, los servicios pueden ser clasificados de la siguiente manera:
a) Servicio fijo, es decir, son todos los servicios informáticos requeridos para que un usuario pueda realizar sus labores habituales dentro de su organización. Por ejemplo: PC, teléfono, sistemas de apoyo, impresoras, etc.
b) Servicios variables, es decir, servicios que son requeridos por el usuario sin ser permanentes su consumo en el tiempo. Por ejemplo: el uso de la mesa de ayuda, las mantenciones de corto plazo, etc.
c) Servicios de valor agregado, es decir, los servicios que agregan valor y producen el cambio dentro de una organización. Por ejemplo: los proyectos que implementan software nuevo, la propia gestión de las tecnologías de información, las mantenciones que significan una evolución en el software que está en funcionamiento, etc.
Esta clasificación tiene por objetivo facilitar el entendimiento de los usuarios respecto a los servicios ofrecidos por TI. Otra opción, puede ser una categorización de carácter técnico, pero no tendría sentido ya que tendería a confundir a los clientes más que aclararlos. Los servicios que se presentan en la tabla 4, están basados en la definición comercial que ha tomado la empresa. Si bien, pueden haber servicios que sean requeridos y que no estén dentro del catálogo, estos eventualmente, pueden ser creados o contratados a terceros, previa evaluación técnico-económica. Para cada tipo de servicio, se pueden definir agrupaciones y subservicios, lo que define finalmente la oferta y por lo tanto el catálogo de servicios. La disponibilidad de los servicios será abordada en la sección de niveles de servicio.
27
Tabla 4: El catálogo de servicios8
8 Fuente: Documento Interno. 2004. Catálogo de Servicios para un holding de empresas forestales. Empresa Forestal Chilena.
28
1.2 Modelo de costos de los servicios El objetivo es establecer un marco agregado para los costos, con la finalidad de simplificar el entendimiento a los clientes finales, respecto a la facturación de los servicios recibidos durante un periodo. Para definir el modelo de costo de los servicios, revisaremos cuales son las componentes sujetas a costo, considerando que:
a) Los PC, notebook, servidores, impresoras y equipos de redes pueden ser arrendados a terceros.
b) Los servicios de impresión poseen un costo fijo y un costo variable. c) Los servicios de comunicaciones son contratados a terceros y se rigen de
acuerdo a lo que ofrece el mercado. d) El costo de las mantenciones correctivas es asumido por el servicio, como parte
de la garantía del software. e) Los servicios básicos (agua, luz, electricidad, etc.) son de costo de la empresa
que recibe el servicio. f) Pueden existir servicios de carácter corporativo y que pueden ser recibidos por
varias empresas simultáneamente. g) Pueden existir servicios de carácter particular y que pueden ser recibidos por una
empresa. h) Los costos de los servicios pueden ser de carácter mensual o por única vez.
Distinguiremos los costos entre gasto e inversión. La diferencia es que una inversión es para bienes nuevos, realizada por única vez y considerada contablemente como un activo de la organización. En cambio, el gasto es de carácter permanente o temporal y se realiza sobre servicios y bienes ya adquiridos. Entonces, cada tipo de costo se puede agrupar de manera tal de establecer un marco para el modelo:
1. Las inversiones agruparan los siguientes tipos de costo: a) Licencias de software. b) Obras civiles. c) Instalación de redes de datos y telefonía nuevas. d) Hardware.
2. Los gastos contendrán los siguientes tipos de costo: a) Consultoría, que corresponde al costo hora-hombre de realizar una
actividad para una filial, esta puede ser interna o contratada a terceros. b) Arriendo de equipos. c) Servicios de terceros bajo contrato permanente ya sea de carácter
temporal o indefinido. d) Mantención de redes de datos y telefonía. e) Mantención de hardware. f) Viajes, viáticos y alimentación.
Luego, para cada tipo de servicio, los costos se pueden desglosar de manera tal de definir su aplicabilidad de acuerdo a la tabla 5.
29
Tabla 5: Criterios para la aplicabilidad de costos a los servicios Cabe señalar que dependiendo de la naturaleza del contrato de servicio, las componentes mencionadas pueden o no presentarse. Para el cálculo del costo final, es necesario diferenciar entre servicios que son provistos corporativamente, es decir, aquellos en que se utiliza una infraestructura tecnológica común y por lo tanto podrían ser prorrateados y servicios que son costeados localmente para cada filial, es decir, aquellos que se proveen con la infraestructura tecnológica propia de la filial o son dirigidos puntualmente a esta.
30
El factor de prorrateo puede ser calculado según las siguientes opciones:
a) Por número total de trabajadores de la filial. b) Por número total de trabajadores que tienen computador. c) Por número total de computadores, no considerando equipos servidores, es
decir, solo PC y notebooks. La elección de una u otra opción dependerá del ámbito del servicio que se está prorrateando. En la tabla 6, se presenta cada servicio con una propuesta para el criterio de prorrateo. El tipo de costeo es directo, cuando el costo es generado directamente por la filial.
Tabla 6: Criterios para aplicar prorrateo a los costos de los servicios Con esto, se ha establecido un modelo que permite el entendimiento y la asignación de los costos a los distintos servicios definidos.
31
1.3 Niveles de Servicio Para definir los niveles de servicio, es necesario entender la problemática desde el punto de vista del cliente final. En general, las personas perciben los servicios de informática desde el punto de vista del resultado, vale decir, evalúan en términos absolutos lo que reciben, sin haber términos medios, ni considerar elementos técnicos dentro de la evaluación. Bajo este paradigma, conviene definir niveles de servicio respecto a la disponibilidad global de los servicios entregados, dentro de un determinado tiempo y que resguarden la posibilidad de falla del servicio. El problema es encontrar el indicador adecuado. Para resolver lo anterior, se puede utilizar la agrupación de servicios propuesta en el catálogo de servicios y definir una segmentación de los usuarios, tomando en cuenta que por la naturaleza de los procesos de negocio de las filiales, no todos requieren los mismos niveles de servicio. Para determinar los distintos segmentos, existen dos criterios que se pueden utilizar:
a) El impacto sobre el negocio de una persona que frente a una pérdida de servicio deja de realizar sus labores o traba procesos productivos o del negocio.
b) La sensibilidad de una persona y/o la llegada sobre la alta dirección de la empresa cliente, es decir, su capacidad de reclamo ante la gerencia, frente a pérdidas de servicio.
Tal como se aprecia en la figura 8, estos componentes permiten identificar cuatro segmentos distintos de usuarios:
a) Usuario Normal: Es una persona que no necesariamente posee una alta jerarquía dentro de la empresa y que frente a una pérdida de servicio TI, el impacto sobre el negocio es bajo. Esta categoría, agrupa a usuarios de tipo administrativo.
b) Usuario Crítico: Es una persona que no necesariamente posee una alta jerarquía dentro de las empresas, pero que frente a una pérdida de servicio TI, produce un alto impacto sobre el negocio. Esta categoría, agrupa a usuarios que tienen directa relación con los procesos de ventas, facturación, operación y productivos de las filiales.
c) Usuario Especial: Es una persona que no necesariamente posee una alta jerarquía y que frente a perdidas de servicio no produce impacto en el negocio, sin embargo, tiene llegada con la alta dirección o posee una alta capacidad de reclamo. Esta categoría, agrupa a usuarios que serán identificados respecto a su comportamiento de reclamo.
d) Usuario VIP: Es una persona que posee una alta jerarquía dentro de las filiales y que posee una alta capacidad de reclamo y que frente a perdidas de servicio TI produce un alto impacto en el negocio. Esta categoría, agrupa a Gerentes y Subgerentes.
32
Figura 8: Segmentación de los usuarios Para el caso de los servicios fijos, la idea es definir un único indicador de disponibilidad que capture el comportamiento global de los servicios recibidos por el usuario. Cada servicio que compone el servicio fijo, tiene una no disponibilidad dentro de un periodo de tiempo y una importancia relativa, que en principio es asignada por el usuario. Por ejemplo, para un operador de etiquetaje de productos, es más importante que funcione la impresora de etiquetas a que funcione Internet. Entonces, sea iND la no disponibilidad del servicio i dentro de un horizonte de tiempo t, medido en horas, e iI 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
iii INDTND
1
Ecuación 1: Tiempo de no disponibilidad de los servicios fijos
Donde 10 iI y n es la cantidad de servicios que componen el servicio fijo. Luego, el porcentaje de disponibilidad del servicio fijo es:
1001%1
n
i
ii
tIND
DSF
Ecuación 2: Porcentaje de disponibilidad del servicio fijo
Pero, ¿cómo se calcula la importancia relativa del servicio? En principio, la importancia de cada servicio debería ser idealmente asignada por cada usuario, sin embargo, esto es impracticable en el corto plazo. Por ello, se asignará arbitrariamente una importancia relativa en relación a la segmentación de los usuarios.
33
Para simplificar la escala de importancia, se definen cinco niveles: alta, media-alta, media, media-baja y nula. Donde el nivel alto toma el máximo valor de importancia y el nivel nulo toma el mínimo valor. La importancia media-alta, media y media-baja tomaran valores intermedios, siendo la importancia media, el valor medio del rango establecido para iI , esto se puede ser en la tabla 7.
Tabla 7: Asignación de valores a la importancia de un servicio Ahora, se debe asignar la importancia de cada servicio respecto a la segmentación de usuarios definida, la que se muestra en la tabla 8. El criterio de asignación de la importancia es respecto al grado de uso estimado por cada tipo de usuario, según el comportamiento habitual observado empíricamente dentro de las empresas.
Tabla 8: Importancia de los servicios según la segmentación de usuarios Para el caso del Usuario Especial, el supuesto es que las componentes de servicio tienen una importancia media ya que a priori no es posible establecer un patrón de comportamiento previo de los reclamos, por lo tanto el valor medio es el que mejor podría representar la importancia de los servicios para este tipo de usuario. Finalmente, los niveles de servicio para los servicios fijos y para cada segmento de usuarios se han definido de acuerdo a la tabla 9.
34
Tabla 9: Niveles de servicio para los servicios fijos En el caso de los servicios variables, se debe distinguir entre los que son a pedido y los orientados al soporte a usuarios y de aplicaciones. Para este caso, se considerará el service desk, el soporte en terreno y las mantenciones de corto plazo, como servicios orientados al soporte a usuarios y de aplicaciones. La videoconferencia y los dispositivos de configuración móvil se considerarán como servicios a pedido, cuyos niveles de servicio serán los que sean contratados de acuerdo al requerimiento de la filial. Existe una serie de indicadores estándares para el service desk, soporte en terreno y el mantenimiento, tanto desde el punto de vista del servicio como del proceso. Por lo tanto, el problema es escoger cuales son los indicadores de servicio adecuados, que aseguren al cliente final que el servicio que está recibiendo se encuentre dentro de márgenes razonables de agilidad, oportunidad y fluidez. Desde el punto de vista del cliente, el interés principal es que el requerimiento o incidente, sea contestado en el menor tiempo posible y que una vez que es registrado por el service desk, sea resuelto en el menor tiempo posible. En resumen, se puede construir una línea de tiempo de acuerdo a la figura 9.
Figura 9: Línea de tiempo de un incidente
35
Se distingue entonces:
a) t0: como el tiempo donde se inicia el proceso de soporte y que es gatillado por la recepción y atención de una llamada en el service desk.
b) ta: como el tiempo en el que se asigno un incidente a un técnico o especialista. c) tr: como el tiempo de resolución del requerimiento o incidente. d) ts: como el máximo tiempo que un usuario puede esperar a que su requerimiento
sea resuelto sin reclamar. e) T1: como el intervalo de tiempo entre la recepción y asignación del incidente o
requerimiento. f) T2: como el intervalo de tiempo entre la recepción y la solución del
requerimiento. g) T3: como el intervalo de tiempo de resolución del requerimiento por parte de un
técnico o especialista. h) TMAX: como el intervalo de tiempo máximo en el que un usuario puede esperar
sin reclamar. Como no todos los incidentes o requerimientos pueden ser resueltos en TMAX para todo el universo de usuarios, la idea es apuntar a que un grupo de requerimientos sea resuelto antes de un cierto periodo de tiempo. Considerando la segmentación propuesta para los servicios fijos, se puede definir niveles de servicio escalonados de acuerdo al tipo de usuario que recibe la atención, según los siguientes supuestos:
a) Usuario Normal: Como el perfil es de tipo administrativo, una pérdida de servicio no tiene impacto sobre el negocio, su capacidad de reclamo es limitada, por lo tanto es el que tiene más baja prioridad de atención y niveles de servicio inferiores a las otras categorías.
b) Usuario Crítico: Como produce un alto impacto sobre el negocio frente a una pérdida de servicio, es el que tiene mayor prioridad de atención y por lo tanto el mejor nivel de servicio.
c) Usuario Especial: Esta categoría, debe tener niveles de servicio y prioridad equivalentes al usuario normal, sin embargo debe considerarse, a nivel del proceso, un método de excepción, que agilice los tiempos de atención y modifique prioridades, para el caso en que se detecte que este usuario pueda establecer un reclamo frente a la alta dirección.
d) Usuario VIP: A pesar de que este segmento posee una alta jerarquía y una alta capacidad de reclamo y que frente a perdidas de servicio TI produce un alto impacto, se le asigna la segunda prioridad de atención y los mismos niveles de servicio que un usuario crítico, ya que el supuesto es que el usuario crítico corresponde a personas que están ligadas directamente con la operación de las fábricas, por lo tanto es más impactante para el negocio una pérdida de servicio para ese tipo de personas, que para un usuario VIP.
Para reflejar la resolución de requerimientos de soporte antes de un periodo de tiempo, definiremos dos indicadores:
36
a) %RNR4, que corresponde al porcentaje de requerimientos no resueltos antes de 4 horas, sobre el total de requerimientos para el tipo de usuario VIP y crítico.
b) %RNR8, que corresponde al porcentaje de requerimientos no resueltos antes de 8 horas, sobre el total de requerimientos para el tipo de usuario normal y especial.
El supuesto para estos indicadores, es que un día de trabajo tiene 8 horas, por lo tanto el objetivo de %RNR4 es incentivar la resolución de requerimientos antes de 4 horas y %RNR8 antes de 8 horas. Para efectos de cálculo, ambos indicadores serán de carácter semanal ya que la idea es privilegiar la resolución. Para el service desk, los indicadores habituales son [22]:
a) Llamadas recibidas, que corresponde al total de llamados recibidos por la central telefónica del service desk.
b) Llamadas contestadas, que corresponde a las llamadas contestadas por los agentes del service desk.
c) Llamadas abandonadas, que corresponde a las llamadas perdidas o no contestadas por los agentes del service desk.
d) Tiempo medio antes de contestar, que corresponde al tiempo promedio en contestar una llamada por el grupo de agentes del service desk.
e) Tiempo medio de conversación, que corresponde a la duración promedio de una llamada.
f) Porcentaje de llamadas abandonadas, que corresponde al porcentaje de llamadas que se abandonaron sobre el total de llamadas.
g) Porcentaje de nivel de servicio, que corresponde a la cantidad de llamadas contestadas antes de un periodo de tiempo, sobre el total de llamadas.
h) Porcentaje de llamadas contestadas, que corresponde al porcentaje de llamadas contestadas sobre el total de llamadas recibidas.
De estos indicadores, los que están relacionados directamente con la percepción del usuario respecto al servicio son: porcentaje de nivel de servicio, el tiempo medio antes de contestar (TMC), porcentaje de llamadas abandonadas (%LLA) y el porcentaje de llamadas contestadas. (%LLC). Un indicador adicional, que impacta directamente en la percepción y el proceso, es la cantidad de requerimientos que son resueltos telefónicamente, por lo tanto se puede definir el porcentaje de resolución, como la cantidad de llamadas resueltas por el service desk, sobre el total de llamadas contestadas. Entonces, de acuerdo a la segmentación de usuarios propuesta y a la definición comercial de la empresa, los niveles de servicio se muestran en la tabla 10.
37
Tabla 10: Niveles de servicio para servicios variables Hay que notar, que los niveles del service desk, son uniformes para todo tipo de usuario, no así los relacionados con el soporte en terreno. Para el caso del mantenimiento de corto plazo, el que consideraremos con un horizonte de tiempo no mayor a 3 meses, no son aplicables los indicadores mencionados, ya que este tipo de actividad la mayor parte del tiempo no es de carácter operativo. Es por ello que se propone utilizar indicadores de cumplimiento mensual, es decir:
a) %RMNR_1m, que corresponde al porcentaje de requerimientos de mantenimiento no resueltos antes de 1 mes, sobre el total de requerimientos y de acuerdo a la prioridad del usuario.
b) %RMNR_2m, que corresponde al porcentaje de requerimientos no resueltos antes de 2 meses, sobre el total de requerimientos y de acuerdo a la prioridad del usuario.
c) %RMNR_2m, que corresponde al porcentaje de requerimientos no resueltos antes de 3 meses, sobre el total de requerimientos y de acuerdo a la prioridad del usuario.
La definición de la empresa, es apuntar a que el 80% de los requerimientos sea resuelto en menos de un mes, el 90% antes de dos meses y el 95% antes de tres meses, por lo tanto, los niveles de servicio son los indicados en la tabla 11.
Tabla 11: Niveles de servicio para la mantención de software de corto plazo
38
Respecto a los servicios de valor agregado, el enfoque es diferente. Este tipo de servicio contempla proyectos y consultoría, donde el cumplimiento de los compromisos juega un rol relevante respecto a la percepción del servicio. Entonces, para el lado del cliente, más que definir métricas relacionadas con el proyecto o con el software, hay que considerar la capacidad de cumplimiento y de gestión y la obtención de resultados dentro de los plazos comprometidos. Bajo este enfoque, se pueden distinguir niveles de servicios asociados a la globalidad, es decir, al conjunto o cartera de proyectos y/o consultorías que es realizado durante un año para una determinada empresa y a la particularidad, es decir, a lo que se espera recibir para un proyecto y/o consultoría puntual. Para reflejar el cumplimiento antes de un periodo de tiempo, definiremos los siguientes indicadores:
a) %PA, de carácter global, que corresponde al porcentaje de proyectos o consultorías atrasadas respecto a la planificación que fue aprobada por el servicio y por el cliente, sobre la cantidad total de proyectos o consultorías en ejecución, para un cliente y dentro del año. Responde a la pregunta: ¿Cómo es la gestión general de la cartera de proyectos?
b) %CC_PG, de carácter global, que corresponde al promedio del porcentaje de cumplimiento de compromisos para la cartera de proyectos o consultorías realizadas dentro del año. Responde a la pregunta: ¿Cómo es el cumplimiento de compromisos del servicio?
c) %CC_P, de carácter particular, que corresponde al porcentaje de cumplimiento de compromisos para un proyecto o consultoría particular, sobre la cantidad total de compromisos a la fecha de cálculo del indicador. Responde a la pregunta: ¿Cómo es el cumplimiento de compromisos del proyecto o consultoría?
d) DA, de carácter particular y corresponde a los días de atraso de un proyecto o consultoría particular respecto a su planificación aprobada. Responde a la pregunta: ¿Cuánto es el atraso del proyecto?
Entonces, de acuerdo las expectativas y definición de la empresa, los niveles de servicio son los indicados en la tabla 12.
Tabla 12: Niveles de servicio para servicios de valor agregado
39
2. Diseño de Procesos Para el desarrollo de los siguientes puntos y debido a la profundidad, extensión y cantidad de temas que pueden ser tratados, se han considerado los aspectos más relevantes que pueden ser mejorados como parte de un primer diseño de los procesos de TI. El enfoque de diseño de los procesos es de carácter general, sugiriendo guías ya que algunos temas por si mismos pueden ser abordados en forma independiente como tema de tesis, memoria, o trabajo posterior.
2.1 Proceso de planeación estratégica TIC para las filiales
2.1.1 Proceso para la planeación estratégica Típicamente, la planificación estratégica en TI se refiere a la identificación e implementación de la tecnología requerida por el negocio para la consecución de su misión, objetivos y estrategias [8]. El carácter multinacional, la cantidad de filiales y la distribución de las localizaciones del holding agregan una complejidad importante a este proceso. Esto sugiere, que cada plan debe ser acorde a las necesidades de cada filial, teniendo en consideración la posibilidad de generar sinergia e intercambio tecnológico entre diferentes empresas. Por otro lado, la velocidad de los avances tecnológicos incorpora, además, una componente temporal que debe ser contrastada con la capacidad de cambio de las empresas en el tiempo y su habilidad para adoptar e incorporar nuevas tecnologías a los procesos de negocio. Se distinguen dos planeaciones según el horizonte de tiempo: una de carácter estratégico, que tendrá relación con la determinación de los lineamientos tecnológicos de largo plazo y otra de carácter más táctico, orientado a alinearse con los periodos de planificación anual de las filiales. La planeación de largo plazo, será entendida como la identificación de la tecnología requerida por el negocio para la consecución de su misión, objetivos y estrategias. En cambio, la de carácter táctico, tendrá relación con el plan de implementación de dichas tecnologías dentro de periodos anuales. Un elemento importante a considerar, es la velocidad de cambio de la tecnología, sin embargo, el carácter conservador del holding respecto a la adopción tecnológica lo sitúan como una empresa netamente seguidora más que adoptadora. Por lo tanto, el horizonte de largo plazo será el que considere tecnología que se encuentre ampliamente probada y desarrollada, es decir cuatro a cinco años. Tomando en consideración lo mencionado en el aspecto teórico de la planeación estratégica, se propone un proceso que sigue los siguientes pasos:
40
1. Definición y declaración de la misión y la visión de TI, con horizonte de tiempo de largo plazo.
2. Análisis de la situación actual de TI. 3. Definición de la situación deseada de TI, con horizonte de tiempo de largo plazo. 4. Formulación de los planes y programas generales de acción:
a) Estrategia de gestión de recursos de TI. b) Arquitectura informática del negocio, con horizonte de tiempo de largo
plazo. c) Definición del portafolio de proyectos. d) Plan de infraestructura.
5. Programación y asignación de prioridades y recursos. 6. Elaboración del presupuesto.
En la figura 10 se muestra la representación del flujo del proceso.
Figura 10: Proceso de planeación estratégica de TI De la figura 10, las actividades de planeación deben ser abordadas conjuntamente con la empresa, por ello es necesaria la creación de un comité de TI que este compuesto de representantes de alto nivel de la empresa y del servicio TIC. El comité tendrá como función realizar la planeación informática, priorizar y aprobar el presupuesto y dirimir respecto a los gastos adicionales que surjan, producto de nuevas necesidades o adecuaciones de procesos de negocio propios, que impacten la componente de tecnologías de información.
41
Profundizando, la declaración de la misión consiste en la expresión del propósito del negocio, en este caso, el servicio de TI, la que incluye, la definición del ámbito actual y los cambios esperados en el futuro, la descripción general de productos y servicios ofrecidos, cobertura geográfica y la selección de una forma de conseguir una posición ya sea de liderazgo, de excelencia, o de asesoramiento, que permita tener una supervivencia sostenible en el tiempo [11]. La visión corresponde a lo que se espera y quiere del servicio de TI desde la perspectiva de la empresa que recibe el servicio [11]. El siguiente paso, análisis de la situación actual de TI, corresponde a la determinación y diagnostico de:
a) La arquitectura informática del negocio. b) La infraestructura, vale decir, cantidad y tipo de equipos, tecnologías utilizadas y
el diagnostico de procesos. c) Los recursos utilizados para el desarrollo y mantención de software, gestión de
TI, soporte a usuarios e infraestructura. d) El estado de los proyectos y mantenciones en curso. e) El gasto realizado para el funcionamiento del servicio de TI.
Como resultado del análisis de la situación actual, la definición de la situación deseada de TI, el plan informático con horizonte de tiempo de largo plazo debe recoger las necesidades actuales y futuras que hayan sido previstas. Este plan general, debe incluir:
a) Estrategia general de recursos de TI, es decir, las definiciones y políticas respecto a: la compra y/o arriendo de equipos, la contratación de servicios y recursos humanos, tanto internos como externos.
b) La arquitectura informática deseada, idealmente considerando soluciones probadas y estándares para la definición de tecnología a utilizar.
c) Estrategia general de infraestructura, es decir, tecnología a utilizar, arquitectura de red, servidores y servicios deseados.
d) Procesos de TI que serán mejorados o abordados, con el objetivo de establecer en el mediano plazo procesos de mejora continua.
La formulación de los planes y programas generales de acción junto con la programación y asignación de prioridades y recursos, corresponde a la definición en detalle y con carácter anual de:
a) Plan táctico de gestión de recursos de TI, es decir, determinación anual de los recursos requeridos para realizar el plan anual de proyectos e infraestructura.
b) Plan anual de mejora e implantación de la arquitectura informática del negocio. c) Definición del portafolio de proyectos de software, el que incluye la descripción
de los proyectos con una valorización previa. d) Plan de infraestructura, el que incluye, proyectos, plan de mantenimiento y
recambio de tecnología, servicios que se requerirán dentro del periodo.
42
2.1.2 Proceso para la elaboración del presupuesto Derivado de la planeación estratégica de TI de la filial, el presupuesto es la estimación de los recursos de dinero para llevar a cabo los planes de acción definidos en la planeación estratégica. El presupuesto de informática se puede dividir según la siguiente clasificación:
a) Proyectos, es decir, toda actividad relacionada con proyectos que signifiquen la adquisición, adecuación e implantación de software nuevo o infraestructura nueva.
b) Mantención de Software, que considera los recursos para las mantenciones evolutivas y adaptativas. Las correctivas no son consideradas ya que se define como una garantía permanente al software instalado, por lo tanto no pueden ser costo de la empresa que recibe el servicio.
c) Licencias de Software, es decir, compra de nuevas licencias y mantención anual de licencias.
d) Mantención de Hardware y Redes, que considera partes y piezas, repuestos y mano de obra tendientes a reparar un producto de hardware o una red de comunicaciones.
e) Arriendo de Equipos, es decir, el arriendo de PC, notebooks, servidores, impresoras, etc.
f) Servicios Informáticos, donde se consideran, los servicios permanentes prestados por terceros.
g) Comunicaciones, que considera los costos de la telefonía fija, móvil y las redes de comunicación WAN.
El presupuesto debe ser especificado en dólares. El tipo de cambio presupuestado es entregado anualmente por el área de finanzas, el que debe ser tomado como referencia para la elaboración del presupuesto. Además, deben ser especificadas todas las actividades y los flujos mensuales, los que son determinados respecto a la planeación anual de las actividades. En la tabla 13, se presenta un ejemplo de un presupuesto.
43
Tabla 13: Ejemplo de un presupuesto El problema de la elaboración del presupuesto es la estimación de los recursos económicos a considerar. Para resolver este punto, en la tabla 14 se presenta una propuesta de criterios que pueden ser utilizados.
44
Tabla 14: Criterios para la presupuestación Además, es importante detallar los ítems que se considerarán dentro del presupuesto ya que es considerado como el plan anual de actividades y servicios de TI, en la tabla 15 se proponen los criterios.
Tabla 15: Criterios para detallar el presupuesto El presupuesto debe ser presentado al comité de TI de la empresa, quienes, dentro del marco de la planeación anual, fijarán el detalle de las prioridades y definirán los recursos.
45
Entonces, el proceso propuesto es:
1. De la planeación estratégica, determinar las actividades y servicios que serán abordados dentro del periodo, contrastando con las necesidades de cada área de la empresa. Esta actividad puede ser en conjunto con los jefes de cada área.
2. Estimar los costos para cada una de las actividades y servicios. 3. Clasificar las actividades de acuerdo a la guía proporcionada anteriormente. 4. Completar la planilla de presupuesto, considerando los tiempos de las
actividades y servicios. 5. Revisar, junto con el comité de TI el presupuesto. El comité determinará el
detalle de las prioridades y recursos que proveerá la empresa. 6. Obtener la aprobación del comité de TI.
En la figura 11 se muestra la representación del flujo del proceso.
Figura 11: Proceso de elaboración del presupuesto
46
2.2 Procesos de software Los procesos de software pueden ser caracterizados y cubiertos por cinco macro procesos:
a) Administración de Proyectos. b) Desarrollo y Administración de Requerimientos. c) Desarrollo de Software. d) Pruebas de Software. e) Mantención de Software.
En esta sección, se presentará la definición general de estos procesos tomando como marco de referencia algunos elementos de la guía proporcionada por CMMi.
2.2.1 Administración de Proyectos La administración de proyectos bajo CMMi abarca una serie de áreas de procesos de los niveles de madurez 2, 3 y 4, identificándose las siguientes como parte de este proceso:
a) Planificación de proyectos. b) Monitoreo y control de proyectos. c) Administración de acuerdos con proveedores. d) Administración integrada de proyectos. e) Administración de riesgos. f) Equipos integrados. g) Administración integrada de proveedores. h) Administración cuantitativa de proyectos.
La idea es generar el proceso básico de administración de proyectos, de acuerdo al tipo de metodología de desarrollo de software. En la industria se encuentran dos grandes visiones metodológicas para el desarrollo de software: los métodos ágiles y los métodos tradicionales. Pero, ¿Cuales son los criterios para escoger entre uno u otro tipo de metodología? Para responder a la pregunta, se pueden definir los siguientes elementos de juicio para apoyar la decisión [2]:
a) Los métodos ágiles tienen una mejor efectividad que los tradicionales cuando se presentan requisitos cambiantes o mal definidos.
b) Si los tiempos de desarrollo del proyecto son ajustados, se está aplicando nueva tecnología y hay poca experiencia del equipo de desarrollo, se puede utilizar metodología ágil con una buena posibilidad de éxito del proyecto.
c) Si se requieren resultados en corto tiempo y existe compromiso y voluntad para que el usuario final y la administración sea parte del equipo de desarrollo, la metodología ágil puede ser aplicada.
d) Si bien la metodología ágil puede ser utilizada en todo tipo de proyectos, es recomendable que para proyectos de mediano y largo plazo se utilicen métodos tradicionales debido a que:
47
a. Se entiende que un proyecto de corto plazo es para resolver algo puntual, por lo tanto un control de proyectos mediante el seguimiento de actividades puede ser aplicado.
b. La cantidad de personas del equipo de proyecto es mayor a la de un proyecto de corto plazo.
c. La cultura organizacional es de carácter tradicional, por lo que la falta de formalidad del método ágil puede ser interpretada por la organización como mala gestión y desorden del proyecto.
Se ha señalado, que en la práctica no existe un proceso de administración de proyectos. Sin embargo, de la situación inicial, se destacan los siguientes puntos:
a) Los proyectos son planificados en tiempo mediante una carta Gantt y los recursos son costeados, de acuerdo a la voluntad del jefe de proyecto.
b) El seguimiento del proyecto no siempre es realizado y cuando se hace, la actividad la ejecuta el superior inmediato del jefe de proyecto, tampoco hay una participación directa del cliente.
Por lo tanto, el énfasis de esta definición, debe ser respecto a la planificación, monitoreo y control de los proyectos. Cabe notar, que por el tamaño de la organización y la escasez de recursos, es necesario contar con una función que concentre el seguimiento e información de control y monitoreo de los proyectos y que permita establecer a nivel del portafolio, la planeación, priorización y coordinación de los recursos asignados a los proyectos. Otro punto importante, es que el servicio de TI puede tercerizar la ejecución de los proyectos, manteniendo un jefe de proyecto interno, es por ello que cobra relevancia la administración de los proveedores, tema que será discutido en el proceso de gestión de proveedores.
2.2.1.1 Administración de proyectos con metodologías ágiles Las metodologías ágiles son caracterizadas por iteraciones de corta duración, por lo tanto la administración de proyectos de este tipo, tiene que ver con el ciclo: planeación, control y monitoreo para el startup del proyecto y las iteraciones posteriores [29]. Entonces, utilizando algunos elementos conceptuales del desarrollo de software ágil, se proponen las siguientes actividades para la administración de proyectos de este tipo:
1. Planificar la iteración. a) Determinar las actividades y su duración. b) Determinar los costos de la iteración. c) Determinar los casos de prueba para el testing [16]. d) Agendar la iteración. e) Agendar la revisión de errores y defectos del software [16].
2. Guiar la iteración. a) Monitorear y controlar la iteración, resolver problemas. b) Evaluar y mitigar riesgos durante la iteración [16]. c) Agendar y realizar la revisión de lo que se hizo durante la iteración.
48
3. Guiar el proyecto. a) Revisar objetivos [16]. b) Mantener actualizado el avance de las actividades. c) Realizar seguimiento y priorización de las actividades de corrección de
errores y defectos [16]. d) Identificar riesgos.
En la figura 12 se muestra la representación del flujo del proceso.
Figura 12: Administración de proyectos con metodologías ágiles
2.2.1.2 Administración de proyectos con metodologías tradicionales Para este tipo de proyectos, el desarrollo puede ser abordado mediante métodos tradicionales, por ejemplo: cascada, espiral, incremental, etc. Las actividades propuestas son:
1. Planificar el proyecto. a) Establecer los objetivos, alcances y ámbito del proyecto [25]. b) Definir el ciclo de vida del proyecto [17]. c) Definir la metodología de desarrollo.
49
d) Definir y estimar las actividades, recursos y costos [25]. e) Definir el plan comunicacional del proyecto. f) Identificar los riesgos del proyecto.
2. Obtener el compromiso de la organización para el plan del proyecto. a) Identificar a los terceros relevantes [25]. b) Obtener el compromiso con el proyecto.
3. Monitorear el proyecto de acuerdo al plan establecido. a) Realizar reuniones de seguimiento y revisión. b) Revisar los compromisos. c) Revisar y mitigar los riesgos [25]. d) Revisar y realizar acciones correctivas.
4. Comunicar el estado del proyecto [17]. En la figura 13 se muestra la representación del flujo del proceso.
Figura 13: Administración de proyectos con metodologías tradicionales Hay que notar, que las variables de monitoreo y control deben estar ligadas a los niveles de servicio comprometidos con las empresas. Esto sugiere, la utilización de los mismos indicadores de cumplimiento vistos en el diseño de los servicios de valor agregado, es decir, la medición de los días de atraso respecto a la planeación original y el grado de cumplimiento de compromisos. Sin embargo, lo anterior no es suficiente para determinar el estado de avance real de un proyecto o un desarrollo de software. Para resolver la problemática, hay que distinguir que cada actividad del proyecto debe producir productos tangibles o entregables bajo una cierta temporalidad definida.
50
Entonces, si n es el número total de actividades del proyecto, iP es la cantidad de productos entregables para una actividad i , con un plazo planificado de realización it y
itr es el tiempo real transcurrido para la realización de la actividad i , se proponen las siguientes métricas para el control y seguimiento:
1. Porcentaje de productos entregados en iri tt : es decir, todas aquellas actividades que produjeron el producto de acuerdo a lo planeado, sobre el total de productos definidos:
100%
1
n
ii
jj
p
P
PPE donde j es tal que jj ttr
Ecuación 3: Porcentaje de productos entregados dentro de plazo
2. Porcentaje de productos entregados en iri tt : es decir, todas aquellas
actividades que produjeron el producto por sobre el tiempo planificado, sobre el total de productos definidos:
100%
1
n
ii
jj
a
P
PPE donde j es tal que jj ttr
Ecuación 4: Porcentaje de productos entregados fuera de plazo
3. Porcentaje de avance del proyecto: es decir, la ponderación entre la cantidad
total de actividades y el factor de cumplimiento de tiempo i
ri
tt , de manera tal que
1i
ri
tt , es decir todas aquellas actividades que se encuentren sin atraso respecto
a lo planificado:
1001% i i
ri
tt
nAP
Ecuación 5: Porcentaje de avance del proyecto
Pero, ¿qué ocurre con las actividades con atraso? Si una actividad está atrasada respecto a lo planificado quiere decir que, o la planeación no fue la correcta, o que la actividad presenta un problema que debe ser corregido, si eso es así, es un riesgo del proyecto que ha de ser mitigado.
51
Cabe señalar, que los indicadores planteados en los puntos 1 y 2 son de carácter ex-post y miden cumplimiento. Respecto a lo propuesto en el punto 3, la idea es tener un indicador de avance, en relación al tiempo respecto a lo planeado, sin embargo si la planificación es mala, esto no tiene sentido. Hay que notar, que la planificación es una estimación de tiempo y actividades de lo que se hará en el proyecto y como tal, debe ser de carácter dinámico ya que debe adaptarse de acuerdo a las situaciones y necesidades que se vayan dando durante la ejecución del proyecto, por ello el indicador propuesto en el punto 3 cobra relevancia desde el punto de vista operativo, entregando una noción de la situación de avance. La realización de las actividades de un proyecto depende de las personas, por lo tanto, está sujeto a variabilidad, esto puede ser mitigado o modelado de acuerdo a la historia del comportamiento productivo de los recursos humanos. Se puede definir, una serie de indicadores de productividad que permitan obtener mejores estimaciones para la planificación, pero hay que tener en cuenta que un indicador debe considerar al menos temporalidad y complejidad, entonces se pueden plantear dos preguntas: Para un producto de software con un cierto nivel de complejidad, ¿Cuánto tiempo se demora un recurso en desarrollarlo de manera tal que la cantidad de defectos sea inferior a una cierta tasa preestablecida? ¿Cuál es la varianza de ese proceso? Se puede considerar una métrica que clasifique piezas de software en base a complejidad, por ejemplo puntos de función y que mediante mediciones, establezca una tasa de tiempo para el desarrollo, lo que finalmente establecerá un criterio de productividad para los recursos. El problema con esta métrica es que depende del recurso, es decir, la actividad de registro de tiempo puede no ser ajustada a la realidad ya sea por olvido, resistencia al control de tiempo y los temores propios de una medición de productividad para una persona. La problemática puede ser resuelta desde varios aspectos, primero a la toma de conciencia de las personas que son medidas, con el sentido de que este tipo de iniciativas permiten tener un mejor control del proceso del proyecto, por lo tanto mejores estimaciones y un mejor servicio entregado al cliente; y segundo, a la automatización y sistematización del proceso de captura de los datos, de manera tal de que la información sea obtenida oportunamente.
2.2.2 Proceso de Desarrollo y Administración de Requerimientos De acuerdo a CMMi, el propósito del desarrollo de requerimientos es producir y analizar los requerimientos de clientes, productos y componentes de productos. La administración de requerimientos, es la gestión de los requerimientos de los productos del proyecto y los componentes del producto y la identificación de las inconsistencias entre esos requerimientos, los planes del proyecto y los productos de trabajo [7]. Ambos procesos distinguen las siguientes etapas [7]: Caso: Desarrollo de Requerimientos.
a) Desarrollar requerimientos de clientes. b) Desarrollar requerimientos de productos. c) Analizar y validar requerimientos.
52
Caso: Administración de Requerimientos.
a) Obtener una comprensión de los requerimientos. b) Obtener compromiso con los requerimientos. c) Administrar los cambios a los requerimientos. d) Mantener la trazabilidad bidireccional de los requerimientos. e) Identificar inconsistencias entre el trabajo del proyecto y los requerimientos.
El enfoque de este proceso, será abocarse a la problemática de levantar el requerimiento del cliente ya que es la falencia principal de la organización. Como se vio anteriormente, la etapa de requerimientos, corresponde a la recepción y aprobación. En términos prácticos, es el usuario quien especifica el requerimiento, de acuerdo a sus propias palabras. El requerimiento es recepcionado por un encargado de TIC, que intenta interpretar y evaluar el requerimiento. Luego, se presenta para aprobación a un comité y de ser aprobado, se realiza. No se genera documentación. Independiente de la metodología del proyecto y del tipo de solicitud, la idea es tener un proceso estándar para el levantamiento de requerimientos. Los elementos relevantes son los relacionados con el levantamiento, es decir: el desarrollo de los requerimientos del cliente, la obtención de una comprensión de los requerimientos el análisis y la validación de los requerimientos y la obtención de compromisos con los requerimientos. Además, es imprescindible la participación de las áreas que transformaran los requerimientos en software. Entonces, el proceso se puede definir de la siguiente manera:
1. Recepción de una solicitud de cambio o de levantamiento de requerimientos. 2. Desarrollar el requerimiento.
a) Determinar los objetivos, visión y alcance [17]. b) Determinar la situación actual y lo deseado. c) Determinar los procesos de negocio y sus requerimientos [17]. d) Determinar los requerimientos funcionales respecto al software. e) Determinar los requerimientos técnicos del software.
3. Comprender el requerimiento. a) Analizar el requerimiento, mediante reuniones y revisión de a pares [17]. b) Determinar el impacto [17]. c) Elaborar el documento de requerimientos.
4. Obtener compromiso. a) Validar con usuario, que lo documentado respecto al requerimiento,
corresponde a lo solicitado [17]. b) Solicitar y obtener compromiso del usuario [17].
5. Evaluar la solicitud. a) Determinar la evaluación económica. b) Determinar la evaluación técnica. c) Determinar si es un proyecto o un mantenimiento.
6. Presentar al comité de informática para aprobación.
53
En la figura 14 se muestra la representación del flujo del proceso. Para las solicitudes de cambio, el ingreso debe ser realizado a través de la mesa de ayuda, se sigue el flujo normal de evaluación, con la diferencia que solamente es validado por el Service Manager, obteniéndose el compromiso y luego sometido a aprobación en el comité. La diferencia con un requerimiento normal, es que se considera una solicitud de cambio como una solicitud de mantención de software.
Figura 14: Proceso de desarrollo y administración de requerimientos Pero, ¿Cómo manejar los cambios de los requerimientos? La posibilidad de cambios siempre se encuentra presente, en cualquier etapa, lo importante es que estos sean realizados, idealmente en el levantamiento de requerimientos, antes de obtener el compromiso con el usuario, entendiendo que dicho compromiso, es la aceptación de la especificación de una cierta funcionalidad, que para ser evaluada y presentada al comité, no puede ser modificada. En la práctica, pueden presentarse situaciones en las que por cambios en el negocio, haya un cambio en los requerimientos. Bajo ese escenario, la propuesta es realizar el ciclo completo de requerimientos, más que concentrarse en los cambios. Si el cambio es menor, debe evaluarse el impacto y comunicar al comité la nueva evaluación.
54
Una vez establecidos los requerimientos, es parte de la evaluación técnica determinar la adecuación al software. Para ello, se propone el uso de una matriz de trazabilidad entre la funcionalidad de software versus los requerimientos. Respecto a las técnicas para el levantamiento y especificación de requerimientos, se propone:
1. La realización de entrevistas con todos los involucrados, utilizando preguntas abiertas para obtener un panorama general del requerimiento y preguntas especificas para el detalle.
2. La utilización de diagramas UML de casos de uso para la especificación ya que son simples, es un modelo estándar, evita ambigüedades y es entendible por usuarios no técnicos.
3. Evitar el uso de palabras o redacciones que puedan estar sujetas a varias interpretaciones, o sean ambiguas.
2.2.3 Proceso de Desarrollo de Software El proceso de desarrollo de software consiste en establecer la manera en que serán desarrolladas las aplicaciones en la empresa, esta definición también va asociada a qué tecnología utilizar para el desarrollo de software. CMMi establece como parte de su área de proceso de solución técnica la guía para afrontar esta problemática, considerando típicamente las fases que siguen al análisis de requerimientos, es decir el diseño y la construcción. Para el caso de metodologías ágiles, el proceso general es definido como sigue:
1. Definir una arquitectura de software para la solución. a) Escoger un patrón arquitectónico de software [16]. b) Crear actividades de desarrollo para implementar la arquitectura [16]. c) Determinar y diseñar las interfaces. d) Identificar los objetivos de rendimiento de la aplicación. e) Definir un prototipo arquitectónico de la aplicación [16]. f) Definir la infraestructura.
2. Ejecutar las actividades de desarrollo. a) Determinar el tiempo para desarrollar la actividad. b) Definir los tests unitarios a aplicar [16]. c) Construir el software [16]. d) Analizar el código. e) Realizar los tests unitarios. f) Verificar y corregir código.
3. Corregir errores. a) Realizar testing con el usuario y encontrar errores [16]. b) Reproducir el error. c) Localizar la causa del error. d) Corregir el error.
55
e) Realizar testing del usuario y volver a iterar en caso de ser necesario [16]. 4. Entregar el producto.
a) Construir el instalador de la aplicación [16]. b) Instalar la aplicación. c) Corregir errores en caso de que se presenten. d) Realizar la aceptación del producto [16].
En la figura 15 se muestra la representación del flujo del proceso.
Figura 15: Proceso de desarrollo de software con metodología ágil Para el caso de métodos tradicionales, el proceso general es definido como sigue:
1. Definir y seleccionar las componentes del producto. a) Crear alternativas detalladas de diseño de la aplicación [17]. b) Diseñar y seleccionar la arquitectura del sistema. c) Determinar y diseñar las interfaces. d) Determinar los requerimientos y escenarios operacionales [17]. e) Crear pruebas de concepto de la aplicación, mediante diagramas [17]. f) Identificar los objetivos de rendimiento de la aplicación.
2. Desarrollar el diseño.
56
a) Revisar el diseño. b) Crear y definir el tiempo de las actividades de desarrollo para implementar
el diseño y la arquitectura [17]. c) Definir los tests unitarios a aplicar. d) Construir el software [17]. e) Analizar el código. f) Realizar los tests unitarios. g) Verificar y corregir código. h) Integrar los cambios.
3. Implementar el diseño a) Escribir y revisar la documentación [17]. b) Corregir el software en caso de presentarse errores.
4. Integrar el producto a) Construir el instalador de la aplicación [17]. b) Instalar la aplicación. c) Corregir errores en caso de que se presenten. d) Realizar la aceptación del producto para su entrega [17].
En la figura 16 se muestra la representación del flujo del proceso.
Figura 16: Proceso de desarrollo de software con metodologías tradicionales
57
Cabe señalar, que las actividades de ensamblaje y entrega de producto, son abordadas en CMMi bajo el proceso de integración del producto, en contraste con el método ágil, el que realiza la entrega dentro de su propio ciclo de desarrollo. Posteriormente se presentan las etapas de validación y verificación, donde el testing del software es realizado, lo que será revisado en el siguiente punto. En resumen, el proceso de desarrollo de software contempla las siguientes grandes etapas:
1. Definir la metodología de proyecto a utilizar: ágil o tradicional, de acuerdo a los criterios propuestos en la sección de administración de proyectos.
2. Seguir los procesos definidos anteriormente de acuerdo a la elección metodológica.
Respecto a la definición de la tecnología a utilizar para el desarrollo de software, en la industria hay dos herramientas comúnmente utilizadas para el diseño y construcción de software empresarial, por una parte .NET de Microsoft y por otra J2EE de Sun Microsystems. Para optar por uno u otro, hay que tener en cuenta las siguientes consideraciones:
1. En la empresa existe software en ambas plataformas, sin embargo, las aplicaciones son en su mayoría .NET, donde el ambiente Windows es predominante.
2. Las aplicaciones J2EE corresponden a software propietario, adquirido a terceros, cuyo ciclo de desarrollo y mantenimiento se ve cubierto por los acuerdos de licenciamiento y soporte existentes.
3. Ambos entornos de programación presentan ventajas y desventajas, siendo las principales:
a) J2EE presenta una mejor portabilidad de plataforma que .NET. b) J2EE es una tecnología más madura que .NET. c) .NET posee soporte para múltiples lenguajes de programación, con
una arquitectura equivalente a la planteada bajo J2EE. d) .NET está especialmente orientado a la creación de servicios web,
con una arquitectura clara y sencilla de clases para crear y distribuir estos servicios.
e) Microsoft con su suite Visual Studio, establece una serie de prácticas de desarrollo de software que pueden ser aplicadas con métodos tradicionales y ágiles, en cambio Sun solo ofrece la plataforma, donde las prácticas son abordadas mediante entornos de programación de terceros.
Entonces, .NET es la elección natural, debido a la predominancia histórica de las aplicaciones de este tipo dentro de la empresa y sus filiales y al soporte multilenguaje, lo que se traduce en mayor flexibilidad para la diversidad que existe actualmente. J2EE tiene mayor madurez pero es un único lenguaje, las aplicaciones actuales bajo esta plataforma son propietarias y por lo tanto no representan el problema para el proceso de desarrollo interno. Por otro lado, el intentar migrar las aplicaciones actuales a J2EE
58
sería demasiado costoso y por lo tanto carente de sentido ya que no aportaría valor a la empresa. Como valor agregado, el proceso de desarrollo establecido por Microsoft para la plataforma .NET contempla un framework para metodologías ágiles y otro orientado a métodos tradicionales, usando CMMi. De ambos, se tomaron los aspectos más relevantes para definir los procesos señalados anteriormente.
2.2.4 Proceso de Pruebas de Software Independiente del enfoque utilizado para desarrollar el software, las pruebas son consideradas como una etapa que debe ser realizada dentro del proceso de software. Dentro de la organización no existe un proceso formal de pruebas y tal como se menciono en el capítulo 1, son realizadas de acuerdo a la voluntad del programador o del jefe de proyecto. La idea del proceso de pruebas, es definir un marco de referencia simple, que permita la aplicación de metodologías de testing en forma permanente. El proceso de pruebas está directamente relacionado con las actividades de desarrollo y mantención de software y por lo tanto los artefactos de software son una entrada para este proceso. En CMMi se definen dos áreas de proceso que abordan la problemática, por una parte, la verificación, cuyo objetivo es asegurar que los productos de trabajo cumplan con los requerimientos especificados [30] y por otra la validación, cuyo objetivo es demostrar que un producto cumple con su uso propuesto cuando es instalado en el entorno propuesto [30]. Una manera práctica de abordar la verificación es realizar la revisión de pares [30], es decir, quien realizó el trabajo le cuenta la solución a un par, de acuerdo a un procedimiento documentado con el objetivo final de encontrar y anticipar errores y defectos. El proceso se puede definir de la siguiente manera:
1. Planificar la verificación. a) Establecer el ambiente de pruebas. b) Seleccionar los productos de trabajo que se verificaran. c) Establecer los casos de prueba de acuerdo a los requisitos del producto. d) Establecer los criterios de éxito de la verificación.
2. Realizar la verificación de acuerdo a los requisitos del producto. a) Identificar a los revisores y agendar la verificación. b) Revisar la visión del producto. c) Revisar el diseño del producto. d) Realizar las pruebas.
3. Registrar los resultados. a) Registrar resultado para cada caso de prueba. b) Registrar el éxito de la verificación y determinar acciones correctivas.
4. Preparar el informe de verificación. En la figura 17 se muestra la representación del flujo del proceso.
59
Figura 17: Proceso de pruebas con metodología ágil En el caso de la validación, la idea es realizar el testing del software de acuerdo a casos y datos de prueba, se propone un proceso con las siguientes etapas:
1. Planificar el testing. a) Establecer el ambiente de pruebas. b) Seleccionar los productos de trabajo que se verificaran. c) Establecer la estrategia de testing. d) Establecer los casos y datos de prueba. e) Establecer los criterios de éxito de la prueba.
2. Ejecutar. a) Ejecutar el testing de acuerdo a la estrategia.
3. Registrar resultados. a) Registrar resultado para cada caso de prueba. b) Registrar el éxito de la validación y determinar acciones correctivas.
4. Preparar el informe de testing. En la figura 18 se muestra la representación del flujo del proceso.
60
Figura 18: Proceso de pruebas con metodologías tradicionales Respecto a la estrategia de testing, se propone que el enfoque sea por proceso (escenario) de negocio más que orientarse por modulo [9], esto con el fin de garantizar que el proceso modelado dentro del software funcione de acuerdo a los requisitos y dentro de cada proceso, realizar el análisis transaccional, esto se puede visualizar en la figura 19. Como no existe una definición metodológica respecto a la construcción de los casos de prueba y no existe mucha experiencia dentro de la organización, se propone utilizar el enfoque de caja negra, el que está orientado a la construcción de los casos de pruebas a partir de las funcionalidades del sistema. Se propone utilizar la técnica de clases de equivalencia, junto con el análisis de valores límite para obtener los casos de prueba que se utilizarán en el análisis transaccional.
61
Figura 19: Diagrama de descomposición para el testing9
2.2.5 Proceso de Mantención de Software En CMMi, la mantención es vista como una etapa más del ciclo de vida del software, que integra los procesos de solución técnica, validación, verificación, junto con la administración y desarrollo de los requerimientos. Esto ya ha sido abordado en los procesos anteriores, es decir, una mantención sigue el mismo ciclo de requerimientos – desarrollo – pruebas. Por lo tanto, el enfoque para definir este proceso, será de acuerdo a solucionar la problemática para la provisión del servicio. Uno de los problemas del proceso de mantención es la asignación de tareas y prioridades al personal que realiza las mantenciones y el entendimiento de lo que es una mantención. Bajo el escenario de un servicio único para todas las filiales, la problemática es aun peor debido a la diversidad de software existente y a la especialización del personal por división de negocio. Esto sugiere dos cosas, por una parte se debe contar con una metodología eficiente de asignación de recursos y por otra, se debe contar con las definiciones adecuadas que permitan discriminar el alcance de una mantención. Se entenderá como mantención de software al proceso general de cambio de un sistema después de que ha sido entregado. Se definen tres tipos [28]:
a) Mantención para reparar fallas de software. b) Mantención para adaptar el software a un ambiente de operación diferente, por
ejemplo modificaciones o cambios de hardware que provoquen cambios en el software.
c) Mantención para agregar o modificar funcionalidades al software.
9 Fuente: Apuntes del curso “Técnicas de Prueba de Software”. 2004. Diplomado en Gestión de Calidad de Software.
62
Esta definición, permite tener un marco global para una mantención, sin embargo no establece alcance en cuanto a tiempo o recursos. El problema de esto es que si una actividad de mantención consume mucho tiempo y recursos, puede transformarse en un proyecto. Por ello, como elemento adicional diferenciaremos los proyectos de software respecto a proyectos de mantenimiento. Un proyecto de software será todo aquel proyecto que implemente un sistema nuevo y un proyecto de mantención, será aquel que cambie un sistema después de haber sido entregado. Una manera rápida de calificar una actividad de mantención de un proyecto, es utilizar criterios de tiempo y costo. Podrían usarse también medidas de software, por ejemplo, puntos de función, sin embargo, al no haber experiencia previa su uso y a la necesidad de responder rápidamente a los clientes, la aplicación podría resultar contraproducente en esta etapa. Por lo tanto, una mantención será calificada como proyecto, cuando como resultado de la estimación de recursos, se determine que el costo de realizar la actividad involucre a una o dos personas por un tiempo superior a tres meses. La problemática es que el personal está especializado por división de negocio por lo que frente a un esquema global, la asignación de tareas no es eficiente. Por ello se proponen dos opciones de especialización:
a) Por proceso de negocio, vale decir, formando grupos de trabajo por tipo de proceso, por ejemplo: ventas, bodegas, etc.
b) Por tipo de tecnología, vale decir, por la tecnología característica del software, por ejemplo: web, aplicaciones en forms, aplicaciones SAP, visual basic, etc.
El problema de la primera opción es que requiere de personas con un amplio dominio de las herramientas tecnológicas, sin embargo, se especializa en los procesos de negocio del cliente. La segunda opción requiere de especialistas en las herramientas tecnológicas utilizadas en el software, pero no es tan relevante la componente de negocio. Otro antecedente, es que en Chile, el mercado de las empresas proveedoras ofrece sus servicios por tipo de tecnología, no por tipo de proceso. Por lo tanto, la opción b) parece la más adecuada para definir líneas de mantenimiento, que en este caso, serán por zonas geográficas. La primera división por tipo de tecnología será para diferenciar las aplicaciones SAP del resto y como es de carácter corporativo y centralizado, no será dividido por zona geográfica, entonces se propone la siguiente división:
1. Mantenimiento SAP. 2. Mantenimiento no SAP.
a) Chile, zona Centro (desde la VI Región hacia el norte). b) Chile, zona Sur (desde la VII Región hacia el sur). c) Argentina y Uruguay. d) Perú y Brasil.
63
e) México. Tomando los antecedentes expuestos anteriormente y considerando las definiciones entregadas, el proceso de mantención es presentado en la figura 20, y se define de la siguiente manera:
1. Recepción de un requerimiento de cambio a través del service desk. 2. Análisis y clasificación del requerimiento.
a) Determinar si es una mantención o no. b) Clasificar el requerimiento.
3. Estimación y asignación de recursos. a) Estimar tiempo y costo. b) Determinar si es un proyecto o no. c) Crear una tarea de mantenimiento. d) Asignar la tarea de mantenimiento, de acuerdo a la disponibilidad de
recursos. 4. Modificación del software, donde se realiza el mantenimiento y tiene que ver con
el proceso de cambio que es realizado sobre el producto, es decir la programación. Desde el punto de vista de los procesos de software, corresponde a la aplicación y uso de metodologías de desarrollo de software.
5. Pruebas de software. 6. Pruebas de aceptación del usuario.
a) Pruebas funcionales. b) Aceptación.
7. Paso a producción.
Figura 20: Proceso de mantención del software
64
2.3 Procesos de soporte al servicio
2.3.1 Gestión de incidencias La gestión de incidencias tiene por objetivo restaurar la operación de un servicio, minimizando el impacto en las operaciones del negocio y asegurando el mantenimiento de la disponibilidad y los niveles de servicio [26]. Para capturar y registrar los requerimientos o incidentes de los usuarios y por el tamaño de la organización, es necesario la definición e implementación de un service desk. Para ello, primero se debe definir la estructura y alcance que tendrá está unidad. Existen tres estructuras básicas [22]:
a) De tipo centralizado, es decir, el service desk atiende centralizadamente todas las llamadas de usuario de la organización, independiente de su ubicación geográfica.
b) De tipo descentralizado, es decir, el service desk se encuentra distribuido en varias zonas geográficas, las que eventualmente pueden ser independientes entre sí.
c) Virtual service desk, que combina los elementos de las estructuras centralizadas y descentralizadas para proporcionar el servicio. Basado en un fuerte componente tecnológico y de telecomunicaciones, provee un único punto de acceso, sin embargo los agentes pueden estar distribuidos en distintas ubicaciones geográficas.
La empresa posee filiales en Chile y Sudamérica, por lo que en principio un modelo descentralizado podría ser la solución. La ventaja, es que al estar localizado geográficamente, se logra fácilmente que el soporte sea específico para la zona, además puede servir de respaldo en caso de que otro service desk, de otra zona geográfica, no se encuentre disponible. Por otro lado, el modelo centralizado requiere de una menor cantidad de personal para ser operado, la gestión está centralizada y por lo tanto su costo es eventualmente menor. El virtual service desk se descarta como opción de solución ya que además introduce costos de comunicación y tecnológicos, que en los otros modelos no se incurren. Otro elemento a considerar es que estratégicamente, el holding se define como líder en costos. Por lo tanto, la elección es por una estructura centralizada en Chile ya permite una mayor optimización y control de los recursos. Respecto a las localidades en el extranjero, la especialización del soporte se puede obtener mediante entrenamiento. Esto puede ser más lento que tener un service desk descentralizado, pero en el mediano plazo se puede lograr el objetivo. Ya definida la estructura del service desk, el proceso de gestión de incidencias se define de la siguiente manera:
1. Detección y registro de incidentes, los que pueden ser reportados directamente al service desk, por correo, o por mecanismos de auto atención [19].
2. Gestión de las solicitudes de servicio. e) Distribución de los requerimientos de servicio.
3. Clasificación de los incidentes y soporte inicial.
65
a) Determinar tipo de incidente. b) Determinar impacto y urgencia. c) Entregar soporte inicial.
4. Investigación y diagnostico del incidente [19]. a) Identificar la solución del incidente. b) Determinar si es un incidente mayor. c) Determinar si se trata de un problema. d) Escalar al siguiente nivel si es necesario.
5. Solución y recuperación. a) Resolver el incidente. b) Implementar acciones correctivas. c) Implementar acciones de recuperación. d) Verificar que el incidente este resuelto.
6. Cierre del incidente. a) Verificar la satisfacción del cliente. b) Cerrar el incidente.
En la figura 21 se muestra la representación del flujo del proceso. Los niveles de servicio del service desk, deben ser los mismos que se han definido en la sección de diseño de servicios. Para la gestión, se propone el uso de los indicadores habituales, es decir:
a) Llamadas recibidas, que corresponde al total de llamados recibidos por la central telefónica del service desk.
b) Llamadas contestadas, que corresponde a las llamadas contestadas por los agentes del service desk.
c) Llamadas abandonadas, que corresponde a las llamadas perdidas o no contestadas por los agentes del service desk.
d) Tiempo medio antes de contestar, que corresponde al tiempo promedio en contestar una llamada por el grupo de agentes del service desk.
e) Tiempo medio de conversación, que corresponde a la duración promedio de una llamada.
f) Porcentaje de llamadas abandonadas, que corresponde al porcentaje de llamadas que se abandonaron sobre el total de llamadas.
g) Porcentaje de nivel de servicio, que corresponde a la cantidad de llamadas contestadas antes de un periodo de tiempo, sobre el total de llamadas.
h) Porcentaje de llamadas contestadas, que corresponde al porcentaje de llamadas contestadas sobre el total de llamadas recibidas.
66
Figura 21: Proceso de gestión de incidencias
2.3.2 Gestión de problemas La gestión de problemas es la búsqueda de la causa de una incidencia, que no ha podido ser resuelta por el soporte estándar, para convertirla en un error conocido e iniciar la acción de mejora o corrección de la situación [26]. Considera dos aspectos [26]:
a) Reactivo, que es concerniente a la solución de problemas en respuesta a uno o más incidentes.
67
b) Proactivo, que tiene relación con la identificación y solución de problemas y errores conocidos antes de que un incidente vuelva a ocurrir.
Además, define dos tipos de controles [21]:
a) Control de problemas, cuyo objetivo es transformar los problemas en errores conocidos, actividad que es parte del proceso.
b) Control de errores, cuyo objetivo es resolver estructuralmente los errores conocidos a través del proceso de gestión de cambio.
La gestión de problemas tiene directa relación con la gestión del cambio ya que los resultados de este proceso generan modificaciones en la infraestructura informática y como tales deben ser controlados y registrados. En el caso de que un error no pueda ser resuelto, el problema es calificado como un error conocido, para el cual deben elaborarse planes y actividades que permitan la corrección temporal o workaround, mientras la solución es encontrada [21]. Las etapas del proceso, serán realizadas por un grupo de solución de problemas (GSP), cuyo objetivo es investigar, diagnosticar y solucionar el problema, considerando aspectos de infraestructura y software. Este comité será integrado por un representante de cada unidad organizacional, quién se encargara de coordinar las actividades de corrección al interior de su unidad organizativa. Las soluciones y planes serán registrados, con el objeto de tener una base de datos con el conocimiento de los problemas. Para definir el proceso, se han tomado los aspectos más relevantes de ITIL y que pueden ser de utilidad para la organización. La definición es la siguiente:
1. Registro del problema y clasificación. a) Detección de los incidentes clasificados como problema. b) Detección de problemas desde otras fuentes, es decir, las provenientes de
la infraestructura informática y el software [21]. c) Determinar el impacto y la urgencia en el negocio [21]. d) Clasificar de acuerdo a lo determinado en el punto c.
2. Investigación y diagnostico del problema. a) Investigar y diagnosticar la causa del problema. b) Determinar las actividades para corregir el problema, escalar al proveedor
en caso de ser necesario y realizar seguimiento. c) En caso de no encontrar la causa del problema, elaborar planes y
actividades que permitan una solución temporal [21]. 3. Control de errores.
a) Implantar la corrección del problema mediante el proceso de gestión del cambio [21].
b) Verificar la eliminación del error [21]. 4. Cierre del problema.
a) Registrar los síntomas del problema y los detalles de la solución. b) Registrar los artefactos, equipos, o ítems de configuración que sufrieron
cambios [21].
68
c) Verificar la satisfacción del cliente. d) Cerrar el registro del problema.
5. Análisis proactivo y revisión de problemas. a) Analizar tendencias de problemas y determinar focos de acción preventiva
[21]. b) Revisar los problemas mayores y las acciones tomadas para su solución,
con el objeto de prevenir que vuelva a ocurrir [21]. En la figura 22 se muestra la representación del flujo del proceso.
Figura 22: Proceso de gestión de problemas
2.3.3 Gestión de inventario y configuración La gestión de inventario y configuración provee la información sobre la estructura de tecnologías de información de una organización, la que es utilizada por otros procesos y para la gestión [26]. Establece el control de la infraestructura, a través del monitoreo y mantención de la información de los recursos necesarios para la distribución del servicio, la evolución de los ítems de configuración en el tiempo y sus relaciones [26]. Para el servicio de TI es imprescindible tener un inventario actualizado de equipos, principalmente PC, notebooks, impresoras, equipos de comunicación y servidores ya que su número y características son utilizados como dato para la facturación de algunos servicios.
69
El principal problema con el inventario, es tener la información actualizada y mantener el control sobre el ciclo de vida del equipo, es decir, el registro de los cambios y configuración, la incorporación, modificación y baja del equipo. Además, como el equipamiento es arrendado, es necesario controlar los eventos que signifiquen perdidas o siniestros, las fechas de inicio y termino del periodo de arriendo, las que no necesariamente pueden concordar con las fechas de recepción y devolución. El proceso requiere de cierta disciplina por parte de las personas que participan en el proceso, en el sentido de que todo evento sobre el equipamiento debe ser registrado en la medida que ocurra. Otros datos de utilidad para mantener en el inventario son: características técnicas del equipo, el lugar físico donde se encuentra, quién lo tiene asignado, un identificador que permita determinar si el equipo está sujeto a servicio técnico y el número del contrato de arriendo. El proceso de inventario y configuración, puede modelarse en los siguientes pasos:
1. Recopilar la información de los equipos, mediante software ad-hoc. 2. Mantener la información, es decir registrar los cambios para la configuración,
ubicación y eventos tales como: hurtos, robos, perdidas o siniestros. La información puede ser mantenida a través del mismo software, o por registro manual según sea el caso.
3. Validar que la información registrada sea la correcta, mediante auditorias manuales, realizadas cada cierto tiempo.
4. Activar los seguros comprometidos, en caso de robo, hurto, o siniestro de los equipos.
En la figura 23 se muestra la representación del flujo del proceso. Debido a la envergadura de la empresa, la recopilación y mantención de los datos no puede ser realizada manualmente, es por ello que necesariamente se debe contar con una herramienta que permita mantener actualizada la información relevante para el inventario. Por ello, se propone que la herramienta, deba al menos poseer la siguiente funcionalidad:
1. Permitir la recopilación automática de los siguientes datos: a) Notebooks, PC y Servidores:
Marca y modelo del equipo. Características técnicas: CPU, RAM, modelo y tamaño del disco
duro, presencia de arreglos de discos, tarjetas de red disponibles, sistema operativo instalado, otro hardware instalado.
Software instalado. b) Impresoras:
Marca y modelo. Marco y modelo del printserver según corresponda. Cantidad de bandejas.
c) Equipos de comunicación:
70
Marca y modelo. Tipo de equipo: switch, firewall, hub, etc. Cantidad de puertas utilizadas y disponibles.
2. Permitir la edición y adición manual de los siguientes datos, para cada equipo: a) Número de contrato de arriendo. b) Número de servicio. c) Número de serie. d) A qué persona o empresa se encuentra asignado. e) Ubicación física, la que entenderemos por: planta o edificio y área del
edificio o planta donde se encuentra. f) Fecha de recepción del equipo. g) Fecha de inicio del periodo de arriendo. h) Fecha de finalización del periodo de arriendo. i) Fecha de devolución del equipo. j) Eventos, es decir: hurtos, robos, perdidas o siniestros.
3. Permitir la emisión de informes de inventario.
Figura 23: Proceso de gestión de inventario y configuración
71
2.3.4 Gestión del cambio El objetivo de la gestión del cambio es minimizar la interrupción de servicios ante cambios. Es decir, se deben asegurar los métodos y procedimientos estándares que se utilizarán para el manejo de los cambios en la infraestructura tecnológica. La gestión se debe realizar desde que se pidió hasta que finalizo [26]. La infraestructura debe ser separada en ambientes de desarrollo, ambiente de pruebas y ambiente de producción, el que definiremos, como el conjunto de hardware y software que es utilizado por la empresa para la ejecución de sus sistemas informáticos y para el cual se debe registrar y establecer una línea base, de manera tal que los cambios sean registrados sobre dicha configuración. El problema con el manejo de cambios, es que existe un escaso control sobre la plataforma de producción, por lo tanto, para esta etapa, el enfoque será la definición de un proceso de paso a producción, el que tiene como requisito previo, que el ambiente de producción sea cerrado y controlado por el personal que administre la infraestructura. El paso a producción es el proceso mediante el cual se instala en ambiente productivo las piezas de software y hardware requeridas para que una aplicación funcione. Entonces, hay que distinguir que un paso a producción tendrá características, actividades y alcances distintos de acuerdo a lo que se desea instalar. Para ello, se puede realizar una clasificación, de acuerdo al tipo de software que se coloca en productivo y al hardware. En el caso del software se distinguen los siguientes tipos:
a) Aplicaciones que se instalan o modifican en equipos de usuarios, actividad que ha de ser realizada por técnicos de terreno.
b) Servicios que se instalan o modifican en servidores en funcionamiento, cuya realización está a cargo de los administradores de la plataforma.
c) Scripts de bases de datos, es decir: procedimientos almacenados, tablas, definiciones, etc., cuya realización está a cargo del administrador de la base de datos.
d) Aplicaciones web, cuya realización está a cargo de los administradores de la plataforma.
e) Otros, es decir, software no clasificado dentro de las categorías anteriores y cuya realización debe ser sancionada de acuerdo a los elementos que la integran.
Para el caso del hardware, se distinguen los siguientes tipos:
a) Hardware nuevo que es instalado en ambiente productivo. b) Modificación a hardware existente en ambiente productivo.
Los criterios de realización del paso a producción dependerán de la disponibilidad de una ventana de tiempo para realizar la actividad y a las restricciones propias impuestas por políticas de la administración de la infraestructura, por ejemplo: restricciones de horarios o días, disponibilidad de recursos, etc.
72
Es importante señalar, que como elementos principales de la actividad, se debe definir el plan de paso a producción, el plan de reversa y un plan de contingencia para el caso en que se presenten problemas. Si hay hardware comprometido, además deben ser especificados los componentes nuevos o sujetos a cambio. En resumen, el proceso de paso a producción significa:
1. Que el desarrollador registra una solicitud de paso a producción, la que debe contener los programas, planes y justificación para poder ser realizada.
2. La solicitud es derivada por la coordinación del service desk, revisada y clasificada, de acuerdo al tipo de software o las actividades relacionadas con el hardware.
3. El paso a producción es agendado de acuerdo a las ventanas de tiempo disponibles, considerando las restricciones que existan en ese momento. Sin embargo, pueden haber excepciones, para afrontar incidentes, que signifiquen perdida de servicio, con posibilidad de detener procesos de negocio, o que tengan carácter de urgencia.
4. El paso a producción es realizado, en caso de presentarse problemas se escala con el desarrollador.
5. El resultado del paso a producción es informado al desarrollador. En la figura 24 se muestra la representación del flujo del proceso.
Figura 24: Proceso de paso a producción
73
Respecto a los equipos de escritorio, notebooks, impresoras y dispositivos que sean utilizados por los usuarios, pero que no son parte de la plataforma de producción, también se debe tener el control respecto a la configuración y sus cambios. Estos provendrán de incidentes de servicio y en general serán realizados por técnicos de terreno. Eventualmente, podría haber compra de hardware o software por lo que un ciclo de aprobación debe ser considerado. Entonces, se puede definir un proceso que aborde esta actividad, de acuerdo a lo siguiente:
1. Recepcionar el incidente de cambio. a) Determinar si es un cambio que requiere compra de hardware o software. b) Registrar elementos sujetos a cambio.
2. En caso de que el cambio signifique la compra de hardware o software, cotizar la realización del cambio e informar al cliente, quién deberá autorizar o no la compra.
3. Realizar el cambio. a) Coordinar con el usuario la fecha y hora del cambio. b) Registrar los cambios realizados.
4. Cerrar el incidente. a) Verificar satisfacción del usuario.
En la figura 25 se muestra la representación del flujo del proceso.
Figura 25: Proceso de gestión del cambio para equipos de escritorio
74
2.3.5 Control y distribución de software y hardware El objetivo del proceso es la protección del ambiente productivo y sus servicios, a través del uso de procedimientos formales y revisiones. Se relaciona directamente con la gestión del cambio [26]. El proceso debe considerar las etapas de planeación, diseño, construcción, configuración y comprobación del hardware y el software para crear un repositorio de versiones para el ambiente productivo [26]. Para el caso del software, las etapas de planeación, diseño, construcción, configuración y comprobación ya fueron abordadas anteriormente, por lo que el enfoque para este proceso es respecto al control de versiones de los artefactos de software. El control de versiones de software puede llevarse a cabo sobre los siguientes aspectos:
a) A nivel de archivos del código fuente, respecto a sus fechas de creación, modificación y eliminación, por parte de uno o más autores.
b) A nivel de cambios dentro del código fuente, es decir, modificaciones, por parte de uno o más autores.
c) A nivel de módulos funcionales del software, es decir un conjunto de archivos de código fuente que componen un módulo.
d) A nivel del producto de software, de acuerdo a diferencias de funcionalidad, o diferencias por correcciones producto de defectos o errores.
Entonces, la problemática es definir que se va a considerar como control de versiones de software y cuáles son los aspectos relevantes para el registro de los cambios. En general, un producto de software está compuesto de módulos propios que se componen de archivos de código fuente y librerías externas, las que pueden ser de terceros o construidas dentro de la empresa. Luego, se puede definir, un control de versiones de carácter jerárquico desde el producto de software hasta los archivos de código fuente que lo componen. Para mantener el orden y en concordancia con lo señalado en el proceso de paso a producción, se propone categorizar el código fuente según el tipo de tecnología, como se muestra en la figura 26. Respecto a la numeración de las versiones, se propone utilizar un correlativo con el formato zzzyyyxxx .. , donde xxx corresponde al número de release o entrega, yyy corresponde al número de revisión y zzz corresponde al número de sub-revisión. Entenderemos por entrega al evento en que una pieza o producto de software, que implementa un grupo de requerimientos, es liberado para su instalación en ambiente de producción. Un cambio de funcionalidad es una nueva entrega, por lo tanto una nueva versión. El número de revisión se incrementará respecto a la entrega de las modificaciones realizadas en el software con el objeto de corregir defectos pero sin cambio de funcionalidad. El número de sub-revisión corresponderá a la entrega de modificaciones menores sobre una revisión del software y que no signifiquen cambio de funcionalidad.
75
Es indispensable contar con un software para el control de las versiones, sobre todo si una pieza de código es modificada por más de una persona. Las funcionalidades mínimas requeridas son:
a) Permitir y llevar la trazabilidad de los cambios realizados sobre el código fuente. b) Permitir la jerarquización del código fuente de acuerdo a lo propuesto en la figura
26. c) Soportar múltiples usuarios y con capacidad de administrar la concurrencia sobre
un archivo de código fuente. d) Manejar el historial de versiones del código fuente y productos de software. e) Soportar el esquema de numeración de versiones propuesto anteriormente. f) Tener mecanismos de seguridad y roles que permitan salvaguardar el código
fuente de accesos no autorizados.
Figura 26: Descomposición del producto de software para el control de versiones En el caso del hardware, es el propio ciclo de gestión del cambio el que realiza el registro de la planeación, construcción, configuración y comprobación, sin embargo el diseño no es parte del proceso y por lo tanto se entenderá que es abordado como parte del diseño del ambiente operacional de un proyecto ya sea de software, mantención, o infraestructura.
76
2.4 Procesos de entrega del servicio
2.4.1 Gestión de disponibilidad y continuidad El objetivo de la gestión de la disponibilidad es asegurar que los servicios de TI tengan una disponibilidad sostenida en el tiempo, a un costo justificable y en satisfacción con los objetivos del negocio [26]. Por otro lado, la continuidad asegura que los servicios provistos por TI puedan ser recuperados dentro de los márgenes de tiempo requeridos y acordados con el negocio [26]. Específicamente, la idea es asegurar la continuidad del negocio frente a un desastre o falla mayor, reducir las vulnerabilidades, riesgos y producir planes de recuperación que estén integrados al negocio. El desarrollo de planes para asegurar la disponibilidad y la continuidad, que contemplen la recuperación y las acciones a tomar frente a la no disponibilidad de un servicio no es suficiente. Se debe considerar que las personas que ejecuten el plan deben estar entrenadas en las actividades que tengan que realizar, con el objeto de que frente a la contingencia, solamente actúen. Si el plan no satisface los requerimientos del negocio frente a la no disponibilidad, entonces debe ser reformulado. Un elemento importante a considerar, es que, las plantas industriales de la empresa, por la naturaleza y velocidad de sus procesos, disponen de poca holgura de tiempo, alrededor de 3 horas antes de parar. Por ello, la formalización e institucionalización del proceso, no solo es a nivel del servicio TIC, sino que también a nivel de la empresa cliente, la que debe incorporar como parte de sus procesos de operación, los planes que sean definidos por la gestión de disponibilidad. En ese sentido, es relevante la participación de un comité con representantes del cliente y del servicio TIC, en el que se revisen y aprueben los planes. Pero, ¿Qué ocurre frente a la disponibilidad? A priori, si un servicio está disponible entonces no habría nada que hacer. Pero, ¿Es suficiente hacer nada para mantener la continuidad de un servicio? De acuerdo a la experiencia práctica, deben realizarse actividades para mantener la continuidad, es decir, administrar, prevenir y monitorear los servicios. No hacerlo significa no estar gestionando la disponibilidad y los niveles de servicio requeridos por el negocio, por lo tanto el resultado final para el cliente puede ser desastroso. Las actividades mencionadas son transversales a los procesos que se han estudiado en esta tesis y por lo tanto son prácticas que han de ser adoptadas por las personas para el éxito de la organización TIC. Como proceso, la gestión de disponibilidad y continuidad, contempla determinar los elementos críticos del negocio, desarrollar planes para gestionar la disponibilidad y la continuidad y formalizar con la organización tanto cliente como del servicio TIC [26], entonces, se debe:
1. Definir los niveles de servicios. a) Determinar las funciones críticas del negocio. b) Determinar los requerimientos de disponibilidad.
77
2. Proponer un plan para la disponibilidad [26]. a) Identificar los componentes de servicio más relevantes. b) Diseñar los servicios de acuerdo a los requisitos de disponibilidad. c) Definir riesgos y su mitigación. d) Definir el plan de recuperación. e) Definir el plan para la no disponibilidad.
3. Determinar las actividades para mantener la continuidad.10 a) Determinar las actividades de administración de la infraestructura. b) Determinar las variables relevantes para monitorear la continuidad. c) Establecer umbrales que permitan la prevención proactiva.
4. Formalizar el plan, capacitar, e institucionalizar mediante acuerdos de nivel de servicio operativos [26].
5. Ejecutar los planes en caso de ser requerido. En la figura 27 se muestra la representación del flujo del proceso.
Figura 27: Proceso de gestión de la disponibilidad y la continuidad
2.4.2 Gestión del nivel de servicio De acuerdo a la figura 28, la gestión del nivel de servicio consiste en mantener y mejorar la calidad del servicio TI, a través de un ciclo continuo de acuerdos, monitoreo y reportes periódicos de estado de los servicios [26]. Para ello, la existencia de un comité
10 El detalle de estos temas, será revisado en la Gestión de Infraestructura.
78
de representantes de la empresa cliente y del servicio TIC es fundamental, para el consenso, definición, acuerdo, revisión y optimización de los niveles de servicio.
Figura 28: Ciclo de gestión del nivel de servicio11 De acuerdo a lo definido por la empresa, los acuerdos de nivel de servicio deben ser establecidos mediante contratos. Sin embargo, un acuerdo de nivel de servicio o SLA (Service Leve Agreement) no debe ser considerado solamente como un contrato formal, es más bien un consenso entre un proveedor y un receptor de servicios y que cubre los siguientes aspectos [3,23]:
a) El acuerdo de servicios, vale decir la definición de lo que se entrega y sus niveles de satisfacción.
b) La prevención de conflictos, de acuerdo a la promesa del proveedor versus la expectativa del cliente.
c) La distinción entre el proceso para entregar el servicio y el proceso de negocio de la empresa que recibe el servicio.
d) Las expectativas del cliente. Pero, ¿Qué elementos se deben considerar para especificar formalmente un nivel de servicio? Primero, debe establecerse un compromiso para la efectividad del servicio frente a los requerimientos del negocio. Segundo, los servicios deben especificarse claramente, se manera tal que sus indicadores tengan sentido para el cliente. Los costos del servicio deben ser claros y diferenciados de acuerdo a los distintos servicios que se están entregando. Finalmente, los acuerdos deben ser comunicados a toda la organización cliente y no permanecer en conocimiento de un grupo reducido de personas. En términos prácticos, un documento de acuerdo de nivel de servicios debe contener al menos los siguientes puntos [3]:
1. Propósito del servicio. 11 Fuente: Microsoft Corp. 2003. MOF: Service Level Management.
79
2. Descripción del servicio. a) Organización para la entrega del servicio. b) Disponibilidad del servicio. c) Manejo de cambios de servicio.
3. Niveles de servicio objetivos y medidas. a) Definición de la métricas de servicio. b) Definición de la manera en que será monitoreado el servicio. c) Definición de los reportes del servicio.
4. Costos del servicio. 5. Escalamiento.
Tomando en consideración lo señalado anteriormente, el proceso de gestión del nivel de servicio se define de la siguiente manera:
1. Levantar los requerimientos de servicio. 2. Definir el catálogo de servicios. 3. Definir los niveles de servicio requeridos por el negocio. 4. Monitorear el cumplimiento de los niveles de servicio. 5. Reportar al cliente los niveles de Servicios. 6. Revisar los acuerdos de nivel de servicio.
En la figura 29 se muestra la representación del flujo del proceso.
Figura 29: Proceso de gestión del nivel de servicio
80
2.4.3 Gestión de finanzas TI El objetivo de la gestión de finanzas es identificar, calcular y gestionar el costo de entregar servicios de tecnologías de información [26]. El proceso lo podemos dividir en tres subprocesos: elaboración del presupuesto, contabilización, facturación y cobro de los servicios. Anteriormente, se definió el proceso de presupuesto y el marco para el costeo de los servicios. La tarificación para el cobro, corresponderá a determinar el precio final que se facturará a los clientes. En este caso, como el objetivo es que la utilidad de la empresa de servicios debe ser igual a cero, la tarifa será el costo de los servicios percibidos por las empresas. Para simplificar y evitar el re cálculo diario de las tarifas, el costo de los servicios fijos, variables y de valor agregado, será calculado anualmente de acuerdo a la oferta de mercado disponible en ese momento. Las variaciones, que pueden representar pérdidas o utilidad serán absorbidas o invertidas para el siguiente periodo fiscal. Respecto a la contabilización, facturación y cobro de los servicios, la empresa utilizará las normas establecidas internamente por el holding, las que no se mencionan por encontrarse fuera del alcance de esta tesis. Como proceso, la gestión de finanzas se puede definir de la siguiente manera:
1. Recepción y contabilización de facturas de proveedores. 2. Prorrateo (si corresponde) de las facturas de proveedores. 3. Aprobación de pago facturas de proveedores. 4. Recopilación y valorización de las horas hombre trabajadas en servicios sujetos
a ese ítem de costo. 5. Elaboración de ítems de facturación para cada empresa que percibió servicios. 6. Facturación, de acuerdo a las normas establecidas internamente. 7. Cobranzas, de acuerdo a las normas establecidas internamente.
En la figura 30 se muestra la representación del flujo del proceso.
81
Figura 30: Proceso de gestión de las finanzas
2.4.4 Gestión de capacidad La gestión de capacidad, tiene por objetivo asegurar que la infraestructura tecnológica sea acorde a las demandas y crecimiento del negocio, a un costo justificable [26]. El proceso involucra, el monitoreo del rendimiento de los servicios y la infraestructura que los soporta, el análisis de los resultados del monitoreo, el tuning de los recursos, el pronóstico de acuerdo a la demanda y la confección de un plan de capacidad, conforme a los requerimientos de la empresa [18]. Existen tres ámbitos que han de ser abordados: la gestión de la capacidad del negocio, la gestión de la capacidad de los servicios y la gestión de la capacidad de los recursos [18].
2.4.4.1 Gestión de capacidad del negocio La gestión de la capacidad del negocio tiene relación con asegurar que los requerimientos futuros de servicio, sean considerados y entendidos y que la capacidad
82
requerida para soportarlos sea planificada e implementada, de acuerdo a la planeación que sea establecida [18]. Por lo tanto, el servicio TIC, debe proveer los mecanismos para:
1. Identificar los requerimientos de servicio y acordar niveles de servicio. 2. Diseñar la configuración para soportar el servicio. 3. Evaluar económicamente el requerimiento. 4. Implementar de acuerdo a las fechas establecidas.
Como parte del diseño organizacional, la función debe ser cubierta, mediante la relación directa con el cliente, es decir, con la toma de requerimientos del negocio y el aseguramiento de que los niveles de servicio comprometidos son cumplidos.
2.4.4.2 Gestión de capacidad de los recursos y servicios El objetivo de la gestión de capacidad de los servicios es, identificar y entender el uso de recursos, patrones de comportamiento y peaks, de los servicios, de manera tal, de asegurar que los niveles de servicio son cumplidos [18]. Por otro lado, la gestión de capacidad de los recursos, tiene relación con la identificación y comprensión de la utilización de cada componente de la infraestructura tecnológica. Lo que asegura, el uso optimo de los recursos de hardware y software, de manera tal de mantener y cumplir con los niveles de servicio acordados [18]. Derivado de lo anterior, es necesario entender, la composición tecnológica de cada servicio, con el objeto de definir un marco para las variables que han de ser consideradas para determinar la capacidad. En la tabla 16, se presenta dicha división. Hay que notar, que existen recursos tecnológicos comunes, que componen los servicios, estos son: servidores, computadores de escritorio (incluyendo notebooks), impresoras y dispositivos de comunicaciones y de red.
83
Tabla 16: Componentes tecnológicos de los servicios Para cada uno de los componentes señalados, se puede establecer, una serie de indicadores que describan su comportamiento, teniendo en consideración, que los SLA definidos tienen relación con la disponibilidad y cumplimiento de compromisos, de acuerdo al tipo de servicio. En estricto rigor, la variable de decisión, debiera reducirse a la disponibilidad, porque independiente del tipo de servicio, los recursos de tecnología son utilizados transversalmente y apoyan la consecución del cumplimiento de compromisos. Entonces, el problema se encuentra en determinar las variables que tienen directa relación con la disponibilidad del recurso tecnológico ya que la falta de capacidad para afrontar una demanda de uso, implica una no disponibilidad. En las tablas 17, 18 y 19 se han categorizado los recursos tecnológicos con sus correspondientes indicadores y
84
criterios para determinar la no disponibilidad. Los servidores y computadores de escritorio, se han agrupado ya que, los indicadores son los mismos, porque el sistema operativo que utilizan es de similares características.
Tabla 17: Indicadores de capacidad de servidores y PC12
12 Fuente: Documento Interno. 2005. Estudio de rendimiento de un sistema de ejecución de manufactura. Empresa Forestal. Chile.
85
Tabla 18: Indicadores de capacidad para impresoras
Tabla 19: Indicadores de capacidad de equipos de comunicación Respecto a la planeación de capacidad para afrontar una demanda de uso, hay que distinguir entre la proyección o pronóstico de uso frente a la predicción. La primera, tiene relación con la estimación del uso en el corto plazo, con el objeto de determinar acciones correctivas en el día a día y entregar tendencias de lo que está ocurriendo con el servicio. La segunda, se refiere al análisis del comportamiento del servicio y a la obtención de un modelo lo suficientemente repetible, para que frente a escenarios de carga distintos, se pueda predecir el comportamiento y por lo tanto, el establecimiento de planes, que permitan la adecuación del servicio, a la necesidades del negocio.
86
La proyección de la carga de trabajo, se puede realizar mediante técnicas de regresión lineal, promedios móviles y suavización exponencial. Se propone la utilización de la suavización exponencial ya que es simple y presenta menor varianza respecto a las otras técnicas. La predicción de la carga de trabajo, es determinada mediante modelos de simulación o modelos analíticos basados en redes de colas (queuing networks), los que se construyen de acuerdo al caso particular y que no se abordarán por encontrarse fuera del alcance de esta tesis.
2.4.5 Gestión de proveedores El objetivo de la gestión de proveedores es garantizar un uso eficiente de los proveedores de servicios internos y externos de TI, de acuerdo a los niveles de servicios comprometidos con el negocio [26]. En particular, se debe asegurar la calidad de la relación, evaluar y controlar el desempeño de acuerdo a criterios establecidos y cuantificables, mantener un inventario de proveedores y su impacto o relación con los servicios. Una de las premisas básicas de la empresa para su relación con los proveedores, es que la relación sea de largo plazo y con carácter de socio estratégico. Por ello la administración de proveedores, tiene que ver con el ordenamiento y homologación de los contratos de servicio que se encuentran distribuidos a través de todas las filiales y el cumplimiento de los niveles de servicio y contratos acordados. El marco general definido por la empresa, para la homologación, contempla que un contrato de servicios de terceros debe contener al menos:
a) Objeto del contrato. b) Especificación, precio, forma de pago y reajuste de los servicios. c) Cláusula de revisión de los servicios. d) Declaración de capacidad e idoneidad del tercero para proveer el servicio. e) Declaración de confidencialidad de la información. f) Responsabilidad por accidentes y daños y seguros. g) Declaración de cumplimiento de las normas de comportamiento, higiene y
seguridad de la empresa. h) Garantías. i) Vigencia del contrato. j) Condiciones de término del contrato. k) Cláusula de arbitraje. l) Modalidad de las comunicaciones para efectos del contrato. m) Oferta comercial del servicio. n) Niveles de Servicio.
Desde el punto de vista del proceso, las actividades propuestas son:
1. Establecer el contrato. a) Acordar servicios y tarifas. b) Firmar el contrato.
2. Administrar el contrato.
87
a) Realizar seguimiento a los niveles de servicio acordados. b) Realizar seguimiento al cumplimiento del servicio. c) Solicitar modificaciones a los servicios de acuerdo a lo que se estipule en
el contrato. 3. Gestionar el cumplimiento de los contratos de los proveedores.
a) Registrar el cumplimiento de acuerdo a las métricas propuestas en el diseño de servicios.
b) Comunicar a la organización el grado de cumplimiento. c) Elaborar ranking de proveedores de acuerdo a su comportamiento. d) Terminar el contrato de los proveedores que no tengan buen
comportamiento de cumplimiento de contrato. En la figura 31 se muestra la representación del flujo del proceso.
Figura 31: Proceso de Gestión de Proveedores Con lo anterior, se estableció un marco del proceso para la administración de proveedores, donde el supuesto era que los proveedores son externos. Por otro lado, ITIL plantea además la gestión de proveedores internos, es decir, cada área de la organización es un receptor y proveedor de servicios de una o más áreas. El objetivo final es establecer niveles de servicio operacionales (Operational Level Agreement, OLA), de manera tal que los servicios entregados por la organización se encuentren dentro de los niveles comprometidos con los clientes.
88
En principio, los OLA debieran ser los mismos indicadores definidos en los SLA, pensando en que el cumplimiento promedio particular de los niveles asegura el cumplimiento global. Sin embargo, de acuerdo a la tabla 20, existen diferencias entre ambos conceptos que deben ser consideradas.
Tabla 20: Diferencias entre SLA y OLA13 Para el caso de los servicios variables y de valor agregado se puede utilizar el mismo indicador de SLA como OLA, ya que están orientados al cumplimiento de compromisos de personas, entre el cliente y el servicio. Pero, para los servicios fijos es necesario especificar OLA particulares, pensando en que en algunos casos se trata de hardware, sobre el cual se pueden realizar operaciones de incorporación, cambio y reparación de elementos de servicio. Entonces, definiremos tres tipos de OLA:
1. OLA de Incorporación, como el nivel de servicio con que se incorporaran elementos nuevos al servicio.
2. OLA de Cambio, como el nivel de servicio con que se cambian las configuraciones del servicio.
3. OLA de Reparación, como el nivel de servicio con que se realizan las reparaciones o reposiciones a los servicios.
Los OLA definidos, son presentados en la tabla 21.
13 Fuente: Microsoft Corp. 2003. MOF: Service Level Management.
89
Tabla 21: OLA para servicios fijos
90
2.5 Procesos de gestión de la infraestructura y seguridad
2.5.1 Gestión de infraestructura La gestión de la infraestructura está definida como un conjunto de procesos, en los que se aborda el (la) [26]:
a) Diseño de la infraestructura y planificación estratégica, es decir la creación y/o mejoramiento de soluciones a través del tiempo, basado en una estrategia de largo plazo.
b) Deployment, relacionado con la implementación y puesta en marcha de las soluciones tecnológicas y del negocio.
c) Operación, es decir, actividades diarias de soporte y mantenimiento de la infraestructura.
d) Soporte técnico, consistente en la estructuración y apoyo a otros procesos para garantizar la entrega del servicio.
Los procesos de soporte técnico y deployment, han sido abordados anteriormente. El primero, como parte del escalamiento en la gestión de incidencias y de problemas y el segundo como el proceso de paso a producción definido en la gestión del cambio, por lo tanto no se revisará. Respecto al diseño y planificación, existen dos aspectos a considerar, primero el relacionado con los modelos de administración y arquitectura que sean más adecuados a las necesidades del negocio, y el segundo a la creación y/o mejoramiento de las soluciones, es decir, el desarrollo de proyectos de infraestructura, que a diferencia del software, son más simples ya que no hay construcción de aplicaciones, solo parametrización de productos, pero complejos en cuanto a la integración a la plataforma. Las actividades propuestas, para un proyecto de infraestructura son:
1. Levantamiento de necesidades. 2. Determinar la solución y la evaluación técnico-económica. 3. Aprobación de la solución por parte del comité de TI. 4. Realización del proyecto de infraestructura.
a) Realizar la ingeniería de detalle. b) Construir la solución. c) Determinar el plan de pruebas. d) Gestionar los riesgos del proyecto. e) Realizar pruebas.
5. Puesta en productivo (integración a la plataforma). En la figura 32 se muestra la representación del flujo del proceso.
91
Figura 32: Actividades generales de un Proyecto de Infraestructura Desde el punto de vista del modelo de gestión, es útil considerar una jerarquización de los elementos que se pueden abordar, de manera tal de establecer las capas fundamentales sobre las que se desarrolla la gestión de la infraestructura. De acuerdo a la figura 33, los elementos de gestión se encuentran divididos, desde lo operativo a lo táctico, en actividades de operación, control y monitoreo, administración de seguridad y administración de infraestructura.
Figura 33: Jerarquización de las actividades de Infraestructura14
14 Fuente: Microsoft Corp. 2005. MOF: Network Administration.
92
2.5.1.1 Administración de la Infraestructura Para administrar la infraestructura, existen cinco modelos básicos de administración [20]:
a) Datacenter centralizado y administración centralizada. b) Datacenter distribuido y administración centralizada. c) Datacenter distribuido y administración centralizada / delegada. d) Datacenter distribuido y administración distribuida. e) Administración de tipo “follow the sun”, es decir datacenters distribuidos entre
distintas localidades geográficas en el mundo, donde la administración y la operación es transferida entre cada unidad de acuerdo a horarios diurnos de trabajo.
El modelo más apropiado es tener una gestión centralizada y datacenters distribuidos, de acuerdo a la disponibilidad de servicios requerida por los negocios. La ventaja de una gestión centralizada, es que se mantiene el control general de la plataforma, se producen ahorros ya sea por cantidad de personas, licencias y consolidación. Sin embargo, puede haber operaciones que requieran la intervención local. Para ello, en vez de delegar la administración la actividad puede ser ejecutada por un técnico en terreno y supervisada por un administrador central. Los servicios de infraestructura son los relacionados con las funcionalidades básicas de red y aplicaciones, las que son descritas en la tabla 22.
Tabla 22: Descripción de los servicios de infraestructura Respecto a la arquitectura de provisión de servicios y considerando que el holding es distribuido geográficamente, conviene definir, un criterio para decidir entre lo que se encontrará centralizado y lo que será particular a cada localidad. La centralización debe ocurrir cuando más de dos empresas tengan necesidades equivalentes y no haya impedimento para la operación normal, es decir, que frente a perdidas de servicio, no se paralice una empresa. Los servicios localizados deben permitir autonomía de manera tal, que frente a pérdidas del servicio WAN, no se vean afectados los procesos de negocio y los servicios básicos de red de la empresa cliente.
93
Finalmente, la administración de la infraestructura define las políticas y estándares, con el fin de normar y establecer lineamientos y entradas claras al proceso de planeación estratégica, respecto a:
a) La arquitectura y diseño técnico de las soluciones de hardware, para los proyectos de software.
b) Equipamiento a utilizar de acuerdo al tipo de aplicación, ambiente, o software. c) La administración de las comunicaciones, en cuanto a reglas de tráfico,
priorización, disponibilidad y recuperación. d) El uso de software para proteger el equipamiento, por ejemplo: antivirus,
antispyware, etc. e) La política de respaldo y recuperación de la información.
2.5.1.2 Administración de la Seguridad La administración de seguridad se revisará más adelante, en el proceso de gestión de seguridad.
2.5.1.3 Monitoreo y Control de Servicios El monitoreo y control de servicios corresponderá a la revisión periódica de indicadores relacionados con los servicios de infraestructura [24]. Para ello es conveniente utilizar software que permita realizar la actividad automáticamente, generando alarmas dirigidas al administrador cuando algún indicador se encuentre fuera de rango por un cierto periodo de tiempo. El administrador deberá realizar las acciones que re-establezcan la operación normal, de acuerdo a los procedimientos de operación que se definan. Las variables de monitoreo pueden ser clasificadas en las que son propias del servicio y las que son propias del servidor en donde es ejecutado dicho servicio. Por la extensión del tema, no se revisarán las variables de los servicios. Sin embargo, a modo de ejemplo, en la tabla 23, se presenta, una definición de las variables típicas de monitoreo de un servidor bajo ambiente Windows y sus umbrales de operación. Cabe señalar, que las variables definidas constituyen una descomposición de servicios, que es requerida, para gestionar la capacidad, por lo tanto son una entrada a dicho proceso.
94
Tabla 23: Variables de monitoreo de un servidor15
2.5.1.4 Actividades de Operación La operación de la infraestructura corresponde a las actividades diarias de administración, soporte y mantenimiento de los servicios. En la tabla 24, se proponen las actividades que debieran ser habituales.
Tabla 24: Actividades de operación habitual de la infraestructura16 Cada una de las actividades mencionadas, debe estar asociada a procedimientos con el fin de asegurar que sean prácticas que se realicen a través del tiempo. Para los
15 Fuente: Documento Interno. 2005. Estudio de rendimiento de un sistema de ejecución de manufactura. Empresa Forestal. Chile. 16 Fuente: Microsoft Corp. 2002. MOF: System Administration.
95
productos Microsoft y Oracle, existen guías ya definidas, las que se pueden encontrar en los sitios web de dichas compañías.
2.5.2 Gestión de seguridad El objetivo de este proceso es la definición, control, gestión e implantación de las políticas de seguridad definidas para las aplicaciones (software) e infraestructura [26]. Dentro del holding, la seguridad solo ha sido abordada desde el punto de vista de acceso desde redes externas, mediante la definición de políticas y la implementación de dispositivos firewall. Por lo tanto no existe desarrollo previo. Como primer paso, se puede establecer un marco para la gestión de la seguridad y cuyo resultado sea el establecer la visión, los mecanismos de control, las revisiones y las políticas. En ese sentido, el proceso, que debe ser parte de la administración de la infraestructura, es continuo en el tiempo. Para el caso de las aplicaciones, las áreas de mantenimiento y de desarrollo de software, deben incorporar las políticas de seguridad como un requisito funcional más y deben entregar herramientas de administración de perfiles para acceder a las funcionalidades y los datos. Entonces, para la gestión de seguridad, se propone el siguiente marco:
1. Establecer una política de seguridad para la organización. a) Acordar una visión compartida de la seguridad y el compromiso de los
terceros relevantes. b) Identificar los requerimientos de seguridad de la organización. c) Identificar los niveles de seguridad para los datos de la organización. d) Implementar revisiones periódicas de la política de seguridad.
2. Establecer un proceso de gestión de riesgos de seguridad. a) Determinar los mecanismos de control de la seguridad. b) Revisar periódicamente los riesgos de seguridad. c) Implementar los mecanismos de control.
3. Establecer un proceso de monitoreo y auditoria de la seguridad. a) Identificar ataques potenciales y problemas de seguridad. b) Identificar debilidades de los sistemas periódicamente. c) Entregar reportes periódicos de los problemas encontrados.
4. Establecer un proceso de respuesta frente a incidentes. El desarrollo de las políticas y los mecanismos de control han de ser definidos una vez que el área respectiva comience a funcionar. De todas maneras, se propone abordar los siguientes puntos como agenda inicial:
1. Definir y establecer la política de seguridad de la organización. 2. Definir la política de seguridad de aplicaciones.
a) SAP. b) no SAP.
96
c) Shop Floor (Piso planta). 3. Definir la política de seguridad del hardware.
a) Dispositivos de red. b) Servidores. c) PC y notebooks. d) PDA. e) Impresoras.
4. Implementar las políticas de seguridad definidas. Una vez realizadas las actividades, se propone la aplicación del proceso marco definido para la gestión.
97
Capítulo 4 – Organización
1. Estructura Organizacional. Las organizaciones son grupos de personas que buscan el logro de un propósito común. Esto se consigue a través de la segmentación o división del trabajo [11]. Para este caso, la estructura organizacional a definir debe ser capaz de soportar los servicios y procesos mencionados en el capitulo anterior. Sin embargo, se presentan inconvenientes adicionales a ser considerados. Un primer problema es la distribución geográfica de las plantas, personal y oficinas del holding. Los focos de localización son: En Chile:
a) Antofagasta, con oficinas comerciales. b) Coquimbo, con oficinas comerciales. c) Santiago, con plantas productivas, oficinas centrales y de filiales del holding. d) Talca, con plantas productivas y oficinas comerciales. e) Concepción, con oficinas de filiales. f) Temuco, con oficinas comerciales. g) Los Ángeles, con oficinas de filiales. h) Nacimiento, con plantas productivas.
En el extranjero:
a) Perú, con plantas productivas. b) Argentina, con plantas productivas. c) Uruguay, con plantas productivas. d) Brasil, con una oficina comercial. e) México, con plantas productivas.
Un segundo elemento relevante es considerar las funciones básicas de TI, que en términos generales, se puede decir que son las siguientes:
a) Gestión de la relación comercial con el cliente. b) Servicio al cliente. c) Desarrollo de proyectos de software. d) Mantención de software. e) Soporte a usuarios. f) Gestión de la infraestructura TI. g) Gestión de la calidad.
Un tercer punto, es referente a la integración y multiplicidad de los negocios del holding, los que están agrupados por divisiones de negocio y que en su conjunto definen una cadena de valor.
98
Culturalmente, existen limitantes en cuanto al enfoque con que las decisiones son tomadas. La manera de funcionamiento del holding es altamente jerarquizada, las decisiones son tomadas por Gerentes y Subgerentes. Por lo tanto, desde la perspectiva de orientación al cliente y la oportunidad del servicio, supone un problema ya que en un esquema de servicios, lo esperado es que las personas sean capaces de tomar sus propias decisiones de acuerdo a un marco de atribuciones funcionales.
1.1 Primer nivel organizacional El primer nivel de gestión, tiene relación con las funciones básicas de tecnologías de información, vale decir: relación comercial con el cliente, servicio al cliente, proyectos de software, mantención de software, soporte, infraestructura y calidad. Esto nos lleva a las siguientes opciones de organización para el primer nivel. Opción 1: 1 Gerencia y 6 Subgerencias funcionales. De acuerdo a la figura 34, bajo esta opción, se tienen seis subgerencias: calidad, relación comercial con el cliente, servicio al cliente, proyectos, infraestructura y mantención. En el caso de soporte, es claro que puede ser integrada bajo la función de servicio al cliente, básicamente porque es un servicio que impacta directamente al usuario final en cuanto a la satisfacción de requerimientos básicos relacionados con herramientas informáticas.
Figura 34: Organigrama general, opción 1 Un problema de esta organización es por un lado, la cantidad de subgerencias y por otra el tener dos unidades organizativas para atacar el problema de los procesos de software: proyectos y mantención, las que a nivel de procesos son equivalentes. Esto lleva a concluir, que podría ser mejor tener una sola unidad que se haga cargo, vale decir, que desde el punto de vista funcional gestione los proyectos de software y realice las mantenciones, con el benefició de que todo el ciclo de vida del producto de software se mantiene bajo una sola responsabilidad. De aquí es que, a continuación, se propone la opción 2. Opción 2: 1 Gerencia y 5 Subgerencias funcionales Esta opción, presentada en la figura 35, plantea tener 5 unidades funcionales: calidad, relación comercial con el cliente, servicio al cliente, software, e infraestructura. La unidad o subgerencia de software se hace cargo de los proyectos de software y las
99
mantenciones, por lo que, tal como se dijo anteriormente, el ciclo de vida del producto se mantiene bajo una sola responsabilidad.
Figura 35: Organigrama general, opción 2 Sin embargo, esta organización tiene el siguiente problema, por ejemplo, si hubiera un proyecto en el que no solamente sea software el involucrado, si no que hay otros elementos y entidades de la organización que participan, ¿de quién es la responsabilidad? La respuesta no es clara. Posiblemente se podría normar la responsabilidad con un procedimiento, pero semánticamente no sería entendido por los clientes. Una manera de resolver el problema, es pensar en que el mantenimiento surge como un requerimiento de cambio, por parte de un usuario, para un producto de software que se encuentra en funcionamiento y que la línea de tiempo para realizar las adecuaciones es de corto plazo. Bajo este enfoque, se puede decir que la mantención es un servicio que impacta directamente la expectativa del usuario, por lo tanto, debiera ser tratada bajo ciertas condiciones que manejen dicha variable. En ese sentido, sería razonable incorporar el mantenimiento de corto plazo como parte de la función de servicio al cliente, por la integración con la mesa de ayuda (que recibe el requerimiento) y por el directo impacto sobre el usuario final. Para el caso de proyectos, es claro que debe ser una unidad funcional aparte, que considere no solamente los aspectos de software nuevo, sino que también, lidere los proyectos de manera integral, e incorpore los proyectos de mantención (mantenciones de largo plazo) como unidad especializada. Una restricción que ha impuesto la empresa, es no incorporar en esta etapa una unidad funcional de calidad. La decisión, se basa en que sería más aprovechable esperar a que la organización se encuentre en régimen por uno o dos años, antes de pensar en abordar el tema durante el proceso de cambio. En todo caso, en el capítulo 6, se plantea un plan de mejora de software, cuya conclusión final plantea la creación de una unidad funcional de calidad. Por otro lado, es necesario incorporar la función de finanzas TI, que en este caso juega el rol de controlar la gestión del área, facturar servicios y administrar contratos, por lo tanto debe ser parte del staff del Gerente. Todo esto nos lleva a la opción 3, que se describe a continuación.
100
Opción 3: 1 Gerencia y 4 Subgerencias funcionales De acuerdo a la figura 36, bajo, esta opción, las funciones se han agrupado y simplificado. Básicamente, se tiene la relación comercial con el cliente, servicio al cliente, proyectos, e infraestructura. No existe la función de calidad.
Figura 36: Organigrama general, opción 3 De las opciones planteadas, la que más ventajas tiene, en términos de simpleza y agrupación de funciones, es la opción 3. Por lo tanto es la que se utilizará para la organización de TI.
1.2 Segundo, tercer y cuarto nivel organizacional Los siguientes niveles organizacionales tienen un carácter táctico-operativo, que son los que finalmente entregan el servicio a las empresas. Aparentemente, resulta más fácil plantear una organización por división de negocio, sin embargo esto es una limitante ya que el personal debe especializarse y focalizarse en dichas divisiones, lo que desde el punto de vista de gestión de recursos limita la posibilidad de redistribuir en caso de ser necesario, entonces, la especialización por negocio no es beneficiosa. Otra opción es aprovechar la distribución geográfica del holding. Podemos distinguir las siguientes zonas:
a) Chile Zona Centro, que comprende, Santiago y las oficinas comerciales del norte del país.
b) Chile Zona Sur, que comprende, Talca, Concepción, Temuco, Los Ángeles y Nacimiento.
Para el extranjero, es natural pensar agrupar Argentina con Uruguay, Perú con Brasil y México aparte. La agrupación por zonas geográficas, resulta más conveniente ya que tiene la facilidad de que la función de TI no se ve afectada por la especialización en una división y permite orientarse a los clientes y los procesos que son transversales al holding de empresas.
101
En consecuencia, la organización para las subgerencias que tienen directa relación con los usuarios, es decir relación comercial y servicio al cliente, se planteará geográficamente. En el caso de proyectos e infraestructura, se pueden considerar como unidades centrales de apoyo y servicios. Por lo tanto la especialización puede plantearse por procesos y/o tecnologías relevantes.
1.2.1 Subgerencia Relación Comercial Cliente En el caso de esta subgerencia, la agrupación se ha realizado por zona geográfica, incorporando jefaturas de zonas: centro, sur, e internacional. Además, se incorpora un recurso de staff de la subgerencia, encargado de la planificación global y gestión del servicio, lo que se puede visualizar en la figura 37.
Figura 37: Organigrama subgerencia relación comercial cliente Las funciones que debe desempeñar esta unidad son las siguientes:
a) Planificación del Servicio TIC. b) Administración de los Niveles de Servicios. c) Toma de requerimientos y expectativas de los clientes. d) Entrega a los clientes de los planes y servicios de TIC con la calidad
requerida y acordada con el Negocio.
102
Las responsabilidades son:
a) Ser el representante de TI ante las filiales del holding, ser el representante de las filiales del holding ante la gerencia de servicio TI.
b) Definir, mantener y difundir los servicios, a través de un catálogo de servicios. c) Velar por mantener una relación equilibrada entre las demandas de los
clientes y el costo del servicio. d) Definir, negociar, seguir y reportar los acuerdos de nivel de servicio con los
clientes. e) Definir, negociar y recopilar los acuerdos de nivel operacional con las
unidades de TI. f) La mejora continua de los servicios. g) La planificación de los servicios y del seguimiento de este plan. h) Identificar, capturar, especificar, evaluar y canalizar los requerimientos de los
clientes respecto de nuevos servicios o funcionalidades de los sistemas de información.
i) Actuar como representante del negocio en la evaluación de impactos de cambios que se produzcan en la infraestructura TIC y sus servicios.
j) Mantener el inventario y configuración de los ítem relacionados a los acuerdos de nivel de servicio y planificación.
k) Proveer información necesaria de la prestación del servicio TI a control de gestión TI.
l) Análisis de impacto al negocio ante desastres que afecten los servicios TI. m) Invocación de planes de contingencia y la relación con las unidades de
negocio ante un desastre que afecte los servicios TI. n) Representar al servicio, junto con el Gerente TI. o) Evaluar el desempeño de los proveedores de TI respecto de su impacto en el
servicio TI.
1.2.2 Subgerencia Servicio al Cliente Servicio al cliente cuenta con la mesa de ayuda (service desk), que entrega los servicios de soporte de primer, segundo nivel y aplicaciones. Se hace la distinción entre aplicaciones SAP y el resto ya que SAP es el ERP de carácter corporativo, por lo tanto se ha incorporado esta figura a la estructura. Soporte consta de técnicos de terreno que atienden los requerimientos de los usuarios que les hayan sido derivados desde la mesa de ayuda. Nuevamente, el primer criterio para organizar es la zona geográfica ya que se tiene un directo impacto sobre los usuarios. El área de mantención, se encarga de las mantenciones de corto plazo, consta del analista de demanda y divisiones por zonas geográficas, salvo SAP que es de carácter corporativo. En la figura 38 se muestra la representación de la subgerencia.
103
Figura 38: Organigrama subgerencia de servicio al cliente Las funciones de la subgerencia son:
a) Atención de usuarios (Service Desk). b) Administración de incidencias. c) Control y distribución de software y hardware. d) Mantención de corto plazo de aplicaciones. e) Administración de servicios y soporte local.
Las responsabilidades son:
a) Proveer de un punto único de contacto entre el servicio y sus usuarios, el cual atienda los requerimientos de soporte referente a los servicios TI.
b) Responsable de recomendar y asesorar a la unidad de relación comercial con el cliente de los niveles de servicios que pueden ser acordados para la atención, soporte a usuarios y mantenimiento de aplicaciones.
c) Responsable de proveer mecanismos de escalamiento eficiente que permitan el cumplimiento de los niveles de servicios establecidos para la atención de incidencias.
d) Responsable del seguimiento, control y cumplimiento de los niveles de servicios relativos al soporte a usuario, mantenimiento de aplicaciones y seguridad informática.
e) Reporta los niveles de servicios alcanzados por la unidad a la unidad de relación comercial con el cliente.
f) Difundir los servicios TI ante los usuarios.
104
g) Responsable del soporte local de los servicios TI en cada una de las empresas del holding.
h) Responsable de encontrar soluciones de fondo ante incidencias repetitivas o cuya causa raíz es desconocida.
i) Responsable de la mejora continua del servicio de atención de usuarios, soporte local, mantenimiento de aplicaciones.
j) Responsable de la planificación del servicio de atención y soporte de usuarios y del seguimiento de este plan.
k) Responsable de la planificación del servicio de mantenimiento de aplicaciones y del seguimiento de este plan.
l) Responsable de mantener el inventario y configuración de los ítem relacionados a la atención de usuarios, soporte de usuarios, mantenimiento de aplicaciones.
m) Responsable de proveer información necesaria de la prestación del servicio a los usuarios a control de gestión TI.
n) Responsable de canalizar las solicitudes de cambio a través del servicio de atención a usuarios.
o) Responsable de la implementación, de acuerdo a los procedimientos establecidos de la plataforma tecnológica de uso de los usuarios, cumpliendo los niveles de servicios establecidos.
p) Gestionar los proveedores TI relacionados con las funciones de la unidad de Servicio al Cliente.
q) Ser el apoyo local de Proyectos e Infraestructura.
1.2.3 Subgerencia de Proyectos Para la subgerencia de proyectos, el criterio de división es respecto a tecnologías y/o procesos asociados. Se distinguen los siguientes:
a) Software general, unidad encargada de realizar proyectos que no caben en las categorías de especialización definidas, por ejemplo: sitios webs, aplicaciones forms, visual basic, etc.
b) Integración, unidad encargada de realizar proyectos relacionados con software middleware, vale decir que integra distintos tipos de sistemas o capas dentro de una arquitectura.
c) Automatización, unidad encargada de realizar proyectos relacionados con la automatización de plantas productivas, vale decir: sistemas de ejecución de manufactura, control automático, gestión de procesos de plantas, etc.
d) Inteligencia del negocio, unidad encargada de realizar proyectos de tipo data warehouse, gestión de la información, minado de datos, etc.
e) SAP, unidad encargada de realizar proyectos SAP, vale decir, se encarga de los proyectos sobre el ERP de la compañía.
f) Mantenimiento, unidad encargada de realizar los proyectos de mantención. De acuerdo a la figura 39, la estructura es de Jefes de Proyecto con su respectivo equipo de Ingenieros de Proyecto, sin embargo, dado el tamaño del holding, es necesario colocar un nivel que agrupe a los jefes de proyecto según su especialización, para ello se definen los Project Manager o Gestores de Proyectos, cuya labor es la
105
gestión y control global de la cartera de proyectos del área de especialización. Además, se contempla una unidad de control y planificación, la que se encarga de realizar el seguimiento global de los proyectos y la asignación de recursos al portafolio.
Figura 39: Organigrama subgerencia de proyectos En la figura 40, se plantea una variante para el nivel de Project Manager, que es desligar la especialización respecto de las actividades de gestión. Para ello se puede definir un spool, que independiente de la especialidad, sea capaz de gestionar y controlar los proyectos, dejando la componente técnica al jefe de proyecto. Con esto se logra una mejor movilidad de recursos dedicados a la gestión.
Figura 40: Organigrama alternativo de la subgerencia de proyectos Para el servicio que se ha definido, la empresa ha pedido, no separar la especialización de la gestión debido al carácter jerárquico de la organización, dejando esta mejora para una implementación posterior.
106
Las funciones de esta subgerencia son:
a) Selección de paquetes de software. b) Implementación de paquetes de Software. c) Desarrollo de software. d) Definir la arquitectura de aplicaciones. e) Soporte especializado ante problemas. f) Desarrollo e implementación de soluciones de software de soporte a la
Inteligencia de Negocio y Automatización. g) Planificación y gestión integral de Proyectos.
Las responsabilidades son:
a) Establecer las normas generales para la Administración de Requerimientos de proyectos y las responsabilidades de cada uno de los entes involucrados.
b) Asegurar la administración y el control de los requerimientos de software a lo largo del ciclo de vida de los proyectos de implementación y desarrollo.
c) Asegurar la participación y compromiso de los grupos involucrados. d) Establecer las normas generales que rigen la Administración de
Configuraciones de Software. e) Establecer y mantener la integridad y consistencia de los productos de
software a través de todo el ciclo de vida de los proyectos de software. f) Establecer las normas generales para la planificación general de proyectos de
software y las responsabilidades de cada uno de los entes involucrados. g) Minimizar los riesgos de la planificación proporcionando confiabilidad
respecto de las estimaciones y de la programación de actividades. h) Asegurar la participación y compromiso de los grupos involucrados. i) Establecer las normas generales para la administración de los subcontratistas
y proyectos de software subcontratados y las responsabilidades de cada uno de los entes involucrados.
j) Normar la contratación de subcontratistas de software, asegurando una eficiente administración de estos y los proyectos que le son asignados.
k) Establecer las normas generales para realizar el seguimiento y control de software y las responsabilidades de cada uno de los involucrados.
l) Establecer acciones preventivas con el fin de evitar desviaciones en el plan de proyecto y/o correctivas si existe una desviación de lo planificado versus lo real.
m) Entregar una visión del avance real de los proyectos a la gerencia TI y usuarios involucrados.
n) Asegurar a la organización el cumplimiento del Proceso de Desarrollo e Implementación de Software.
o) Establecer las normas generales para garantizar la calidad de los productos de software y las responsabilidades de cada uno de los entes involucrados en el desarrollo y la implementación de estos.
p) Definir y utilizar los estándares que regirán el desarrollo e implementación de software.
q) Realizar mantenciones de software de largo plazo, bajo la modalidad de proyectos.
107
1.2.4 Subgerencia de Infraestructura Primero, hay notar que las actividades de administración y operación son desarrolladas centralizadamente. Si se requiere la intervención directa a algún equipo se utiliza como apoyo el técnico de terreno de soporte. Debido a lo anterior, no vale la pena pensar en una organización basada en la distribución geográfica. Sin embargo, las responsabilidades si podrían ser de ese modo, por ejemplo, la administración de sistemas, puede ser dividida en las mismas zonas geográficas, pero el personal puede ir rotando con el fin de que tengan conocimiento general de las plataformas. De acuerdo a lo propuesto en la figura 41, para la subgerencia de infraestructura se considera una división clásica, vale decir:
a) Operaciones, que se encarga de la operación de los sistemas, ejecución de procesos batch, etc.
b) Redes, que se encarga de la administración de redes WAN y LAN, además de la telefonía.
c) Ingeniería, unidad que realiza la ingeniería de sistemas y la administración de servidores. Se encuentra dividida en: bases de datos, sistemas unix y sistemas windows.
d) Seguridad, que define y aplica las políticas de seguridad en cuanto a aplicaciones, acceso a servidores y perimetral.
Figura 41: Organigrama subgerencia de infraestructura Las funciones definidas para la subgerencia son las siguientes:
a) Diseño y planificación de plataforma computacional. b) Administración y operación de la plataforma computacional y software del
negocio. c) Pasos a producción de aplicaciones e infraestructura TI. d) Gestión de cambios de la infraestructura TI.
108
e) Administración de bases de datos. f) Administración de la seguridad. g) Administración de servidores. h) Sintonía de la plataforma computacional. i) Asesoría especializada. j) Resolución de incidentes de la plataforma computacional central o crítica. k) Diseño y planificación de la infraestructura de telecomunicaciones.
Las responsabilidades son:
a) El monitoreo, soporte a soluciones y escalamiento de los recursos computacionales servidores, redes, sistemas operativos y aplicativos de negocio.
b) Diseñar y Planificar la infraestructura de soporte a los servicios TI. c) Definición de los estándares de Implementación apropiados para las
soluciones de infraestructura TI en el ambiente productivo. d) Implementación de las soluciones desarrolladas o adquiridas para el negocio
y/o TI, con una mínima interrupción de los procesos de negocio. e) Proveer una plataforma TI estable y segura, disponible a ser usada como un
soporte fundamental para la provisión de servicios en beneficio del negocio. f) Mantener y operar de manera eficiente y efectiva los procedimientos
operacionales de la infraestructura TI, asegurando que todos los servicios y componentes de TI reúnan los objetivos y requerimientos que satisfacen al negocio.
g) Entregar un soporte y asesoramiento especializado para la adquisición y utilización de la infraestructura TI que dan soporte a los servicios.
h) Gestión, seguimiento y control de los proveedores de infraestructura y servicios bases computacionales.
i) Gestión, seguimiento y control de la seguridad informática. j) Proveer las capacidades y disponibilidades necesarias en la infraestructura y
aplicaciones de TI para el cumplimiento de los SLA. k) Responsable de la existencia de planes de recuperación ante desastre que
puedan afectar los servicios TI soportados por la plataforma computacional. l) Provisión, mantención y administración de la infraestructura de
telecomunicaciones acorde a las exigencias de los aplicativos de negocio.
2. Definición de Cargos De la estructura organizacional definida en el punto 1 de este capítulo, se presenta la definición de los cargos.
2.1 Gerencia de Servicios TIC Gerente de Servicios TIC Es el responsable máximo de la entrega del servicio TIC a cada una de las empresas del holding.
109
Jefe de Finanzas y Control de Gestión Responsable del control, soporte y seguimiento del presupuesto TIC. Revisa aspectos contables, tiene a cargo la facturación y cobro de los servicios.
2.2 Subgerencia de Relación Comercial Subgerente Relación Comercial Es el responsable de la definición, planificación, seguimiento y control del servicio TIC ante los clientes. Service Manager Responsable de la entrega del servicio TIC, su planificación y resultados en el ámbito de la zona o empresas que representa. Canaliza los requerimientos de los clientes de manera eficiente y efectiva a través de la organización de servicios TIC. Ingeniero de Planificación y Gestión del Servicio Apoya las funciones del Subgerente y de cada uno de los Service Manager en la planificación de la entrega del servicio. Responsable del soporte al seguimiento de los niveles de servicio.
2.3 Subgerencia de Servicio al Cliente Subgerente de Servicio al Cliente Responsable del funcionamiento eficaz y eficiente del área de servicio al cliente, acorde a los requerimientos del negocio y a un costo justificable. Jefe de Soporte y Mesa de Ayuda Responsable de la implantación, revisión y funcionamiento del proceso de incidencias y problemas y del soporte local. Jefe de Soporte Zonal Responsable de los procesos y funcionamiento del soporte de segundo nivel, incluyendo el seguimiento y solución de problemas y errores conocidos. Se preocupa de que los incidentes no solucionados por el service desk, sean solucionados, investigados y evitados.
110
Técnico de Terreno de Soporte Responsable de entregar apoyo a los procesos y funcionamiento del soporte de segundo nivel, incluyendo el seguimiento y solución de problemas y errores conocidos. Se preocupa de que los incidentes que no soluciona el service desk, sean solucionados, investigados y evitados. Ingeniero de Soporte Responsable de entregar apoyo y coordinar los procesos y funcionamiento del soporte de segundo nivel, incluyendo el seguimiento y solución de problemas y errores conocidos. Se preocupa de que los incidentes que no soluciona el service desk, sean solucionados, investigados y evitados. Jefe de Mantención Responsable del servicio de mantención de aplicaciones. Jefe de Mantención Zonal/SAP Responsable del control y planificación del proceso de mantención de aplicaciones. Analista de Demanda Responsable del soporte a la gestión, asignación y control del mantenimiento de las aplicaciones. Analista de Aplicaciones Responsable del soporte al análisis, diseño, modificación y construcción de aplicaciones de negocio o implantación de paquetes comerciales. Ingeniero de Mantención Responsable del análisis, diseño y construcción de aplicaciones de negocio o implantación de paquetes comerciales.
2.4 Subgerencia de Proyectos Subgerente de Proyectos Responsable del funcionamiento del área de proyectos, se encarga de gestionar las personas, recursos y procesos de manera eficiente. Project Manager Responsable de la gestión de proyectos de desarrollo, e implementación de aplicaciones y paquetes comerciales.
111
Jefe de Proyectos Responsable del análisis, diseño y construcción de aplicaciones. Se preocupa de la implementación de paquetes comerciales. Ayuda a los clientes a identificar problemas y soluciones. Ingeniero de Proyectos Responsable de la ejecución de los procesos de desarrollo, mantención, e implementación de software. Ingeniero de Control y Planificación Responsable de apoyar las labores de asignación de recursos, seguimiento y control de los procesos de desarrollo e implementación de software, arquitectura y plataforma SAP.
2.5 Subgerencia de Infraestructura Subgerente de Infraestructura Responsable de la definición, planificación, coordinación, diseño y funcionamiento de la infraestructura informática de la organización. Gestiona personas, recursos y procesos de manera eficiente. Jefe de Operaciones Responsable de la operación de la plataforma informática. Coordina y diseña la infraestructura, establece políticas y documentación necesaria. Jefe de Redes Responsable de la coordinación con proveedores y diseño de la infraestructura de redes de la organización. Jefe de Ingeniería Responsable de la coordinación con proveedores y diseño de la plataforma de la organización. Jefe de Seguridad Informática Responsable de la definición y seguimiento de las políticas de seguridad al interior de la organización.
112
Analista de Seguridad Responsable de ejecutar las actividades necesarias para cumplir con las políticas de seguridad. Operador de Sistemas Responsable de la operación, mantenimiento y control de los activos informáticos. Administrador de Red Administra y coordina los cambios sobre la plataforma de redes de la organización. Realiza labores de optimización. Administrador de Base de Datos Administra y coordina los cambios sobre la plataforma de base de datos de la organización. Realiza labores de optimización. Ingeniero de Sistemas Responsable del diseño, planes y estrategias de implementación de una plataforma de acuerdo a las necesidades de la organización.
113
Capítulo 5 – Implementación, transición y cambio
1. Plan de implementación, transición y cambio Para la implementación del servicio, un primer aspecto a considerar es la cultura organizacional. El holding, se caracteriza por su carácter jerárquico, donde prácticamente todas las decisiones son validadas o tomadas por los Gerentes o Subgerentes de área. Esto es contrapuesto con un esquema de servicios ya que es él cliente quien define lo que necesita y en muchas ocasiones no hay tiempo para recurrir al Gerente o Subgerente para que valide o decida sobre una determinada acción. Este problema, se ve aminorado por la definición y el marco de los procesos, sin embargo, es necesario convencer a las personas para que adopten un nuevo enfoque para la atención de los requerimientos de los usuarios. Los servicios entregados por la filial de servicios compartidos, son transversales a las empresas y por lo tanto requieren de un trabajo de colaboración más que jerárquico entre las diferentes unidades. Otro elemento a considerar es que la alta dirección ha pedido, que durante el periodo de transición, las filiales que reciben servicios de TI no sufran impacto por el cambio. Por lo tanto, el plan de implementación, transición y cambio debe considerar aspectos culturales, de operación actual y actividades a desarrollar en el tiempo. Como marco general, se distinguen las siguientes grandes etapas:
a) Previa al cambio. b) Transición y cambio. c) Entrega del servicio.
Durante la etapa previa se definen los procesos, la estructura organizacional y la planeación operativa para la transición. Durante la transición, se va implantando la nueva estructura organizacional y los procesos definidos, para finalmente entrar en régimen en la etapa de entrega del servicio. A continuación se presenta el detalle de cada etapa.
1.1 Etapa previa al cambio La etapa previa al cambio, corresponde al conjunto de actividades de capacitación y definición de la estructura organizacional y los procesos TI.
114
1.1.1 Actividades de Capacitación Dentro de las actividades de capacitación al personal, se distinguen dos aspectos: las relacionadas con el desarrollo de competencias y habilidades personales y las relacionadas con el entendimiento del modelo que se está implementando. Para atacar el primer aspecto, el área de recursos humanos de la empresa ha definido una serie de cursos y talleres tendientes a entregar herramientas a las personas para desenvolverse bajo el nuevo paradigma, estos son:
a) Talleres de integración, cuyo objetivo es lograr que las personas de la gerencia de servicios TIC se conozcan entre sí.
b) Taller de negociación, cuyo objetivo es capacitar y practicar en los aspectos y técnicas modernas de la negociación, orientado a Subgerentes y a jefes de área.
c) Taller de manejo de conflictos, cuyo objetivo es entregar elementos y técnicas de resolución de conflictos, orientado a todo el personal TIC.
d) Curso y taller de servicio al cliente, orientado a todo el personal TIC, con el objetivo de dar a conocer y aplicar los conceptos y claves de la orientación al cliente.
Para el segundo aspecto, se contempla la necesidad de los siguientes cursos y talleres:
a) Curso de ITIL, orientado a todo el personal y con el objetivo de dar a conocer el modelo ITIL desde una perspectiva general.
b) Talleres de procesos, cuyo objetivo es incorporar a los Subgerentes y a jefes de área en las definiciones de los procesos TI.
1.1.2 Actividades de definición de los procesos TI Tal como se revisó en el capítulo 2, la definición de los procesos es hecha mediante el enfoque de re-ingeniería. Contempla la participación de los subgerentes y jefes de área en la definición de los procesos, mediante talleres.
1.1.3 Actividades de definición de la estructura organizacional Respecto a la estructura organizacional, el enfoque es realizar la definición en conjunto con el gerente de servicios TIC y la empresa consultora. Posteriormente, será validado por cada Subgerente designado para cada área.
115
1.2 Etapa de transición y cambio Operativamente, el problema de la etapa de transición y cambio es el traspaso de funciones del personal sin causar un gran impacto sobre el servicio actual. Para afrontar esto, es necesario definir una estrategia de traspaso y un plan de difusión del servicio. En primera instancia, el plan de traspaso debe considerar la función actual que es realizada por una persona y la función futura a la que será destinada. Se pueden distinguir dos casos:
1. Que una persona se mantenga realizando las mismas funciones, luego no tiene nada que traspasar, pero si podría recibir, producto de la consolidación de funciones y servicios.
2. Que una persona no se mantenga realizando las mismas funciones, distinguiéndose dos situaciones:
a) La función es nueva, por lo tanto solo debe entregar. b) La función se venía realizando con la estructura antigua y por lo tanto
tiene que recibir y entregar. Un criterio de traspaso, es realizar un big bang, es decir, hacer traspasos ordenados independientes de las funciones y criticidades actuales. Por ejemplo, si una persona está en un proyecto, entonces deberá entregar su función en el proyecto, a la persona que asumirá el rol en la nueva organización. El problema de esto, es que provoca inestabilidad en los servicios, por el hecho de introducir cambios de personas en trabajos que ya están en curso y por lo tanto las empresas pueden verse más afectadas de lo que podría esperarse. Otro criterio para minimizar la inestabilidad, es considerar, de la estructura organizacional antigua, las funciones críticas para mantener operativos los servicios que reciben las filiales. Entonces se tendrán los siguientes casos:
a) Personas que participan en proyectos en curso. b) Personas que realizan las mantenciones de software. c) Personas que realizan funciones de administración de servidores, servicios y
bases de datos. d) Personas que realizan soporte a usuarios.
Para las personas que participan en proyectos en curso, el objetivo es no incorporar riesgos que signifiquen atraso o inestabilidad a esos proyectos, por lo tanto deberán permanecer en ellos hasta que finalicen. Sin embargo, si tienen que entregar funciones anexas al proyecto y la persona que las recibe, las puede asumir, entonces deberá hacer entrega de esas funciones. En el caso de las personas que realizan mantenciones de software, si son asignadas a funciones nuevas, entonces deberán terminar las mantenciones que tienen asignadas y luego asumir y/o recibir las nuevas actividades.
116
Para las personas que realizan funciones de soporte a usuarios, administración de servidores, servicios y bases de datos y que son asignadas a nuevas funciones, entonces, a diferencia de los casos anteriores, deberán entregar las funciones actuales y asumir las nuevas. Entonces, la estrategia de cambio es un proceso que comienza primero con la línea de subgerentes asumiendo sus funciones y luego, en una segunda etapa, el personal asignado a cada subgerencia. Los traspasos se han de realizar de acuerdo a los criterios señalados anteriormente en el tiempo que sea necesario, hasta completar toda la organización, siendo deseable completar este proceso en un periodo de a lo más un año. Cada subgerente, coordinara con su par en la estructura antigua el detalle de las actividades que puedan ser traspasadas, generando así, un plan de traspaso que será dado a conocer a la organización TIC. El plan de difusión del servicio, consiste en una serie de reuniones en donde se presentará y se dará a conocer la nueva modalidad de servicio a los representantes de las filiales. Además, se distribuirá un folleto explicativo al personal de las empresas. Esta actividad será ejecutada una vez que los subgerentes asuman sus funciones. La presentación del servicio será realizada por: el Gerente de servicios TIC, el Subgerente de Relación Comercial y el Service Manager de la empresa a la cual se realizará la presentación. Se darán a conocer los siguientes puntos:
a) Breve introducción de la empresa de servicios compartidos. b) Presentación de la nueva modalidad de servicios: estructura organizacional
TIC, breve descripción de los procesos que se utilizarán, acceso a los servicios.
c) Descripción de los servicios ofertados. d) Formalización de inicio de la nueva modalidad de servicios.
En la tabla 25, se presenta el plan global de transición, difusión y cambio.
1.3 Etapa de entrega del servicio Finalmente, la etapa de entrega del servicio, es el estado de régimen de la organización, en donde los procesos se encuentran adoptados y en funcionamiento. El objetivo es llegar a este estado un año después de iniciado el proceso de transición y cambio.
117
Tabla 25: Plan global de difusión y cambio
118
Capítulo 6 – Estrategia para la Mejora del Software
1. Marco del Proceso de Mejora de Software El objetivo de este capítulo es diseñar el plan de acción estratégico para la mejora del proceso de software (SPI) para proyectos de desarrollo y el proceso de mantención del área de tecnologías de información, dentro de un marco de trabajo futuro, pensando en la evaluación bajo CMMi en el mediano y largo plazo. El plan de acción, integrara todas las actividades de mejora del proceso de software mediante la adopción del modelo CMMi para la disciplina de Ingeniería en Software. Este modelo, proporciona una guía para mejorar el proceso de una organización y la capacidad para administrar el desarrollo, adquisición y mantención de productos y servicios, proveyendo facilidades para ayudar a las organizaciones a examinar la efectividad de sus procesos, establecer prioridades de mejoramiento y apoyar la implantación de las mejoras. Los esfuerzos realizados se contrastaran con las evaluaciones, tanto formales como informales de CMMi, las recomendaciones serán incorporadas e institucionalizadas con el objeto de incentivar la mejora continua del proceso. En este capítulo, se presenta el plan del proyecto SPI cuyos objetivos son alcanzar en el tiempo los distintos niveles de madurez CMMi, estandarizar las prácticas y procesos de software para el área, disminuir el costo empresa de los proyectos y mantenciones de software. La motivación de esta iniciativa se basa en principios guías y en la oportunidad de entregar mejores servicios a los clientes. El compromiso de la alta gerencia es crítico para esta iniciativa, se espera:
a) Se disponga de los recursos apropiados y adecuados para el proyecto. b) Existan comunicaciones continuas hacia la organización, filiales y gerencia
sobre la importancia del SPI y los avances que se produzcan en el proyecto. c) Convencer a las filiales para incorporar como propio el proceso de mejora de
software, dejando en claro las expectativas reales de la iniciativa. d) Se provea de un esquema de incentivos y reconocimiento para aquellas
personas que muestren adherencia a las mejoras del proceso y en general a la participación y aporte en el proyecto.
El éxito del SPI se medirá mediante la evaluación exitosa en los niveles de madurez de CMMi. La mejora continua estará dada por: la evaluación periódica del nivel alcanzado, incorporando los hallazgos de estas actividades a las empresas y el avance en los niveles de madurez CMMi.
119
2. Plan Estratégico de Mejora del Proceso de Software
2.1 Misión Promover la mejora de procesos continúa a través de las filiales del holding, proveer la guía hacia el camino de la excelencia en cada una de las áreas de proceso, que permitan a la organización aumentar y mantener su nivel de madurez en el tiempo.
2.2 Visión El servicio compartido de tecnologías de información pondrá todos sus esfuerzos en institucionalizar los procesos de software mediante estándares documentados y proveer productos fiables y servicios a tiempo, al mínimo costo.
2.3 Valores Personas: Nuestra gente es la fortaleza de nuestra área. Creemos en el trabajo en equipo y el compromiso de las personas, propiciamos un ambiente que permite al personal crecer y desarrollarse profesionalmente. Calidad: Creemos que la calidad de nuestros productos está directamente relacionada con la calidad de nuestros procesos. Madurez del Proceso de Software: Creemos que el modelo CMMi es un método práctico de identificación y evaluación para medir la madurez del proceso de software.
2.4 Principios Guías
1. La satisfacción de nuestros clientes es crítica y de suma importancia para los negocios.
2. La mejora continua del proceso de software es esencial para el éxito. 3. Procesos comunes y estándares son indispensables para el crecimiento
organizacional. 4. Los esfuerzos en la mejora de procesos son administrados con un eficiente uso
de recursos.
120
2.5 Metas de Corto Plazo Obtener evaluación satisfactoria en CMMi nivel 2 en un plazo no superior a 2 años. Estandarizar las prácticas y procesos de software del área de tecnologías de información de la empresa de servicios compartidos. Disminuir el costo empresa de los proyectos y mantenciones de software.
2.6 Metas de Largo Plazo Desarrollar e institucionalizar la cultura de ingeniería de software basada en la mejora continua de los procesos. Alcanzar los distintos niveles de madurez CMMi cada 2 años, realizando evaluaciones cada 1 año.
2.7 Metas Estratégicas Derivadas del Negocio Alinearse con la política de calidad del holding matriz respecto a los procesos productivos. Mantener el liderazgo en costos y la producción de productos de alta calidad, conforme a los estándares internacionales de la industria.
2.8 Objetivo El objetivo de esta iniciativa es disminuir los costos para los procesos de desarrollo y mantención de software.
2.9 Beneficios Esperados
1. Aumentar la productividad. 2. Reducir los esfuerzos de retrabajo para las mantenciones. 3. Mejorar el tiempo del ciclo del producto. 4. Disminuir la cantidad de defectos los productos de software. 5. Mejorar la moral de los empleados.
2.10 Principios Guía del SPI El proyecto SPI pretende atacar las distintas etapas del proceso de software que vale la pena mejorar, vale decir: issues del negocio, soluciones técnicas, administración de
121
proyectos y calidad. La organización debe ser capaz de explicar a los terceros relevantes porque una actividad determinada o un entregable son importantes. Los procesos deben ser concisos, agregar valor y deben ser usables. Se privilegiará la re-utilización de cualquier práctica, documento, o artefacto existente en la organización.
2.11 Supuestos Para el desarrollo de este plan es necesario contar con los recursos, tanto humanos, técnicos y financieros, que permitan llevar a un buen término el proyecto SPI, bajo este paradigma se asumen una serie de supuestos críticos para el éxito, estos son:
a) La creación de una Subgerencia de Calidad, que se hará cargo de los procesos, la mejora continua y liderará esta iniciativa a través del tiempo.
b) CMMi será utilizado como base para todas las definiciones de proceso, políticas y prácticas definidas bajo el proyecto SPI.
c) Cada integrante del proyecto deberá destinar 1 hora diaria a las actividades de SPI. El Subgerente de calidad o el jefe de proyecto que este designe, tendrá la facultad para programar y disponer de dicho tiempo.
d) Se debe definir un modelo de incentivos y reconocimientos al personal que participe activamente en el proyecto.
2.12 Auspicio Se cuenta con el auspicio del Gerente de TI y del Gerente General de la empresa de servicios compartidos, de quienes se tiene el compromiso de alinear y comunicar al holding de empresas respecto a la importancia y alcances del proyecto. Además, será el canal de comunicación hacia niveles más altos de la organización. Se cuenta con el auspicio de los subgerentes del área de tecnologías de información, de quienes se tiene el compromiso de facilitar los recursos humanos.
122
2.13 Riesgos En la tabla 26, se presenta una matriz de riesgos para el proyecto SPI:
Tabla 26: Riesgos del proyecto de mejora del proceso de software
2.14 Barreras Una de las principales barreras a enfrentar por este proyecto, es el grado conservador del holding respecto a la adopción de nuevas tecnologías y a que no se ha tomado conciencia de que el servicio de informática es un real apoyo para el negocio como generador de beneficios. Históricamente, las empresas han tenido su focalización en el negocio desechando actividades que no generan valor, el servicio de informática se considera como un centro de gastos más que un centro generador de beneficios por lo que cualquier iniciativa proveniente del área tiene un alto grado de cuestionamiento. Por otro lado, la capacitación interna en temas de tecnologías de información es bastante baja por lo que puede ser una barrera al momento de integrarlo con los clientes finales. Desde el punto de vista financiero, el proyecto debe ser evaluado utilizando los métodos tradicionales, sin embargo al no existir experiencia previa se dificulta la medición de beneficios cuantitativos del proyecto y por lo tanto su justificación en el directorio de la empresa. Se debe partir, por una evaluación cualitativa hasta obtener algún resultado concreto, por ello no se descarta un enfoque incremental del proyecto. Las barreras pueden ser superadas mediante el apoyo claro para el proyecto SPI de la alta dirección del holding y la capacitación continua en el modelo.
123
2.15 Organización para la Mejora del Proceso
2.15.1 Alcance Organizacional El proyecto SPI tiene alcance sobre el holding completo, afectando a los servicios informáticos que se prestan en cada una de las filiales, el área involucrada directamente en esta iniciativa es la Gerencia de Tecnologías de Información y Comunicaciones. Desde el punto de vista de las filiales, los procesos que les signifiquen participación del proceso de software están dentro del alcance de este proyecto, el plan comunicacional deberá incorporar a los clientes finales de cada filial, con el objeto de transmitirles las prácticas y procedimientos sujetos a mejora continua, esto aportará también la institucionalización del proceso. El sponsor de este proyecto es el Gerente General de la empresa de servicios compartidos, cuyas responsabilidades son:
a) Establecer y promover en el holding el proyecto SPI. b) Entregar la visión corporativa desde el punto de vista del negocio para el
proyecto SPI. c) Proponer issues de mejora al comité ejecutivo. d) Alinear a los Gerentes Generales de las filiales con este proyecto.
2.15.2 Comité Ejecutivo El comité ejecutivo es el encargado de guiar y gobernar el proyecto SPI. Sus responsabilidades son:
a) Determinar el tipo de planificación estratégica a utilizar. b) Definir y crear el plan estratégico de acción. c) Revisar e integrar la visión, misión y plan de negocio al proceso de mejora de
software. d) Comunicar a los niveles altos de la organización el desarrollo de los objetivos
y logros del proceso. e) Supervisar como el proceso se está llevando a cabo.
El comité estará integrado por:
a) Gerente General de Servicios Compartidos. b) Gerente de Tecnologías de Información y Comunicaciones. c) Jefe de Proyecto SPI.
124
2.15.3 Jefe del Proyecto SPI El jefe del proyecto, tendrá la responsabilidad de coordinar y liderar el proceso de mejora de software, sus responsabilidades son:
a) Documentar el plan de acción estratégico. b) Planificar las actividades, identificar recursos y esfuerzos. c) Realizar el seguimiento del progreso del proyecto respecto a lo planificado. d) Revisar los planes de acción de los grupos de trabajo y el equipo del
proyecto. e) Recopilar semanalmente el estado de avance de los grupos de trabajo y le
equipo del proyecto. f) Informar mensualmente el estado de avance al comité ejecutivo. g) Sugerir acciones correctivas al comité ejecutivo cuando se produzcan
desviaciones respecto a la planificación. h) Adquirir y coordinar los recursos para capacitación y consultoría.
2.15.4 SEPG (Software Engineering Process Group) El SEPG tendrá las siguientes responsabilidades:
a) Determinar y definir la organización (procesos y métodos). b) Establecer la forma de evaluar el proceso. c) Presentar los resultados del proceso a los diferentes niveles de la
organización. d) Establecer planes tácticos de acción. e) Supervisar los proyectos de mejoramiento. f) Evaluar y verificar los avances.
El SEPG estará compuesto por:
a) Jefe del Proyecto SPI. b) Project Managers.
2.15.5 Grupos de Trabajo Técnicos (TWG) Los miembros de los grupos de trabajo técnicos, tendrán la responsabilidad de producir, revisar y asistir en el piloteo de nuevos procesos de software y de herramientas de mejora. Cada grupo, tendrá un líder que tendrá la responsabilidad de aceptar cada hito del plan de proyecto SPI e implementar las recomendaciones de cada ciclo de mejora. En particular, el TWG:
a) Desarrollará y documentará nuevos procesos. b) Evaluará los actuales procesos proponiendo mejoras. c) Documentará y recopilara los artefactos actuales de procesos de la
organización.
125
d) Conducirá los pilotos. e) Propondrán mejoras y modificaciones a los procesos.
Se definirán 6 TWG, cuyas áreas de proceso serán asignadas de común acuerdo con el líder del proyecto SPI. Los TWG están compuestos por: TWG 1:
a) Jefe del Proyecto SPI (como facilitador). b) Jefe de Proyectos de Automatización. c) Ingeniero de Proyectos SAP.
TWG 2:
a) Jefe del Proyecto SPI (como facilitador). b) Jefe de Proyectos de Inteligencia de Negocio. c) Ingeniero de Mantención.
TWG 3:
a) Jefe del Proyecto SPI (como facilitador). b) Jefe de Proyectos SAP. c) Ingeniero de Proyectos Automatización.
TWG 4:
a) Jefe del Proyecto SPI (como facilitador). b) Jefe de Proyectos de Integración. c) Ingeniero de Proyectos Inteligencia de Negocio.
TWG 5:
a) Jefe del Proyecto SPI (como facilitador). b) Jefe de Proyectos Software General. c) Ingeniero de Proyectos Integración.
TWG 6:
a) Jefe del Proyecto SPI (como facilitador). b) Jefe de Proyectos de Mantención. c) Ingeniero de Proyectos Software General.
2.15.6 Consultores Externos Como parte del proyecto SPI, se utilizarán consultores externos para la evaluación formal en los niveles de madurez CMMi. Además dado que no existe experiencia en el holding en este tipo de iniciativas, para el levantamiento y la puesta en marcha del proyecto SPI se contratará la asesoría de una empresa especializada.
126
2.16 Criterios de Éxito El éxito de este proyecto será alcanzado de la siguiente manera: Desde el punto de vista estratégico:
a) Obtener satisfactoriamente la evaluación CMMi nivel 2 en un periodo no mayor a 2 años.
b) Obtener satisfactoriamente la evaluación CMMi en niveles superiores cada 2 años a partir de la fecha de obtención del nivel 2.
c) Institucionalización de las áreas de procesos relacionadas con el desarrollo de software.
d) A mediano plazo, el establecimiento de evaluaciones informales cada año y formales cada año por medio.
2.16.1 Medición de Metas de Corto Plazo La estandarización de las prácticas y procesos de software, será medida mediante la adopción de los procedimientos por parte de los involucrados, vale decir, que se medirá el porcentaje de cantidad de procesos actualmente en uso respecto a la cantidad de procesos totales, un valor del 100% se considerara exitoso, cualquier otro valor será considerado como no exitoso. La medición de realizará anualmente mediante evaluaciones informales. La disminución del costo empresa de los proyectos y mantenciones de software, será medida como el porcentaje del costo del esfuerzo en un proyecto o mantención respecto al costo del esfuerzo de un proyecto o mantención de tamaño similar que haya sido realizado en el pasado. Para determinar la similaridad del proyecto o mantención se utilizaran puntos de función. Si para un proyecto o mantención los puntos de función son iguales, entonces se consideraran equivalentes. El porcentaje de disminución de proyectos y mantenciones similares debe ser de al menos un 10%.
2.16.2 Medición de Metas de Largo Plazo Para medir el desarrollo e institucionalización de la cultura de ingeniería de software basada en la mejora continua de los procesos, se tomarán controles a los integrantes del área informática. Se considerará logrado el objetivo cuando se obtenga en promedio un 100% de respuestas correctas en los controles.
2.16.3 Medición de Metas Estratégicas Derivadas del Negocio La medición del alineamiento con la política de calidad del holding respecto a los procesos productivos, será medida mediante la obtención de evaluaciones satisfactorias en los niveles de madurez de CMMi.
127
Para medir el mantenimiento del liderazgo en costos y la producción de productos de alta calidad conforme a los estándares internacionales de la industria, se establecerán dos medidas, por una parte se exigirá al proyecto SPI el mismo ROI que es exigido a la empresa, por el directorio y en segundo lugar los defectos de los productos de software deberán ser eliminados por sobre el 99%.
2.17 Planificación
2.17.1 Costos Estimados Para el proyecto SPI se estima un costo de US$ 393.000, cuyo detalle se encuentra en la tabla 27.
Tabla 27: Costos del proyecto de mejora del proceso de software
128
2.17.2 Roadmap La planeación estimada de actividades, se puede visualizar en la tabla 28.
Tabla 28: Roadmap del proyecto de mejora del proceso de software
129
Capítulo 7 - Conclusiones Este proyecto logró el cambio de la estructura organizacional, de acuerdo a los objetivos planteados. Los servicios son entregados a las empresas y de acuerdo a los niveles de servicio definidos. Los procesos fueron abordados con un carácter general, donde la idea era establecer un marco de trabajo para la organización, desde la planeación estratégica hasta el manejo de la infraestructura informática. Los procesos TIC fueron definidos bajo el marco de referencia de CMMi e ITIL, lo que permite tener una base de procesos estándar, contribuyendo a la simplificación de la operación y control del negocio y con la posibilidad de adoptarlos completamente. En contraste con la situación inicial, en donde prácticamente no existían procesos formales ni estandarizados. Sin embargo, el incremento de la calidad de los productos y servicios entregados no está asegurado ya que los procesos definidos ordenan la organización, pero no establecen mecanismos que promuevan la mejora continua. Por ello, el plan estratégico de mejora del proceso de software presentado en el capítulo 6, es un primer paso en dicha dirección. El esquema de servicios compartidos permite que las soluciones tecnológicas sean transversales al holding, generando sinergia, economías de escala, estandarización y por lo tanto, la posibilidad de disminuir los costos de los proyectos y servicios externos, contribuyendo a identificar las fuentes para minimizar los gastos de operación de las actividades de apoyo al negocio. En la situación inicial estos beneficios no se presentaban ya que no era posible un enfoque global que permitiera tomar decisiones pensando en el conjunto y en los procesos de negocio de las distintas empresas del holding, los que son prácticamente equivalentes. En términos cuantitativos, bajo la situación inicial, el gasto promedio mensual en tecnologías de información para una planta industrial con 500 usuarios era de US$ 70.200, con el servicio compartido TIC bajó aproximadamente a US$ 62.000 promedio mensual, lo que representa una disminución promedio de un 11,7%. Paradójicamente, los proyectos de software son aproximadamente un 15% más caros respecto a la situación inicial, esto producto de la transparentacíon de los costos del personal propio, pero como son considerados inversiones, en la evaluación económica se exige una tasa de descuento superior, lo que compensa la situación.17 Las definiciones entregadas en esta tesis se basan en decidir la mejor estrategia de provisión de servicios, respecto a la localización geográfica de las instalaciones, el tipo de industria y al paradigma de servicios compartidos. Es interesante destacar que los marcos de referencia utilizados, prácticamente se independizan de estas variables y establecen criterios de diseño de acuerdo a las mejores prácticas, criticidad y distribución de los procesos propios del negocio.
17 Fuente: Reportes de facturación del servicio TIC y presupuestos internos del holding.
130
Aún queda trabajo por hacer en la definición de, los procedimientos y el detalle de los procesos que, por su extensión, solo fueron elaborados en sus aspectos más relevantes. Además, se han de normalizar los dos grandes problemas que aparecieron producto de la implementación de este proyecto. El primer problema fue la tendencia de la dirección de este proyecto, a minimizar y simplificar el esfuerzo requerido para producir el cambio y en focalizarse en definir la organización antes que los procesos. También, el suponer que todas las personas colaborarían y adoptarían los nuevos modelos, produjo una serie de dificultades en la implantación. Se presentaron problemas de coordinación, disputas de poder entre áreas y en general, desorden respecto a lo que se deseaba alcanzar. Si bien simplificar el problema puede ser una aproximación para abordarlo y entenderlo, este criterio no debe ser usado para la ejecución de proyectos de este tipo, que por sus características y complejidad requiere estudio, participación más amplía de las personas y análisis en profundidad. El segundo problema fue que la asignación de las personas a cargos claves, se realizo sobre el concepto de carrera funcionaria, lo que de alguna manera produjo que personas que a pesar de tener mucha experiencia, no eran competentes para el cargo en el que fueron designados, lo que produjo que áreas completas no operen de acuerdo al marco definido. Un error de este proyecto fue el no haber abordado este punto con el apoyo de profesionales especialistas en selección de personal. La asignación de personas a funciones debe realizarse con un conocimiento acabado de competencias y perfiles. El uso de modelos y estándares de la industria no garantiza el éxito de una organización. Se pueden modelar, adoptar, e implementar procesos, pero sin la contribución y aporte de las personas, este tipo de iniciativas puede fracasar. Por ello, las llamadas habilidades blandas, juegan un factor relevante como medios para el cambio, sobre todo, en la modificación de hábitos de trabajo. Una deficiencia en esta componente dificulta este tipo de proyectos, produciendo resistencia a la adopción de nuevas formas de trabajar. Por lo tanto, los líderes de este tipo de proyectos deben ser buenos negociadores, poseer un manejo fluido de la comunicación y ser guías del proceso de adopción, más que impositores de estructuras. Finalmente, la adopción de estándares probados, facilita a las áreas de tecnologías de información, la definición de sus propios procesos de negocios. Ambos modelos son el esfuerzo de la industria, en respuesta a la manera en que los procesos han evolucionado, a la dependencia creciente en las tecnologías para la sobrevivencia del negocio y a la necesidad de las organizaciones de proveer a sus clientes, productos y servicios en forma oportuna y con la calidad requerida, asegurando así, la competitividad y por lo tanto, la sustentabilidad a través del tiempo.
131
Bibliografía [1] ACHÁ, VERONICA. 2004. Apuntes del curso: “ISO 9000”. Diplomado en Gestión de Calidad de Software. Departamento de Ciencias de la Computación. Universidad de Chile. [2] BASTARRICA, MARIA CECILIA. 2004. Apuntes del curso: “Introducción a la Ingeniería de Software”. Postítulo en Ingeniería y Calidad de Software. Departamento de Ciencias de la Computación. Universidad de Chile. pp 78-83. [3] BOUMAN, JACQUES, et al. 2000. Specification of service level agreement, clarifying concepts on the basis of practical research. University of Technology Eindhoven. Netherlands. pp 1-3 [4] DOCUMENTO INTERNO. 2004. Catálogo de servicios para un holding de empresas forestales. Documento Interno. Empresa Forestal. Chile. 120p. [5] DOCUMENTO INTERNO. 2004. Estudio de viabilidad de un servicio compartido para una empresa forestal. Documento Interno. Empresa Forestal. Chile. 30p. [6] DOCUMENTO INTERNO. 2005. Estudio de rendimiento de un sistema de ejecución de manufactura. Documento Interno. Empresa Forestal. Chile. 93p. [7] CMMI PRODUCT TEAM. 2002. CMMi for Software Engineering Staged Representation (CMU/SEI-2002-TR-02, ESC-TR-2002-029). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. 639p. [8] CURRY J. y FERGUSON J. 2000. Increasing the Success of the Global Information Technology Strategic Planning Process. Proceedings of the 33rd Hawaii International Conference on System Sciences. IEEE. USA. pp 4-5. [9] GUERRERO, JOSÉ. 2004. Apuntes del curso: “Técnicas de Pruebas”. Diplomado en Gestión de Calidad de Software. Departamento de Ciencias de la Computación. Universidad de Chile. [10] GUERRERO, LUIS. 2005. Apuntes del seminario: “Introducción al UML”. Postítulo en Gestión Informática. Departamento de Ciencias de la Computación. Universidad de Chile. [11] HAX A y MAJLUF N. 1996. Gestión de Empresa con una Visión Estratégica. Ediciones Dolmen. Chile. Capítulo 1. [12] HUGHET, JOHN. 2001. IT Strategy in Forest Products. Accenture, 36p [13] JORRAT, MICHAEL. 2000. Apuntes del curso: “Evaluación de Proyectos”. Departamento de Ingeniería Industrial. Universidad de Chile.
132
[14] KETTINGER W et al. 1998. The process reengineering life cycle methodology: A case study. En: GROVER, V y KETTINGER W. Business Process Change: Reengineering, Concepts, Methods and Technologies. USA. IDEA Group. pp 211-244 [15] MAYER R. et al. 1998. A Framework and a suite of methods for business process reengineering. En: GROVER, V y KETTINGER W. Business Process Change: Reengineering, Concepts, Methods and Technologies. USA. IDEA Group. pp 245-290. [16] MICROSOFT CORPORATION. 2005. Microsoft Framework Solutions for Agile Software Development. Visual Studio Team System. Build 100.4. USA. [17] MICROSOFT CORPORATION. 2005. Microsoft Framework Solutions for CMMi. Visual Studio Team System. Versión 1.0. USA. [18] MICROSOFT CORPORATION. 2004. MOF: Capacity Management. USA. Microsoft Press. pp 1-9 [19] MICROSOFT CORPORATION. 2002. MOF: Incident Management. USA. Microsoft Press. pp 11-12 [20] MICROSOFT CORPORATION. 2005. MOF: Network Administration. USA. Microsoft Press. pp 6-7 [21] MICROSOFT CORPORATION. 2002. MOF: Problem Management. USA. Microsoft Press. pp 9-11 [22] MICROSOFT CORPORATION. 2002. MOF: Service Desk. USA. Microsoft Press. pp 7-10 [23] MICROSOFT CORPORATION. 2003. MOF: Service Level Management. USA. Microsoft Press. pp 9-10 [24] MICROSOFT CORPORATION. 2002. MOF: System Administration. USA. Microsoft Press. pp 9-20 [25] OCHOA, SERGIO. 2005. Apuntes del curso: “Gestión de Proyectos Informáticos”. Postítulo en Gestión Informática. Departamento de Ciencias de la Computación. Universidad de Chile. 247p [26] OFFICE OF GOVERNMENT COMMERCE. 2003. ITIL Service & Support CD. UK. The Stationery Office. [27] PICONE, GERMÁN. 2003. Trends and Directions in the Forest and Paper Industry. IBM Business Consulting Services, 34p [28] SOMMERVILLE, IAN. 2000. Software Engineering. 6th Edition. USA. Pearson Education. Capitulo 27, pp 5-6
133
[29] STRAUB, PABLO. 2004. Apuntes del curso: “Introducción a la gestión de calidad”. Diplomado en Gestión de Calidad. Departamento de Ciencias de la Computación. Universidad de Chile. [30] PINTO, FERNANDO. 2004. Apuntes del curso: “Introducción a CMMi”. Diplomado en Gestión de Calidad de Software. Departamento de Ciencias de la Computación. Universidad de Chile. [31] VARAS, SAMUEL. 2003. Apuntes del curso “Tecnologías de Información y Rediseño de Procesos”. Departamento de Ingeniería Industrial. Universidad de Chile. 554p [32] WWW.IDEF.COM. Descripción del modelo IDEF [en línea]. http://www.idef.com. [Consulta: 22 de Marzo de 2006] [33] WWW.ISO.ORG. Resumen del modelo ISO 9126. [en línea]. http://www.iso.org. [Consulta: 23 de Noviembre de 2005]
134
ANEXOS
135
ANEXO I: Comparación entre las plataformas .NET y J2EE
136
ANEXO I: Una comparación entre .NET y J2EE No es sencillo realizar una comparación de ambas plataformas, debido a la cantidad y complejidad de los elementos que las componen (ver figuras 1 y 2). Por lo tanto, la idea es entregar algunos criterios que permitan al lector tener una visión rápida de las diferencias, similitudes, ventajas y desventajas, desde el punto de vista global.
Figura 2: Arquitectura J2EE19 De acuerdo a SUN, J2EE es un conjunto de especificaciones y prácticas que permiten el desarrollo de soluciones empresariales multi-capa, basados en la tecnología Java. Considera un único lenguaje de programación, Java, que se caracteriza por ser portable robusto, estable, orientado a objetos, e independiente de la plataforma. Al igual que C++, el que podría considerarse como su predecesor, esta orientado fuertemente a mantener la consistencia de los tipos de datos, provee mecanismos para herencia múltiple, pero no permite la programación de funciones fuera de las clases. La ejecución de aplicaciones se realiza utilizando una máquina virtual, que interpreta el código intermedio generado por el compilador. .NET es una plataforma de desarrollo de servidores, clientes y servicios. Se basa en estándares abiertos como CLI, SOAP y WSDL. Permite al programador trabajar sobre múltiples lenguajes en un entorno único de desarrollo (Visual Studio). Al igual que J2EE, utiliza código intermedio, con la diferencia que el compilador traduce los lenguajes soportados a uno común, el que es ejecutado por un interprete. Esto permite que un programa en un cierto lenguaje pueda utilizar código o componentes escritos en otro lenguaje. Los lenguajes base de la plataforma con C# y Visual Basic. C# es una especie de evolución entre Java y C++, por lo que existen coincidencias con Java, es decir:
Ambos lenguajes son compilados a código intermedio, independiente de la plataforma y del sistema operativo para el caso de Java y dependiente del sistema operativo para los lenguajes bajo .NET. Cabe señalar, que existen una serie de iniciativas para portar .NET a ambientes UNIX, siendo el proyecto Mono, de código abierto, uno de los mas utilizados.
No permiten el uso de punteros, aunque con C# se pueden utilizar en el modo de programación unsafe.
El código es organizado en clases. Ambos permiten herencia múltiple mediante el uso de interfaces.
En el siguiente cuadro, se presenta un resumen con las principales diferencias y coincidencias entre el lenguaje Java y los lenguajes base de .NET.
Tabla 1: Comparación entre lenguajes .NET y Java20 Respecto a las plataformas, las ventajas de .NET sobre J2EE son:
1. .NET soporta múltiples lenguajes de programación, lo que permite flexibilidad al programador y una evolución en los entornos de programación, facilitando la integración y portabilidad de las aplicaciones.
2. El entorno de programación .NET está orientado a la creación de servicios web, incluyendo nativamente formatos SOAP, WSDL y UDDI, Sin que el programador tenga que generar por si mismo el código XML.
3. Microsoft con su suite Visual Studio, establece una serie de prácticas de desarrollo de software que pueden ser aplicadas con métodos tradicionales y ágiles, en cambio J2EE solo ofrece la plataforma, donde las prácticas son abordadas mediante entornos de programación de terceros.
Por otro lado, J2EE presenta las siguientes ventajas respecto a .NET:
1. La tecnología Java es abierta y basada en estándares internacionales. 2. J2EE puede ser adquirido en varias compañías, en contraste con .NET, en el
que el proveedor es único. 3. Posee un nivel de madurez superior a .NET en relación a la arquitectura sobre
diferentes plataformas, el tiempo de permanencia en el mercado y en la estabilidad.
Finalmente, la elección de una u otra plataforma dependerá del contexto empresarial y de los costos de implementación. Como criterio general, si las aplicaciones de la empresa son predominantemente Windows, construidas con el entorno Visual Studio, 20 Fuente: JIMÉNEZ, LUZ ELENA. 2003. Una comparación entre JAVA y .NET. En: Sistemas & Telemática. Universidad ICESI. Colombia. pp 80-81
139
es mejor utilizar .NET ya que la evolución tecnológica no significa mayores costos (salvo licencias, por supuesto) y resulta ser directa. Lo mismo ocurre con J2EE, si la plataforma ya está establecida bajo Windows, tiene menos costo seguir con la mismo, frente a una migración. Por otro lado, en entornos nuevos, si la plataforma per-se es UNIX, J2EE resulta ser la elección natural. En cambio, para Windows, la diferencia la hará el costo de implementación y mantención entre J2EE y .NET, el que debe ser evaluado de acuerdo al caso particular.
140
ANEXO II: Ejemplos de Normas y Procedimientos
141
ANEXO II: Políticas Generales del Servicio TIC OBJETIVOS
El servicio TIC es la responsable de normar todos los aspectos relacionados con los sistemas, comunicaciones de red y tecnologías de información del holding y sus filiales, con el objeto de prestar servicios, para que el personal disponga de las herramientas, que apoyen efectivamente su gestión en el logro de los objetivos de las empresas, operando eficientemente sus sistemas de información y de comunicación. En particular con respecto a esta área se debe tener en cuenta los siguientes aspectos:
1. Todas las Aplicaciones, Software y Sistemas que se carguen en la plataforma computacional, tanto preliminares como definitivas, deben estar debidamente licenciadas y deben ser autorizadas.
2. Se deben realizar los respaldos necesarios, en relación a Sistemas, Bases de Datos y Servidores, que permitan un adecuado nivel de seguridad y resguardo de la información en caso de fallas o desastre. Los programas de respaldo se deberán definir cada 6 meses, con el objeto de ajustarlo a las reales necesidades de las empresas.
3. El acceso a aplicaciones, software y sistemas debe estar autorizado por el Jefe de Seguridad y/o Gerente, Subgerente del área respectiva. En particular, se deben tener las siguientes consideraciones:
a. Acceso a aplicaciones y sistemas: Autoriza Jefe de Seguridad y/o Gerente, Subgerente, quien deberá entregar su aprobación por escrito.
b. Acceso a la red Internet, creación de cuentas de red y cuentas de correo: Autoriza Jefe directo del usuario.
c. Software licenciado: Autoriza Ingeniero de Soporte teniendo en cuenta el esquema de licenciamiento.
d. Software no licenciado: No se instala. e. Software no autorizado: No se instala. f. Software de desarrollo: No se instala en equipos de usuario solo en el de
personal del servicio TIC y contratistas que realizan desarrollo utilizando equipos de la plataforma computacional del holding y sus filiales, previa autorización del Gestor de Proyectos.
g. Software base de datos, es decir Oracle y SQL Server: Solo se instalan a los clientes con previa autorización del Ingeniero de Soporte.
ALCANCE Aplicable al personal del holding y sus filiales. POLÍTICA SOBRE LA SEGURIDAD EN EL ACCESO A LA RED
1. Para el acceso de los usuarios a los Sistemas de Información se dispondrá de dos niveles de seguridad, definidos por claves o Contraseña. El primero estará dado por el acceso a la red computacional y el segundo por el acceso al sistema propiamente tal.
142
2. Para acceder a la red computacional, cada usuario dispondrá de una Contraseña personal e intransferible, asignada inicialmente por el administrador de red, la que será cambiada la primera vez que utilice su cuenta de red. Además el usuario podrá libre e independientemente cambiar su contraseña cuando lo requiera. Las contraseñas de usuario tendrán una expiración no mayor a 3 meses, cumplido ese tiempo el sistema de autenticación de red pedirá cambiar el Contraseña al usuario. Las Contraseña asociadas a la Administración de Servidores serán cambiadas con una frecuencia no mayor de 3 meses. Las Contraseña tendrán un largo igual o superior a 6 caracteres y no podrá repetirse el mismo Contraseña por 3 periodos.
3. Para acceder a un sistema de información, los usuarios dispondrán de una Contraseña, asignada por el Ingeniero de Soporte, el que es responsable de definir el perfil del usuario. Se recomienda un cambio de Contraseña con una frecuencia no mayor de 3 meses.
4. Toda vez que un trabajador abandone la empresa, el área de Recursos Humanos informará con anticipación, con el objeto de eliminar su acceso a la red computacional y demás privilegios en los sistemas.
5. El ingreso a las Salas de Computación de las Plantas, donde se encuentran los servidores y otros elementos de hardware relevantes de la red, será restringido sólo a personal autorizado.
POLÍTICA DE RESPALDO Y RECUPERACIÓN DE DESASTRE.
1. Con el objeto de reponer los servicios en el más breve plazo y disminuir el riesgo de pérdida de información, frente a contingencias graves en las instalaciones físicas, se dispondrá de los correspondientes respaldos de información y de alternativas de acción para reponer las distintas líneas de equipos.
2. Se privilegiará mantener convenios de soporte técnico y mantención de los equipos críticos con los proveedores o sus representantes oficiales.
3. Para asegurar una adecuada reposición de los sistemas de información y recuperación de los datos, frente a fallas en los equipos centrales y, o acciones involuntarias, se dispondrá de los respaldos necesarios de las aplicaciones y de los datos. A fin de disminuir el riesgo frente a contingencias mayores, estos respaldos se almacenarán en diferentes lugares de las instalaciones.
4. El servicio TIC, no se hace responsable por el respaldo de PC de usuarios, es el usuario el responsable de su respaldo mediante las herramientas disponibles actualmente.
POLÍTICA DE ACCESO RED COMPUTACIONAL
1. Para acceder a los servicios computacionales prestados por el servicio TIC, el usuario debe poseer una Cuenta de Usuario y una Contraseña.
2. Cada Jefe de Departamento puede solicitar la creación de cuenta de red para el personal a su cargo, esta solicitud será canalizada al Service Desk, especificando el nombre y departamento al cual pertenece el usuario, área, teléfono (anexo) e indicar si el usuario tendrá correo o no.
3. Todas las cuentas de red por defecto tendrán acceso a Internet. El acceso VPN será a pedido. El solicitante deberá especificar las excepciones.
143
4. La Cuenta de usuario será personal e intransferible. La Contraseña inicial será asignada al momento de la creación de la Cuenta y puede ser cambiada libre e independientemente por el propio usuario.
5. La contraseña de red expira, excepto la contraseña empleada para crear la cuenta.
POLÍTICA DE REQUERIMIENTO DE CORREO ELECTRÓNICO
1. El requerimiento de la cuenta de Correo Electrónico debe ser solicitado al Service Desk, siguiendo los mismos pasos de la Política Acceso red Computacional.
2. Se debe tener en cuenta los siguientes puntos: a. Cada Cuenta de Correo debe estar asociada a una Cuenta de Red. b. Las Cuentas de Correo de contratistas deben tener como descripción la
función desempeñada y la identificación de la empresa contratista. c. Se debe configurar la estación cliente con un archivo PST local, la entrega
de los correos tiene que estar direccionada a las carpetas personales. d. Las casillas de correo poseen una limitación de 10 Megabytes para el
volumen de información de envió y recepción. e. Los correos almacenados en el servidor están sujetos a un tamaño
máximo de 100 Megabytes. POLÍTICA DE INSTALACIÓN DE SOFTWARE EN ESTACIONES DE TRABAJO
1. El requerimiento de instalación de Software debe ser solicitado al Service Desk, por el usuario. El proceso de instalación deberá seguir los siguientes pasos:
a. El Service Desk registrará el requerimiento y asignará la actividad al Coordinador de Service Desk, con toda la información necesaria del producto solicitado a instalar.
b. El Coordinador, enviará un correo al Ingeniero de Soporte para que sancione la solicitud. Si el software no esta licenciado la solicitud se rechaza inmediatamente.
c. Recibida la confirmación, el Coordinador asignará al Técnico de Terreno, al Ingeniero de Soporte, o ambos si corresponde para informar y proceder con la ejecución de la instalación.
d. En caso que la solicitud sea negativa, se informará al usuario POLÍTICA ACCESO A INTERNET
1. El acceso a Internet está disponible a todo el personal del holding y sus filiales. 2. El usuario realizará un llamado al Service Desk solicitando el acceso a
INTERNET, se registrará el requerimiento y se procederá al igual que en el procedimiento de instalación de Software.
3. La salida a Internet se realiza a través de un servidor PROXY. 4. El acceso de personas que no pertenezcan al holding y sus filiales, deben ser
autorizado por la línea ejecutiva respectiva.
144
POLÍTICA DE CONEXIÓN DE EQUIPAMIENTO A LA RED
1. El servicio TIC es el responsable de aprobar la incorporación de equipamiento computacional a la red con el objeto de cautelar la confidencialidad, disponibilidad e integridad del recurso de información de la empresa.
2. Esta política se basa en los siguientes principios: a. Ingreso seguro a la red. Todo equipo que no pertenezca al holding y sus
filiales debe ser chequeado técnicamente por personal autorizado con el objeto de asegurar que no produzcan problemas en el funcionamiento de la red computacional.
b. Disponibilidad de Software. Los equipos deben disponer del software y sus respectivas licencias que permitan asegurar un adecuado funcionamiento y el cumplimiento de leyes de propiedad intelectual.
c. Configuración estándar de equipos. Los equipos deben tener la configuración estándar de los equipos computacionales de la empresa.
d. Operación segura de equipos conectados de terceros. 3. La detección de una anomalía en algún equipo conectado a la red, que atente
contra la seguridad, debe ser aislado hasta que se supere los inconvenientes y se logre un re-ingreso seguro.
4. Los equipos conectados a la red deben contener necesariamente antivirus. En el caso de que no lo tuviesen, se proporcionará el software durante el tiempo que el computador se encuentre en operación.
145
ANEXO II: Procedimiento de Paso a Producción OBJETIVOS Establecer las normas y procedimiento para los pasos a producción. Disminuir el impacto de los pasos a producción sobre la plataforma informática en operación. Controlar y documentar la puesta en marcha de hardware, servicios, software y servidores. ALCANCE Aplicable a todo el personal del holding y sus filiales. RESPONSABILIDADES Project Manager, Ingeniero de Proyectos, Ingeniero de Mantención: Realiza una solicitud de paso a producción y apoya las actividades relacionadas de la solicitud. Jefe de Operaciones, Jefe de Ingeniería: Aprueba, autoriza o rechaza cualquier tipo de solicitud de paso a producción. Ingeniero de Sistemas: Ejecuta el paso a producción según la documentación entregada. Administrador de base de datos: Ejecuta el paso a producción según la documentación entregada. Coordinación Service Desk: Asigna y coordina el requerimiento de paso a producción. Mesa de Cambios: Instancia (reunión) donde son analizados los cambios en la plataforma de servidores derivados de: pasos a producción, mejoras operacionales, o cualquier cambio que signifique una modificación en la configuración de uno o más servidores. EQUIPOS Y MATERIALES
1. Plan de paso a producción: Conjunto de actividades tendientes a realizar el paso a producción. El plan deberá poseer al menos la siguiente información:
a. Actividad a realizar. b. Tiempo estimado de la actividad. c. Responsable de la actividad.
2. Plan de reversa del paso a producción: Conjunto de actividades tendientes a reversar un paso a producción. El plan deberá poseer al menos la siguiente información:
a. Actividad a realizar. b. Tiempo estimado de la actividad.
146
c. Responsable de la actividad. 3. Plan de contingencia: Conjunto de actividades que será aplicado en caso de
presentarse problemas con el servicio, software o el servidor que se encuentra o que se está pasando a producción.
4. Plan de pruebas ejecutado: Conjunto de actividades realizadas sobre el software que aseguran y demuestran su buen funcionamiento.
5. Procedimiento de instalación de productos de software: Documento orientado al soporte, que muestra paso a paso como realizar la instalación de un producto de software.
6. Documento de especificación de plataforma: Documento único donde se especifica técnicamente los elementos de un paso a producción de servidor, servicio, o software sobre un servidor. Se deberán completar las secciones que apliquen a la actividad que se realizará.
7. Protocolo de entrega: Certificado de la conformidad del paso a producción. 8. Scripts de base de datos. 9. Artefactos de software. 10. Sitios o páginas web. 11. Servicios. 12. Equipos computacionales.
NORMAS GENERALES
1. El Gestor de Proyectos, Ingeniero de Proyectos, Ingeniero de Mantención son las únicas personas autorizadas para solicitar un paso a producción. A falta de esta persona por enfermedad, vacaciones u otro motivo, el Subgerente de área deberá designar un representante que realizará la solicitud. La designación deberá ser comunicada a Infraestructura y Servicio al Cliente. En último caso el comité de subgerentes, deberá resolver cuales son las personas autorizadas.
2. Se deberá entregar obligatoriamente la siguiente documentación, según los siguientes casos:
a. Base de Datos. i. Plan de paso a producción. ii. Plan de reversa del paso a producción. iii. Plan de contingencia. iv. Plan de pruebas ejecutado. v. Protocolo de entrega.
b. Aplication Server. i. Plan de paso a producción. ii. Plan de reversa del paso a producción. iii. Plan de contingencia. iv. Plan de pruebas ejecutado. v. Protocolo de entrega.
c. Sitios y páginas web. i. Plan de paso a producción. ii. Plan de reversa del paso a producción. iii. Plan de contingencia. iv. Plan de pruebas ejecutado. v. Protocolo de entrega.
d. Servicios y software sobre servidores en operación.
147
i. Plan de paso a producción. ii. Plan de reversa del paso a producción. iii. Plan de contingencia. iv. Documento de especificación de plataforma. v. Protocolo de entrega.
e. Servidores. i. Plan de paso a producción. ii. Plan de reversa del paso a producción. iii. Plan de contingencia. iv. Documento de especificación de plataforma. v. Protocolo de entrega.
f. Productos de software. i. Plan de paso a producción. ii. Plan de reversa del paso a producción. iii. Plan de contingencia. iv. Procedimiento de instalación para técnicos en terreno. v. Protocolo de entrega.
g. Otros no especificados. i. Plan de paso a producción. ii. Plan de reversa del paso a producción. iii. Plan de contingencia. iv. Plan de pruebas ejecutado. v. Documento de especificación de plataforma. vi. Procedimiento de instalación. vii. Protocolo de entrega.
3. Una solicitud de paso a producción podrá ser rechazada en los siguientes casos: a. No presentación de uno o más documentos mencionados en el punto 2. b. Incompletitud, no entendimiento, o inconsistencia de la documentación
entregada. 4. Las personas facultadas para rechazar un paso a producción son el Ingeniero de
Soporte, el Administrador de Base de Datos y el Ingeniero de Sistemas. 5. Todo paso a producción que afecte a la plataforma de redes de área local,
servidores y sus servicios en operación deberá ser autorizada por Infraestructura. 6. Horarios para pasos a producción:
a. Base de Datos: Lunes y Miércoles a partir de las 18:00 hrs. b. Aplication Server: Lunes y Miércoles a partir de las 18:00 hrs. c. Productos de software: Lunes a Jueves de 12:30 a 14:00 hrs y después
de las 18:00 hrs. d. Sitios Intranet: Lunes a Jueves a partir de las 18:00 hrs. e. Sitios y páginas Internet (Extranet) para Chile: Lunes a Jueves a partir de
las 18:00 hrs. f. Sitios y páginas Internet (Extranet) para resto del mundo: Lunes a Jueves
a cualquier hora del día. g. Servicios: Domingo a Jueves según mejor ventana de tiempo previamente
acordada con la empresa. h. Servidores nuevos: Lunes a Jueves a cualquier hora del día. i. Otros no especificados: Lunes a Jueves según mejor ventana de tiempo
previamente acordada con el cliente.
148
7. No se realizarán pasos a producción los días Viernes, Sábados y Festivos salvo expresa autorización con la debida justificación.
8. Se define como hora de cierre para los pasos a producción ingresados el mismo día lo siguiente:
a. Base de Datos: Lunes y Miércoles hasta las 16:30 hrs. b. Aplication Server: Lunes y Miércoles hasta las 16:30 hrs. c. Productos de software: Lunes a Jueves hasta las 11:30 hrs. y hasta las
17:00 hrs. d. Sitios Intranet: Lunes a Jueves hasta las 17:00 hrs. e. Sitios y páginas Internet (Extranet) para Chile: Lunes a Jueves a hasta las
17:00 hrs. f. Sitios y páginas Internet (Extranet) para resto del mundo: Una hora antes
de realizar el paso a producción. g. Servicios: Según planificación. h. Servidores nuevos: Según planificación. i. Otros no especificados: Según planificación.
9. En caso de presentarse una contingencia que signifique realizar un paso a producción fuera de los horarios mencionados en el punto 6 y que comprometa la continuidad operacional de la empresa, se deberá solicitar autorización para la realización de la actividad. La contingencia deberá estar debidamente justificada y podrá ser rechazada si:
a. No se presenta la justificación b. La justificación es inconsistente o incompleta, o no explica claramente la
contingencia del negocio. c. No se cumplen los requisitos mínimos de documentación para un paso a
producción. 10. Debido a la dinámica y exigencias del negocio de las empresas, se podrán
realizar pasos a producción extraordinarios durante horarios distintos a los definidos en este procedimiento. Para ello se solicitará al usuario final o área cliente una justificación donde se especifiquen claramente los motivos por los cuales se requiere el paso. Además se deberá solicitar autorización por e-mail, indicando fecha y hora de la actividad y la justificación del usuario o área cliente. El paso a producción extraordinario podrá ser rechazado si:
a. No se presenta la justificación del usuario. b. La justificación es inconsistente o incompleta, o no explica claramente la
necesidad del negocio a satisfacer. c. Se presentan situaciones de carga en la o las plataformas que se verían
afectadas. d. No se cumplen los requisitos mínimos de documentación para un paso a
producción. 11. Durante un paso a producción se deberá contar con la presencia del
desarrollador ya sea en el lugar donde se realiza la actividad o por teléfono. Su labor durante el paso a producción será la de apoyar la actividad según sea requerido.
12. Todo producto de software y/o servicio y/o servidor y en general cualquier pieza de software y/o hardware que no haya sido entregada y protocolizada según el procedimiento mencionado en el documento, facultará a Infraestructura y Soporte para derivar directamente cualquier requerimiento o contingencia al desarrollador responsable por dichas piezas.
149
PROCEDIMIENTO
1. La solicitud de paso a producción se registrará a través de la aplicación de service desk, adjuntando la documentación mencionada y los artefactos a pasar a producción.
2. El Coordinador asignará el requerimiento según lo siguiente: a. Base de Datos: Administrador de base de datos. b. Aplication Server: Administrador de base de datos o Ingeniero de
Sistemas. c. Productos de software: Coordinación de técnicos de terreno. d. Sitios Intranet: Ingeniero de Sistemas. e. Sitios y páginas Internet (Extranet) para Chile: Ingeniero de Sistemas. f. Sitios y páginas Internet (Extranet) para resto del mundo: Ingeniero de
Sistemas. g. Servicios: Ingeniero de Sistemas. h. Servidores nuevos: Ingeniero de Sistemas. i. Otros no especificados: Ingeniero de Sistemas.
3. Los administradores, recibirán y revisarán la información entregada por el desarrollador y podrán rechazar la solicitud. De no haber objeciones o rechazo, se procederá como sigue:
a. Base de Datos: El DBA procederá a programar la fecha y hora del paso a producción y notificará al desarrollador de la actividad.
b. Aplication Server: Administrador de base de datos o Ingeniero de Sistemas, según sea el caso procederá a programar la fecha y hora del paso a producción y notificará al desarrollador de la actividad.
c. Productos de software: La coordinación solicitará a un técnico en terreno probar el procedimiento de instalación del software, en caso de que se presentasen dudas o inconvenientes, el técnico reportará a la coordinación el problema y se rechazará la solicitud, también informará al desarrollador las causas del rechazo. Para está actividad el técnico en terreno contará con un tiempo de 30 minutos a contar de la asignación del requerimiento. Si no se presentan inconvenientes y una vez probado el procedimiento de instalación, el Ingeniero de Sistemas procederá a copiar el software al repositorio de programas de instalación de cada empresa y se agendará la instalación definitiva para los usuarios.
d. Sitios Intranet: El Ingeniero de Sistemas procederá a programar la fecha y hora del paso a producción y notificará al desarrollador de la actividad.
e. Sitios y páginas Internet (Extranet) para Chile: El Ingeniero de Sistemas procederá a programar la fecha y hora del paso a producción y notificará al desarrollador de la actividad.
f. Sitios y páginas Internet (Extranet) para resto del mundo: El Ingeniero de Sistemas procederá a programar la fecha y hora del paso a producción y notificará al desarrollador de la actividad.
g. Servicios: El Ingeniero de Sistemas solicitará autorización al Jefe de Operaciones, quién podrá autorizar o rechazar la solicitud y convocar a la “mesa de cambios” según sea el caso. De no haber objeciones se procederá según los horarios mencionados anteriormente. Si una solicitud
150
es rechazada será informada al desarrollador junto con las recomendaciones a seguir.
h. Servidores nuevos: El Ingeniero de Sistemas solicitará autorización al Jefe de Operaciones quién podrá autorizar o rechazar la solicitud y convocar a la “mesa de cambios” según sea el caso. De no haber objeciones se procederá según los horarios mencionados anteriormente. Si una solicitud es rechazada será informada al desarrollador, junto con las recomendaciones a seguir.
i. Otros no especificados: El Ingeniero de Sistemas solicitará autorización al Jefe de Operaciones, quién podrá autorizar o rechazar la solicitud y convocar a la “mesa de cambios” según sea el caso. De no haber objeciones se procederá según los horarios mencionados anteriormente. Si una solicitud es rechazada será informada al desarrollador junto con las recomendaciones a seguir.
4. Finalmente, una vez que se ha realizado el paso a producción, el desarrollador deberá entregar el protocolo de entrega a Soporte e Infraestructura.
151
ANEXO II: Procedimiento de monitoreo de un servidor OBJETIVOS Establecer el procedimiento de monitoreo y eliminación de procesos inactivos en el servidor. Nivelar la carga de procesos relacionados con iAS del servidor. ALCANCE Aplicable a todo el personal que realiza administración de servicios y servidores. RESPONSABILIDADES Ingeniero de Sistemas Ejecuta este procedimiento. Administrador de Base de Datos: Apoya las actividades de este procedimiento. EQUIPOS Y MATERIALES Se requiere conexión vía telnet al servidor. NORMAS GENERALES
1. La revisión y eliminación de procesos debe realizarse 1 vez a la semana a cualquier hora del día.
PROCEDIMIENTO
1. Conectarse al servidor mediante telnet, utilizar la cuenta oracle. 2. Verificar la carga del servidor mediante el comando: sudo topas, este comando
solicitara el password de la cuenta la primera vez que sea ejecutado. 3. El comando topas nos muestra el estado general de carga del servidor y los
procesos más consumidores. Para el caso del servidor los parámetros básicos normales de operación son los siguientes:
a. User <= 10. b. Runqueue <= 1. c. Waitqueue <= 2% . d. Utilización de CPU por proceso < 1% (lista de procesos).
152
4. En caso de presentarse anormalidades se debe proceder como sigue:
a. Caso 1: Dos o más procesos poseen un uso de CPU mayor al 20% y son antiguos
i. Verificar que el proceso sea f60webm o f60runm. ii. Verificar antigüedad del proceso con el comando ps –fea | grep
PID, donde PID es el identificador de procesos. iii. Si el proceso tiene una antigüedad superior a un día, entonces se
debe hacer un kill -9 PID, donde PID es el identificador de procesos.
b. Caso 2: Dos o más procesos poseen un uso de CPU mayor al 20% y no son antiguos, vale decir se encuentra dentro del mismo día.
i. Verificar que el proceso sea f60webm o f60runm. ii. Verificar antigüedad del proceso con el comando ps –fea | grep
PID, donde PID es el identificador de procesos. iii. Identificar junto con el DBA la operación de base de datos o form
involucrado. iv. Una vez identificado, informar al Coordinador de Sistemas para su
corrección. 5. Verificar la antigüedad de procesos mediante el comando ps –fea. En AIX el
comando produce la siguiente salida:
153
El PID corresponde al segundo campo y la antigüedad al quinto campo.
6. Ejecutar el comando kill -9 PID, donde PID es el identificador de procesos, a todos los procesos que:
a. Sean f60runm o f60webm. b. Posean una antigüedad superior a un día.
Por ejemplo, el proceso 103490 está activo desde el 2 de Enero (Jan 02), si estamos en el mes de Febrero este proceso es antiguo, luego se debe hacer un kill -9 103490, el resultado es:
Hay que notar que el proceso 103490 tenía como proceso padre (segundo campo) el PID 1, esto significa que el proceso no es un “subproceso” o un thread.
154
Si se hace un kill a un proceso cuyo proceso padre no es el PID 1, entonces al ejecutar nuevamente ps –fea nos encontraremos con que dicho proceso queda en estado <defunct>, esto quiere decir que este proceso es un “subproceso” o un thread. El estado <defunct> puede generar procesos de tipo zombie (hacen nada) y pueden ser eliminados por el propio scheduler del sistema operativo.
