1. Introducción a las Herramientas de Gestión TIC en el Servicio Andaluz de Salud

1.1. ¿Qué son las Herramientas de Gestión TIC?

Definición

Las herramientas de gestión TIC son aplicaciones software especializadas que facilitan, automatizan y optimizan las actividades relacionadas con la función TIC de una organización.

Diferencia clave:

• Sistemas negocio (ej: Diraya, PACS, ClicSalud+): Apoyan procesos CORE negocio organización (asistencia sanitaria, gestión pacientes…).
• Herramientas gestión TIC: Apoyan procesos INTERNOS función TIC (desarrollar proyectos, mantener operaciones, gestionar conocimiento técnico…).

Metáfora: Si Diraya es el «producto» que TIC entrega a médicos/pacientes, las herramientas gestión TIC son las «herramientas fábrica» que TIC usa internamente para construir/mantener Diraya.

1.2. Importancia de las Herramientas de Gestión TIC

Sin herramientas adecuadas:

• Caos organizativo: ¿Quién hace qué? ¿Cuál es prioridad? ¿Dónde está documentación?
• Ineficiencia: Tiempo perdido buscando info, reuniones improductivas, duplicación trabajo.
• Falta visibilidad: Dirección NO sabe estado proyectos, riesgos ocultos hasta tarde.
• Conocimiento volátil: Si experto clave se va, conocimiento se pierde (NO documentado).
• Mala calidad: Incidencias NO rastreadas, problemas recurrentes NO resueltos raíz.

Con herramientas adecuadas:

• Coordinación fluida: Equipo sabe prioridades, asignaciones, dependencias (tableros Kanban, Gantt…).
• Productividad: Automatización tareas repetitivas (alertas, workflows…), reducción overhead gestión.
• Transparencia: Stakeholders ven progreso real-time (dashboards), decisiones informadas.
• Conocimiento institucionalizado: Documentación centralizada, accesible, versionada (wikis, repositorios).
• Mejora continua: Métricas objetivas (tiempo resolución incidencias, velocidad sprints…), identificar áreas mejora.

1.3. Clasificación de Herramientas de Gestión TIC

Las herramientas TIC se pueden clasificar según su propósito principal:

Enfoque Tema 38: Nos centramos en las 4 primeras categorías (Proyectos, Operación, Conocimiento, Gestión Interna), que son las mencionadas explícitamente en el título tema y más relevantes para rol TFA-STI generalista. Desarrollo Software y Monitorización se tratan superficialmente (más específicas perfiles técnicos especializados).

1.4. Características Deseables en Herramientas de Gestión TIC

Independientemente de categoría, herramientas gestión TIC efectivas deben cumplir:

1. Usabilidad

• Interfaz intuitiva: Curva aprendizaje baja, adopción rápida equipo.
• Accesibilidad: Web-based (acceso desde cualquier ubicación/dispositivo), responsive mobile.
• Ejemplo negativo: Herramienta legacy con interfaz arcaica (pantallas verdes texto, comandos crípticos) → resistencia usuarios, baja adopción.

2. Integración

• APIs abiertas: Conectar con otras herramientas ecosistema (ej: JIRA ↔ Confluence ↔ GitLab).
• Single Sign-On (SSO): Autenticación unificada (ej: credenciales corporativas Junta válidas todas herramientas).
• Evitar silos: Datos NO deben quedar aislados en cada herramienta.

3. Escalabilidad

• Crecer con organización (más usuarios, más datos, más complejidad procesos).
• Ejemplo SAS: Service Desk debe soportar ~15.000 profesionales SAS generando tickets.

4. Seguridad y Cumplimiento

• ENS: Herramientas deben cumplir Esquema Nacional Seguridad (cifrado, auditoría, backup…).
• RGPD: Si herramienta trata datos personales (ej: tickets Service Desk con nombres usuarios), protección datos.
• Control acceso granular: Permisos por rol (no todos usuarios ven/modifican todo).

5. Soporte y Comunidad

• Vendor support: Proveedor ofrece soporte técnico (SLA, actualizaciones, parches…).
• Comunidad activa: Foros, documentación, plugins desarrollados terceros (especialmente importante herramientas open source).
• Ejemplo: JIRA/Confluence (Atlassian) tienen comunidad enorme, miles plugins marketplace.

6. Coste-Beneficio

• TCO (Total Cost of Ownership): NO solo licencias, también infraestructura, formación, mantenimiento.
• ROI (Return on Investment): Incremento productividad, reducción errores, tiempo ahorrado justifican inversión?
• Dilema AAPP: Presupuesto limitado → tentación elegir herramientas gratuitas/open source, pero ojo costes ocultos (necesidad expertise interno, soporte limitado…).

1.5. Contexto Específico SAS: Ecosistema Herramientas TIC

El SAS, como organización pública sanitaria compleja (~15.000 profesionales, 40+ hospitales, 1.500+ centros salud), requiere ecosistema herramientas robusto coordinado.

Desafíos particulares SAS:

• Distribución geográfica: Andalucía entera (8 provincias, zonas rurales remotas) → herramientas deben ser accesibles remotamente, fiables.
• Diversidad usuarios TIC: Desde TFA-STI (perfil generalista) hasta arquitectos software senior, DBAs, especialistas seguridad → herramientas deben servir múltiples perfiles.
• Operación 24/7 crítica: Sistemas salud NO pueden parar (vidas en riesgo) → herramientas operación (Service Desk, monitorización) deben ser ultra-fiables.
• Normativa estricta: ENS ALTO (Diraya), RGPD categoría especial datos salud, auditorías frecuentes → herramientas deben cumplir compliance riguroso.
• Interoperabilidad Junta de Andalucía: SAS es parte administración autonómica → herramientas deben integrarse con ecosistema corporativo Junta (Circuit, Consigna, Cl@ve…).

Arquitectura típica herramientas SAS (simplificado):

• Capa Proyectos: JIRA (gestión tareas/sprints), MS Project (planificación macro), Confluence (documentación proyectos).
• Capa Operación: ayudaDIGITAL (Service Desk), Nagios (monitorización), ELK Stack (logs centralizados).
• Capa Conocimiento: Confluence (wikis técnicas), SharePoint Junta (documentación corporativa), repositorios código GitLab.
• Capa Colaboración: MS Teams (reuniones, chat), Circuit (comunicación interna Junta), email corporativo (@juntadeandalucia.es).
• Capa Almacenamiento: Consigna (intercambio ficheros pesados), FicherosJunta (repositorio documentos corporativos).

Integración SSO: Credenciales corporativas únicas (dominio Junta) → login único para acceder todas herramientas (evita múltiples usuarios/contraseñas, mejora seguridad, facilita onboarding nuevos empleados).

2. Herramientas de Gestión de Proyectos

Contexto: Estas herramientas materializan las metodologías vistas en Tema 37 (PMBOK, Scrum, Kanban, MCMI…). Permiten planificar, ejecutar, monitorizar y controlar proyectos TIC de forma estructurada.

2.1. Microsoft Project (MS Project)

¿Qué es MS Project?

MS Project es la herramienta de gestión proyectos tradicional (predictiva/Waterfall) más extendida mundialmente, desarrollada por Microsoft desde 1984.

Características principales:

• Diagramas Gantt: Visualización cronograma proyecto (barras temporales, hitos, dependencias).
• Gestión recursos: Asignación personas/equipamiento a tareas, nivelación recursos (evitar sobrecarga).
• Ruta crítica (CPM): Identificación automática secuencia actividades críticas (retraso → retraso proyecto completo).
• Líneas base: Guardar plan original, comparar vs ejecución real (desviaciones alcance/tiempo/coste).
• Informes predefinidos: Exportación a PDF, Excel, PPT para reporting stakeholders.

Versiones MS Project:

• MS Project Standard: Desktop, monousuario, gestión proyectos individuales.
• MS Project Professional: Desktop + conectividad Project Server (colaboración multiusuario, centralización portfolio).
• MS Project Online: Cloud (Microsoft 365), accesible navegador, colaboración real-time, integración Teams/SharePoint.

Uso típico en SAS:

• Proyectos grandes predictivos: Ej. migración Diraya cloud (12-18 meses), despliegue infraestructura nueva (renovación CPD), contratos LCSP con fases/hitos rígidos.
• Planificación macro: Jefe Proyecto STIC usa MS Project para cronograma alto nivel, WBS maestro, asignación recursos equipos (equipo implantación, consultoras externas…).
• Reporting Dirección: Generar Gantt actualizados mensualmente para Comité Dirección SAS, transparencia estado proyectos.

Ventajas MS Project:

• Potencia cálculo: Motor scheduling robusto (CPM, PERT, nivelación recursos automática).
• Integración ecosistema Microsoft: Office, SharePoint, Teams, Power BI → SAS usa suite Microsoft ampliamente.
• Estándar industria: Ampliamente conocido, formación abundante, formato archivo .mpp reconocido.

Desventajas MS Project:

• Curva aprendizaje empinada: Interfaz compleja, muchas funcionalidades avanzadas requieren expertise.
• Rigidez metodológica: Diseñado para Waterfall, NO natural para Agile (aunque versiones recientes mejoran).
• Coste licencias: Professional/Online caros (cientos €/usuario/año).
• Colaboración limitada (versiones desktop): Archivo .mpp NO multiusuario real-time (conflictos versiones si varios editan).

2.2. JIRA (Atlassian)

¿Qué es JIRA?

JIRA es la herramienta de gestión proyectos Agile más popular (70%+ mercado Agile), desarrollada por Atlassian (empresa australiana).

Origen: Creada 2002 para tracking bugs software, evolucionó a plataforma completa gestión proyectos Scrum/Kanban.

Productos familia JIRA:

• JIRA Software: Desarrollo software Agile (Scrum, Kanban). MÁS RELEVANTE SAS.
• JIRA Service Management: Service Desk ITSM (tickets soporte, gestión incidencias). Alternativa a ayudaDIGITAL.
• JIRA Work Management: Gestión tareas equipos no-técnicos (marketing, RRHH…).

Características principales JIRA Software:

1. Issues (elementos trabajo)

• Tipos issue:
  • Epic: Funcionalidad grande (ej: «Módulo Telemedicina Diraya»).
  • Story (User Story): Requisito usuario (ej: «Como médico, quiero ver histórico videoconsultas paciente»).
  • Task: Tarea técnica (ej: «Diseñar esquema BBDD videoconsultas»).
  • Bug: Error software (ej: «Error 500 al guardar consulta»).
  • Subtask: Subdivisión task/story.
• Campos issue: Título, descripción, asignatario, prioridad (Blocker/Critical/Major/Minor/Trivial), etiquetas, tiempo estimado, Sprint asignado, componentes afectados…

2. Tableros (Boards)

• Scrum Board: Backlog (issues pendientes) + Sprint activo (columnas: To Do → In Progress → Done). Planning Poker integrado, Burndown charts automáticos.
• Kanban Board: Flujo continuo (columnas personalizables, límites WIP configurables).
• Drag & Drop: Mover issues entre columnas visualmente (cambio estado automático).

3. Sprints y Releases

• Sprint Planning: Crear Sprint (duración 2-4 sem), arrastrar issues desde Backlog a Sprint.
• Sprint Review: Marcar Sprint completo, generar reporte velocidad (Story Points completados).
• Releases: Agrupar Sprints en versión entregable (ej: «Diraya 6.0»).

4. Automatizaciones y Workflows

• Workflow estados: Definir flujo issue (ej: Open → In Progress → Code Review → Testing → Done). Transiciones con condiciones (ej: NO puede pasar a Testing si NO tiene Test Cases asociados).
• Automatizaciones: Triggers (ej: si Bug prioridad Blocker creado → notificar Slack canal #urgencias + asignar automáticamente Lead Técnico).

5. Integración

• Confluence: Documentación proyecto enlazada issues (requisitos, diseño técnico…).
• GitLab/GitHub: Commits código linkan issues JIRA (trazabilidad código ↔ requisito).
• Slack/Teams: Notificaciones issues en canales chat.
• Jenkins/CI-CD: Despliegues automáticos marcan issues como «Deployed Production».

Uso típico en SAS:

• Desarrollo evolutivo Diraya: Equipo desarrollo Diraya (STIC + consultoras) usa JIRA Scrum:
  • Product Backlog: Cientos User Stories priorizadas por Product Owner (responsable funcional SAS).
  • Sprints 3 semanas: Cada Sprint, equipo selecciona Stories, desarrolla, testea, despliega entorno PRE.
  • Daily Standup virtual: Equipo revisa tablero JIRA, actualiza issues, identifica bloqueos.
  • Sprint Review: Demo funcionalidades completadas a stakeholders, marcar Sprint Done, burndown chart muestra progreso.
• Proyectos innovación (IA, Big Data): Alta incertidumbre, requisitos emergentes → JIRA Kanban perfecto (flujo continuo, adaptación constante).
• Tracking bugs producción: CSU (Centro Soporte Usuarios) escala bugs críticos Diraya → crean issues JIRA tipo Bug → equipo desarrollo prioriza, resuelve, despliega hotfix.

Ventajas JIRA:

• Agile-native: Scrum/Kanban out-of-the-box, curva aprendizaje rápida equipos Agile.
• Flexibilidad: Workflows, campos, tipos issue 100% personalizables.
• Visibilidad: Transparencia total progreso (cualquier stakeholder puede ver tablero, burndown…).
• Ecosistema Atlassian: Sinergia con Confluence, Bitbucket, Trello… (suite integrada).
• Comunidad y Marketplace: Miles plugins (ej: Tempo Timesheets, Zephyr testing…).

Desventajas JIRA:

• Complejidad configuración inicial: Muchas opciones, puede abrumar. Necesita administrador experto configurar bien.
• NO ideal proyectos Waterfall largos: Gantt limitado (aunque existen plugins), MS Project mejor para eso.
• Coste creciente: Licencias por usuario (aunque hay tiers gratis <10 usuarios, SAS necesita cientos licencias → coste significativo).

2.3. Confluence (Atlassian)

¿Qué es Confluence?

Aunque Confluence es herramienta Gestión Conocimiento (Sección 4), tiene rol CRÍTICO en gestión proyectos → la incluimos aquí también.

Confluence es wiki corporativa y repositorio documentación desarrollada por Atlassian (misma empresa JIRA).

Uso gestión proyectos:

• Documentación proyecto:
  • Project Charter: Objetivos, alcance, stakeholders, presupuesto, cronograma macro.
  • Especificaciones requisitos: Detalle User Stories JIRA (mockups, diagramas UML, casos uso…).
  • Arquitectura técnica: Diagramas componentes, decisiones arquitectónicas (ADRs), manuales despliegue.
  • Actas reuniones: Sprint Planning, Sprint Review, Retrospective, Comité Seguimiento.
  • Lecciones aprendidas: Post-mortem proyecto, qué funcionó/NO funcionó, recomendaciones futuros proyectos.
• Integración JIRA: Páginas Confluence enlazan issues JIRA (ej: requisito funcional detallado página Confluence ↔ User Story JIRA), macros JIRA en Confluence (mostrar roadmap, burndown charts en documentación…).

Características clave Confluence:

• Espacios: Organización jerárquica (ej: Espacio «Proyecto Diraya Telemedicina» → páginas subordinadas por tema).
• Plantillas: Plantillas reutilizables (Project Plan, Meeting Notes, Product Requirements…).
• Versionado: Histórico cambios página, rollback a versión anterior, comparación versiones.
• Permisos granulares: Control acceso por espacio/página (ej: arquitectura sensible → solo arquitectos + PM).
• Búsqueda potente: Indexación full-text, búsqueda inteligente por etiquetas, autor, fecha…

2.4. Otras Herramientas Gestión Proyectos (Mención)

Trello

• Qué es: Herramienta visual Kanban simple (tableros, listas, tarjetas). Adquirida por Atlassian 2017.
• Uso SAS potencial: Proyectos pequeños/equipos reducidos, gestión tareas personales, organización eventos/workshops.
• Ventaja: Simplicidad extrema, curva aprendizaje 5 minutos.
• Limitación: Funcionalidades básicas, NO escala bien proyectos complejos.

Asana

• Qué es: Plataforma gestión trabajo (proyectos, tareas, equipos). Competidor directo JIRA/Trello.
• Diferenciador: UX muy pulida, interfaz moderna, enfoque productividad equipos multidisciplinares (no solo desarrollo software).
• Uso SAS: Menos probable (ecosistema ya consolidado JIRA/Confluence), pero posible equipos específicos.

Monday.com

• Qué es: Plataforma Work OS (sistema operativo trabajo), muy flexible, visual.
• Fortaleza: Automatizaciones visuales, integraciones (200+ apps), dashboards personalizables.
• Uso SAS: Improbable (más orientado sector privado, coste alto).

Redmine

• Qué es: Herramienta gestión proyectos open source (Ruby on Rails), tracking issues, Gantt, wiki integrada.
• Ventaja: Gratuito, open source, personalizable código fuente.
• Desventaja: Interfaz anticuada, comunidad menos activa que JIRA, requiere infraestructura propia (hosting, mantenimiento).
• Uso SAS: Históricamente algunos equipos TIC usaron Redmine (antes adopción JIRA corporativo), posible legacy en proyectos antiguos.

2.5. Comparativa Herramientas Gestión Proyectos

3. Herramientas de Gestión de la Operación: ITSM e ITIL

Contexto: Mientras herramientas gestión proyectos se enfocan en crear/cambiar sistemas TIC (esfuerzos temporales), herramientas gestión operación se enfocan en mantener/operar sistemas TIC día a día (actividades continuas, BAU – Business As Usual).

3.1. Fundamentos ITSM e ITIL

¿Qué es ITSM (IT Service Management)?

Definición

ITSM (IT Service Management – Gestión de Servicios TIC) es el conjunto de políticas, procesos y procedimientos que una organización TIC utiliza para diseñar, planificar, entregar, operar y controlar servicios TIC ofrecidos a usuarios.

Enfoque ITSM: TIC NO es mero proveedor tecnología (hardware, software), sino proveedor SERVICIOS que generan valor negocio.

Ejemplos servicios TIC SAS:

• Servicio «Acceso Diraya»: Profesionales sanitarios pueden acceder Historia Clínica Electrónica 24/7 desde cualquier centro SAS.
• Servicio «Email Corporativo»: Profesionales tienen buzón @juntadeandalucia.es funcional, seguro, con X GB capacidad.
• Servicio «Soporte Técnico»: Usuarios reportan incidencias TIC, reciben resolución en

Cada servicio tiene:

• SLA (Service Level Agreement): Acuerdo nivel servicio (ej: disponibilidad 99,5%, tiempo respuesta incidencias críticas <2h).
• Catálogo servicios: Descripción servicio, usuarios elegibles, coste (si aplica), cómo solicitarlo…
• Procesos subyacentes: Gestión incidencias, problemas, cambios, configuración… que aseguran entrega servicio.

¿Qué es ITIL (Information Technology Infrastructure Library)?

Definición

ITIL es el marco de buenas prácticas ITSM más adoptado mundialmente (estándar de facto), desarrollado originalmente por gobierno británico (años 80), actualmente gestionado por Axelos.

Versiones ITIL:

• ITIL v3 (2007): Ciclo vida servicios (Estrategia, Diseño, Transición, Operación, Mejora Continua). Muy extendida.
• ITIL 4 (2019): Actualización significativa, enfoque más ágil/DevOps, sistema valor servicios (SVS). Adoptándose gradualmente.

ITIL NO es:

• Una herramienta software (es marco conceptual, buenas prácticas).
• Una metodología prescriptiva rígida (son recomendaciones adaptables).
• Obligatorio por ley (aunque AAPP españolas tienden adoptarlo, alineado ISO 20000).

ITIL SÍ es:

• Guía estructurada procesos ITSM (qué hacer, cuándo, quién, métricas…).
• Lenguaje común industria TIC (hablar mismos términos: incident, problem, change, CMDB…).
• Base certificaciones profesionales (ITIL Foundation, Practitioner, Expert…).

Procesos ITIL más relevantes (selección)

1. Gestión de Incidencias (Incident Management)

• Objetivo: Restaurar servicio normal lo más rápido posible, minimizar impacto negativo en negocio.
• Incidencia: Interrupción NO planificada o reducción calidad servicio TIC (ej: Diraya caído, impresora NO imprime, password olvidado…).
• Flujo típico:
  1. Usuario reporta incidencia → Service Desk registra ticket.
  2. Service Desk intenta resolución N1 (first-line support, soluciones conocidas).
  3. Si NO resuelve → escala N2 (especialistas: red, BBDD, sistemas…) o N3 (proveedores externos).
  4. Resolución → comunicar usuario → cerrar ticket.
• Métricas: Tiempo medio resolución (MTTR – Mean Time To Repair), % incidencias resueltas N1, satisfacción usuario.

2. Gestión de Problemas (Problem Management)

• Objetivo: Identificar causa raíz incidencias recurrentes, prevenir futuros incidentes.
• Problema: Causa desconocida de uno o más incidentes (ej: Diraya lento martes mañanas → problema: consulta SQL mal optimizada).
• Diferencia Incident vs Problem:
  • Incident: Reactivo, restaurar servicio rápido (workaround OK).
  • Problem: Proactivo, encontrar causa raíz, solución definitiva (puede tomar semanas análisis).
• Known Error: Problema identificado con workaround documentado (mientras se trabaja solución permanente).

3. Gestión de Cambios (Change Management)

• Objetivo: Asegurar que cambios en infraestructura/servicios TIC se realizan de forma controlada, minimizando riesgos.
• Cambio: Añadir, modificar, eliminar algo que pueda afectar servicio TIC (ej: actualizar versión Diraya, cambiar regla firewall, migrar servidor…).
• Flujo típico:
  1. Solicitante crea RFC (Request For Change) → justificación, plan implementación, plan rollback, ventana mantenimiento…
  2. CAB (Change Advisory Board – Comité Asesoramiento Cambios) evalúa RFC → aprueba/rechaza/difiere.
  3. Si aprobado → implementar cambio en ventana acordada.
  4. Post-implementación → revisar éxito, actualizar CMDB.
• Tipos cambio:
  • Normal: Cambio planificado, requiere aprobación CAB.
  • Estándar: Cambio pre-aprobado, bajo riesgo, repetitivo (ej: renovar certificado SSL mensualmente) → NO requiere CAB cada vez.
  • Emergencia: Cambio urgente para resolver incident crítico (ej: Diraya caído, hotfix urgente) → aprobación CAB exprés o posterior.

4. Gestión de Configuración (Configuration Management)

• Objetivo: Mantener información actualizada sobre componentes infraestructura TIC (CIs – Configuration Items) y relaciones entre ellos.
• CMDB (Configuration Management Database): Base datos centralizada con inventario detallado CIs (servidores, switches, aplicaciones, licencias software…) + atributos (ubicación, responsable, estado, dependencias…).
• Uso CMDB:
  • Análisis impacto cambios: Antes cambiar servidor X, consultar CMDB → qué aplicaciones dependen servidor X? Si falla, qué servicios afectados?
  • Resolución incidencias: Usuario reporta «aplicación Y NO funciona» → CMDB muestra que aplicación Y corre en servidor Z → verificar servidor Z.
  • Auditorías: Verificar inventario real vs CMDB (detección shadow IT, software NO autorizado…).

5. Gestión de Nivel de Servicio (Service Level Management)

• Objetivo: Negociar, acordar, documentar y monitorizar SLAs con clientes internos/externos.
• SLA: Contrato formal nivel servicio (ej: «Diraya disponible 99,5% tiempo hábil mensual, incidencias críticas resueltas <2h").
• OLA (Operational Level Agreement): Acuerdo interno entre equipos TIC (ej: equipo BBDD se compromete restaurar backup <30 min).
• UC (Underpinning Contract): Contrato con proveedor externo que soporta SLA (ej: proveedor cloud Azure garantiza uptime 99,9%).

3.2. Herramientas ITSM: Service Desk

¿Qué es un Service Desk?

Service Desk es el punto único contacto (SPOC – Single Point Of Contact) entre usuarios y organización TIC para solicitar servicios, reportar incidencias, consultar estado…

Service Desk vs Help Desk:

• Help Desk (anticuado): Enfoque reactivo, solo resuelve incidencias técnicas.
• Service Desk (moderno): Enfoque proactivo, gestiona ciclo vida completo servicios TIC (incidencias + peticiones servicio + información + consultas).

Funciones Service Desk:

• Registro tickets: Capturar solicitud usuario (teléfono, email, portal web, chat…).
• Clasificación y priorización: Categorizar incidencia (hardware, software, red…), asignar prioridad (crítica, alta, media, baja) según impacto + urgencia.
• Resolución N1: Intentar resolver usando base conocimiento (FAQs, procedimientos estándar).
• Escalado: Si NO resuelve N1 → escalar equipos especializados N2/N3.
• Seguimiento: Mantener usuario informado progreso ticket.
• Cierre: Verificar satisfacción usuario, cerrar ticket, documentar solución (alimentar base conocimiento).

Niveles soporte típicos:

3.3. Principales Herramientas Service Desk / ITSM

ServiceNow

• Líder mercado: Plataforma cloud ITSM más usada grandes empresas/gobiernos.
• Funcionalidades: Gestión incidencias, problemas, cambios, CMDB, catálogo servicios, workflows automatizados, portales autoservicio, integración 360°.
• Fortaleza: Muy completa, escalable, personalizable, ecosistema enorme.
• Debilidad: Coste muy alto (licencias + implementación), complejidad configuración.
• Uso SAS: Improbable (demasiado caro para presupuesto público), pero estándar industria que TFA-STI debe conocer.

BMC Remedy (Helix ITSM)

• Veterano mercado: Una de primeras herramientas ITSM enterprise (años 90).
• Fortaleza: Robustez, integración mainframes legacy, certificación ITIL nativa.
• Debilidad: Interfaz anticuada (aunque Helix modernizó), coste alto.
• Uso SAS: Posible históricamente (algunos organismos públicos usaban Remedy), pero probablemente migrado a soluciones modernas.

JIRA Service Management (Atlassian)

• Evolución: Antes llamado JIRA Service Desk, rebranding 2020 a JIRA Service Management (JSM).
• Enfoque: Service Desk moderno, ágil, colaborativo, integración nativa con JIRA Software + Confluence.
• Fortaleza: UX excelente, adopción rápida equipos ya usan JIRA/Confluence, coste moderado vs ServiceNow.
• Uso SAS potencial: Si SAS ya usa JIRA Software (desarrollo), lógico extender a JSM (operaciones) → ecosistema Atlassian unificado.

Freshservice

• Challenger mercado: Plataforma cloud ITSM moderna (Freshworks, empresa india).
• Fortaleza: Precio competitivo, implementación rápida (días vs meses), interfaz intuitiva.
• Uso SAS: Posible para proyectos piloto o departamentos específicos.

3.4. ayudaDIGITAL: Service Desk Corporativo del SAS

¿Qué es ayudaDIGITAL?

ayudaDIGITAL es el portal corporativo de soporte TIC del Servicio Andaluz de Salud, implementando modelo Service Desk ITIL para profesionales sanitarios y administrativos SAS.

Características ayudaDIGITAL (inferidas):

• Portal web autoservicio: Profesionales acceden con credenciales corporativas, consultan FAQs, videos tutoriales (N0).
• Gestión tickets: Abrir incidencias/peticiones online, seguimiento estado real-time, comunicación bidireccional con técnicos.
• Catálogo servicios: Solicitar servicios TIC estándar (alta nuevo usuario, instalación software, acceso VPN…) mediante formularios predefinidos.
• Base conocimiento: Documentación técnica, procedimientos, soluciones problemas comunes (alimentada continuamente por resoluciones tickets).
• Integración CSU: Backend conectado CSU (Centro Soporte Usuarios SAS), agentes N1 gestionan tickets desde consola centralizada.

CSU (Centro Soporte Usuarios SAS)

• Función: Service Desk físico (call center) + virtual (portal ayudaDIGITAL).
• Canales soporte:
  • Teléfono: 955 XX XX XX (línea directa soporte TIC, horario laboral).
  • Email: csu.sas@juntadeandalucia.es (o similar).
  • Portal web: ayudaDIGITAL (24/7 autoservicio, tickets).
  • Chat/WhatsApp: Canales emergentes (tendencia sector).
• Horario: Típicamente 8:00-20:00 L-V (sistemas críticos 24/7 tienen soporte fuera horario mediante guardias).
• SLA indicativo:
  • Incidencias críticas (Diraya caído hospital completo): Respuesta <30 min, resolución <2h.
  • Incidencias altas (usuario NO accede Diraya): Respuesta <2h, resolución <8h.
  • Incidencias medias (impresora NO funciona): Respuesta <4h, resolución <24h.
  • Incidencias bajas (solicitud info): Respuesta <24h, resolución <72h.

Flujo típico incidencia ayudaDIGITAL:

1. Médico tiene problema: «NO puedo acceder Diraya, error autenticación».
2. Médico accede ayudaDIGITAL → categoría «Acceso Aplicaciones» → subcategoría «Diraya» → descripción problema → adjunta captura pantalla error → envía ticket.
3. Sistema auto-asigna ticket → ID único (ej: INC-2024-123456), prioridad AUTO calculada (impacto: 1 usuario, urgencia: alta → prioridad ALTA).
4. Agente CSU recibe alerta → revisa ticket → intenta resolución N1 (verifica usuario activo LDAP, resetea password, pide intentar login nuevamente).
5. Si resuelto → notifica médico, cierra ticket (tiempo resolución: 15 min).
6. Si NO resuelto → escala N2 (equipo seguridad/identidad) → investigan (problema certificado digital caducado) → renuevan certificado → notifican médico → ticket cerrado (tiempo resolución total: 4h).
7. Post-cierre: Sistema envía encuesta satisfacción médico, documentación solución añadida base conocimiento (próxima vez N1 puede resolver directamente).

4. Herramientas de Gestión del Conocimiento

Contexto: El conocimiento técnico es el activo más valioso organización TIC. Herramientas gestión conocimiento capturan, organizan, comparten y preservan este conocimiento, evitando pérdida cuando personas se van, facilitando onboarding nuevos empleados, mejorando eficiencia resolución problemas.

4.1. Fundamentos de Knowledge Management (KM)

¿Qué es Knowledge Management?

Knowledge Management (KM – Gestión del Conocimiento) es el proceso sistemático de identificar, capturar, organizar, almacenar, compartir y aplicar conocimiento organizacional para mejorar rendimiento, innovación y competitividad.

Tipos de conocimiento:

• Conocimiento explícito: Fácilmente documentable, codificable, transferible (ej: manuales técnicos, procedimientos, código fuente comentado, diagramas arquitectura…).
• Conocimiento tácito: Difícil documentar, está en cabezas personas, se adquiere experiencia (ej: «intuición» arquitecto senior sobre qué diseño funcionará mejor, «know-how» DBA optimizar BBDD…).

Desafío KM: Convertir conocimiento tácito → explícito (externalización), capturarlo herramientas antes que se pierda.

Ciclo KM típico (modelo SECI – Nonaka & Takeuchi):

1. Socialización: Tácito → Tácito (aprender observando experto, mentoring).
2. Externalización: Tácito → Explícito (documentar know-how, escribir wiki).
3. Combinación: Explícito → Explícito (integrar docs múltiples fuentes, crear guía completa).
4. Internalización: Explícito → Tácito (leer manual, practicar, interiorizar conocimiento).

Beneficios KM en organización TIC:

• Reducir dependencia personas clave: Si experto único tema X se va/enferma, conocimiento NO se pierde (documentado).
• Acelerar resolución problemas: Base conocimiento con soluciones problemas recurrentes → técnicos resuelven más rápido (NO reinventar rueda).
• Onboarding rápido: Nuevo TFA-STI accede wikis técnicas, aprende arquitectura sistemas, procedimientos operativos → productivo más rápido.
• Innovación: Combinar conocimientos múltiples dominios → nuevas ideas, soluciones creativas.
• Cumplimiento normativo: Documentación exhaustiva procesos, decisiones, cambios → auditorías (ENS, ISO…) más fáciles.

4.2. Confluence (Atlassian)

¿Qué es Confluence?

Confluence es la wiki corporativa y plataforma colaboración documentación más popular (desarrollada Atlassian, misma empresa JIRA), usada por >75.000 organizaciones mundialmente.

Características principales:

1. Espacios (Spaces)

• Espacio: Contenedor lógico páginas relacionadas (ej: «Espacio Proyecto Diraya Telemedicina», «Espacio Equipo Infraestructura», «Espacio Procedimientos STIC»).
• Tipos espacio:
  • Team Space: Colaboración equipo pequeño.
  • Documentation Space: Documentación técnica producto/sistema.
  • Knowledge Base: Base conocimiento pública/interna (FAQs, troubleshooting…).
• Jerarquía: Espacios contienen páginas padre → páginas hijas → subpáginas (árbol navegación).

2. Páginas

• Editor WYSIWYG: Interfaz visual (What You See Is What You Get), NO necesita conocer HTML/Markdown (aunque soporta).
• Elementos ricos:
  • Macros: Componentes dinámicos (tabla contenidos auto, roadmap JIRA embebido, calendario, diagrama Gliffy, código syntax highlighting…).
  • Multimedia: Imágenes, videos, GIFs, archivos adjuntos.
  • Tablas complejas: Fusionar celdas, ordenar, filtrar.
  • Diagramas: Integración draw.io (flowcharts, UML, arquitectura…) directamente Confluence.
• Versionado: Histórico completo cambios página, comparar versiones, restaurar versión anterior, ver quién cambió qué/cuándo.
• Comentarios: Usuarios comentan páginas (feedback, preguntas, discusiones), notificaciones autor.

3. Plantillas (Templates)

• Predefinidas: Confluence incluye decenas plantillas (Meeting Notes, Product Requirements, Technical Specification, How-To Article, Troubleshooting Guide…).
• Personalizadas: Crear plantillas corporativas (ej: «Plantilla Procedimiento Operativo SAS», «Plantilla Análisis Riesgos Proyecto»).
• Beneficio: Homogeneidad documentación, acelerar creación docs.

4. Búsqueda Potente

• Full-text indexing: Buscar cualquier palabra contenido páginas + archivos adjuntos (PDFs, Word…).
• Filtros avanzados: Por espacio, autor, fecha modificación, etiquetas, tipo contenido…
• Búsqueda inteligente: Sugerencias autocompletado, ranking relevancia, snippets contexto.

5. Permisos Granulares

• Niveles:
  • Espacio: Quién puede ver, editar, administrar espacio completo.
  • Página: Restricciones específicas página (ej: arquitectura sensible → solo arquitectos).
• Grupos: Permisos por grupos LDAP corporativos (ej: grupo «TIC-STIC-Desarrollo» tiene acceso espacio «Desarrollo Diraya»).

6. Integración JIRA

• Linking bidireccional: Página Confluence ↔ issue JIRA (ej: requisito funcional detallado página Confluence enlaza User Story JIRA).
• Macros JIRA: Insertar en páginas Confluence:
  • JIRA Issues: Lista issues filtrados (ej: todos Bugs prioridad Blocker).
  • JIRA Roadmap: Timeline Epics, visualización high-level proyecto.
  • JIRA Charts: Burndown, velocity, pie charts… embebidos documentación.

Uso típico Confluence en SAS:

A. Documentación Técnica Sistemas

• Espacio «Diraya»:
  • Arquitectura técnica (diagramas componentes, bases datos, infraestructura…).
  • Manuales instalación, configuración, despliegue.
  • Guías desarrollo (estándares código, convenciones naming, workflows Git…).
  • Release Notes (qué cambió cada versión).
  • FAQs técnicas (problemas comunes + soluciones).

B. Knowledge Base Service Desk

• Espacio «KB-SoporteTIC»:
  • Procedimientos resolución incidencias recurrentes (ej: «Cómo resetear password usuario Diraya»).
  • Tutoriales paso a paso (capturas pantalla, videos).
  • Troubleshooting guides (árbol decisión: SI problema X → verificar Y → solución Z).
• Integración Service Desk: Desde ticket ayudaDIGITAL, técnico busca KB Confluence, encuentra solución documentada, resuelve ticket, añade link KB en cierre ticket (alimentación continua KB).

C. Documentación Proyectos

• Espacio «Proyecto-Telemedicina-Diraya»:
  • Project Charter (objetivos, alcance, stakeholders…).
  • Requisitos detallados (User Stories expandidas con mockups UX, diagramas flujo…).
  • Diseño arquitectónico (decisiones técnicas, ADRs – Architecture Decision Records).
  • Actas reuniones (Sprint Planning, Review, Retrospective, Comité Seguimiento).
  • Lecciones aprendidas (post-mortem: qué funcionó, qué NO, recomendaciones futuros proyectos).

D. Procedimientos Operativos

• Espacio «Procedimientos-STIC»:
  • Procedimientos gestión cambios (cómo crear RFC, aprobar CAB, ejecutar cambio…).
  • Procedimientos backup/restore (frecuencia, retención, testing restores…).
  • Procedimientos seguridad (respuesta incidentes, gestión vulnerabilidades…).
  • Runbooks (guías operativas sistemas críticos: arranque/parada servicios, troubleshooting emergencias…).

E. Onboarding Nuevos Empleados

• Espacio «Bienvenida-TIC-SAS»:
  • Organigrama STIC, roles, responsabilidades.
  • Herramientas corporativas (credenciales, accesos, instalación software…).
  • Cultura trabajo (horarios, metodologías, canales comunicación…).
  • Contactos útiles (quién es quién, a quién preguntar según tema…).

Ventajas Confluence:

• Colaboración real-time: Múltiples usuarios editan simultáneamente, conflictos versiones gestionados automáticamente.
• Usabilidad: Curva aprendizaje rápida, interfaz intuitiva, NO requiere conocimientos técnicos avanzados.
• Ecosistema Atlassian: Sinergia total con JIRA (proyectos + documentación integrados).
• Escalabilidad: Desde equipos pequeños hasta organizaciones 50.000+ usuarios.
• Marketplace: Miles plugins (ej: Scroll Viewport – documentación versionada profesional, Gliffy – diagramas, draw.io…).

Desventajas Confluence:

• Puede crecer desordenadamente: Sin governance (plantillas obligatorias, convenciones naming, limpieza periódica páginas obsoletas), puede convertirse en «caos documentación».
• Búsqueda sobrecargada: Si miles páginas, encontrar info específica puede ser difícil (necesita etiquetado disciplinado).
• Coste: Licencias por usuario (aunque más barato que ServiceNow, suma si cientos usuarios).

4.3. Otras Herramientas Gestión Conocimiento

SharePoint (Microsoft)

• Qué es: Plataforma colaboración, gestión documentos, intranets corporativas (Microsoft).
• Fortaleza: Integración total ecosistema Microsoft (Office 365, Teams, OneDrive), muy usado AAPP (Junta Andalucía usa SharePoint).
• Uso SAS: Probable como repositorio documentos corporativos NO técnicos (ej: políticas RRHH, procedimientos administrativos, intranet general SAS). Para documentación técnica TIC, Confluence probablemente más adecuado (más ágil, orientado equipos técnicos).

MediaWiki

• Qué es: Software wiki open source (mismo que usa Wikipedia), muy usado comunidades open source.
• Fortaleza: Gratuito, open source, muy customizable, potente (escala a millones páginas – Wikipedia).
• Debilidad: Interfaz menos moderna que Confluence, sintaxis wikitext (curva aprendizaje), requiere infraestructura propia (hosting, mantenimiento).
• Uso SAS: Posible históricamente (algunos equipos TIC usaban MediaWiki antes adopción Confluence corporativo), pero probablemente migrado.

Notion

• Qué es: Plataforma all-in-one (notas, wikis, bases datos, gestión tareas, colaboración). Muy popular startups, equipos modernos.
• Fortaleza: UX increíble, flexible (bloques modulares), gratis equipos pequeños.
• Uso SAS: Improbable corporativamente (cloud 100%, datos en servidores Notion USA → problemas compliance RGPD, ENS), pero posible uso personal TFA-STI o equipos pequeños proyectos internos informales.

Repositorios Código (GitLab, GitHub, Bitbucket)

• Función primaria: Control versiones código fuente (Git).
• Función secundaria KM: README.md (documentación básica repo), Wikis integradas (GitLab/GitHub tienen wikis Markdown), Issues con discusiones técnicas (conocimiento embebido conversaciones).
• Uso SAS: GitLab probable (STIC usa GitLab corporativo para repos Diraya, proyectos internos). Documentación técnica código (README, comentarios, wikis repo) complementa Confluence (Confluence = docs alto nivel, wikis GitLab = docs específicas código).

4.4. Buenas Prácticas Gestión Conocimiento

1. Cultura Documentación

• Promover desde liderazgo: Directores TIC deben valorar/recompensar documentación (NO solo «producir código»).
• Tiempo asignado: Sprints incluyen tareas documentación (NO «lo haré cuando tenga tiempo» → nunca lo tiene).
• Definition of Done: Tarea NO completa hasta documentada (ej: User Story solo «Done» si hay página Confluence explicando funcionalidad).

2. Plantillas y Estándares

• Plantillas obligatorias: Para tipos docs comunes (diseño técnico, procedimiento operativo, post-mortem proyecto…) → homogeneidad, NO reinventar estructura cada vez.
• Convenciones naming: Espacios, páginas con nombres consistentes (ej: «Proyecto-NombreProyecto», «Procedimiento-NombreProcedimiento»).

3. Ownership Claro

• Cada doc tiene owner: Responsable mantener actualizado (NO «documentos huérfanos» obsoletos).
• Revisión periódica: Trimestral/anual, verificar vigencia, actualizar o archivar.

4. Accesibilidad y Búsqueda

• Etiquetado disciplinado: Páginas con etiquetas relevantes (ej: #diraya, #seguridad, #bbdd…) → facilita búsqueda.
• Índices/portales: Páginas índice que listan docs clave (ej: «Portal Documentación Diraya» con links organizados por tema).

5. Integración Workflows

• Documentar cerca donde se trabaja: Confluence integrado JIRA (documentar requisitos cerca user stories), wikis GitLab cerca código…
• Automatizaciones: Ej. cerrar ticket Service Desk → sistema sugiere «¿quieres documentar solución en KB Confluence?».

5. Herramientas de Gestión Interna para la Función TIC en el SAS

Contexto: Estas herramientas facilitan el trabajo diario interno de los equipos TIC: comunicación, colaboración, compartición ficheros, productividad personal, monitorización sistemas… Son el «pegamento» que une equipos distribuidos, permite trabajo remoto efectivo, asegura disponibilidad servicios críticos.

5.1. Herramientas de Colaboración y Comunicación

Microsoft Teams

¿Qué es MS Teams?

MS Teams es la plataforma colaboración unificada de Microsoft (integrada Office 365/Microsoft 365), que combina chat, videoconferencias, compartición archivos, integración aplicaciones.

Características principales:

• Equipos y Canales:
  • Equipo (Team): Grupo personas trabajan juntas (ej: «Equipo Desarrollo Diraya»).
  • Canales: Subdivisión temática equipo (ej: canales «#general», «#bugs», «#releases», «#dudas-técnicas»).
• Chat: Mensajería instantánea 1:1 o grupal, menciones (@usuario), emojis/GIFs, hilos conversación.
• Videoconferencias: Reuniones virtuales hasta 10.000 participantes (webinars), compartir pantalla, grabación, transcripción automática, subtítulos real-time.
• Integración Office: Coeditar Word/Excel/PowerPoint directamente Teams, sincronización OneDrive/SharePoint.
• Apps integradas: Planner (tareas), Forms (encuestas), Power BI (dashboards), JIRA, GitLab…

Uso típico SAS:

• Comunicación equipos distribuidos: Equipos TIC STIC (Sevilla) + técnicos provinciales (8 provincias) → canal Teams «#soporte-provincial» para coordinación diaria.
• Daily Standups virtuales: Equipos Agile hacen Daily Scrum por videollamada Teams (equipo desarrollo Diraya remoto/híbrido).
• Reuniones proyecto: Sprint Planning, Sprint Review, Comité Seguimiento → Teams + compartir pantalla (Gantt MS Project, tablero JIRA…).
• Soporte informal: Canal «#ayuda-técnica-rápida» donde técnicos preguntan dudas compañeros (complemento Service Desk formal para consultas internas rápidas).

Ventajas MS Teams:

• Integración ecosistema Microsoft: Junta Andalucía usa Office 365 → Teams nativo, SSO corporativo.
• Todo-en-uno: Chat + videollamadas + archivos + apps integradas → reduce necesidad múltiples herramientas.
• Accesibilidad: Desktop (Windows, Mac), móvil (iOS, Android), web browser.

Desafíos MS Teams:

• Notificaciones abrumadoras: Si muchos canales activos, puede distraer (necesita disciplina gestionar notificaciones).
• Búsqueda limitada: Encontrar mensaje/archivo antiguo puede ser difícil (vs email archivado sistemáticamente).

Circuit (Unify)

¿Qué es Circuit?

Circuit es plataforma colaboración unificada (chat, voz, video, compartición contenido) desarrollada por Unify (antes Siemens Enterprise Communications), utilizada por administraciones públicas europeas, incluyendo Junta de Andalucía.

Contexto Junta Andalucía:

• Junta Andalucía desplegó Circuit como herramienta colaboración corporativa (alternativa/complemento Teams).
• Circuit on-premise: Datos alojados CPDs propios Junta (vs Teams cloud Microsoft) → mayor control datos, cumplimiento ENS.
• Federación Circuit: Junta Andalucía puede comunicarse vía Circuit con otras AAPP europeas que usen Circuit (interoperabilidad).

Características similares Teams:

• Espacios conversación (equivalente canales Teams).
• Chat, videollamadas, compartir pantalla.
• Compartición archivos.
• Apps móviles + desktop + web.

Uso SAS:

• Comunicación interna Junta: Personal SAS (parte Junta) usa Circuit para comunicaciones formales corporativas.
• Coordinación inter-consejerías: Ej. proyecto conjunto SAS (Consejería Salud) + SGAD (Consejería Presidencia) → espacios Circuit compartidos.

Teams vs Circuit en SAS (coexistencia):

• MS Teams: Más usado equipos técnicos TIC (desarrollo, proyectos), integración Office 365, ágil, moderno.
• Circuit: Más usado comunicaciones corporativas formales Junta, interoperabilidad AAPP, cumplimiento ENS estricto (datos on-premise).
• Realidad: Muchos empleados usan AMBAS (fragmentación, cierta redundancia, pero cada una tiene su nicho).

Email Corporativo

Dominio: @juntadeandalucia.es (empleados públicos Junta, incluyendo SAS).

Plataforma: Probablemente Microsoft Exchange (integrado Office 365) o sistema correo corporativo Junta.

Uso TIC:

• Comunicaciones formales: Actas reuniones, informes dirección, notificaciones oficiales.
• Coordinación proveedores externos: Consultoras, proveedores N3 (NO tienen acceso Circuit/Teams internos).
• Alertas automatizadas: Sistemas monitorización envían emails alertas (ej: «Servidor X caído», «Backup falló»).

Email sigue siendo crítico (a pesar auge chat): Trazabilidad legal, comunicaciones formales, archivo histórico.

5.2. Herramientas de Productividad y Compartición Ficheros

Consigna (Junta de Andalucía)

¿Qué es Consigna?

Consigna es el servicio corporativo de intercambio ficheros grandes de la Junta de Andalucía (equivalente WeTransfer, pero corporativo, seguro, ENS).

Problema que resuelve:

• Email tiene límite tamaño adjuntos (típico 25 MB).
• Enviar ficheros grandes (ej: backup BBDD 5 GB, ISO software 10 GB, logs comprimidos 500 MB…) por email imposible.
• Usar servicios públicos (Dropbox, Google Drive, WeTransfer…) → riesgo seguridad (datos sensibles Junta en cloud externo), incumplimiento ENS.

Cómo funciona Consigna:

1. Usuario sube fichero(s) grande(s) a portal web Consigna (autenticación credenciales corporativas).
2. Sistema genera link descarga único + contraseña opcional.
3. Usuario envía link destinatario(s) (email, chat…).
4. Destinatario descarga fichero desde link (validez temporal: 7-30 días configurable).
5. Pasado plazo, fichero se borra automáticamente (NO almacenamiento permanente).

Características Consigna:

• Tamaño máximo: Típicamente 2-10 GB por fichero (políticas Junta).
• Seguridad: Cifrado tránsito (HTTPS), contraseña protección descarga, logs auditoría (quién subió/descargó qué/cuándo).
• Caducidad automática: Ficheros NO permanecen indefinidamente (evita saturación almacenamiento, cumple RGPD minimización datos).

Uso típico SAS TIC:

• Compartir logs debug: Técnico SAS necesita enviar logs aplicación (200 MB comprimidos) a proveedor N3 → sube Consigna, envía link.
• Transferir backups: Migrar BBDD entre entornos, enviar backup DBA → DBA remoto.
• Distribuir software: Compartir instalador aplicación interna (demasiado grande email) con técnicos provinciales.

FicherosJunta (Repositorio Documentos Corporativo)

¿Qué es FicherosJunta?

FicherosJunta (nombre inferido, puede variar) es el repositorio corporativo de documentos de la Junta de Andalucía, basado en SharePoint o sistema ECM (Enterprise Content Management) similar.

Diferencia vs Consigna:

• Consigna: Intercambio temporal ficheros grandes (punto a punto, caducidad corta).
• FicherosJunta: Almacenamiento permanente documentos corporativos (estructurado, versionado, permisos, búsqueda).

Funcionalidades típicas:

• Bibliotecas documentos: Organización jerárquica carpetas (ej: «SAS > STIC > Proyectos > Diraya-Telemedicina > Documentación»).
• Versionado: Histórico versiones documento, control cambios, restaurar versión anterior.
• Check-in/Check-out: Bloquear documento mientras se edita (evitar conflictos versiones).
• Permisos granulares: Por carpeta/documento, grupos LDAP corporativos.
• Metadatos: Etiquetas, categorías, campos personalizados (ej: fecha creación, autor, proyecto relacionado…) → búsqueda avanzada.
• Integración Office: Abrir/editar/guardar Word/Excel directamente desde FicherosJunta (sin descargar/volver subir).

Uso típico SAS:

• Documentación proyectos: Almacenar pliegos técnicos, contratos, informes seguimiento, actas comités (documentos oficiales formales).
• Políticas y procedimientos: Procedimientos operativos TIC, políticas seguridad, normativa interna (acceso controlado según rol).
• Plantillas corporativas: Plantillas documentos estándar (informes, presentaciones, actas…) reutilizables.

OneDrive / OneDrive for Business

¿Qué es OneDrive?

OneDrive es el servicio almacenamiento nube personal de Microsoft (integrado Office 365), cada usuario tiene cuota (típico 1 TB).

OneDrive for Business: Versión corporativa, gestión centralizada TI, cumplimiento políticas seguridad.

Uso SAS:

• Almacenamiento personal: Cada empleado guarda ficheros trabajo propios (borradores docs, notas, scripts personales…).
• Sincronización desktop: Carpeta OneDrive sincronizada automáticamente PC usuario (acceso offline, backup automático).
• Compartir ficheros ad-hoc: Compartir documento específico con compañero(s) generando link (alternativa ligera a FicherosJunta para colaboraciones informales).

OneDrive vs FicherosJunta (SharePoint):

• OneDrive: Personal, ficheros individuales, colaboración ligera.
• FicherosJunta (SharePoint): Corporativo, documentos equipos/departamentos, estructurado, governance.

5.3. Herramientas de Monitorización y Operación

Contexto: Monitorización continua infraestructura TIC crítica (servidores, BBDD, red, aplicaciones…) para detectar fallos antes que impacten usuarios, responder proactivamente.

Nagios

¿Qué es Nagios?

Nagios es herramienta monitorización infraestructura TIC open source, estándar industria desde 1999.

Qué monitoriza:

• Hosts: Servidores (Windows, Linux), switches, routers, firewalls… (¿están UP/DOWN?)
• Servicios: HTTP (web servers), SSH, SMTP (email), BBDD (MySQL, Oracle), procesos críticos… (¿funcionan correctamente?)
• Métricas: CPU, RAM, disco, ancho banda red, tiempo respuesta… (¿dentro umbrales normales?)

Cómo funciona:

1. Checks periódicos: Nagios ejecuta plugins verificación cada X minutos (ej: cada 5 min verificar si servidor Diraya responde).
2. Estados: OK (verde), WARNING (amarillo), CRITICAL (rojo), UNKNOWN (gris).
3. Alertas: Si estado cambia a WARNING/CRITICAL → envía alerta (email, SMS, integración Slack/Teams, llamada teléfono…) a responsables guardia.
4. Dashboards: Panel visual estado todos sistemas monitorizados (mapas topología red, gráficos métricas…).

Uso típico SAS:

• Monitorización Diraya: Servidores aplicación, BBDD Oracle, balanceadores carga, servicios integración (HL7, FHIR) → si alguno falla → alerta inmediata equipo guardia.
• Monitorización infraestructura: CPDs (servidores físicos, virtualización VMware, almacenamiento SAN…), red troncal Junta (routers principales).
• SLA tracking: Calcular disponibilidad real sistemas (ej: Diraya disponible 99,6% mes pasado → cumple SLA 99,5%).

Alternativas Nagios:

• Zabbix: Open source, más moderno que Nagios, auto-discovery hosts, gráficos nativos mejores.
• Prometheus + Grafana: Stack moderno monitorización (Prometheus recoge métricas, Grafana visualiza), muy usado entornos cloud/Kubernetes.
• PRTG Network Monitor: Comercial, Windows-friendly, muy visual.

ELK Stack (Elasticsearch, Logstash, Kibana)

¿Qué es ELK?

ELK es stack open source gestión logs centralizada:

• Elasticsearch: Motor búsqueda/indexación distribuido (almacena logs).
• Logstash: Procesador logs (recolecta, parsea, transforma, envía a Elasticsearch).
• Kibana: Frontend visualización (dashboards, gráficos, búsquedas sobre logs Elasticsearch).

Problema que resuelve:

• Sistemas TIC generan millones líneas logs diarios (aplicaciones, servidores, BBDD, firewalls…).
• Logs dispersos múltiples servidores, formatos heterogéneos, difícil buscar/correlacionar eventos.
• Troubleshooting incidencias requiere analizar logs → proceso manual lento, propenso errores.

Flujo típico ELK:

1. Recolección: Logstash/Beats (agentes ligeros) envían logs desde servidores → Logstash central.
2. Procesamiento: Logstash parsea logs (extrae campos: timestamp, nivel error, IP origen, mensaje…), enriquece (geolocalización IPs…), filtra ruido.
3. Indexación: Logstash envía logs procesados → Elasticsearch (indexados full-text, búsqueda rápida).
4. Visualización: Técnicos acceden Kibana web, crean dashboards (ej: gráfico errores 500 Diraya últimas 24h, tabla top IPs generando tráfico…), buscan logs específicos (ej: «todos logs usuario X última hora»).

Uso típico SAS:

• Troubleshooting aplicaciones: Diraya genera error → técnico busca Kibana logs Diraya últimos minutos, filtra por nivel ERROR, encuentra stack trace excepción → identifica bug.
• Seguridad (SIEM básico): Detectar patrones sospechosos (ej: intentos login fallidos masivos, accesos URLs prohibidas, tráfico red anómalo…).
• Auditoría: Compliance ENS requiere logs auditoría → ELK centraliza, retiene X años, facilita auditorías.

Herramientas Monitorización APM (Application Performance Monitoring)

Ejemplos: New Relic, Dynatrace, AppDynamics, Elastic APM…

Función: Monitorización rendimiento aplicaciones nivel código (transacciones, consultas BBDD lentas, errores exceptions, experiencia usuario…).

Uso potencial SAS: Monitorizar performance Diraya (tiempo carga pantallas, latencia consultas BBDD, identificar cuellos botella código…) → optimización proactiva.

5.4. Integración y Single Sign-On (SSO)

Problema fragmentación herramientas:

• TFA-STI típico usa: JIRA, Confluence, ayudaDIGITAL, GitLab, Teams, Circuit, Consigna, FicherosJunta, Nagios, Kibana…
• Si cada herramienta requiere usuario/contraseña diferente → caos (olvido credenciales, contraseñas débiles reutilizadas, overhead gestión).

Solución: Single Sign-On (SSO)

• Autenticación centralizada: Credenciales corporativas únicas (dominio Junta de Andalucía, LDAP/Active Directory).
• Login una vez: Usuario autentica mañana con credenciales corporativas → accede TODAS herramientas sin volver loguearse (sesión válida 8-24h).
• Protocolos SSO: SAML 2.0, OAuth 2.0 + OpenID Connect (estándares industria).
• Proveedor Identidad (IdP): Junta Andalucía tiene IdP central (probablemente basado Microsoft Azure AD o similar) → todas apps corporativas integran SSO con IdP.

Beneficios SSO:

• Usabilidad: Experiencia usuario fluida, productividad (NO perder tiempo logueándose múltiples herramientas).
• Seguridad: Contraseña única más fácil hacer fuerte (+ MFA – Multi-Factor Authentication), desactivar acceso empleado que se va es inmediato (revocación IdP → NO accede NADA).
• Compliance: Auditorías accesos centralizadas (logs IdP muestran quién accedió qué/cuándo).

6. Cuestionario de Autoevaluación – 25 Preguntas Tipo Test

7. Mapa Conceptual y Referencias

      HERRAMIENTAS GESTIÓN TIC
                |
        ┌───────┴───────────┐
        |                   |
    4 CATEGORÍAS      CARACTERÍSTICAS
    PRINCIPALES          DESEABLES
        |                   |
┌───────┼────────┐      Usabilidad
|       |        |      Integración
|       |        |      Escalabilidad
|       |        |      Seguridad/ENS
|       |        |      Soporte
|       |        |      Coste-Beneficio
|       |        |
|   PROYECTOS  OPERACIÓN  CONOCIMIENTO  INTERNA
|       |        |            |           |
|   MS Project ITSM/ITIL  Confluence  Teams/Circuit
|   JIRA Softw Service Desk SharePoint Consigna
|   Trello     ayudaDIGITAL MediaWiki  OneDrive
|   Confluence CSU (SAS)   GitLab     Nagios
|              CMDB        Wikis      ELK Stack
|              Incident              SSO
|              Problem
|              Change
|              Config
|              SLA
|
APLICACIÓN SAS:
- Proyectos: JIRA (desarrollo Diraya), MS Project (macro)
- Operación: ayudaDIGITAL + CSU (Service Desk N1)
- Conocimiento: Confluence (wikis técnicas, KB)
- Interna: Teams/Circuit (comunicación), Consigna (ficheros),
  Nagios (monitorización), ELK (logs), SSO (autenticación única)
    

8. Referencias Normativas y Bibliográficas