Mejora de Servicios TI utilizando el modelo eSCM-SP

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

[email protected]

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.

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

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

Fuente: elaboración propia

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:

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]

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]

• 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) ppl: People Management (administración de personas) prf: Performance Management (administración de rendimiento) rel: Relationship Management (administración de relaciones) tch: Technology Management (administración de tecnología) thr: Threat Management (administración de amenazas)

cnt: Contracting (contratación) sdd: Service Design & Deployment (diseño y despliegue del servicio) del: Service Delivery (entrega del servicio) tfr: Service Transfer (transferencia del servicio)

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.

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

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

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.

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.

Debilidades y requerimientos

Knowledge management

Threat Management

Technology Management

Service Transfer

Service Delivery

Relationship Management

People Management

Performance Management Contracting

Service Design &

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

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

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]

• 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

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.

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.

− 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

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.

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

Wiki Templates de Informes

Checklist de Pruebas

Repositorio de Configuracion

es

Políticas de Trabajo

Control de Cambios

Tiempos de Demora Internet Móvil Backup/Restor

e

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




es


Control de Cambios


e

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




es


Control de Cambios


e

Áreas de Capacidad (Knowledge Management)




es


Control de Cambios


e

knw01 (Share Knowledge) X

knw02 (Provide Required

Information) X X X X X X X

knw03 (Knowledge

System) X X X X

knw04 (Process Assets) X X

knw05 (Engagement Konwledge)

knw06 (Reuse) X X X X knw07

(Version & Change Control)

X X

knw08 (Resource

Consumption) X

Áreas de Capacidad (Threat Management)




es


Control de Cambios

Tiempos de Demora Internet Móvil Backup/Restore

thr01 (Risk Management) X

thr02 (Engagement Risk)

thr03 (Risk Across

Engagements) X

trh04 (Security) X X

thr05 (Intellectual

Property) X

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:

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

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.

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.