Propuesta de Mejora de Gestión de Servicios TI Utilizando el Modelo eSCM-SP

1. Universidad Técnica Federico Santa María
Departamento de Informática
Programa Magíster en Tecnologías de la Información
Propuesta de Mejora de Gestión de Servicios TI
Utilizando el Modelo eSCM-SP
Daniel Antonio Eugenín Morales
IT Linux Ltda.
General Holley 2363 of. 1301 – Providencia, Santiago
deugenin@it-linux.cl
Resumen. El presente trabajo tiene por finalidad desarrollar una propuesta de mejoras para la gestión de los
servicios TI, definida en la incorporación de buenas prácticas, y fundamentada en la búsqueda de la mejora
continua así como también en establecer un valor agregado diferenciador dentro del mercado de las empresas
proveedoras de servicios TI, con el fin de mejorar las capacidades a lo largo del ciclo de vida de la prestación de
servicios TI de una empresa en particular.
1. Introducción
El eSourcing se refiere a la prestación de servicios que utilizan las Tecnologías de la Información como un
componente clave o como un facilitador. Los proveedores de servicios utilizan las TI como un componente clave en la
entrega de sus servicios. Estos servicios incluyen mantenimiento de escritorio, soporte de centros de datos y aplicaciones
gestión, así como los servicios BPO (Business Process Outsourcing) como recursos humanos, callcenters, servicios de
ingeniería, entre otros. [3]
La organización sobre la cual se desarrolla este proyecto posee como principal línea de negocio la realización de
diferentes servicios TI basados en plataforma Linux. Actualmente, la organización no utiliza ningún tipo de metodología o
modelo formal para la ejecución de sus trabajos, lo cual, a futuro, puede provocar ciertos inconvenientes tales como
deficiencias en los tiempos de respuesta ante incidentes, en la gestión de riesgos, en la calidad de los servicios ofrecidos,
entre otros.
Ante esta situación, se hace necesaria la implantación de una metodología “ad-hoc” que recoja las buenas prácticas de
diferentes modelos existentes y que puedan ser aplicadas al interior de la organización, considerando su tamaño, naturaleza
y particularidad de sus servicios.

2. Dado el tamaño de la organización, y considerando el reducido número de personal, se ha escogido un reciente
modelo llamado eSCM (eSourcing Capability Model), el cual considera un conjunto de buenas prácticas con el fin de
ayudar a las organizaciones de sourcing administrar y reducir los riesgos y mejorar sus capacidades a lo largo del ciclo de
vida del sourcing [3]. Estas buenas prácticas sirven como referencia para el diseño y la implementación de un subconjunto
de éstas que permita mejorar la gestión de los servicios TI que la compañía presta, en base a una selección de buenas
prácticas que la compañía requiere y que sean factibles y rápidas de implementar, sin necesidad de cumplir al 100% con
algún estándar o modelo específico.
eSCM-SP (eSourcing Capability Model for Service Providers) es un modelo propuesto por el IT Services
Qualification Center (ITSqc) de la Universidad Carnegie Mellon, el cual toma como referencia las mejores prácticas de
otros modelos, tales como ITIL/ISO 20000, ISO-9000, CMMs, ISO 17799, COBIT y COPC-2000, y puede ser
implementado en paralelo con estos otros frameworks. Ayuda a las organizaciones de sourcing administrar y reducir sus
riesgos y mejorar sus capacidades en todo el ciclo de vida del abastecimiento, puesto que este modelo no sólo incluye la
Entrega, sino que también la Iniciación y Finalización de contratos. Ha sido diseñado para complementar los modelos de
calidad existentes para proveedores de servicios y puedan sacar provecho de sus esfuerzos de mejoras anteriores, como
también para una base de referencia a la implementación de un estándar propio para una empresa proveedora de servicios
TI.
1.1. Objetivos
Como principal objetivo que se ha planteado para este trabajo se tiene la Implementación de Buenas Prácticas para la
mejora de los servicios TI utilizando el modelo eSCM-SP. Adicionalmente, para lograr esto, es necesario cumplir con los
siguientes objetivos específicos:
• Realizar un análisis e identificación de principales características y deficiencias en el actual servicio de
Soporte Técnico que posee la compañía.
• Definir una metodología de trabajo “ad-hoc” utilizando las buenas prácticas del modelo eSCM-SP que
sean factibles de aplicar dentro de área de Soporte Técnico.
• Instanciar en la organización el uso de la metodología diseñada para la prestación de servicios.
• Implementar este modelo en la realización de Soportes a clientes con y sin contrato.
El resultado buscado con la implementación de este proyecto es el de mejorar la gestión y la calidad de los servicios
TI bajo plataforma Linux. Se espera medir los resultados mediante encuestas de satisfacción de clientes (una vez maduradas
las buenas prácticas), así como también concientizar al personal interno de la organización acerca de la importancia que
tiene la implementación de metodologías, específicamente en el área de TI.
1.2. Metodología utilizada
La metodología utilizada para desarrollar este proyecto básicamente consta de los siguientes pasos:
• Investigación: se procede con la investigación y
estudio acerca del modelo eSCM-SP.
• Análisis: se realiza un análisis de la situación
actual de la organización, buscando sus principales
características de operación, como también sus
principales debilidades en los servicios que ésta
área realiza. Se adiciona también las necesidades
propias del negocio que son listadas como una
serie de requerimientos.
• Diseño: de acuerdo al estudio realizado, y
considerando las debilidades encontradas como los
Fuente: elaboración propia requerimientos del negocio, se realiza el diseño de una
metodología de trabajo utilizando las buenas prácticas
que posee el modelo eSCM-SP, que sean factibles de implementar y aplicar de acuerdo a la realidad de los
servicios de soporte.
• Implementación: se realiza la implementación de las buenas prácticas que han resultado a partir del

3. análisis y diseño previo.
• Análisis de resultados: se realiza un breve análisis objetivo de los resultados de la implementación de esta
metodología. Dado el tiempo disponible, y la poca madurez en que se encuentra la implementación, sólo
se realiza una entrevista al interior de la organización para conocer la percepción interna acerca de la
implementación de esta metodología.
• Documentación: durante todas las etapas del proyecto se realizará la documentación pertinente.
1.3. Organización del Informe
La organización de este informe, sin considerar la parte introductoria, se ha dividido en 4 secciones:
• La primera de ellas corresponde a la definición del marco teórico global, el cual comprende la investigación
acerca del modelo eSCM-SP, sus principales características, y la justificación del por qué se utiliza este
modelo como base para el desarrollo de este proyecto.
• A continuación, se realiza una presentación acerca de la Organización y particularmente el área donde se
implementó este proyecto. Se realiza el análisis de la situación actual del área de la organización donde se ha
desarrollado este proyecto, como también se enumeran los principales requerimientos que el negocio posee
para la mejora de sus servicios TI.
• La siguiente sección describe el método desarrollado para la elección de las áreas de capacidad que se
implementaron en la organización, considerando el análisis de las debilidades encontradas y los
requerimientos del negocio. Adicionalmente, como marco teórico particular, se detalla cada una de las buenas
prácticas que han sido escogidas para su desarrollo e implementación.
• Posteriormente corresponde la implementación de las buenas prácticas, particularmente al trabajo que se
desarrolló y se implementó en la organización. También se mencionan los resultados obtenidos al interior de la
organización como suerte de una primera medición después de la implementación de las buenas prácticas
desarrolladas.
• Finalmente, en la última sección se realizan las conclusiones pertinentes, lecciones aprendidas y
recomendaciones que se puedan realizar como derivadas a la realización de este proyecto.
• Adicionalmente, se adjunta una serie de Anexos que sirven de apoyo a la implementación de este proyecto.
2. Investigación
Durante el desarrollo de este proyecto, es necesario realizar un estudio e investigación acerca del modelo a emplear,
por lo cual este documento se inicia con un resumen acerca del modelo a utilizar.
2.1. Una mirada a eSCM
eSCM (eSourcing Capability Model) es un modelo de referencias que agrupa un conjunto de buenas prácticas
establecidas con el objetivo de ayudar a los Clientes y Proveedores de servicios TI a enfrentar retos directivos que están
asociados con la tercerización de servicios TI. Fue desarrollado por el Information Technology Services Qualification
Center (ITSqc) de la Carnegie Mellon University. [6]
El eSCM está dividido en 2 modelos: eSCM-CL v1.1 (eSourcing Capability Model for Client Organizations), y el
eSCM-SP v2 (eSourcing Capability Model for Service Providers), los cuales están estructurados para concentrar las buenas
prácticas aplicables a Clientes y Proveedores, respectivamente.
Los siguientes esquemas representan el contenido de ambos modelos:

4. eSCM-CL v1.1. El eSourcing Capability Model for
Client Organización (eSCM-CL) está constituido por 17
áreas de capacidad y 95 buenas prácticas definidas con el
objeto de ayudar a las organizaciones “cliente” a
desempeñar eficientemente las actividades desarrolladas
para establecer, administrar y mejorar el Outsoursing de los
servicios de TI. [6]
Fuente: Administración de Outsourcing TI [6]
eSCM-SP v2. El eSourcing Capability Model for
Service Providers (eSCM-SP) está constituido por 10 áreas de
capacidad y 84 buenas prácticas definidas para ayudar a los
“proveedores” de servicios TI a establecer, administrar y
mejorar de forma eficiente las relaciones, lo cual permite a los
proveedores de servicios diferenciarse entre sí por los niveles
de madurez que éstos posean. eSCM-SP es un estándar
certificable de buenas prácticas para aquellas organizaciones
que proveen servicios apoyados en tecnologías de la
información y comunicaciones. [6]
Fuente: Administración de Outsourcing TI [6]
2.1.1. Justificación: ¿ Por qué utilizar este modelo ?
Los modelos eSCM fueron desarrollados con 3 objetivos principales: [5]
• Facilitar a los proveedores de servicios y clientes de sourcing la evaluación y mejora de sus capacidades para
gestionar y proporcionar sistemáticamente servicios de alta calidad
• Facilitar a los proveedores de servicios y clientes a establecer y gestionar de forma continua mejoras en sus
relaciones
• Dar a los clientes una base consistente y objetiva para comparar proveedores durante el proceso de selección
del sourcing
Los modelos eSCM cubren aspectos importantes para las empresas que no se abordan en otros marcos de trabajo, tales
como el ciclo de vida completo de sourcing: análisis, inicio y finalización. Además, son complementarios con el resto de
marcos de trabajo como CMMI o ISO 9001. [5]
Como se muestra en la figura a continuación, el
modelo eSCM-SP cubre áreas de capacidad que otros
modelos o estándares no cubren y que pueden ser
complementarias para su implementación. Existe
numerosa documentación [7, 8] acerca de
comparativas entre eSCM-SP y otros modelos que
puede ser revisada con detalle.
Fuente: Carnegie Mellon University [1]

5. ITIL® y eSCM también son complementarios, pero cada uno desde una perspectiva diferente. ITIL® se centra en la
gestión de servicios, mientras que eSCM se centra en la capacidades del sourcing. Se debe señalar que ITIL® proporciona
una guía básica acerca de las opciones y proveedores del sourcing desde una perspectiva de gestión de servicios, sin
embargo, no cuenta con niveles de capacidad definidos ni los medios para evaluar las capacidades organizativas. [5]
Particularmente, se escogió este modelo puesto que, como se observará más adelante, la organización sobre la cual se
desarrolló este proyecto consta de un número muy reducido de personal, con lo cual, la aplicación de otras normativas como
ISO 9001 o ITIL® se transformaría en una carga de trabajo extra para todos los integrantes de la organización.
A través de la aplicación de buenas prácticas definidas por eSCM, se busca atacar ciertas debilidades que actualmente
posee la organización, así como también mejorar su funcionamiento tanto desde el punto de vista de negocio como de
entrega de los servicios TI. Dado que no es un estándar que obliga a implementar todos los puntos, es posible focalizarse en
aquellos aspectos que son más críticos para el negocio.
Se piensa en un futuro ir aplicando paulatinamente el resto de buenas prácticas que lleven al mejoramiento constante
de los servicios que la organización presta, marcando de esta forma una diferenciación con el resto de las empresas
existentes en el mercado.
Adicionalmente, se piensa que el desarrollo de este trabajo servirá para el resto de las empresas del sector y de otros
sectores que presten servicios TI, en un primer lugar, para que se conozca la existencia de estos modelos, puesto que, al ser
muy recientes, no son aún conocidos en el país.
Se espera, además, que sirva como referencia para otras empresas del sector que deseen mejorar sus servicios TI
utilizando buenas prácticas que sean aplicables a la mejora de sus propias debilidades y requerimientos internos del negocio,
como también para aquellas medianas o grandes empresas proveedoras de servicios TI que actualmente ya poseen otros
modelos y que pueden aprovechar estos modelos para complementar aquellos modelos o metodologías que ya posean,
utilizando un punto de vista diferente del resto, el cual ya no está basado en la gestión de los servicios sino que en las
capacidades del sourcing, como también en la posibilidad que tendrían los clientes para poder medir y comparar los
sourcing de servicios entre diferentes proveedores.
2.2. Descripción General
[3] El estándar eSCM-SP fue desarrollado por el
Information Technology Services Qualification Center
(ITSqc) de la Carnegie Mellon University. Su primera
versión (v1.0) fue lanzada en Noviembre de 2001 y
contenía 100 prácticas. Después de significantes
evaluaciones y revisiones, se liberó la versión 1.1 en
Octubre de 2002 que contenía 93 prácticas. Finalmente,
en Abril de 2004 se libera la actual versión 2, la cual está
compuesta por 84 prácticas, distribuidas a lo largo de tres
dimensiones:
Sourcing Life-Cycle
Capability Area
Capability Level
Cada versión de este modelo fue desarrollada y revisada por una variedad de entradas: revisiones extensas de literatura,
entrevistas con clientes de sourcing y proveedores de servicios, revisiones de frameworks existentes, tests pilotos del
modelo y métodos de certificación, ofertas de entrenamiento, y revisiones técnicas por una mesa de expertos. [3]
2.2.1. Dimensiones
La primera dimensión, Sourcing Life-Cycle, está dividida en 4 secciones: [1]

6. • Ongoing Practices: desarrolladas a lo largo de ciclo de vida
completo del sourcing.
• Initiation: se enfoca en las capacidades necesarias para
preparar la entrega del servicio. Estas prácticas están
relacionadas con obtener requerimiento, negociar, contratar,
diseñar y desplegar el servicio.
• Delivery: se enfoca en las capacidades para entregar el
servicio según lo acordado.
• Completition: se enfoca en las capacidades necesarias para
cerrar efectivamente el servicio al final del ciclo de vida. La
organización transfiere recursos, y la responsabilidad de la entrega del servicio retorna al cliente, o a quien el
cliente designe.
La segunda dimensión, Capability Areas, provee agrupamientos lógicos de prácticas que ayudan a los usuarios a
recordar mejor y administrar intelectualmente el contenido del Modelo. Estos agrupamientos permiten a los proveedores de
servicios construir o demostrar capacidades en cada función crítica del sourcing. [1]
Las 10 Capability Areas son:
Figura: Áreas de capacidad.
knw: Knowledge Management (administración del conocimiento)
cnt: Contracting (contratación)
ppl: People Management (administración de personas)
sdd: Service Design & Deployment (diseño y despliegue del
prf: Performance Management (administración de rendimiento) servicio)
rel: Relationship Management (administración de relaciones) del: Service Delivery (entrega del servicio)
tch: Technology Management (administración de tecnología) tfr: Service Transfer (transferencia del servicio)
thr: Threat Management (administración de amenazas)
La tercera dimensión, Capability Levels, describe los lineamientos de las mejoras que los clientes deben esperar de
los proveedores de servicio. Los niveles son 5:[1]
Capability Level 1 (Proporcionar servicios): un proveedor de servicio es capaz de proveer
servicios pero no tiene implementado todas las prácticas del Nivel 2, y puede tener un alto riesgo
de falla.
Capability Level 2 (Cumplir consistentemente los requerimientos): un proveedor de servicio es
capaz de cumplir consistentemente los requerimientos, y tiene implementado, como mínimo, las
48 prácticas del Nivel 2.

7. Capability Level 3 (Gestionar el desempeño organizacional): un proveedor de servicio es
capaz de proveer servicios de acuerdo a los requerimientos establecidos, incluso si los servicios
requeridos difieren significativamente de la experiencia del proveedor, y tiene, como mínimo,
implementadas las 74 prácticas de los niveles 2 y 3.
Capability Level 4 (Aumentar valor proactivamente): un proveedor
de servicio es capaz de innovar continuamente para agregar valor estadísticamente y
prácticamente significativo a los servicios que provee. Para lograr el Nivel 4, el proveedor de
servicio tiene que implementar satisfactoriamente las 84 prácticas del eSCM-SP.
Capability Level 5 (Excelencia sostenida): un proveedor de servicio ha demostrado un
rendimiento de excelencia mensurable, sostenido y consistente, y mejorando efectivamente la
implementación de las prácticas de los niveles 2, 3 y 4 para dos o más Evaluaciones de
Certificación consecutivas cubriendo un periodo de al menos 2 años. No hay prácticas
adicionales que deban ser implementadas en el nivel 5.
Resumen del modelo:
2.3. Implementando el eSCM-SP
Existen 2 estrategias principales para la mejora de un proveedor de servicios: [1]
- Basado en framework: utiliza modelos y estándares como marco de trabajo para identificar qué procesos y
sistemas deberías ser implementados en una organización exitosa. Mejoramiento basado en eSCM-SP es un ejemplo de esta
estrategia.
- Basado en medición: los procesos y sistemas del proveedor de servicio son medidos y comparados con un
conjunto de objetivos establecidos por la gerencia con el fin de identificar cuáles necesitan ser mejorados.
Un ciclo de mejora continua es una parte crítica de cualquier estrategia de mejora, e incluye 6 pasos:
1) Identificar la necesidad del cambio
2) Establecer el patrocinio para el mejoramiento
3) Diagnosticar problemas y oportunidades de mejoramiento
4) Actuar en el diagnóstico
5) Monitorear los resultados
6) Loopback para continuar con el ciclo de mejora

8. 3. Análisis de la Situación Actual
3.1. Acerca de la Organización
IT Linux Ltda. es una pequeña empresa proveedora de servicios bajo plataforma Linux, entre los cuales se pueden
mencionar servicios de soporte técnico, capacitación, consultoría, y la integración e implementación de proyectos. Sus
principales líneas de negocio son los Servicios de Soporte Técnico y la Implementación de Proyectos.
Específicamente, dentro del área de Soporte Técnico, se atienden a clientes con contrato de soporte, así como también
a otros clientes bajo la modalidad de soporte HH (Hora-Hombre). La atención de los clientes por contrato se realiza en su
mayoría a través de una plataforma de atención a Clientes, llamada Portal de Soporte (basada en el software OTRS1), el cual
básicamente es una plataforma de administración, registro y seguimiento de los casos de soporte de los clientes mediante
tickets.
3.2. Análisis de la Situación Actual
Realizando un análisis de la situación actual del área de Soporte Técnico, se encontraron la siguientes debilidades:
Inexistencia de una base de conocimientos (Knowledgebase): Actualmente no se cuenta con un sistema de base de
conocimientos, lo cual provoca que se tenga que reinventar la rueda muchas veces, al no tener documentada distintas
acciones o soluciones realizadas para resolver problemas particulares y repetitivos en diferentes clientes.
Obligatoriedad del uso del Sistema de tickets: Si bien se posee un sistema de registro y seguimiento de tickets para los
requerimientos de los clientes, éste no es de carácter obligatorio tanto para los clientes como para el personal interno, puesto
que hay clientes acostumbrados a enviar sólo un correo personal, o llamar telefónicamente, cuyas atenciones no son
registradas en el sistema de tickets.
Inexistencia de un Registro de Credenciales: No hay un registro en común de los accesos (credenciales) a los
servidores y sistemas de los clientes, lo cual causa problemas cuando la persona que conoce el acceso no está en la oficina.
Incumplimiento de tiempos de respuesta: Todos los contratos de soporte poseen un tiempo de respuesta de una hora,
es decir, después de que el cliente ha levantado el caso de soporte en el Portal de Soporte, se debe dar alguna respuesta
dentro del tiempo estipulado en el contrato. Con respecto a lo anterior, hay veces en que los tiempos de respuesta no son
respetados porque el personal está trabajando en otros proyectos fuera de la oficina y no hay quién esté atendiendo las
solicitudes de los clientes con contrato de soporte.
Desconocimiento de detalles particulares de contratos: Todos los contratos de soporte son relativamente homogéneos,
pero cada uno de ellos tiene sus propias particularidades, las cuales no son conocidas en su totalidad por el personal de
atención de los contratos de soporte.
Inexistencia de un Registro de Accesos: No se cuenta con un registro de cada acceso que realiza el personal de soporte
a los servidores de los clientes, como tampoco se tiene un registro acerca de qué acciones (comandos) han realizado en cada
servidor de los clientes.
3.3. Requerimientos del Negocio
Los siguientes requerimientos del negocio corresponden a una parte del Plan Estratégico de la organización, en cuanto
al área de Soporte Técnico, el cual tiene como fin el mejorar los servicios que actualmente se prestan mostrando un valor
agregado con respecto a la competencia.
Como requerimiento del negocio se tiene:
1
OTRS = Open source Ticket Request System (http://www.otrs.org)
2
Ruby on Rails: http://www.rubyonrails.org

9. Tiempos de respuesta: Disminuir la tasa de atención de soporte fuera de los tiempos establecidos en los contratos. Si
bien la organización nunca ha tenido problemas mayores (disputas o acciones legales) con los clientes, se hace necesario
que se cumpla con los tiempos de respuesta establecidos en los contratos.
Conectividad: Aumentar la conectividad de los ingenieros de soporte cuando están en terreno. Es decir, que los
ingenieros posean conexión a Internet para poder brindar soporte remoto cuando estén en terreno.
Tiempos de solución: Mejorar los tiempos de solución a las atenciones de soporte, entendiendo como tiempo de
solución al tiempo transcurrido entre la solicitud del cliente hasta que se cierra el caso (ticket) con el detalle de la solución.
Para entender un poco más este concepto, el flujo básico de las atenciones de soporte es el siguiente:
- Cliente solicita soporte mediante un Portal, generando un ticket
- Ingeniero toma el ticket y se conecta al servidor del cliente para realizar la solución al problema
- Ingeniero le informa al cliente que está corregido el problema y le solicita que realice pruebas y confirme
- Cliente confirma el funcionamiento y se cierra el ticket
Políticas de seguridad: Establecer políticas de seguridad en la organización con el fin de proteger la propiedad
intelectual, así como también los datos (accesos y contraseñas) de los clientes que maneja el personal de soporte.
Normalmente en el área de Ingeniería y Soporte Técnico, el personal maneja muchos datos sensibles y confidenciales tanto
para la organización como para el cliente, puesto que puede administrar contraseñas de usuarios, bases de datos,
cortafuegos, y correos electrónicos, entre otros, por lo cual es necesario el establecimiento de Políticas de Seguridad en la
cual se resguarden la confidencialidad, integridad y disponibilidad de la información que se maneja.
Detalles de contratos: Que todo el personal de la organización conozca en profundidad los detalles de cada uno de los
contratos de soporte, en cuanto a los tiempos de respuesta, duración del contrato, horario de atención, contraparte del cliente
y otros detalles de los contratos.
Metodología: Se requiere la implementación de buenas prácticas dentro de la organización con el fin de mejorar la
calidad y eficiencia de los servicios; éstas deben ser fáciles y rápidas de implementar, y que ayude al personal a mejorar su
trabajo en directa relación con los clientes.

10. 4. Diseño y Propuesta de Prácticas
A continuación se realiza la definición de un método de priorización con el cual será posible distingir cuáles de las
áreas de capacidad serán las que más se ajustan -o resuelven- las debilidades encontradas en el análisis de la situación actual
de la organización, como también los requerimientos del negocio.
4.1. Método de Priorización
Para la elección de las áreas de capacidad a abordar, se ha realizado una matriz de priorización, en la cual se
ponderaron las siguientes variables: Área de Capacidad vs. Debilidad encontrada en la empresa y Requerimientos del
Negocio.
La idea de esta matriz de priorización es definir el orden en el cual se desarrollarán a futuro las áreas de capacidad.
Service
Debilidades y Knowledge Threat Technology Service Service Relationship People Performance
Contracting Design &
requerimientos management Management Management Transfer Delivery Management Management Management
Development
Base de conocimiento X
Registro de accesos a
servidores X
Información unificada
de credenciales X
Información detallada
de Contratos X
Control de cambios X
Personal no disponible X
Tiempos de respuesta X X
Conectividad X
Tiempos de solución X X
Políticas de seguridad X X
Detalles de contratos X X X
Metodología
4.1.1. Selección de Áreas de Capacidad
De acuerdo a la tabla anterior, se han seleccionado las siguientes áreas de capacidad:
Knowledge management (8 prácticas)
Threat management (7 prácticas)
Estas áreas de capacidad son escogidas a raíz del análisis de la situación actual de la provisión de servicios de la
empresa, de la cual, las principales debilidades se presentan en estas 2 áreas. Adicionalmente, se ha acotado el desarrollo de
esta tesina a estas áreas dado el tiempo disponible para el desarrollo de ésta.
4.1.2. Roadmap
Durante el desarrollo de esta tesina, la organización se ha concientizado y ha apostado por continuar con el desarrollo
e implementación de las buenas prácticas, para lo cual se ha definido un roadmap de implementación a futuro, posterior a la
finalización de esta tesina:
Technology Management
Service Transfer

11. Service Delivery
Relationship Management
People Management
Performance Management
Contracting
Service Design & Development
El objetivo principal de la organización es el de -en primer lugar- establecer las bases para un mejora de los servicios
que actualmente se desarrollan, así como también poseer un elemento diferenciador con respecto a la competencia.
4.2. Descripción detallada de las Áreas de Capacidad
A continuación se describe las áreas de capacidad seleccionadas y sus prácticas asociadas, para lo cual se presenta una breve
descripción de la práctica, describiendo sus requerimientos y el propósito de la práctica así como también sus beneficios
esperados.
4.2.1. Knowledge Management (knw)
Las prácticas de la Administración del Conocimiento están enfocadas en el manejo de la información y sistemas de
conocimiento con el fin de que el personal tenga un acceso fácil al conocimiento que necesitan para trabajar efectivamente.
Todas las prácticas de la Administración de Conocimiento son en curso (Ongoing) y cubren lo siguiente: [2]
• Demostrar un compromiso para compartir el conocimiento a través de políticas formales.
• Proveer la información necesaria al personal en un sistema de conocimiento que permita acceso controlado,
pero eficiente.
• Administrar efectivamente el uso de los activos de los procesos a través de la organización, asegurando
consistencia. Reutilizar activos de los procesos para mejorar la efectividad del personal y tomar ventaja de
prácticas expertas.
• Controlar los cambios a los productos a través del control de versiones y el control de cambios.
• Mantener la información en el uso de recursos y lecciones aprendidas para mejorar el rendimiento actual y
futuro.
knw01: Share Knowledge (Compartir el Conocimiento)
Establecer e implementar una política para compartir el conocimiento para las partes interesadas.
Fomentar el compartir el conocimiento entre los stakeholders con el fin de que puedan aprender y mejorar el
rendimiento mientras ellos establecen relaciones más fuertes entre sí. Una política de compartir también clarifica las reglas
por las cuales el conocimiento puede ser compartido entre la organización, cliente, proveedor y partners. [2]
knw02: Provide Required Information (Facilitar la Información Requerida)
Identificar, controlar y proveer la información que el personal necesita para desarrollar su trabajo.
Proveer acceso a la información que es esencial para que el personal realice su trabajo, de tal forma que trabaje
eficientemente. Se deben mantener los apropiados niveles de control, incluyendo control de versiones de documentos,
control de accesos para asegurar que las personas apropiadas tengan el acceso apropiado a la información, y que la
mantención de la información sea consistente con el enfoque de la organización (políticas y procedimientos) para la
seguridad y protección de la propiedad intelectual. La facilidad de acceso para la información requerida permite al personal
ser más eficiente y efectivo en el rendimiento de su trabajo. [2]
knw03: Knowledge System (Sistema de Conocimiento)
Establecer y mantener un sistema de conocimiento para identificar, controlar y proveer información.
Proveer un sistema de conocimiento coordinado con el fin de permitir a la organización mantener la información
actual y permitir al personal localizar fácilmente la información requerida. Un sistema de conocimiento no es
necesariamente un repositorio electrónico central de información sino un método coordinado para administrar y comunicar
la información necesaria. Un sistema de conocimiento puede ser implementado mediante una o más bases de datos, sistemas
de archivos, medios físicos de storage, u otro método apropiado para proveer sistemáticamente el acceso y control necesario

12. de la información. [2]
Esta práctica expande el knw02, la cual cubre la provisión de la información que el personal necesita para desarrollar
su trabajo. El foco de esta práctica es expandida a controlar y proveer información y conocimiento mediante un sistema
formal de conocimiento. Esta práctica está fuertemente relacionada con knw04, dado que este sistema de conocimiento es el
primer lugar donde los activos de los procesos son mantenidos, y es considerado como un activo de procesos en sí mismos.
[2]
knw04: Process Assets (Activos de los Procesos)
Establecer y mantener un conjunto de activos procesos para el uso a través de la organización.
Crear un conjunto consistente de activos de procesos a través de compromisos con el fin de ayudar a la organización
lograr economías de escala y aplicar buenas prácticas desde antes de los compromisos hasta nuevos compromisos similares.
Enfocarse en recolectar sistemáticamente el conocimiento es fundamental para el aprendizaje organizacional.
Proporcionando un conjunto coordinado de activos de procesos permite que el conocimiento recolectado esté disponible
consistentemente para los compromisos. [2]
Los activos de procesos incluyen cualquier documentación de lineamientos – últimos documentos que proveen guías
en cómo debe ser desarrollado el trabajo – tales como procesos, políticas, procedimientos, lineamientos, ayudas de trabajos,
plantillas, checklists, etc. Los activos de procesos también incluyen infraestructura, tales como repositorios y las
herramientas necesarias para ejecutar el trabajo descrito en la documentación de lineamientos. [2]
knw05: Engagement Knowledge (Compromiso del Conocimiento)
Analizar y utilizar el conocimiento ganado de los compromisos de los clientes.
Utilizar las lecciones aprendidas desde compromisos actuales y pasados con el fin de hacer mejoras en los
compromisos actuales y futuros. Analizando y utilizando efectivamente el compromiso ganado desde compromisos
anteriores y actuales permite a la organización reutilizar sus mejores prácticas, para direccionar problemas que han ocurrido
y para mejorar el rendimiento general de los compromisos actuales y futuros. [2]
knw06: Reuse (Reutilización)
Identificar y reutilizar productos de trabajo.
Facilitar el acceso a los productos de trabajo anteriores con el fin de permitir al personal tomar ventaja de sucesos
pasados y para propagar prácticas expertas. Reutilizar los productos de trabajo puede ayudar a la organización guardar un
considerable monto de esfuerzo, tiempo y costos mientras también se ayuda a estandarizar la calidad de los productos de
trabajo. [2]
knw07: Version & Change Control (Control de Versiones y Cambios)
Establecer e implementar procedimientos para aplicar un control de versiones y un control de cambios a los
productos de trabajo.
Controlar los cambios a los productos de trabajo con el fin de mantener la integridad del servicio. El control de
versiones involucra el seguimiento a los cambios de los productos de trabajo de una manera controlada, con la versión de
cada producto de trabajo que pueda ser identificada. El control de cambios consiste en el análisis, coordinación, aprobación
o desaprobación, e implementación de cambios a los productos de trabajo. Tanto el control de versión como el control de
cambios son requeridos para mantener la integridad del servicio, pero el rigor de utilizar el control de cambios dependerá de
las necesidades del cliente y la organización. [2]
knw08: Resource Consumption (Consumo de Recursos)
Establecer e implementar procedimientos para analizar y utilizar la información de los recursos consumidos.
Entender el uso de recursos para los compromisos actuales del cliente con el fin de mejorar el entendimiento y el
control de la utilización de recursos. Este entendimiento es la información base de estimaciones precisas y planificación de
los recursos requeridos para los nuevos compromisos del cliente. El análisis de los recursos permite a la organización
estimar con precisión las necesidades de balance y uso futuro, mientras se entrega el servicio a los clientes existentes. [2]
4.3. Threat Management (thr)
Las prácticas de la Administración de Amenazas se enfocan en la identificación y administración activa de las
amenazas para que la organización tenga la capacidad de cumplir sus objetivos y los requerimientos del cliente. Se enfocan
en la administración activa de los riesgos, poniendo particular atención en los riesgos asociados con la seguridad,
confidencialidad, infraestructura y desastres que puedan interrumpir el servicio o fallar para cumplir con los requerimientos
del cliente. Todas las prácticas de la Administración de Amenazas son en curso (Ongoing) y cubren lo siguiente: [2]

13. • Demostrar el compromiso de la gerencia para administrar el riesgo a través de políticas formales
• Identificar, evaluar y controlar riesgos
• Administrar las amenazas de seguridad, confidencialidad y propiedad intelectual
• Prepararse para, y administrar la recuperación ante desastres
• Monitorear los estados y regulaciones para asegurar el cumplimiento
thr01: Risk Management (Administración de Riesgos)
Establecer e implementar una política de administración de riesgos.
Demostrar el compromiso de la gerencia para proactivamente identificar, evaluar y administrar los riesgos con el fin
de mejorar la habilidad de la organización para proveer apropiados niveles de servicios a pesar de la ocurrencia de
amenazas. Una política documentada ayuda a demostrar el compromiso de la gerencia y provee una aproximación de cómo
la organización debe manejar los riesgos. También éste es el primer paso para demostrar el compromiso con los
requerimientos regulatorios y contractuales. Una política de administración de riesgos también provee las directrices para
los stakeholders internos en su esfuerzo de administrar proactivamente el riesgo. [2]
thr02: Engagement Risk (Compromiso con el Riesgo)
Identificar, evaluar, y administrar los riesgos específicos para el compromiso con el cliente.
Administrar los riesgos con el fin de reducir su impacto e incrementar la confianza con los clientes en la habilidad de
la organización para mantener los niveles de servicios deseados. Identificando y evaluando los riesgos eficientemente
permite a la organización tomar acciones de mitigación para prevenir la ocurrencia de riesgos, para bajar su probabilidad de
ocurrencia, o reducir su impacto, cuando este ocurra. Estas acciones mejoran la habilidad de la organización para proveer un
nivel de servicio apropiado a pesar de la ocurrencia de problemas. [2]
La administración de riesgos efectiva es particularmente crítica en las primeras etapas de un compromiso, donde los
requerimientos están siendo analizados y el servicio está siendo diseñado para satisfacer estos requerimientos. Los
problemas encontrados aquí pueden impactar la entrega satisfactoria del servicio en todo el compromiso. [2]
thr03: Risk Across Engagements (Riesgo a través de Compromisos)
Establecer e implementar procedimientos de administración de riesgos a través de compromisos con el cliente.
Establecer un enfoque para la administración de riesgos con el fin de reducir su impacto y proveer a los clientes con
confianza en la habilidad de la organización para mantener los niveles de servicio deseados. La identificación efectiva y la
evaluación de riesgo permite a la organización tomar acciones de mitigación para prevenir el riesgo desde su ocurrencia, o
bajar el impacto cuando éste ocurra. Este esfuerzo mejora la habilidad de la organización para proveer niveles apropiados de
servicios a pesar de la ocurrencia de problemas. La administración de riesgos efectiva mejora la confianza de los clientes en
la habilidad de la organización para mantener los servicios y los niveles de servicios necesarios. Mediante la administración
de riesgos efectiva, la organización puede balancear los riesgos a través de múltiples compromisos. [2]
thr04: Security (Seguridad)
Establecer e implementar procedimientos para cumplir con los requerimientos de seguridad.
Cumplir o superar los requerimientos de los stakeholders respecto de la seguridad con el fin de fomentar las relaciones
satisfactorias con el cliente e incrementar los niveles de confianza. Quiebres, tales como violaciones de seguridad, pueden
impactar la habilidad de la organización para proveer un servicio adecuado, de tal modo de dañar la relación y hacer a las
partes vulnerables a acciones legales. La seguridad efectiva es esencial para cumplir los requerimientos de privacidad y
proteger la propiedad intelectual (thr05). Los requerimientos de seguridad pueden venir desde el cliente o de estatutos y
regulaciones que gobiernan el servicio. La administración de la seguridad debe cubrir la seguridad de las personas,
tecnología, ambiente de trabajo y la información. [2]
Tal como se usa en esta práctica, la seguridad provee 4 tipos de control: confidencialidad, integridad, disponibilidad y
rendición de cuentas. Confidencialidad significa que sólo los usuarios autorizados pueden acceder a la información.
Integridad significa que la exactitud y completitud de la información es mantenida y no es cambiada sin autorización.
Disponibilidad significa que el servicio o la información está disponible para usuarios autorizados cuando lo necesiten.
Rendición de cuentas es la habilidad de realizar trazas del origen de los cambios en los recursos controlados. [2]
thr05: Intellectual Property (Propiedad Intelectual)
Establecer e implementar procedimientos para proteger la propiedad intelectual de los interesados.
Cumplir o exceder los requerimientos de los stakeholders respecto de la protección de la propiedad intelectual para
incrementar los niveles de confianza, con el fin de fomentar relaciones satisfactorias. El uso inapropiado o divulgación de
propiedad intelectual puede dañar las relaciones con los stakeholders y hacer a la organización vulnerable a disputas o

14. acciones legales. [2]
Esta práctica está relacionada con thr04, porque los procedimientos de seguridad deben asegurar que la propiedad
intelectual está protegida apropiadamente. [2]
thr06: Statutory & Regulatory Compliance (Cumplimiento Legal y Regulatorio)
Establecer e implementar procedimientos para cumplir con los requerimientos legales y regulatorios.
Cumplir con los estatutos y regulaciones que impactan la capacidad de servicio de la organización con el fin de
satisfacer los requerimientos de los clientes y evitar la insatisfacción de los clientes. El cumplimiento es crucial en las
relaciones internacionales de sourcing que están bajo una jurisdicción o múltiples sistemas legales. El cumplimiento con los
estatutos y los requerimientos regulatorios también son necesarios para defender los estándares éticos de la organización y
protegerla de disputas o acciones legales. [2]
thr07: Disaster Recovery (Recuperación de Desastres)
Establecer e implementar procedimientos de recuperación ante desastres.
Prepararse para posibles desastres con el fin de minimizar su impacto en la habilidad de la organización para entregar
sus servicios. Siguiendo los procedimientos de recuperación ante desastres durante fallas significativas de infraestructura o
instalaciones, la organización puede continuar proporcionando un servicio aceptable. La preparación cubre la entrega de
servicios, seguridad, la protección de propiedad intelectual, gestión de crisis, la seguridad del personal y promueve la
confianza en la habilidad de la organización para reaccionar efectivamente ante situaciones adversas. [2]
4.4. Diseño de la implementación
La etapa de diseño de la implementación básicamente consiste en considerar todos los factores mencionados
anteriormente, tales como:
•Análisis de la situación actual
•Requerimientos del negocio
•Selección de buenas prácticas a implementar
•Detalle de las buenas prácticas
Considerando estos puntos, se definió que se empezará con la implementación de un documento maestro, que contenga una
estandarización de la forma de trabajo que normalmente se realiza con los clientes. Este documento será la guía oficial de
trabajo, desde la cual se desprenderán las buenas prácticas a implementar.
Se definió empezar con aquellas buenas prácticas más sencillas de implementar, para posteriormente continuar con aquellas
más complejas, informando al mismo tiempo al personal del área de Ingeniería la inclusión de una nueva buena práctica
para que sea aplicada inmediatamente en los futuros servicios.
5. Implementación e Instanciación
A continuación se presenta el detalle de las buenas prácticas implementadas al interior de la organización. La
implementación de estas buenas prácticas no ha resultado de manera dificultosa puesto que el número del personal que las
emplea es bastante reducido y sólo bastaban pequeñas reuniones informativas de área acerca de las implementaciones de
cada buena práctica, en las cuales se impone la nueva forma de trabajo y se empieza a aplicar inmediatamente.
No se debió ocupar alguna metodología de instanciación o puesta en marcha de estas buenas prácticas, como tampoco
en la preparación del personal interno para estos cambios, dado que sólo se debía realizar una imposición de la nueva
metodología de trabajo a una sola persona, puesto que los otros 2 integrantes del área son los socios de la empresa que ya
estaban de acuerdo previamente en la implementación de estas mejoras.
Con el fin de que el nuevo personal que ingrese a futuro en el área esté al tanto de la forma de trabajo y utilice las
prácticas que ya posee el área, se ha preparado, en conjunto con la implementación de las buenas prácticas, un documento
de Políticas Internas para el área de Ingeniería, el cual se utilizará como documento de apoyo para la inducción del nuevo
personal, como también para el apoyo en el trabajo diario que éste realiza.

15. 5.1. Detalle de Buenas Prácticas
El detalle de las buenas prácticas implementadas al interior de la organización, que se mencionan a continuación,
corresponden al resultado del estudio, análisis, y diseño de las buenas prácticas que se seleccionaron a implementar en esta
tesina.
Wiki/Base de Conocimiento
Este corresponde a una aplicación web en la cual los ingeniero del área pueden ingresar documentación acerca de la
implementación de diferentes servicios, sus archivos de configuración, scripts que normalmente se utilizan, tips de
comandos.
Hasta el momento aún no se ha definido una política de gestión del conocimiento en donde se enmarque qué
contenido, frecuencia o responsabilidades se deben tener con la publicación de contenidos, sino que está sujeta a la libertad
de los ingenieros, en donde se les presenta una plataforma en la cual pueden documentar diferentes configuraciones, scripts
y archivos de configuración de implementaciones que normalmente están realizando.
Esta documentación está abierta al público en general y se puede considerar como una base para futuras
implementaciones de servicios sin necesidad de tener que re-inventar la rueda cada vez que se implementa un servicio ya
realizado en el pasado. Revisar: http://wiki.it-linux.cl
Templates de Informes
Estos corresponden a documentos base que ahora utilizan los ingenieros del área para desarrollar sus informes. Si bien
antes existían bases de informes, éstos no estaban formalizados y la información existente en los informes de
implementación o soporte era la que decidía el ingeniero que realizaba el informe. Ahora se ha estandarizado con una
estructura fija, con tipos y tamaños de letra fijos, así como también qué información mínima se debe incluir en cada
informe, ya sea de implementación de algún servicio como también de la realización de un soporte en algún cliente.
Checklist de Pruebas
Se ha diseñado un documento con un listado de pruebas que se deben realizar cada vez que se implementa algún
servicio en particular. Estas pruebas están organizadas por servicio y son consideradas como las pruebas obligatorias que
debe realizar el ingeniero cuando ha finalizado con la implementación de algún servicio. [APÉNDICE A]
Repositorio de configuraciones
Se ha creado un repositorio de configuraciones de los principales servicios. Normalmente estas corresponden a
configuraciones ya probadas o realizadas en diferentes clientes, las cuales sirven como base para nuevas implementaciones
de estos mismos servicios. Con esto se disminuye notablemente los tiempos de configuración de los servicios que se estén
implementando, dado que ya se tienen las bases de las configuraciones ya probadas y no es necesario re-inventar la rueda
cada vez que se implementa algún servicio en particular.
Políticas de trabajo [APÉNDICE A]
Este corresponde al documento maestro con el cual se inició el diseño de la implementación de las buenas prácticas.
− Guardar backup de configuración
Básicamente se le indicó al personal del área de soporte que, como buena práctica, cada vez que se vaya a modificar un
archivo de configuración de algún cliente, se guarde previamente un backup de dicha configuración con cierta estructura.
Esto con el fin de poder realizar una vuelta atrás en caso de cualquier falla posterior a las modificaciones realizadas. Esto
quedó también plasmado en un documento oficial de área para uso futuro.
− Políticas de establecimiento de contraseñas
Se ha definido una política de establecimiento de contraseñas para todas las instalaciones e implementaciones de servicios
que realiza el personal de Ingeniería, puesto que cada vez que se implementaba algún servicio, se colocaba una contraseña
“por defecto” y se le recomendaba al cliente que la cambiara después que hayan finalizado los servicios de implementación,
actividad que en la mayoría de las veces el cliente no realizaba, quedando el servidor expuesto a ataques dado que la
contraseña por defecto era muy fácil de adivinar. A raíz de esto se definieron nuevas políticas de establecimiento de
contraseñas para todas las implementaciones futuras quedando éstas políticas plasmadas en un documento oficial al interior
del área.

16. − Políticas internas de seguridad
Bajo esta política se ha realizado un sistema de control de conexiones a clientes. Esto quiere decir que, cada vez que uno de
los ingenieros se conecta a cualquier servidor de un cliente, se enviará un correo tanto al cliente como al área de ingeniería
de IT Linux con el registro de quién se ha conectado, desde qué dirección IP y a qué hora se ha conectado.
Adicionalmente, se ha realizado un ajuste en las configuraciones de los servidores de los clientes, puesto que los Sistemas
Operativos Linux guardan un máximo de los últimos 1.000 comandos realizados en el servidor (normalmente) y no guardan
la fecha ni hora en que éstos fueron ejecutados, por lo cual se ha modificado las configuraciones de los Sistemas Operativos
para que ahora guarde un historial de 10.000 comandos con su fecha y hora de ejecución.
Control de Cambios [APÉNDICE A]
En un principio se creó un documento de Control de Cambios para cada cliente con contrato de soporte, el cual
posteriormente fue reemplazado por una aplicación web. Esto se decidió porque el trabajo al interior del área se haría más
tedioso y burocrático, puesto que cada vez que se realizaba una modificación en los archivos de configuración se tenía que
ir a un repositorio central, descargar el archivo, registrar la modificación, y volver a subir el archivo al repositorio central, lo
cual provocaba que el ingeniero gastaba más tiempo en registrar el cambio que la duración del cambio mismo. Esto fue
reemplazado por una interfaz web construida internamente en el área, la cual ayudó a registrar el cambio de forma mucho
más sencilla y sólo con la información que le interesa a la gerencia del área.
Vista de los últimos Controles de Cambios aplicados (se han ocultado los datos sensibles por razones de seguridad)
Esta aplicación web se desarrolló bajo plataforma Ruby on Rails2, la cual permitió un rápido desarrollo de sólo unos
días, y permite mantener el registro de todos los cambios que se realizan en los clientes, con la información requerida por el
área de Soporte:
• Persona que realiza el cambio (automático en el momento en que el ingeniero ingresa al sistema)
• Fecha y hora en que se realiza el cambio (automático)
• Cliente y servidor en que se realiza el cambio
• Qué archivo(s) se han modificado(s)
• Cuáles con los archivos de backup antes del cambio
• Detalle del cambio, en el cual se puede indicar un resumen del por qué se ha realizado el cambio, si
corresponde a un ticket de soporte, si corresponde a un servicio sólo de mantención/prevención, entre otros.
2
Ruby on Rails: http://www.rubyonrails.org

17. Registro unificado de credenciales [APÉNDICE A]
Aprovechando esta aplicación de Control de Cambios, se ha integrado la información de los clientes con contrato de
soporte, la identificación de los servidores que están bajo contrato para cada cliente, así como también la información de los
accesos (credenciales) de cada uno de los servidores.
Aplicación Web de Control de Cambios de IT Linux con la información de las credenciales de acceso a clientes (se han
ocultado los datos sensibles por razones de seguridad)
Con esto se ha solucionado de manera considerable el problema de la mantención de las credenciales de acceso a los
servidores, puesto que no se tenía esta información de forma unificada y cada ingeniero tenía su propio archivo de
credenciales. Ahora esto se ha transformado en la plataforma con la información oficial y actualizada, por lo cual, cada
ingeniero debe conectarse regularmente a esta plataforma para verificar los últimos cambios que se han realizado y para
obtener las credenciales de acceso a los clientes. Esto también servirá para la utilización cuando ingresen nuevos ingenieros
al área, puesto que habrá mucha información que le servirá para su trabajo habitual.
Planilla de tiempos de demora en configuraciones de servicios
Se ha diseñado una planilla con la información de detalle de los trabajos principales que involucra la realización de la
implementación de algún servicio en particular. Básicamente se trata de las principales actividades que involucra la
implementación de algún servicio así como también el tiempo aproximado que se demora la implementación de dicho
servicio, basado en las experiencias anteriores de implementación de dichos servicios.
Esto es de gran ayuda para el área comercial, puesto que esto se considera como base para el cálculo de las horas y
detalles de los trabajos que involucra la implementación de algún servicio, sin tener que estar realizando estos cálculos y
escribiendo los detalles de trabajos cada vez que se realiza una cotización de servicios de implementación.
Dispositivos de Internet Móvil
La organización ha comprado unos planes de dispositivos de Internet móvil para sus ingenieros. Con esto ahora es
posible que el ingeniero se pueda conectar a los clientes con contrato en caso de que éste se encuentre en terreno y no tenga
conexión a Internet, cumpliendo con los tiempos de respuesta establecidos en los contratos de soporte.
Sistema de Backup/Restore
Se ha implementado una plataforma de Backup y Restore (Respaldo y Recuperación) de las estaciones de trabajo de la
organización. Esta plataforma está basada en la aplicación BackupPC, la cual permite una rápida y fácil implementación y
utilización para gestionar los backups de las estaciones de trabajo y también de servidores.
Esta plataforma es muy útil cuando es necesario volver atrás con alguna configuración en la cual no se haya realizado
un respaldo previo.

18. Aplicación web BackupPC que muestra el estatus general del servidor de respaldos (se han ocultado los datos
sensibles por razones de seguridad)
5.2. Cuadros Resumen
Los siguientes cuadros permiten resumir cada una de las buenas prácticas implementadas en la organización, en base a
las principales debilidades encontradas, como también los requerimientos del negocio y también las áreas de capacidad que
cubren estas buenas prácticas implementadas. Con esto es posible resumir qué está cubriendo cada una de las buenas
prácticas implementadas al interior de la organización.
Debilidades del área
Repositorio de
Templates de Checklist de Políticas de Control de Tiempos de Backup/Restor
Wiki Configuracion Internet Móvil
Informes Pruebas Trabajo Cambios Demora e
es
Knowledge Base X X
Sistema de Tickets
Registro de
Credenciales X
Tiempos de
Respuesta X X
Detalles de
Contratos X
Registros de Acceso X
Requerimientos del Negocio
Repositorio de
Templates de Checklist de Políticas de Control de Tiempos de Backup/Restor
Wiki Configuracion Internet Móvil
Informes Pruebas Trabajo Cambios Demora e
es
Tiempos de
Respuesta X X X X
Conectividad X X X
Tiempos de
Solución X X X
Políticas de
Seguridad X
Detalles de contratos X

19. Repositorio de
Templates de Checklist de Políticas de Control de Tiempos de Backup/Restor
Wiki Configuracion Internet Móvil
Informes Pruebas Trabajo Cambios Demora e
es
Áreas de Capacidad (Knowledge Management)
Repositorio de
Templates de Checklist de Políticas de Control de Tiempos de Backup/Restor
Wiki Configuracion Internet Móvil
Informes Pruebas Trabajo Cambios Demora e
es
knw01
(Share Knowledge) X
knw02
(Provide Required X X X X X X X
Information)
knw03
(Knowledge X X X X
System)
knw04
(Process Assets) X X
knw05
(Engagement
Konwledge)
knw06
(Reuse) X X X X
knw07
(Version & Change X X
Control)
knw08
(Resource X
Consumption)
Áreas de Capacidad (Threat Management)
Repositorio de
Templates de Checklist de Políticas de Control de Tiempos de
Wiki Configuracion Internet Móvil Backup/Restore
Informes Pruebas Trabajo Cambios Demora
es
thr01
(Risk Management) X
thr02
(Engagement Risk)
thr03
(Risk Across X
Engagements)
trh04
(Security) X X
thr05
(Intellectual X
Property)
thr06
(Statutory &
Regulatory
Compliance)
thr07
(Disaster Recovery) X X
5.3. Resultados Internos
Como una forma de medir los primeros resultados de la aplicación de estas buenas prácticas, y considerando el
reducido número de personas de la Organización, se han desarrollado entrevistas informales al interior de ésta, con el fin de
poder obtener un feedback acerca de la percepción del personal interno con respecto a las buenas prácticas implementadas.
Básicamente las percepciones se pueden resumir en:

20. • Notable mejoramiento en el acceso a la información de apoyo para la realización del trabajo
• Mejoras en la realización de los informes de implementación y soporte, puesto que ya se encuentra ahora
estandarizado con la información mínima que debe contener
• Ayudó en la mejora de los tiempos de respuestas, dado que ahora se tiene repositorio de configuraciones, base
de conocimiento, y registro unificado de accesos a clientes, lo cual antes no existía y ahora no es necesaria la
dependencia de quién tenía dicha información actualizada
Dado el poco tiempo que llevan en implementación estas buenas prácticas al interior de la organización, se esperará un
tiempo razonable para que se madure y se mejore, con el fin de que el cliente final observe cambios al interior de la
organización y así poder efectuar encuestas de satisfacción al cliente para poder obtener métricas que ayuden a establecer
nuevas mejoras y cambios al interior de la organización.
Adicionalmente, no se espera que la implementación de estas buenas prácticas se quede como viejos hábitos o
procesos estándares de trabajo, sino que se buscará la excelencia mediante la mejora continua de los servicios, que busque la
utilización de toda la capacidad intelectual, creativa y experiencia del personal, con el fin de mejorar sistemáticamente los
niveles de calidad y productividad, reduciendo costos y tiempos de respuesta, mejorando los índices de satisfacción de los
clientes, para de esa forma mejorar la participación de la empresa en el mercado. Para esto se deberá desarrollar un Plan de
Mejora Continua que involucre a todos los miembros de la organización.
6. Conclusiones
En primer lugar, y considerando el objetivo principal que se ha planteado, se ha cumplido con todas las expectativas
realizadas al iniciar este trabajo. Se ha mejorado la calidad de los servicios TI como también se ha ayudado en la mejora de
la gestión de estos servicios.
La implementación de las buenas prácticas desarrolladas en este trabajo al interior de la Organización no provocó el
rechazo interno ni aumentó la cantidad de tiempo, ni burocracia, ni recursos adicionales que se deban agregar para la
ejecución; sino que todo lo contrario, puesto que ayudó a mejorar la calidad de los servicios, mejoró la comunicación tanto
interna como externa, y se notó una mejoría en cuanto a los tiempos de respuestas y soluciones ante requerimientos de los
clientes, entre otras mejoras.
La utilización del modelo eSCM-SP ayudó a implementar buenas prácticas dedicadas a la resolución de las principales
debilidades encontradas en el área como también a cubrir algunos de los principales requerimientos del negocio, de una
forma bastante rápida y fácil de implementar, sin necesidad de tener que establecer algún otro estándar que se deba aplicar
al 100% en cada proceso de la organización, sino que -por el contrario- se puede ir implementando paulatinamente
cubriendo las principales debilidades en un principio, para posteriormente ir madurando las buenas prácticas e ir
incorporando el resto para ir escalando paulatinamente los niveles de capacidad y así marcar un elemento diferenciador con
el resto de las empresas del mercado.
El autor considera que este trabajo ha aportado a la difusión acerca de este modelo, el cual, al ser relativamente
reciente, aún no es conocido por la mayoría de las empresas proveedoras de servicios TI. Se debe considerar también que
este modelo puede ser utilizado como apoyo a los ya existentes puesto que éste se preocupa del punto de vista de la
capacidad del Sourcing, a diferencia del resto de modelos que pueden no considerar algunas de las áreas de capacidad que
este modelo presenta, tal como ha sido mencionado en el punto 2.1.1.
Se espera que en un futuro cercano se continúe con el desarrollo del resto de áreas de capacidad incorporando nuevas
buenas prácticas que ayuden a mejorar aún más, como también se espera madurar las buenas prácticas ya existentes para
que éstas marquen un elemento diferenciador con el resto de las empresas proveedoras de servicios TI existentes en el
mercado. Para esto, se presentará un plan a mediano plazo a los socios de la Organización, definiendo una Plan de Mejora
Continua, y un roadmap detallado de implementación de buenas prácticas, junto a los principales beneficios que incorporará
la implementación del resto de buenas prácticas de este modelo.

21. 7. Referencias
1. Hyder, E., Heston, K., Paulk, M. (2006). El eSCM-SP v2.01: Descripción modelo. Pittsburgh, PA. Universidad
Carnegie Mellon, TR# CMU-ITSQC-06-006.
2. Hyder, E., Heston, K., Paulk, M. (2006). El eSCM-SP v2.01: Detalles de la práctica. Pittsburgh, PA. Universidad
Carnegie Mellon, TR# CMU-ITSQC-06-007.
3. Information Technologies Services Qualification Center (ITsqc). (2007). Improve your eSourcing Capability.
Pittsburgh, PA. Universidad Carnegie Mellon
4. eSCM-SP. http://www.worldlingo.com/ma/enwiki/es/eSCM-SP. Revisado el 2/Feb/2011.
5. Los Modelos eSCM. http://www.datati.es/1283/los-modelos-escm.html. Revisado el 3/Feb/2011.
6. Administración de Outsourcing TI. http://www.cepra.com.mx/asentti_v2/secciones/secciones/soluciones/saot3.asp.
Revisado el 12/Mar/2011.
Actualización: http://www.cepra.com.mx/secciones/servicios_unidades/unidades/asentti/sist_admin_outs.asp (17/Oct/2011)
7. Itsqc (Information Technologies Services Qualification Center). Comparasions. http://www.itsqc.org/models/escm-
sp/comparisons.html. Revisado 17/Oct/2011.
8. Elaine B. Hyder, Keith M.Heston, Mark C. Paulk. ITsqc. The eSCM-SP v2: Model Overview. http://reports-
archive.adm.cs.cmu.edu/anon/isri2004/CMU-ISRI-04-113.pdf. Revisado 17/Oct/2011.

22. APÉNDICE A
Políticas Internas de IT Linux Ltda.
Este apéndice muestra el documento oficial de IT Linux Ltda. con algunas de las principales políticas internas, buenas
prácticas, pautas y otras consideraciones. Por razones de confidencialidad no se presenta el documento en su plenitud, y por
razones de seguridad, se ha debido ocultar algunos datos sensibles para la organización.