Embed Size (px)
Citation preview
Implantación de herramienta de ticketing Alejandro Rodríguez Pubill Grado en Ingeniería Informática Dirección de Proyectos Profesor Director: Atanasi Daradoumis Haralabus Profesor Colaborador: Xavier Martínez Munné 7/6/2019
i
Esta obra está sujeta a una licencia de Reconeixement-NoComercial-SenseObraDerivada 3.0 Espanya de Creative Commons
ii
FICHA DEL TRABAJO FINAL
Título del trabajo: Implantación de herramienta de ticketing
Nombre del autor: Alejandro Rodríguez Pubill
Nombre del consultor: Xavier Martínez i Munné
Nombre del PRA: Atanasi Daradoumis Haralabus
Fecha de entrega (mm/aaaa): 7/6/2019
Titulación o programa: Grado en Informática
Área del Trabajo Final: Gestión de Proyectos
Idioma del trabajo: Castellano
Palabras clave OTRS, Ticketing, Opensource
Resumen del Trabajo (máximo 250 palabras): La finalidad de este trabajo es la de documentar todo el proceso de implantación de una herramienta OpenSource para el tratamiento de carga de trabajo (tickets) en una empresa que no disponía de ningún tipo de estandarización ni parametrización de su metodología de trabajo. El proyecto interconexiona todos los departamentos de la empresa que trabajan independientemente para establecer un vínculo entre ellos y canalizar el flujo de trabajo hacia un camino común, siendo esté visible para la alta dirección. A su vez, se corregirá la deficiencia documental existente en materia de protección de datos, así como la elaboración de los diferentes documentos normativos que afectan a la empresa. Como resultado de este proyecto, la empresa ha corregido bastantes irregularidades legales y ha conseguido que toda su información actualmente tenga un nivel alto de disponibilidad, integridad, confidencialidad, autenticidad y trazabilidad.
iii
Abstract (in English, 250 words or less):
The purpose of this work is to document the entire process of implementing an OpenSource tool for the treatment of workload (tickets) in a company that did not have any type of standardization or parameterization of their work methodology. The project interconnects all the departments of the company that work independently to establish a link between them and channel the workflow towards a common path, being visible to top management. In turn, the existing documentary deficiency in data protection will be corrected, as well as the elaboration of the different normative documents that affect the company. As a result of this project, the company has corrected many legal irregularities and has achieved that all its information currently has a high level of availability, integrity, confidentiality, authenticity and traceability.
iv
Índex
1. Introducción .................................................................................................... 1 1.1 Contexto y justificación del Trabajo ........................................................... 1 1.2 Objetivos del Trabajo ................................................................................. 2 1.3 Enfoque y método a seguir ........................................................................ 4 1.4 Planificación del Trabajo ........................................................................... 5
1.5 Breve sumario de productos obtenidos ..................................................... 8 1.6 Breve descripción de los otros capítulos de la memoria............................ 8
2. Implicando Alta dirección ................................................................................ 9 3 Estudio de situación y requisitos...................................................................13
3.1 Auditoria de situación inicial .................................................................... 14 3.2 Estudio financiero .................................................................................... 15 3.3 Plan de implantación ............................................................................... 16
4 Análisis software OTRS y alternativas .......................................................... 17 4.1 OTRS ...................................................................................................... 17 4.2 Alternativa 1 (Zoho Desk) ........................................................................ 19 4.3 Alternativa 2 (FreshService) .................................................................... 21
5 Sistema OTRS .............................................................................................. 23 5.1 Evaluación ............................................................................................... 23
5.2 Casos de uso .......................................................................................... 26 5.3 Diseño de procedimientos ....................................................................... 29
5.3.1 Instalación ............................................................................................ 29 5.3.2 Uso de la herramienta – Manual cliente ............................................... 32 5.3.3 Uso de la herramienta – Manual Agente .............................................. 34
5.4 Configuración Módulos ............................................................................ 38 5.4.1 Copias de seguridad............................................................................. 41
5.4.1 Configuración Módulo SendMail ........................................................... 43 6 Documentación ............................................................................................. 44
6.1 Modelo Organizativo................................................................................ 44 6.1.1 Objeto y Ámbito .................................................................................... 44
6.1.2 Estructura Organizativa ........................................................................ 44 6.1.2.1 Grupo de Trabajo de Seguridad, Investigación y Proyectos (GTSIP) 44 6.1.2.2 Responsable de la Información ......................................................... 45
6.1.2.3 Responsable del Servicio .................................................................. 45 6.1.2.4 Responsable de Seguridad ............................................................... 46 6.1.2.5 Responsable del Sistema .................................................................. 47 6.1.2.6 Analista de Riesgos de Seguridad..................................................... 47
6.1.2.7 Secretario del GTSIP ......................................................................... 48 6.2 Política de Seguridad .............................................................................. 48 6.2.1 Objeto y Ámbito .................................................................................... 48 6.2.1.1 Objetos de la Política de Seguridad .................................................. 48 6.2.2 Estructura Organizativa ........................................................................ 49
6.2.3 Principios básicos de seguridad en SEYMA S.L .................................. 52 6.2.3.1 Gestión de Riesgos ........................................................................... 52 6.2.3.2 Desarrollo Normativo ......................................................................... 52
6.2.3.3 Cumplimiento Normativo ................................................................... 52
v
6.2.3.4 Terceras Partes / Colaboradores y Servicios Externos ..................... 52
6.2.3.5 Concienciación y Formación ............................................................. 53
6.2.3.6 Continuidad del Servicio .................................................................... 53 6.2.4 Revisión de la Política de Seguridad .................................................... 53 6.3 Grupo de Trabajo de Seguridad, Investigación y Proyectos .................... 53 6.4 Plan formativo especifico ......................................................................... 55 6.5 Implantar una WIKI .................................................................................. 55
6.5.1 Beneficios ............................................................................................. 56 6.5.2 Usos ..................................................................................................... 56 6.5.3 Estudio de Software a implantar ........................................................... 56 6.5.4 Selección de Software .......................................................................... 58
7. Conclusiones ................................................................................................ 60
8. Glosario ........................................................................................................ 61
9. Bibliografia .................................................................................................... 62
vi
Lista de figuras
Ilustración 1 Diagrama de Gantt 5 Ilustración 2 Diagrama de Gantt 5 Ilustración 3 Precios Zoho Desk 20 Ilustración 4 Precios FreshService 22
Ilustración 5 Arquitectura de red 23 Ilustración 6 Capa Básica de arquitectura OTRS 24 Ilustración 7 Esquema interfaz genérica 26 Ilustración 8 Caso de uso Cliente 27 Ilustración 9 Caso de Uso creación ticket 28
Ilustración 10 Listado conexiones activas 29
Ilustración 11 Listado de módulos cargados Apache 30 Ilustración 12 Módulos OTRS instalados 31
Ilustración 13 Login cliente 32 Ilustración 14 Primer ticket 32 Ilustración 15 Tickets 33 Ilustración 16 Formulario creación tickets 33
Ilustración 17 URL Login Agente 34 Ilustración 18 Dashboard del agente 35
Ilustración 19 Ticket Cliente 35 Ilustración 20 Cambiar prioridad 35 Ilustración 21 Gente 36
Ilustración 22 Comunicación 36
Ilustración 23 Pendiente 36 Ilustración 24 Cerrar ticket 36 Ilustración 25 Misceláneo 37
Ilustración 26 Añadir cita 37 Ilustración 27 Configuración Módulos - 1 38
Ilustración 28 Configuración Módulos - 2 38 Ilustración 29 Colas 39
Ilustración 30 Cuenta de correo 39 Ilustración 31 Agentes 40 Ilustración 32 Registro de sistema 40 Ilustración 33 Comando Backup 41 Ilustración 34 Periodicidad Backup 42
Ilustración 35 Listado de Backups realizados 42 Ilustración 36 Restauración copia de seguridad 43
Ilustración 37 Código Restaurar Backup 43 Ilustración 38 Edición sendmail.mc 43 Ilustración 39 Edición código sendmodule 44 Ilustración 40 Formato de firma 54 Ilustración 41 MediaWiki 57
Ilustración 42 TWiki 57 Ilustración 43 WikkaWiki 58
vii
Lista de Tablas
Tabla 1Comparativa servicios OTRS Cloud ..................................................... 15 Tabla 2 Directorio OTRS .................................................................................. 25 Tabla 3 Codigo Backup OTRS ......................................................................... 41 Tabla 4 Elección Software WiKi ....................................................................... 59
1
1. Introducción
1.1 Contexto y justificación del Trabajo
Empresa de Medios Audiovisuales y Seguridad Electrónica (SEYMA S.L) tiene una dinámica de trabajo no estandarizada con múltiples deficiencias procedimentales y normativas que afecta tanto a la productividad como a posibles sanciones por negligencias por el tratamiento de datos. La empresa opera a nivel nacional en las 17 Comunidades más Ceuta y Melilla. Es esa diversificación la que hace que falte homogeneidad en la forma de trabajar, ya que algunas sedes toman sus propias decisiones de manera autónoma y eso está perjudicando a la empresa de cara a los clientes más importantes. La empresa ofrece servicios externos e internos entre otros como pudieran ser: EXTERNOS: - Seguridad Perimetral: Implantación, administración y mantenimiento
de sistemas de seguridad, incluyendo grabación de imágenes - Producción Audiovisual (grabación de eventos, edición de video y
audio, montaje técnico de showrooms) - Uso de drones para fines Audiovisuales - Grabación de imágenes aéreas usando helicópteros y su posterior
visualización
INTERNOS: - Suministro de terminales móviles bastionados y gestionados por un
MDM a empleados. - Suministro a sus sedes nacionales de todo el material que se solicite
a través del almacén
Es por esta deficiencia y falta de productividad por la que se contrata una empresa externa para la puesta en marcha de OTRS y la creación
Open-source Ticket Request System u OTRS (en español
"sistema de solicitud de tiques de código abierto") es un sistema libre que cualquier institución puede utilizar para asignar identificadores únicos llamados tickets2 a solicitudes de servicio o de información, de forma de facilitar el seguimiento y manejo de dichas solicitudes, así como cualquier otra interacción con sus clientes o usuarios. Se distribuye bajo la licencia GNU Affero General Public License. OTRS está certificado ITIL V3.1
2
1.2 Objetivos del Trabajo
El objetivo principal que se quiere obtener en este proyecto es la documentación de la implementación de la herramienta OTRS en una organización y de las medidas necesarias para subsanar esa insuficiencia normativa:
1. Implantación e integración de OTRS para la gestión de las ordenes de trabajo que llegan a la empresa que permita una respuesta eficaz evitando pérdidas de tiempo e información mejorando el rendimiento de la organización.
2. Realización de la documentación necesaria para el cumplimiento del RGPD
a. Modelo organizativo b. Política de Seguridad c. Grupo de Trabajo de Seguridad de la Información
3. Parametrizar procesos ITIL (Estrategia y Mejora Continua) sobre OTRS para saber cómo realizar las actividades afectadas en el proceso de gestión de servicios TIC. El resto de los procesos, no los tendremos en cuenta, ya que con la implantación de OTRS, cubriremos los mismos, basada la herramienta en ITIL (CMDB, Gestión de Cambio, incidentes, requerimientos, etc.)
Dentro del proyecto, se intentarán abarcar objetivos secundarios como:
1. Generar una KB (Base de conocimientos) para los usuarios 2. Generar un gestor documental 3. Generar la ITSM para aportar valor (utilidad más garantía) al
negocio mediante soluciones TI combinando Personas, procesos y tecnología. Esto incluye:
i. Estrategia ii. Diseño iii. Transición iv. Operación v. Mejora Continua
4. Formar a los usuarios 5. Análisis de riesgos e implementar medidas de seguridad
Como objetivos finales para la empresa de todo lo anterior sería:
• Homogeneización de la herramienta del tratamiento de actuaciones (todos los usuarios trabajan con la misma herramienta).
• Unificación y creación de un repositorio digital en un servidor Linux (ubuntu18.04) ubicado en un Centro de Proceso de Datos.
• Estandarización de las medidas de seguridad, al tener solo que configurar el servidor del CPD y no cada uno de los ordenadores
3
locales de cada usuario, creando políticas, normativa y manuales de seguridad.
• Realización de manera correcta la creación de los distintos documentos de seguridad que aplica actualmente con el RGPD. En concreto el registro de actividades de tratamiento de datos, del articulo 30.del RGPD.
• Realización de copias de seguridad tanto de OTRS como del sistema completo.
• Trazabilidad de principio a fin, por cada actividad de trabajo.
• Control estadístico completo para medir los parámetros que se deseen (productividad, temporalidad, autorización, etc.)
• Creación de un grupo de soporte
• Consecución de métricas de rendimiento, en función de lo que cada departamento solicite
• Organización de la comunicación, tanto interna como externa, a través de estructuras claras y procesos optimizados, mejorando la rapidez y la calidad del servicio.
• Automatización y estandarización para no usar herramientas de terceros.
• Optimización de los flujos de trabajo, por tanto, del rendimiento neto.
• Gestión de Recursos a través de los distintos calendarios y fechas de los tickets de trabajo.
4
1.3 Enfoque y método a seguir
El enfoque del proyecto estará basado en un primer análisis de la situación actual para ver el estado en el que se encuentran los distintos departamentos de la empresa. Una vez analizados dichos datos, se establecerá un alcance del proyecto y su posterior puesta en marcha. El método que seguir en la puesta en marcha será:
A. Estudio de la situación y definición de los requisitos a. Auditoria de situación inicial
i. Estudio económico 1. Estimación inicial 2. Estimación final
b. contratación de empresa externa IT c. Plan de implantación y asignación de funciones
B. Análisis de la herramienta de ticketing OTRS, así como alternativas.
a. OTRS b. Alternativa 1 c. Alternativa 2 d. Alternativa 3 (si procede)
C. Sistema OTRS a. Requisitos previos y evaluación b. Casos de uso c. Diseño de procedimientos
i. Instalación ii. Uso
d. Implantación i. Configuración ii. Instalación iii. Configuración de módulos iv. Migración de datos
e. Formación a los usuarios D. Documentación
a. Normativa b. Formación c. Implantación de un gestor documental d. Implantar una WIKI - FAQ
E. Presentación y puesta en marcha del proyecto F. FIN
El método está realizado de manera que, desde el principio del proyecto, habrá un total control sobre el mismo, pasando por las diferentes fases iniciales de estudio y análisis, para finalizar con un sistema totalmente implantado en la empresa cumpliendo con la normativa europea del tratamiento de datos.
5
La implicación de la Alta dirección se hace esencial junto con la designación de un responsable que lleve a efecto la toma de decisiones tomadas por el grupo de trabajo.
1.4 Planificación del Trabajo
• Entrega del presente Plan de Trabajo (PAC 1): 15/03/2019 • Entrega 1 (PAC 2): 12/04/2019 • Entrega 2 (PAC 3): 10/05/2019 • Entrega final: 7/06/2019
Ilustración 1 Diagrama de Gantt
La ilustración 1 muestra un diagrama de Gantt realizado con GanttProject 2.8.9 Pilsen (build 2335) con licencia GPL, donde podemos ver toda la planificación del proyecto, sus fases y la temporización de cada una de ellas. Son 60 días de trabajo contando solo los días laborables.
6
Hito 1. PAC 1. Entrega del Plan de trabajo. Plan de trabajo:
Lectura sobre OTRS. Descripción del Trabajo Final de Grado Contexto y justificación del Trabajo. Objetivos del Trabajo. Objetivos generales. Objetivos específicos. Enfoque y método a seguir. Planificación del Trabajo.
Hitos:
Temporización general. Diagrama de Gantt. Breve Sumario de productos obtenidos (Desarrollo inicial que se irá revisando con el producto del trabajo). Breve descripción de los otros capítulos de la memoria (Desarrollo inicial que se irá revisando con el producto del trabajo). Revisar y Decidir qué tipo de licencia que aplicaré al trabajo Documentación de la PAC 1 (portada, ficha de trabajo, abstract, y puntos del 1.1 al 1.6). Entrega de la PAC 1.
Hito 2. PAC2.
Plan de trabajo: Estimación de 20 días laborables disponibles.
• Horas productivas: Estimación de 40h de trabajo real.
• Fines de semana de descanso para compaginar con el cuidado de un hijo.
Investigación sobre la metodología a seguir Lectura ITIL: Fundamentos Lectura RGPD Búsqueda de información sobre auditorias y análisis de riesgos.
Hitos:
Finalización de las fases de:
• Estudio de situación y requisitos
• Análisis OTRS y alternativas
• Creación de la normativa básica ( Entrega de la PAC2
7
Hito 3. PAC3.
Plan de trabajo: Al igual que en el hito2, estimación de 20 días laborables disponibles.
• Horas productivas: Estimación de 40h de trabajo real.
• Fines de semana de descanso para compaginar con el cuidado de un hijo.
Lectura ITIL: Estrategia y Mejora continua Lectura: Instalación y configuración de módulos OTRS
Hitos:
Finalización de las fases de:
• Sistema OTRS: Tener implementada toda la aplicación
• Entrega de la PAC3
Hito 4. Entrega Final. Plan de trabajo:
Entrega final del trabajo final, memoria, presentación y demás documentación.
Hitos:
Revisión final de la Memoria. Preparación de la Defensa. Grabación de la Defensa. Redacción Auto informe del Trabajo. Entrega de la Memoria y la Defensa.
Para la resolución del TFG dispongo de distintos recursos como pudiera ser acceso a Internet a través de un portátil, Office, y distintos programas Opensource para su elaboración como el mencionado anteriormente (GanttProyect).
8
1.5 Breve sumario de productos obtenidos
En este trabajo se pretende obtener: - Consenso de la alta dirección - Implantación y configuración de la herramienta OTRS - Creación de procedimientos y normativa - Formar a los usuarios
1.6 Breve descripción de los otros capítulos de la memoria
En el capítulo 2.1 se introducirá el concepto de creación de grupos de trabajo, así como comentarios sobre la resistencia al cambio y de la importancia de que la alta dirección reme en la misma dirección.
2.2 Se realizará un estudio de la situación de la empresa, realizando una auditoria, se expondrá el plan contable y su viabilidad, así como el plan de implantación final.
2.3 Aquí, se analizarán las distintas aplicaciones que tendremos disponibles en el mercado para implantar en la organización y cubrir las necesidades de esta. Habrá subapartados para cada una de las herramientas.
2.4 Se detallará al completo OTRS así como la documentación de todos los procedimientos
2.5 En este apartado, se mostrará la necesidad de la importancia de una buena formación a los usuarios para su posterior uso.
2.6 Finalmente previa a la presentación del proyecto, en este apartado se realizará todo lo relacionado a la documentación del proyecto, así como toda la normativa al respecto, la bibliografía y texto de formación como su posterior consulta en una WIKI que se implantará.
2.7 Como finalización, aquí se presentará y se podrá en marcha el proyecto.
9
2. Implicando Alta dirección
Cuántos proyectos ambiciosos de desarrollo de software no se han llevado a cabo o, ejecutándose, no han llegado a tener éxito por falta de implicación de la alta dirección. Cuántas empresas han visto mermadas su productividad y/o han perdido mercado por no haberse adaptado a tiempo a los cambios provocados por la evolución de las TICs.
El liderazgo, compromiso y la implicación de la alta dirección son esenciales para la implementación, el desarrollo y el mantenimiento de un sistema de gestión efectivo y eficiente para lograr los beneficios de la organización y de todas las partes interesadas. A través de la política de la organización, la alta dirección define un marco de referencia para que todo el personal de la organización comprenda qué pretende en cuanto a la calidad. Además, la política de la empresa puede cambiar en un determinado momento por diferentes razones y es la alta dirección de la organización quien debe estar atento para realizar su adecuación cuando sea necesario, de lo contrario, puede volverse obsoleta.
Por tanto, la informática debe estar siempre alineada con los objetivos de la organización y a cambio la organización debe darle a la misma el papel y el respaldo que se merece, esta situación permite conseguir un equilibrio muy provechoso, lo contrario es entrar en una situación de desequilibrio y falta de control, que provocará que en muchos casos se dediquen esfuerzos TICs en asuntos que no son trascendentes para el funcionamiento de la organización, descuidando otros aspectos importantes que sí pueden provocar consecuencias económicas directas o indirectas en el funcionamiento de la institución.
2.1 Creación grupo de trabajo
La estructura organizativa de SEYMA S.L estará compuesta por el Grupo de Trabajo de Seguridad, Investigación y Proyectos, en adelante GTSIP, el cual será responsable de velar e impulsar las directrices en materia de investigación, creación de proyectos y la seguridad de la Información. El GTIP será designado por el Director General de SEYMA S.L y se encontrará al menos formado por:
• Responsable de la Información.
• Responsable del Servicio(proyecto).
• Responsable de la Seguridad.
• Responsable de Sistemas. Tal y como se describe en el Punto 6.1 Modelo organizativo, aprobado por el Director General de SEYMA S.L en fecha 02-04-2019.
10
2.2 Detalle de las competencias del GSTIP
Niveles normativos:
Nivel Estratégico Normas Básicas Primer nivel normativo
Nivel Táctico Normas Específicas Segundo nivel Normativo (GTIP)
Nivel Operacional o técnico
Procedimientos Instrucciones técnicas Políticas de uso
Tercer nivel Normativo (SSI – Subcomité de Seguridad de la Información)
Serán competencias del GTSIP dentro de SEYMA S.L:
• Redactar y aprobar las normas de segundo nivel correspondientes al ámbito de influencia.
• Velar e impulsar el cumplimiento de las normas de segundo nivel y promover el desarrollo del tercer nivel normativo. Como tercer nivel normativo están identificados los Procedimientos, Instrucciones técnicas y Políticas de uso.
• Promover y Aprobar proyectos para su implantación en SEYMA S.L junto con la designación del Responsable de Servicio que se va a desarrollar.
• Aprobación de documentos de correspondencia de responsables en su ámbito competencial.
• Aprobación de los planes de mejora de la seguridad en su ámbito de
competencias, de acuerdo a los presupuestos disponibles.
• Promover la mejora continua en la gestión en su ámbito de
competencias.
• Impulsar la formación y concienciación en su ámbito.
• Resolver los conflictos que puedan aparecer entre los diferentes responsables y/o entre diferentes áreas de la Organización, elevando aquellos casos en los que no tenga suficiente autoridad para decidir.
2.3 Funcionamiento del Grupo de Trabajo de Seguridad, Investigación y Proyectos
Una vez identificada la estructura que forma parte del GTSIP se hace necesario dotar al grupo de un funcionamiento interno con el fin de gestionar los
11
diferentes temas que ha de tratar. Para ello se ha creado una lista de distribución de correo [email protected] atendiendo a las siguientes premisas: Será obligatoria la asistencia a las reuniones del GTSIP del representante designado por SEYMA SL conforme al Modelo Organizativo para participar en las decisiones que se tomen en las sesiones del Grupo.
En caso de que exista alguna imposibilidad que no permita su asistencia, el miembro titular del GTSIP comunicará formalmente al Grupo y con anticipación a la reunión su intención de delegar esta función en un delegado. Una vez nombrado se considerará que el delegado tiene la misma capacidad de representación que el titular del GTSIP. Cuando uno de los miembros cause baja permanente en el GTSIP será obligatoria su sustitución por otro representante. Dicha sustitución deberá ser comunicada de forma oficial para proceder a la baja y alta en la lista de distribución [email protected] Las reuniones ordinarias del GTSIP tendrán lugar en la Sede designada de SEYMA S.L estableciéndose una periodicidad trimestral para realizar las mismas. El GTSIP podrá cambiar dicha periodicidad y el lugar de celebración según la necesidad de este.
Las reuniones extraordinarias del GTSIP serán propuestas por cualquiera de los integrantes del GTSIP, para ello se remitirá una petición al GTSIP a través de la lista de distribución correo del GTSIP indicando la fecha y de la convocatoria y el motivo o los motivos para convocar al GTSIP. Se establecerá un flujo de trabajo para la revisión y aprobación de los documentos de segundo nivel presentados al GTSIP. Una vez aprobados los documentos de segundo nivel será el Responsable de Seguridad, o la persona en quien delegue, el encargado de custodiar los mismos y de promover las normas de tercer nivel. Para la aprobación de los documentos por parte del GTSIP, dada la importancia de los asuntos que van a tratar, se exige la unanimidad de los miembros presentes en las reuniones del GTSIP. Cuando se realicen informes de auditoría, será el Jefe del Servicio(proyecto) como Responsable quien remitirá a la lista de distribución de correo del GTSIP [email protected] los resultados obtenidos con el fin de poner en conocimiento del GTSIP, si procede, la situación de las auditorías realizadas. En su caso en la siguiente reunión ordinaria del GTSIP se tratarán dichos resultados. En el caso de que los resultados obtenidos obliguen a convocar una reunión extraordinaria, el Responsable de Seguridad lo comunicará al GTSIP a través de la lista de distribución de correo [email protected].
12
2.4 Subcomité de Seguridad de la Información
Con el fin de facilitar la operativa diaria relacionada con la Seguridad de la Información, el Responsable de Seguridad se apoyará en el Subcomité de Seguridad de la Información, en adelante SSI. Este Subcomité, SSI, estará integrado fundamentalmente por personal de Seguridad TIC. Además, a criterio del Responsable de la Seguridad, podrán participar, de forma puntual o permanente, asesores y/o consultores con perfil técnico, tanto del ámbito de la administración pública como personal ajeno a la misma. Las funciones principales del SSI serán la de redactar las normas del tercer nivel normativo (instrucciones técnicas y políticas de uso), confeccionar los informes técnicos demandados por el GTSIP o elaborados por iniciativa propia, tomar decisiones sobre políticas y autorizaciones que no sean competencia del GTSIP, y aquellas otras funciones que le sean encomendadas por el GTSIP. El SSI será presidido por el Responsable de la Seguridad que se reunirá de manera ordinaria semanalmente y de forma extraordinaria a petición del GTSIP. En caso de indisponibilidad de asistencia, el Responsable de la Seguridad será suplido por el Analista de Riesgos de Seguridad conforme al Modelo Organizativo. Si el SSI considera necesario escalar un incidente de seguridad grave al GTSIP, será el Responsable de la Seguridad quien lo ponga en conocimiento del mismo mediante la lista de distribución del GTSIP, [email protected] Todas las actuaciones urgentes del SSI que no conlleven un escalado al GTSIP serán comunicadas a dicho Grupo en la siguiente reunión ordinaria, en la cual, el Responsable de la Seguridad comunicará al mismo los incidentes urgentes tratados y las soluciones adoptadas.
13
3 Estudio de situación y requisitos
Actualmente, la empresa no dispone de ninguna aplicación estandarizada para la gestión de incidencias y de carga de trabajo. Cada departamento trabaja de manera individualizada y por cuenta propia. El objetivo final es la implantación de una herramienta que permita la gestión de todo el servicio, para lo cual, se implantara desde cero y durante el plan de implantación se realizara la migración de los datos que sean necesarios. Referente a los requisitos o requerimientos, como vemos a través de la propia página de OTRS, este, se puede instalar en Linux y en otras distribuciones de Unix (por ejemplo, OpenBSD o FreeBSD). Actualmente, no es posible implementar OTRS en sistemas de Microsoft Windows tal y como lo dicen en su propia página web: “However, when running OTRS on Windows platforms we have encountered repeated performance losses, and despite an exhaustive analysis, it has not been possible to solve these issues to our satisfaction due to technical differences. It is thus with a heavy heart that we have ceased development on our Windows Installer and the OTRS Appliance due to the currently limited availability of necessary third-party components offered by other vendors” Para ejecutar OTRS, se deberá utilizar un servidor web como proxy inverso y un servidor de base de datos. Aparte de eso, debe instalar Perl y / o instalar algunos módulos adicionales de Perl en la máquina OTRS. Perl debe instalarse en la misma máquina que OTRS. El back-end de la base de datos y el servidor web pueden instalarse localmente o en otro host. Para Perl, se necesitarán algunos módulos adicionales que se pueden instalar con la shell de Perl y CPAN, o mediante el administrador de paquetes del sistema operativo (rpm, yast, apt-get). OTRS tiene un comando de consola para verificar el entorno y los módulos faltantes. Requisitos hardware Los requisitos de hardware dependen en gran medida del uso de OTRS. OTRS se puede usar para procesar algunos tickets por mes o para procesar cientos de tickets por día. El requisito de almacenamiento también depende de la cantidad de tickets y el tamaño de los archivos adjuntos. Recomendamos usar una máquina con al menos:
• Xeon a 3 GHz o CPU comparable
• 8 GB de RAM
• 256 GB de almacenamiento
14
Requisitos Software Perl
• Perl 5.16.0 o superior
• Paquetes Perl listado por: /opt/otrs/bin/otrs.CheckEnvironment.pl a través de comando de consola
Web Servers
• Apache2
• nginx
• Cualquier web server que se pueda usar como proxy inverso
Bases de datos
• MySQL 5.0 o superior
• MariaDB
• PostgreSQL 9.2 o superior
• Oracle 10g o superior Otras dependencias
• Elasticsearch 6.x
• Node.js 8.9 o superior Navegadores
• Apple Safari version 7 o superior
• Google Chrome
• Microsoft Internet Explorer 11
• Microsoft Edge
• Mozilla Firefox version 32 o superior
• Cualquier navegador actual con soporte JavaScript
3.1 Auditoria de situación inicial 3.1.1 Alcance La auditoría se realizará sobre el actual sistema informático en computadoras personales que estén conectados a la red interna de la empresa. 3.1.2 Objetivo El objetivo no es otro que tener actualizada la información relativa al sistema informático que usa la empresa en cuanto a la seguridad, carga de trabajo, políticas de utilización y la seguridad de activos para la implantación de la
15
nueva herramienta (OTRS) y que la empresa contratada para su implementación tenga la máxima información sobre los sistemas. 3.1.3 Recursos Se enviará un formulario sencillo y escueto a todos los responsables de departamento para que en 24h devuelvan completamente completado. 3.1.4 Obtención de resultados En esta fase se obtendrán los resultados obtenidos para la posterior aplicación de los procedimientos que estime oportunos la empresa contratada para poder determinar si se cumplen con los objetivos de control previos y con los requisitos de la herramienta.
3.2 Estudio financiero En base a lo obtenido en la Auditoria y las necesidades, se hace un estudio sobre que paquete debe contratar SEYMA para su sistema OTRS en Cloud:
Nivel de Servicio
SILVER GOLD TITANIUM PLATINUM
Agentes concurrentes
10 50 100 200
Configuración Remote or On-
site
Provisionamiento de sistema
(1 Instancia) - hasta 10
agentes/usuarios
Provisionamiento de sistema
(1 Instancia) - hasta 50
agentes/usuarios
Provisionamiento de sistema
(1 Instancia) - hasta 100
agentes/usuarios
Provisionamiento de sistema
(1 Instancia) - hasta 200
agentes/usuarios
Servidor 1x virtual 1x dedicado 1x dedicado 1x dedicado
Espacio de almacenamiento
50 GB 400 GB 1000 GB 2000 GB
Disponibilidad 98.00% 98.50% 99.50% 99.95%
Soporte Telefónico de Emergencia
– dentro del horario laboral
24/7/365 24/7/365
Precio 500€/año 1500€/año 2750€/año 5000€/año Tabla 1Comparativa servicios OTRS Cloud
En base al presupuesto destinado para esta actividad y los resultados
obtenidos en la auditoria previa, los directivos optan por contratar la opción TITANIUM, ya que los principales usuarios del OTRS serán los 52 delegados de telecomunicaciones de las 50 provincias de España más las ciudades de Ceuta y Melilla a los que habrá que incluir los diferentes agentes en la sede de Madrid que tengan que provisionar todas las incidencias del servicio e intentar resolverlas
16
3.2.1 Coste en formación Será necesaria la formación de los Agentes y clientes que vayan a utilizar la herramienta:
Tipo Usuarios Horas Precio Usuario
Coste final
Agente 10 15 1500 15.000€
Cliente 52 5 750 39.000€
3.3 Plan de implantación
El objetivo es establecer un plan que permita llevar a cabo la implantación del Sistema Informático OTRS, tomando en cuenta las partes de planificación, organización y control.
Se realiza la planificación del plan de implantación, determinando las actividades a realizar.
Se ha definido previamente la estructura organizativa del Responsable encargado de ejecutar el proyecto estableciendo las funciones y responsabilidades de los miembros.
Se desarrollan las formas de control, que permita evaluar los avances en la realización de actividades y controlar la asignación de los recursos.
a) Las áreas o departamentos afectados son: i. Administración y RRHH ii. Secretaría técnica iii. Proyectos I+D iv. Seguridad Electrónica v. Medios Audiovisuales vi. Redes vii. Telefonía y Planificación
b) El número y tipo de hardware a modificar, así como la estructura de red.
i. Servidores ii. Sistemas Operativos
c) El Personal afectado
i. Agentes ii. Clientes iii. Administradores
Es imprescindible, con el fin de garantizar el éxito del cambio, informar a
los afectados de los planes a desarrollar, así como el procedimiento y el calendario previsto, con la finalidad de obtener colaboración por parte de estos. Es necesario elaborar breves documentos con las instrucciones de acceso al nuevo sistema y se impartirán jornadas de formación de 5 horas de manera inmediata.
17
Además, se identificarán necesidades personalizadas en función de las necesidades de cada grupo que utilizara la herramienta OTRS. El software, se desarrollará en preproducción, con varios grupos Beta Testers en varios puntos del territorio nacional, para realizar distintas pruebas de carga “reales”. El resultado obtenido, servirá como feedback para ir mejorando los fallos de la aplicación que pudieran aparecer. Existirá un periodo de transición donde coexistirán los procedimientos de trabajo antiguos con la nueva herramienta OTRS, para dar un margen de adaptación a los agentes. Una vez finalizado, la única vía de entrada del flujo de trabajo será OTRS, desapareciendo cualquier otra vía de comunicación.
4 Análisis software OTRS y alternativas
4.1 OTRS
OTRS es una herramienta para la gestión y respuesta de solicitudes de los clientes de una empresa. Es un sistema de solicitud de ticket, conocido también como sistema de ticketing, basado en código abierto y distribuido bajo la Licencia Publica General (GPL), con ciertas características para gestionar llamadas, e-mails o faxes de los clientes. También dispone de una versión de pago para empresas, que es la que interesaría a SEYMA, debido a las características ofrecidas por la misma.
Puesto que no utiliza contenidos Web, como los applets de Java y Flash, este sistema puede ser usado desde cualquier browser (navegador Web), tanto de teléfonos móviles como ordenadores personales, además de que no requiere de un sistema operativo en especial, sino únicamente un navegador Web. OTRS está basado en varios componentes, el componente básico lo constituye el framework OTRS, el cual contiene todas las funciones centrales para la aplicación y el sistema de tickets.
Las características principales del framework OTRS son:
1-Interfaz Web:
• Fácil manejo con un navegador Web.
• Soporte para varios lenguajes.
• Una interfaz Web para manejar las peticiones del cliente por parte de los empleados / agentes a través de la Web se integra.
18
2-Interfaz de correo:
• Soporte para archivos adjuntos de correo.
• Autorespuestas de los clientes, configurable por colas.
• Correos de notificaciones para los agentes sobre nuevos tickets, así como el seguimiento de los tickets abiertos.
3-Tickets:
• Posibilidad de bloquear los tickets.
• Definición del control de acceso para los tickets.
• Cambiar y fijar prioridades de un ticket.
• Control y seguimiento sobre todas las incidencias de cada ticket (cambios de estados, respuestas, notas, etc.)
• Tickets Recordatorio
• Avisos al correo electrónico 4-Sistema:
• Otrs se ejecuta sobre cualquier sistema operativo (Linux, Solaris, FreeBSD, OpenBSD, Mac OS 10.x).
• Soporte ASP (active service providing).
• Autenticación de clientes por medio de la base de datos.
• Soporte para diferentes bases de datos, por ejemplo, MySQL, PostgreSQL, Oracle.
Este sistema está concebido para permitirles a las empresas responder rápidamente a los requerimientos y solicitudes que reciben de sus clientes, reduciendo costos y aumentando la satisfacción de los clientes.
Ventajas del producto
• Reducción de costes (reduciendo el tiempo empleado en la resolución de problemas).
• Rapidez en la recepción de requerimientos de los usuarios/clientes.
• Rapidez en respuestas.
• Facilidad de seguimiento de tickets y de las incidencias relacionadas con ellos.
• Centralización y unificación del punto de recepción de requerimientos.
• Incrementa la satisfacción del cliente por la mejora en la atención recibida y la rapidez en la solución del problema.
En OTRS, todas las incidencias, solicitudes de información, reclamos, etc.; es decir, todos aquellos requerimientos de los clientes de la empresa son tickets, independientemente si son recibidos como e-mails o llamadas telefónicas. Todos los tickets son gestionados como e-mails normales y se almacenan en
19
forma de texto en el disco duro, las cabeceras se almacenan como base de datos para poder clasificar los tickets y darles respuesta.
Otra particularidad de esta aplicación es que posee un sistema de cola, que es en donde se almacenan los tickets, y desde donde sólo un agente los puede mover de una cola a otra, dependiendo del tema y/o según los criterios establecidos.
Los datos anteriores se han obtenido desde la página del desarrollador http://www.otrs.com/?lang=es.
4.2 Alternativa 1 (Zoho Desk) Zoho Desk es una solución en la nube que pertenece a Zoho Corporation. Las características clave incluyen la gestión de tickets de soporte, un portal de atención al cliente, gestión de contratos y creación de informes.
Zoho Desk recopila interacciones de varias fuentes (correo electrónico, teléfono, chat, redes sociales, portal de autoservicio, foros y formularios) y las presenta en un único lugar. Tareas como la asignación de tickets, escalamientos de servicio, reglas de notificación y acciones basadas en el tiempo pueden automatizarse mediante el establecimiento de reglas de flujo de trabajo. La solución proporciona informes personalizables y programados, y un panel gráfico para analizar la satisfacción del cliente.
Con la integración con el CRM de Zoho, la información del cliente se incluye en los tickets registrados en Zoho Desk, lo que permite a los agentes de servicio saber más sobre el cliente.
El sistema permite a los usuarios realizar cambios personalizados, como renombrar pestañas, añadir nuevos departamentos, personalizar plantillas de correo electrónico, definir horas de trabajo y añadir carpetas de ayuda. Zoho Desk también se puede integrar con los sistemas internos de los clientes.
La estructura está formada por tres planes de precios. El primero es el gratuito con un límite de 3 agentes, pero es una solución bastante completa para PYMES. Estos son los planes de los que dispone:
20
Ilustración 3 Precios Zoho Desk
Requisitos: En el servidor:
• Hardware o Mínimo una CPU con 1GHz o Mínimo 1 GB de memoria RAM o Disco duro de 6GB
• Software o Servidor Web
▪ Apache ▪ Nginx ▪ ISS
o Servidor Base de datos ▪ MySQL 5.0 o superior ▪ Decodificador PHP
• IonCube
• Zend Optimizer ▪ PHP cache y acelerador
• Xcache
21
• Apc
• Eaccelerator ▪ Módulos de PHP requeridos:
• Mbstring
• Curl
• Pdo_mysql
• Imap
• Mcrypt
• Xml
• json
4.3 Alternativa 2 (FreshService) Por último, tenemos a Freshservice. Es una solución de gestión de servicios y Help Desk basada en la nube que simplifica las operaciones de IT. El software ofrece funciones que incluyen un sistema de tickets, un portal de autoservicio y una base de conocimientos. La herramienta también proporciona una aplicación móvil para iOS y Android que permite a los administradores de IT atender las solicitudes de forma remota. Freshservice proporciona componentes de ITIL que ayudan a los administradores a gestionar activos, incidencias y cambios. El componente Gestión de activos ayuda a las organizaciones a ejercer control sobre sus activos de IT. Los activos de software/hardware pueden agregarse, etiquetarse, seguirse y desvincularse, lo que garantiza su visibilidad. Freshservice puede integrarse con aplicaciones de terceros para gestionar el Help Desk. Está disponible con una suscripción anual que incluye soporte por correo electrónico y teléfono. Estos son los planes que dispone:
22
Ilustración 4 Precios FreshService
Los puntos más destacables son los siguientes:
• No hace falta tener demasiados conocimientos para usar o instalarlo, podríamos decir que es de instalación sencilla.
• Administración de ticket, base de conocimiento, fórums de comunidad, soporte por chat, telefónico, etc.
• Resulta muy útil para crear comunidades de soporte.
• Multicanal.
• Software en español.
• Económico los precios oscilan entre 0 y 62€. Contras:
• No dispone de API, es decir nuestros desarrolladores pueden tener problemas para crear programas específicos.
• Es poco personalizable, comparado con otras alternativas.
• No tiene inventario, por lo que no podemos ver los incidentes que afectan a cada objeto de inventarios y hace que tengamos que buscar otros medios para gestionar clientes, facturas etc.
• Sus datos de evaluación muestran los porcentajes de satisfacción, pero falta algo más para conocer la evolución de nuestro negocio.
23
5 Sistema OTRS
5.1 Evaluación Se evalúa la arquitectura de red donde trabajara OTRS así como el framework:
Ilustración 5 Arquitectura de red
El framework de OTRS es modular y puede ser representada mediante el siguiente esquema:
24
Ilustración 6 Capa Básica de arquitectura OTRS
La interfaz genérica de OTRS continúa con el modularidad de OTRS. La siguiente imagen muestra la arquitectura de capa básica de la interfaz genérica: Directorios
Directory Descripción
bin/ Herramienta línea de comandos
bin/cgi-bin/ Scripts CGI
bin/fcgi-bin/ fast CGI
Kernel Código de aplicación
Kernel/Config/ Archivos de configuración
Kernel/Config/Files Archivos de configuración
Kernel/GenericInterface/ Interfaz genérica API
Kernel/GenericInterface/Invoker/ Invocador de módulos para la interfaz genérica
25
Directory Descripción
Kernel/GenericInterface/Mapping/ Modulos mapping para la interfaz genérica
Kernel/GenericInterface/Operation / Módulos de operación para la interfaz genérica
Kernel/GenericInterface/Transport / Módulos de transporte para la interfaz genérica como “HTTP SOAP”
Kernel/Language Archivos de traducción
Kernel/Scheduler/ Archivos de calendario
Kernel/Scheduler/TaskHandler Módulos para las tareas del calendario
Kernel/System/ Modulos Core como Log, Ticket
Kernel/Modules/ Módulo front end, como QueueView
Kernel/Output/HTML/ Plantillas html
var/ variable data
var/log Archivos de Log
var/cron/ Archivos cron
var/httpd/htdocs/ htdocs directorio con el index.html
var/httpd/htdocs/skins/Agent/ Skins disponibles para la interface de los agentes
var/httpd/htdocs/skins/Customer/ Skins disponibles para la interface de los clientes
var/httpd/htdocs/js/ Archivos JavaScript
scripts/ Archivos misc
scripts/test/ Archivos de testeo
scripts/test/sample/ Ejemplo de archivos de testeo
Tabla 2 Directorio OTRS
26
Ilustración 7 Esquema interfaz genérica
Teniendo en cuenta todo lo anterior, al implementarlo tenemos los siguientes riesgos:
• Proyecto de software libre con baja o nula calidad de soporte por parte del desarrollador teniendo que contratarlo a un tercero.
• Sin posibilidad de contratar Formación directamente.
• Riesgo de abandono de mejora de versiones.
5.2 Casos de uso Los casos de uso son una de las herramientas principales del Unified Modeling Language (UML), que es una notación basada en diagramas adoptada como estándar para describir sistemas de software orientados a objetos, siendo una forma de especificar el comportamiento externo de un sistema. Esto, nos va a permitir conocer los requerimientos del sistema, así como conocer y entender a través de los servicios o funciones que ofrece a los usuarios que usaran la herramienta de OTRS.
27
5.2.1 Customer - Cliente
Ilustración 8 Caso de uso Cliente
Nombre Login
Actores Cliente
Objetivo El cliente tiene que hacer login para acceder al sistema
Escenario Básico 1.introducir usuario 2. introducir contraseña 3. Click en "iniciar sesión"
Nombre Crear Ticket
Actores Cliente
Objetivo El cliente que crear un ticket
Escenario Básico El cliente deberá rellenar todos los campos obligatorios: 1. Introducir "tipo" (desplegable) 2. introducir "para" (desplegable) 3. Introducir "asunto" 4. Introducir "texto" 5. Añadir adjuntos (no obligatorio) 6. Elegir prioridad 7. Click en "enviar"
Nombre Logout
Actores Cliente
Objetivo El cliente tiene que hacer logout para acceder al sistema
Escenario Básico 1.introducir usuario 2. introducir contraseña 3. Click en "Logout Usuario"
28
5.2.1 Resolución de tickets – Agente
Ilustración 9 Caso de Uso creación ticket
Nombre Actuación
Actores Agente
Objetivo El agente deberá leer la incidencia y comunicar los pasos a seguir al cliente o con el proceso de resolución de la misma.
Escenario Básico El agente deberá seleccionar del dashboard el ticket: 1. leer la incidencia 2. introducir una actuación sobre la incidencia 3. comunicar al cliente a través de la interfaz o del correo electrónico. 4. Cerrar el ticket en caso necesario.
Nombre Resolución y cierre
Actores Agente
Objetivo El agente deberá resolver la incidencia y cerrarla
Escenario Básico El agente tomará las medidas necesarias para resolver la incidencia.
29
5.3 Diseño de procedimientos Dentro de la posibilidad de procedimientos que se realizaran, debido a la extensión de los mismos para este proyecto, se realizara uno para su instalación en el servidor y otro para el uso de la herramienta. Podría optarse por realizarlo en ANEXOS separados, pero se ha optado por implementarlos en el proyecto:
5.3.1 Instalación Se procede a realizar una instalación limpia sobre un servidor Linux con Ubuntu 18.04 instalado en el mismo.
1. Actualizar repositorio de Ubuntu.
2. Instalar Apache2 y PostgreSQL con apt:
3. Chequear que Apache y PostgreSQL están funcionando chequeando el puerto:
Ilustración 10 Listado conexiones activas
Se comprobará que el puerto 80 estará siendo usado por Apache y que el puerto 5432 estará usado por PostgreSQL.
4. OTRS está basado en Perl, por lo que se requiere la instalación de modules de Perl:
30
5. Una vez instalado, debemos activar el módulo de Perl para Apache y posteriormente reiniciar el servicio de apache.
6. Comprobaremos que el módulo de apache haya cargado correctamente:
Ilustración 11 Listado de módulos cargados Apache
7. OTRS es una aplicación basada en web y se ejecuta bajo el servidor web apache. Para mayor seguridad, necesitamos ejecutarlo con un usuario normal, no con el usuario root.
-r: hace al usuario como cuenta de sistema -d /opt/otrs: define el directorio home para el nuevo usuario -c: comentario añadido, en este caso "OTRS User"
8. Añadir el usuario OTRS al grupo 'www-data', porque apache se está ejecutando bajo el usuario y grupo 'www-data'.
31
9. Chequear que el usuario OTRS está disponible:
10. Una vez realizado todo lo anterior se procederá a la descarga, extracción e instalación de OTRS:
11. Una vez instalada la aplicación, chequeamos que todos los módulos estén OK;
Ilustración 12 Módulos OTRS instalados
Los módulos que aparecen como no instalados no son necesarios para el caso que nos acomete.
12. Una vez terminada la instalación y configuración, ya podremos acceder al sistema.
32
5.3.2 Uso de la herramienta – Manual cliente
1. Acceso al sistema En un navegador web, acceder a través de la dirección: http://10.39.102.24/otrs/customer.pl
Ilustración 13 Login cliente
Rellenar los campos con el nombre de usuario y Contraseña, y hacer clic en Iniciar Sesión. Al iniciar la sesión, nos devolverá la pantalla de bienvenida.
2. Creación de un ticket
i) La primera vez que se ingresa, y no se ha creado previamente un ticket, nos aparecerá esta imagen:
Ilustración 14 Primer ticket
33
Hacer clic en el botón Cree su primer ticket
ii) si anteriormente había ya creados tickets nos aparecerá esta imagen:
Ilustración 15 Tickets
Ilustración 16 Formulario creación tickets
34
Campos obligatorios marcados con asterisco:
• Tipo: Aquí aparecen las categorías previamente creadas.
• Para: Aquí aparece el listado de las colas de tickets.
• Asunto: Asunto del ticket.
• Texto: Cuerpo del ticket donde se detalla la incidencia. Campos opcionales:
• Archivos adjuntos: Ficheros relevantes que se vayan a adjuntar.
• Prioridad: Se establece la urgencia del ticket.
5.3.3 Uso de la herramienta – Manual Agente
1. Acceso al sistema En un navegador web, acceder a través de la dirección: http://10.39.102.24/otrs/index.pl
Ilustración 17 URL Login Agente
35
Rellenar los campos con el nombre de usuario y Contraseña, y hacer clic en Iniciar Sesión. Al iniciar la sesión, nos devolverá la pantalla de bienvenida.
2. Dashboard En la pantalla principal, saldrán los tickets de los clientes que nos habrán sido asignados
Ilustración 18 Dashboard del agente
Una vez dentro del ticket, nos aparecerá el problema del cliente:
Ilustración 19 Ticket Cliente
Desde esta pantalla, las opciones a realizar son las siguientes:
• Imprimir: Permite imprimir en PDF o en papel, el ticket en cuestión.
• Prioridad: Permite cambiar la prioridad de 1 a 5:
Ilustración 20 Cambiar prioridad
36
• Gente: Permite cambiar tanto el propietario como el cliente del ticket:
Ilustración 21 Gente
• Comunicación: Permite añadir una actuación en el ticket mediante:
▪ Nota ▪ Llamada saliente ▪ Llamada entrante ▪ Email Saliente
Ilustración 22 Comunicación
• Pendiente: Poner el ticket en pendiente de realizar actuaciones sobre él:
Ilustración 23 Pendiente
• Cerrar: Permite cerrar el ticket
Ilustración 24 Cerrar ticket
• Borrar: Permite borrar un ticket si eres administrador.
37
• Misceláneo: Diferentes opciones para realizar sobre el ticket:
Ilustración 25 Misceláneo
Entre esas opciones tenemos:
• Bloquear: Bloquea un ticket dentro del grupo de agentes, para que otro agente no pueda trabajar sobre el mismo incidente.
• Historial: Se puede ver el historial de actuaciones sobre un ticket.
• Campos libres: Permite modificar todos los campos del ticket que ha rellenado el cliente, por si hubiera rellenado los campos con errores.
• Enlazar: Permite enlazar tickets que tengan relación entre ellos.
• Fusionar: Si varios tickets piden lo mismo, se pueden fusionar para que solo exista un solo ticket.
• Nueva cita: Permite añadir al calendario, eventos:
Ilustración 26 Añadir cita
38
5.4 Configuración Módulos Desde la herramienta de Admin, se configurarán todos los módulos pertinentes:
Ilustración 27 Configuración Módulos - 1
Ilustración 28 Configuración Módulos - 2
En cada una de las opciones tendremos las distintas modalidades de configuración. Para este proyecto, veremos solo las más relevantes:
39
1. Colas: donde se configuran las distintas colas de trabajo, donde se ubicaran los tickets y que solo determinados usuarios accederán a ella:
Ilustración 29 Colas
2. Cuentas de correo electrónico: Los correos que lleguen a esta cuenta, inyectara automáticamente los correos como tickets
Ilustración 30 Cuenta de correo
3. A través de todas estas opciones, crearemos los agentes, a qué
grupo pertenecen, que roles tienen y en definitiva, cada una de las opciones relativas a los permisos y pertenencia dentro de OTRS.
40
Ilustración 31 Agentes
4. Registro del sistema: a través de esta opción veremos todo lo que
va ocurriendo en el sistema, en caso de error:
Ilustración 32 Registro de sistema
41
5.4.1 Copias de seguridad Los medios de almacenamiento contienen uno de los activos más preciados: la información. Estos dispositivos pueden verse involucrados en situaciones como robos, incendios, inundaciones, fallos eléctricos, rotura o fallo del dispositivo, virus, borrados accidentales, etc. Para ello, es sistema OTRS contará con un sistema automatizado de copias de seguridad a través del terminal del sistema operativo. Usage: backup.pl -d /data_backup_dir [-c gzip|bzip2] [-r DAYS] [-t fullbackup|nofullbackup|dbonly] Options:
-d -Directory where the backup files should place to. [-c] -Select the compression method (gzip|bzip2).Default: gzip. [-r DAYS] -Remove backups which are more than DAYS days old.
[-t] -Specify which data will be saved (fullbackup|nofullbackup|dbonly). [-h] -Display help for this command.
Help: Using -t fullbackup saves the database and the whole OTRS home directory (except /var/tmp and cache directories). Using -t nofullbackup saves only the database, /Kernel/Config* and /var directories.
With -t dbonly only the database will be saved. Tabla 3 Codigo Backup OTRS
En nuestro sistema el código a implementar será el siguiente:
Ilustración 33 Comando Backup
Con este código, realizaremos la copia completa del sistema OTRS, pero solo cuando se ejecute el mismo, por lo que deberemos añadirlo a un cronjob para que se realice recursivamente en el periodo de tiempo que estimemos oportuno. Para ello ejecutaremos el siguiente comando: crontab -e
42
Ilustración 34 Periodicidad Backup
con este comando, conseguimos que todos los días del año, a las 17:00 horas se realice una copia completa del sistema (fullbackup), haciendo una llamada al script backup.pl y poniéndola en la ruta de destino /home/servidor/BACKUP/.
Ilustración 35 Listado de Backups realizados
43
En caso de que sea necesario restaurar una copia de seguridad:
Restore an OTRS system from backup. Usage: restore.pl -b /data_backup/<TIME>/ -d /opt/otrs/ Options: -b - Directory of the backup files. -d - Target OTRS home directory. [-h] - Display help for this command.
Ilustración 36 Restauración copia de seguridad
Llegado el momento y llegado el caso el código a implementar sería el siguiente:
Ilustración 37 Código Restaurar Backup
Con este comando, conseguimos que se realice un restauración completa del sistema, haciendo una llamada al script restore.pl y restaurando el archivo de la copia de seguridad de la ruta /home/servidor/BACKUP/FECHA DE La COPIA/ e instalándolo en la ruta: /opt/otrs
5.4.1 Configuración Módulo SendMail Uno de los módulos más productivos de OTRS es el que crea la posibilidad de que todos los correos electrónicos entren directamente en el sistema como tickets aparte de los que nos enviase el cliente en cuestión. Para ello, configuraremos los siguientes parámetros:
1. Editar el archivo sendmail desde /etc/mail/sendmail.mc , ejecutando el siguiente código:
Ilustración 38 Edición sendmail.mc
44
2. Quitar el comentario de la siguiente línea: dnl define(`SMART_HOST', `smtp.your.provider')dnl
Ilustración 39 Edición código sendmodule
3. Una vez modificado, hay que regenerar el fichero de configuración /etc/mail/sendmail.cf con el siguiente comando: /etc/mail/make
4. Una vez terminada la configuración es necesario reiniciar el
servicio con el siguiente comando: service sendmail restart
6 Documentación
6.1 Modelo Organizativo
6.1.1 Objeto y Ámbito El objeto del presente documento es la definición del Modelo organizativo dentro SEYMA S.L. De acuerdo con lo que se describirá en la Política de Seguridad de la Información de SEYMA S.L, el Modelo organizativo de la seguridad de la información resulta de aplicación los sistemas de información y activos utilizados por la SEYMA S.L en cualquier tipo de soporte en el que se puedan encontrar. El Modelo organizativo es de obligado cumplimiento por todo el personal de la SEYMA S.L, así como por terceros que presten servicios para SEYMA S.L o para colaboradores.
6.1.2 Estructura Organizativa
La estructura organizativa de Seguridad de la Información de SEYMA S.L, estará compuesta por:
6.1.2.1 Grupo de Trabajo de Seguridad, Investigación y Proyectos (GTSIP)
45
Será el responsable de velar e impulsar las directrices en materia de Seguridad de la Información en la SEYMA S.L. Las funciones del Grupo de Trabajo de Seguridad, Investigación y Proyectos, en adelante GTSIP, serán las que se indican en la Política de Seguridad de la SEYMA S.L. El GTSIP será presidido por el Director General de SEYMA S.L o por el cargo en quien delegue. El GTSIP se encontrará formado por:
• El Responsable de la Información.
• El Responsable del Servicio.
• El Responsable de la Seguridad.
• Los Responsables de los Sistemas.
• El Secretario del GTSIP.
Anualmente, se realizará la revisión de la composición del GTSIP, procediendo a su renovación si se considera pertinente.
6.1.2.2 Responsable de la Información Es la persona que tiene la potestad de establecer los requisitos de la información en materia de seguridad. Esta función de Responsable de la Información recae sobre el Subdirector General de Logística de la SEYMA S.L. Corresponde al Responsable de la Información: a) Determinar los niveles de seguridad de la información tratada, valorando los
impactos de los incidentes que afecten a la seguridad de la información.
b) Realización de los análisis de riesgos, seleccionando las salvaguardas a
implantar. Esta actuación la realizará junto con el Responsable del Servicio
(Proyectos) y contando con la participación del Responsable de Seguridad.
c) Aceptación de los riesgos residuales respecto a la información, calculados
en el análisis de riesgos.
Para la determinación de los niveles de seguridad de la información, el responsable de la información solicitará informe del Responsable de la Seguridad.
6.1.2.3 Responsable del Servicio Es la persona que tiene la potestad de establecer los requisitos del servicio. Dentro de la SEYMA S.L esta función recaerá sobre el Jefe del Area de Informática y Comunicaciones.
46
Las funciones del Responsable del Servicio son las siguientes: a) Determinar los niveles de seguridad del servicio, valorando los impactos de
los incidentes que afecten a la seguridad del servicio.
b) Realización, junto a los Responsables de la Información y contando con la
participación del Responsable de Seguridad, de realizar los análisis de
riesgos; seleccionando las salvaguardas a implantar.
c) Aceptación de los riesgos residuales respecto a los servicios, calculados en
el análisis de riesgos.
d) Para la determinación de los niveles de seguridad del servicio, el
responsable del servicio solicitará informe del Responsable de la Seguridad.
6.1.2.4 Responsable de Seguridad Es la persona que determina las decisiones para satisfacer los requisitos de seguridad de la información y de los servicios. Dentro de la SEYMA S.L esta función en el Jefe del Servicio de Seguridad TIC. Son funciones del responsable de la Seguridad, dentro de su ámbito de actuación, las siguientes: a) Desarrollar las directrices, estrategias y objetivos dictados por el GTSIP.
b) Proveer de asesoramiento y apoyo al GTSIP.
c) Elaborar la normativa de seguridad.
d) Aprobar los procedimientos operativos de seguridad.
e) Mantener la seguridad de la información manejada y los servicios
electrónicos prestados por los sistemas.
f) Realizar o promover auditorías periódicas para verificar el cumplimiento de
las obligaciones en materia de seguridad de la información.
g) Realizar el seguimiento y control del estado de la seguridad de la
información dentro de SEYMA S.L
h) Verificar que las medidas de seguridad son adecuadas para la protección
de la información y los servicios.
i) Apoyar y supervisar la investigación de los incidentes de seguridad desde
su notificación hasta su resolución.
j) Elaborar informes periódicos de seguridad para el GTSIP que incluyan los
incidentes más relevantes de cada período.
47
k) Supervisar el registro de activos.
l) Participar en los Grupos de Trabajo de Responsables de Seguridad
(GTRS).
6.1.2.5 Responsable del Sistema El Responsable del Sistema es la persona que tiene la responsabilidad de desarrollar, operar y mantener el Sistema de Información durante todo su ciclo de vida, de sus especificaciones, instalación y verificación de su correcto funcionamiento. Esta responsabilidad recae sobre el Jefe del Área de Informática y el Jefe del Área de Telecomunicaciones, en función de dónde se encuentre ubicado el sistema de información y quién lo explote.
Las funciones del Responsable del Sistema son:
a) Aprobar la definición de la topología del sistema de Información y la gestión
de este. Estableciendo los criterios de uso y los servicios disponibles.
b) Asegurar que las medidas específicas de seguridad se integran
adecuadamente dentro del marco de la seguridad en la SEYMA S.L.
c) Suspensión del manejo de una cierta información o la prestación de un
determinado servicio por deficiencias graves de seguridad. Esta decisión
debe ser acordada con los responsables de la información afectada, del
servicio afectado y el Responsable de la Seguridad, antes de ser ejecutada.
6.1.2.6 Analista de Riesgos de Seguridad Es la persona encargada de coordinar todo el proceso de análisis y gestión de riesgos de acuerdo a las fases de la presente guía y los documentos resultantes de cada fase. Esta responsabilidad recaerá sobre el 2º Jefe del Servicio de Seguridad TIC. El analista de riesgos de seguridad es responsable de:
• Coordinar a los participantes y llevar el peso documental del proceso de
análisis y gestión de riesgos.
• Identificar los roles implicados en el análisis y gestión de riesgos.
• Identificar el nivel de cumplimiento de los controles identificados.
• Analizar los riesgos asociados e identificar los controles de seguridad
que deben de cumplir los activos.
• Revisar y actualizar la lista de controles y riesgos asociados en las
fases de implantación y verificación de controles.
48
• Informar al Responsable de Seguridad de los controles no implantados
o parcialmente implantados.
• Realizar el seguimiento de los proyectos de los controles aceptados y
pendientes de implantar.
6.1.2.7 Secretario del GTSIP
Será el Secretario quien asistirá a las reuniones del GTSIP, elaborando las actas de cada reunión del GTSIP que dan fe y quedan como evidencia de lo tratado en dichas reuniones. El Secretario del GTSIP firmará el acta donde se reflejen el/los documento(s) que ha(n) sido aprobado(s). Esta responsabilidad recaerá sobre un funcionario del Área de Informática y Comunicaciones de la SEYMA S.L.
6.2 Política de Seguridad
6.2.1 Objeto y Ámbito El objeto del presente documento es desarrollar la Política de Seguridad de la Información de SEYMA S.L, en adelante SEYMA S.L. Esta Política de Seguridad será de aplicación a los sistemas de información y activos utilizados por SEYMA S.L, en cualquier tipo de soporte en el que se puedan encontrar. La Política de Seguridad de la Información será de obligado cumplimiento para todo el personal de SEYMA S.L así como para terceros que presten servicios para SEYMA S.L o colaboradores.
6.2.1.1 Objetos de la Política de Seguridad
1. Asegurar que el personal de SEYMA S.L conoce y comprende los
problemas asociados a la seguridad de la información y que asumen
y son conscientes de sus responsabilidades en este tema.
2. Proporcionar una guía para establecer los estándares,
procedimientos y medidas de seguridad para desarrollar un Sistema
de Seguridad de la Información.
3. Asegurar la confidencialidad de la información almacenada en los
sistemas de información.
49
4. Maximizar la disponibilidad e integridad de la información.
5. Reducir o eliminar los peligros y riesgos inherentes a nuestras
actividades por medio de la mejora continua del desempeño en
seguridad en nuestros procesos y servicios.
6. Garantizar que las operaciones y procesos actuales y futuros
cumplan con la legislación vigente en materia de seguridad de la
Información.
7. Mantener a disposición de las partes interesadas la Política presente,
así como los futuros desarrollos de la misma.
6.2.2 Estructura Organizativa La estructura organizativa de Seguridad de la Información de SEYMA S.L, estará compuesta por: Grupo de Trabajo de Seguridad, Investigación y Proyectos: Es el responsable de velar e impulsar las directrices en materia de Seguridad de la Información, Investigación y la realización e implantación de Proyectos en SEYMA S.L. Las funciones del Grupo de Trabajo de Seguridad, Investigación y Proyectos, en adelante GTSIP, serán:
1. Redactar y aprobar las normas de segundo nivel correspondientes al
ámbito de influencia de SEYMA S.L.
2. Velar e impulsar el cumplimiento de las normas de segundo nivel y
promover el desarrollo del tercer nivel normativo.
3. Aprobación de los planes de mejora de la seguridad en su ámbito de
competencias, de acuerdo a los presupuestos disponibles.
4. Promover la mejora continua en la gestión de la seguridad de la
información en su ámbito de competencias.
5. Impulsar la formación y concienciación en su ámbito.
6. Resolver los conflictos que puedan aparecer entre los diferentes
responsables y/o entre diferentes áreas de la Organización, elevando
aquellos casos en los que no tenga suficiente autoridad para decidir.
Responsable de la Información: Es la persona o personas que tienen la potestad de establecer los requisitos de la información en materia de seguridad. Serán funciones del Responsable de la Información:
50
1. Determinar los niveles de seguridad de la información tratada, valorando
los impactos de los incidentes que afecten a la seguridad de la
información.
2. Realización, junto a los Responsables del Servicio y contando con la
participación del Responsable de Seguridad, de realizar los análisis de
riesgos; seleccionando las salvaguardas a implantar.
3. Aceptación de los riesgos residuales respecto a la información,
calculados en el análisis de riesgos.
Para la determinación de los niveles de seguridad de la información, el responsable de la información solicitará informe del Responsable de la Seguridad. Responsable del Servicio: Es la persona o personas que tienen la potestad de establecer los requisitos del servicio en materia de seguridad. Puede coincidir en la misma persona las responsabilidades de la información y del servicio. La diferenciación tiene sentido cuando el servicio maneja información de diferentes procedencias.
Las funciones del Responsable del Servicio serán las siguientes:
4. Determinar los niveles de seguridad del servicio, valorando los impactos
de los incidentes que afecten a la seguridad del servicio.
5. Realización, junto a los Responsables del Servicio y contando con la
participación del Responsable de Seguridad, de realizar los análisis de
riesgos; seleccionando las salvaguardas a implantar.
6. Aceptación de los riesgos residuales respecto a los servicios, calculados
en el análisis de riesgos.
7. Para la determinación de los niveles de seguridad del servicio, el
responsable del servicio solicitará informe del Responsable de la
Seguridad.
Responsable de Seguridad: Es la persona que determina las decisiones para satisfacer los requisitos de seguridad de la información y de los servicios. Cuando por razones de complejidad, distribución, separación física de sus elementos o número de usuarios de los sistemas de información lo justifiquen, el Director General de SEYMA S.L podrá designar los Responsables de Seguridad delegados que considere necesarios que tendrán dependencia funcional del Responsable de Seguridad siendo responsables en su ámbito de todas aquellas acciones que les delegue.
51
Serán funciones del responsable de la Seguridad, dentro de su ámbito de actuación, las siguientes:
1. Desarrollar las directrices, estrategias y objetivos dictados por el
GTSIP.
2. Proveer de asesoramiento y apoyo al GTSIP.
3. Elaborar la normativa de seguridad.
4. Aprobar los procedimientos operativos de seguridad.
5. Mantener la seguridad de la información manejada y los servicios
electrónicos prestados por los sistemas.
6. Realizar o promover auditorías periódicas para verificar el
cumplimiento de las obligaciones en materia de seguridad de la
información.
7. Realizar el seguimiento y control del estado de la seguridad de la
información dentro de SEYMA S.L.
8. Verificar que las medidas de seguridad son adecuadas para la
protección de la información y los servicios.
9. Apoyar y supervisar la investigación de los incidentes de seguridad
desde su notificación hasta su resolución.
10. Elaborar informes periódicos de seguridad para el GTSIP que
incluyan los incidentes más relevantes de cada período.
11. Supervisar el registro de activos.
12. Participar en los Grupos de Trabajo de Responsables de Seguridad
(GTRS).
El Responsable del Sistema:
El Responsable del Sistema es la persona o personas que tienen la responsabilidad de desarrollar, operar y mantener el Sistema de Información durante todo su ciclo de vida, de sus especificaciones, instalación y verificación de su correcto funcionamiento.
Las funciones del Responsable del Sistema serán:
1. Definir la topología del sistema de Información y la gestión de
este. Estableciendo los criterios de uso y los servicios disponibles.
2. Asegurar que las medidas específicas de seguridad se integran
adecuadamente dentro del marco de la seguridad en SEYMA S.L.
3. Suspensión del manejo de una cierta información o la prestación
de un determinado servicio por deficiencias graves de seguridad.
Esta decisión debe ser acordada con los responsables de la
52
información afectada, del servicio afectado y el Responsable de la
Seguridad, antes de ser ejecutada.
6.2.3 Principios básicos de seguridad en SEYMA S.L
6.2.3.1 Gestión de Riesgos SEYMA S.L está altamente concienciada en la prevención, detección,
corrección y mitigación de los riesgos.
Son, los Responsables de la Información y de los Servicios, los encargados de
la identificación, tratamiento y control de los riesgos.
Las medidas de seguridad a aplicar para el tratamiento de los riesgos serán
propuestas por el Responsable de Seguridad, debiendo revisarse al menos una
vez al año por dicho responsable.
6.2.3.2 Desarrollo Normativo SEYMA S.L desarrollará su Política de Seguridad de la Información en base a 3
niveles:
1. Nivel Normativo: Política de Seguridad de la Información y Normas
Básicas de Seguridad de la Información.
2. Normas Específicas de Seguridad de la Información.
3. Procedimientos, Instrucciones Técnicas, Registros, etc.
El Responsable de Seguridad será el encargado de velar por que la documentación de seguridad se encuentre actualizada y organizada.
6.2.3.3 Cumplimiento Normativo SEYMA S.L cumplirá con la legislación vigente referida a la Protección de
Datos de Carácter Personal, al Esquema Nacional de Seguridad en el ejercicio
de sus servicios a la administración pública, así como con todas aquellas
normativas de obligado cumplimiento en materia de Seguridad de la
Información.
6.2.3.4 Terceras Partes / Colaboradores y Servicios Externos
Cuando por cualquier tipo de relación con SEYMA S.L un tercero tenga acceso
a la información de la misma se asegurará su adhesión a los términos y las
condiciones referentes a la Política de Seguridad de la Información.
53
Cuando algún aspecto de la Política de Seguridad de la Información no pueda
ser satisfecho por una tercera parte, se requiera al Responsable de Seguridad
que precise los riesgos en que se incurre y la forma de tratarlos.
6.2.3.5 Concienciación y Formación
SEYMA S.L velará porque todo el personal relacionado con el tratamiento de la
información se encuentre formado e informado de sus deberes y obligaciones
en materia de Seguridad de la Información. Para ello SEYMA S.L dispondrá de
una planificación anual donde se detallarán la formación y la concienciación.
6.2.3.6 Continuidad del Servicio Es imprescindible para SEYMA S.L establecer las pautas de actuación a seguir en caso de que se produzca una interrupción de los servicios prestados por fallos graves en la seguridad o desastres de cualquier tipo. Para garantizar la continuidad del servicio en estos casos, SEYMA S.L establecerá Planes de Contingencia que permitan la recuperación de las actividades al menos a un nivel mínimo en un plazo razonable de tiempo. La Gestión de la continuidad del negocio (Servicio) incluirá, por tanto, diversos controles para la identificación y reducción de riesgos/impactos con el fin de limitar las consecuencias dañinas de los mismos y asegure la reanudación de las actividades esenciales en el menor tiempo posible.
6.2.4 Revisión de la Política de Seguridad Se revisará periódicamente y siempre que haya cambios significativos la Política de Seguridad de la Información.
6.3 Grupo de Trabajo de Seguridad, Investigación y Proyectos
6.3.1 Objeto y Ámbito
En el punto 2.1.3 Funcionamiento del Grupo de Trabajo de Seguridad,
Investigación y Proyectos, se lee textualmente:
“Se establecerá un flujo de trabajo para la revisión y aprobación de los documentos de segundo nivel presentados al GTSIP. Una vez aprobados los documentos de segundo nivel será el Responsable de Seguridad, o la
54
persona en quien delegue, el encargado de custodiar los mismos y de promover las normas de tercer nivel. Para la aprobación de los documentos por parte del GTSIP, dada la importancia de los asuntos que van a tratar, se exige la unanimidad de los miembros presentes en las reuniones del GTSIP.”
El objeto del presente documento describe cómo se realiza el flujo de trabajo para la revisión y aprobación de los documentos presentados al GTSIP. Este documento se encuentra dentro del Marco Normativo de Seguridad de la Información que existe en SEYMA S.L El ámbito de actuación serán todos los documentos que forman parte del Marco Normativo de Seguridad de la Información dentro de SEYMA S.L
6.3.2 Flujo de revisión y aprobación de documentos por el GTSIP Los documentos presentados al GTSIP en sus reuniones de trabajo serán enviados con la suficiente antelación a todos sus miembros a través de la lista de distribución [email protected] para su estudio y revisión. En las reuniones de trabajo del GTSIP, los documentos serán discutidos y quedarán aprobados por unanimidad de los miembros presentes una vez se llegue a un acuerdo.
Esta aprobación quedará reflejada en el acta de la reunión correspondiente en la que figurarán los asistentes a ella. El secretario del GTSIP firmará electrónicamente todos los documentos aprobados con el fin de dar fe de la aprobación de estos:
Secretario del GTSIP – Área de Informática y Comunicaciones
Aprobado en la reunión del GTSIP de fecha: dd/mm/aaaa
Ilustración 40 Formato de firma
Cuando en la discusión de un documento se decida realizar cambio/s sobre el mismo, será el propio GTSIP el que acuerde, bien la aprobación de este en esa misma reunión figurando dicho/s cambio/s en el acta correspondiente, o bien que sea presentado para su discusión y aprobación en la siguiente reunión. Los documentos aprobados por el GTSIP serán entregados al Responsable de Seguridad de Información y al secretario del GTSIP para su
55
custodia y difusión de los mismos a través del repositorio común establecido para tal fin.
6.4 Plan formativo especifico Este apartado plasmara en base de la visión de la empresa y a la identificación de las necesidades del personal, dirigida a los colectivos específicos que responda a la necesidad que tienen determinadas las áreas que usan el software OTRS, para así acceder a acciones formativas acordes con las tareas que realizan o la especificidad de las competencias atribuidas a esas áreas.
Acción formativa
Horas Horario Modalidad Destinatarios
OTRS 50 8:30 – 14:30 Presencial Todo el personal
La inscripción se realizará a través del email corporativo al área de formación. Al finalizar la formación, se realizará una prueba de evaluación para ver el grado de asimilación de los contenidos del curso. Además, a todos los alumnos se les dará un formulario que deberán rellenar de forma anónima para obtener un feedback del curso formativo y tener conocimiento de la calidad de este. Al finalizar, se otorgará a cada alumno un certificado de aprovechamiento, el cual acreditará la asistencia al mismo, siendo requisito indispensable para la obtención del mismo, acreditar una asistencia superior al 80% de las horas lectivas de la acción formativa.
6.5 Implantar una WIKI Como parte del planning, veremos los distintos aspectos para implantar una wiki corporativa. Para ello analizaremos los beneficios o ventajas y el uso que se le podrá aplicar dentro de SEYMA S.L. Antes de analizarlos, definiremos que es un wiki, y tal y como dice Wikipedia el término wiki (proviene del hawaiano wiki, «rápido») alude al nombre que recibe una comunidad virtual, cuyas páginas son editadas directamente desde el navegador, donde los mismos usuarios crean, modifican, corrigen o eliminan contenidos que, normalmente, comparten.
56
6.5.1 Beneficios Uno de los principales beneficios de la Wiki (y a menudo motivo por el cual se decide implantar una en la organización) es la de mantener un repositorio de conocimiento. La mayor parte del conocimiento de las personas es implícito y se escapa de la organización cuando un individuo decide dejarla por otro puesto de trabajo en otra organización. Enumerare los beneficios directos más importantes al montar una wiki corporativa:
• Es económica (Open-Source)
• Permite crear y mejorar las páginas de forma instantánea
• Contienen contenidos actualizados
• Favorecen la revisión del trabajo
• Incrementan la motivación e inteligencia colectiva.
6.5.2 Usos La wiki corporativa podrá usarse para:
• Fuente de información de servicios de la compañía: Podrá almacenar en tiempo real sobre las funcionalidades y novedades del servicio.
• Evaluación de nuevos productos
• Ejecución de nuevos proyectos: Se pueden mostrar las distintas fases del proyecto y hacer un seguimiento de los avances de manera rápida y de forma abierta y trasparente para la empresa.
• Nuevos empleados: La adaptación de los nuevos empleados al funcionamiento de la empresa puede ser mucho más sencillo si dispone del contenido Wiki adaptado para ese fin, como pudiera ser manuales de bienvenida, organigramas o contactos
• Repositorio de información
6.5.3 Estudio de Software a implantar Dentro de las distintas opciones del mercado, y considerando que podría ser una mejora dentro del servicio que ofrecería la empresa, se considera la implantación de los siguientes softwares:
• MediaWiki: (software A)
o Open Source
57
o SO: Windows 2008 o superior o Web Service: apache,IIS o Lenguaje: PHP o BBDD: MySQL, PostgresSQL, Sqlite
Ilustración 41 MediaWiki
• TWiki: (software B)
o Open Source o SO: Windows XP o superior o Web Service: apache,IIS o Lenguaje: Perl o BBDD: No aplica o Control de acceso o Estadística o Notificación por email
Ilustración 42 TWiki
58
• WikkaWiki: (Software C)
o Open Source o SO: Windows, Linux y iOS o Web Service: Apache o Lenguaje: PHP o BBDD: MySQL o Control de acceso o Compatibilidad con varios idiomas o No tiene foro
Ilustración 43 WikkaWiki
6.5.4 Selección de Software Haremos una identificación superficial de las características que debería tener la posible solución incluyendo tanto los aspectos propios de la solución como los del proveedor, implantador, apoyo y costes. Aspectos Propios:
• Facilidad de uso
• Funcionalidad
• Calidad documental
• Documentación
• Escalabilidad Proveedor:
• Sectorización: Buscaremos un ERP especializado en educación.
59
• Eficiencia: Comprobación de resultados anteriores de éxito.
• Soporte:
• Adaptabilidad: Es una plataforma cerrada o permite modulación. Implantador:
• Conocimiento
• Capacidad
• Estrategia Apoyo: Se debe contar con una empresa capaz de coordinar recursos y que sea capaz de identificar las particularidades del sector de educación.
• Consultoría Costes: Los costes asociados a las parametrizaciones locales tendrá una relevancia alta.
• licencias
• Contratos de formación
• Internos y externos (desarrollo y mantenimiento) Se realiza una tabla de valoración con los criterios decisorios anteriores para la comparativa de las soluciones. Esta ponderación estará establecida por el GTSIP. En esta tabla, el peso más alto se ha correspondido a la documentación debido a la importancia de esa característica para la empresa:
Tabla 4 Elección Software WiKi
Una vez realizada la valoración, si la alta dirección decide implantar una WiKi, está será la opción B, es decir, la Wiki TWiKi
60
7. Conclusiones
Una de las lecciones que he aprendido es que cualquier empresa que no tenga un proceso estandarizado de trabajo, es una empresa que está perdiendo una productividad muy alta en base a la cantidad de horas desaprovechadas para una post-estandarización entre distintos departamentos. No tiene sentido que distintos responsables de departamentos tengan que realizar reuniones para decidir cómo resolver una incidencia.
Es ahí, donde OTRS y su proceso de estandarización y protocolización donde saca todo su potencial, ya que el proceso esta estandarizado y normalizado de principio a fin. Desde mi punto de vista, he conseguido alcanzar todos los objetivos, pero no sin tener diferentes inconvenientes que me he encontrado durante la realización de las distintas PACs, como fueron:
• Falta de centrar el alcance del proyecto, queriendo abarcar demasiados puntos
• Pequeños contratiempos personales
• Durante la PAC2, no pude realizar diversos puntos debido a la coincidencia de un elevado volumen de carga en el trabajo junto con varios viajes profesionales fuera de Madrid.
• Debido al punto anterior, he modificado levemente la planificación, ya que he podido recuperar el tiempo perdido en la anterior PAC.
61
8. Glosario
• ADMIN: Usuario con los privilegios más altos que permite controlar toda la configuración del sistema sobre el que actúe.
• AGENTE: Tipo de empleado que resuelve las incidencias a través de los tickets.
• DASHBOARD: Cuadro de mando o panel de control del usuario.
• DIBA: Data Internet Banda Ancha.
• CLIENTE: Tipo de empleado que crea las incidencias a través de los tickets.
• CPD: Centro de Proceso de Datos.
• ERP: Enterprise Resource Planning (Planificación de Recursos Empresariales).
• FEEDBACK: Retroalimentación para el control de sistemas.
• FRAMEWORK: Es un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.
• GTSIP: Grupo de Trabajo de Seguridad, Investigación y Proyectos.
• ITIL: La Biblioteca de Infraestructuras de Tecnologías de Información, conocida como ITIL (acrónimo de Information Technology Infrastructure Library) es un marco de trabajo de buenas prácticas aplicables a la Gestión de Servicios de TI y definidas para ayudar a las organizaciones proveedoras de servicios de TI a conseguir una mayor calidad y eficiencia en la entrega y gestión de sus servicios.
• ITSM: La gestión de servicios de tecnologías de la información (en inglés IT Service Management, ITSM) es una disciplina basada en procesos, enfocada en alinear los servicios de TI proporcionados con las necesidades de las empresas, poniendo énfasis en los beneficios que puede percibir el cliente final.
• KB: La Knowledge Base (KB) o Base de Conocimientos, nos ayuda a compartir el conocimiento de una forma organizada mediante una base de datos.
• MDM: Mobile Device Management (Gestión de dispositivos móviles).
• MISCELANEO: Que está compuesto por dos o más opciones.
• OpenSource: El código abierto es un modelo de desarrollo de software basado en la colaboración abierta
• OTRS: Open-source Ticket Request System.
• RGPD: Reglamento General de Protección de Datos.
• SSI: Subcomité de Seguridad de la Información
• TESTER:
• TIC: Tecnologías de la Información y la Comunicaciones.
• Ticket: Nombre que recibe el trabajo o actuación a realizar.
• WIKI: Sistema de trabajo informático utilizado en sitios web que permite a los usuarios modificar o crear su contenido de forma rápida y sencilla para su posterior documentación.
62
9. Bibliografía Corbelli, O.A., (2016), ITIL Edición 2011 – ESTRATEGIA, Madrid, España, Tecnofor Ibérica S.L Berzal, C. 2004- El lenguaje Unificado Modelado (UML), Disponible en: http://elvex.ugr.es/decsai/java/pdf/3E-UML.pdf “Aplicación práctica (y progresiva) del nuevo Reglamento europeo de protección de datos”. Web lopdat Grupo Isonor. Fecha de publicación:6/09/16 (Data de consulta: 10 mayo) http://www.lopdat.es/noticias/aplicacion-practica-y-progresiva-del-nuevo-reglamentoeuropeo-de-proteccion-de-datos
