Modulo 01. Que es un servicio y como se cataloga

Objetivo del modulo

Definir que es un servicio de TI, que elementos lo componen, como convertirlo en una entrada clara de catalogo y como se relaciona con el proceso de Service Level Management (SLM).

Resultados esperados

• Diferenciar servicio, producto, aplicacion y componente tecnico con criterios claros.
• Identificar elementos minimos de una ficha de servicio orientada a valor.
• Construir una taxonomia basica de catalogo alineada con SLM.
• Entender el rol del catalogo como base para la definicion de SLAs y OLAs.

Desarrollo teorico

Un servicio de TI no es solo una herramienta tecnica ni una aplicacion aislada. Es un conjunto de capacidades que permite a un cliente o unidad de negocio obtener un resultado sin tener que gestionar toda la complejidad tecnica subyacente. Esta definicion, alineada con ITIL 4, es importante porque evita dos errores frecuentes: catalogar componentes internos como si fueran servicios de negocio, o presentar al usuario un catalogo que en realidad es una lista de aplicaciones sin contexto de valor.

El proceso de Service Level Management (SLM) establece que cada servicio catalogado debe tener expectativas de nivel de servicio definidas, medibles y acordadas con el cliente. SLM no es un proceso que ocurre despues del catalogo; es un proceso que se integra desde el diseno del servicio. Cuando se cataloga un servicio, ya se debe pensar en que disponibilidad, tiempos de respuesta y soporte se van a comprometer, porque esos parametros condicionan la ficha, los recursos necesarios y la forma en que el servicio se presenta al negocio.

Un servicio suele incluir alcance funcional (que hace y que no hace), usuarios objetivo (quien puede consumirlo), propietario o service owner (quien responde por su calidad), horario de disponibilidad (cuando esta operativo), niveles de soporte (como se gestionan incidencias y peticiones), dependencias tecnicas (que componentes lo soportan) y, en muchos casos, un modelo de solicitud o consumo (como se pide). Por ejemplo, "Correo y colaboracion" puede ser un servicio; dentro de el pueden existir componentes como Exchange Online, Teams, antispam y archivado. El usuario del catalogo no necesita navegar esos componentes al principio; necesita entender que valor obtiene, que incluye el servicio, que no incluye y como solicitarlo o reportar incidencias.

Catalogar implica seleccionar una unidad de servicio coherente. Si se baja demasiado al detalle, el catalogo se vuelve inmanejable y pierde la perspectiva de valor. Si se queda demasiado alto, pierde utilidad y el usuario no encuentra lo que necesita. Una regla practica es catalogar aquello que tiene owner claro, consumidor identificable, expectativa de nivel de servicio medible y capacidad de solicitud o soporte diferenciada. "Red corporativa" puede ser servicio interno; "Alta de usuario en ERP" probablemente sea una peticion dentro de otro servicio; "Switch de planta 2" es un componente, no un servicio para el negocio.

La relacion entre catalogo y SLM es bidireccional. El catalogo define que servicios existen y para quien; SLM define que nivel de calidad se compromete y como se mide. Sin catalogo, SLM no tiene objeto sobre el cual definir niveles de servicio. Sin SLM, el catalogo es una lista sin expectativas verificables. Esta interdependencia implica que al disenar una ficha de servicio, se deben incluir al menos los parametros basicos que despues se formalizaran en SLAs: disponibilidad objetivo, horario de servicio, severidades de incidencia y tiempos de respuesta y restauracion orientativos.

La ficha de servicio minima deberia incluir: nombre del servicio con lenguaje de negocio, descripcion orientada a valor y resultado, cliente objetivo con segmentos si procede, service owner con nombre y contacto, horario de servicio y ventanas de mantenimiento, canales de soporte y modelo de escalado, dependencias relevantes que puedan afectar la disponibilidad, criterios de criticidad para la organizacion, enlaces a SLAs vigentes o parametros orientativos de nivel de servicio, y modelo de solicitud o consumo. Algunas organizaciones anaden coste unitario o showback, centro de coste, ubicaciones cubiertas, proveedor principal y requisitos de seguridad. Lo importante es que la ficha sirva para entender y gobernar, no para acumular campos sin uso.

La taxonomia del catalogo establece como se organizan los servicios para que el usuario encuentre lo que necesita. Una taxonomia orientada a resultados agrupa servicios por necesidad: "Puesto de trabajo", "Colaboracion", "Aplicaciones de negocio", "Conectividad", "Identidad y acceso", "Seguridad". Dentro de cada categoria puede haber servicios consumibles, peticiones estandar y articulos de conocimiento. La taxonomia debe ser estable pero no rigida: debe poder evolucionar cuando cambia la cartera de servicios sin perder la coherencia para el usuario.

Un catalogo bien estructurado habilita directamente el proceso SLM porque cada entrada tiene un owner que responde por la calidad, metricas definibles, consumidores identificados y una cadena de soporte conocida. Sin esta estructura, intentar negociar SLAs se convierte en un ejercicio abstracto sin anclaje operativo.

Contenido ampliado

Puntos clave

• Servicio no es sinonimo de aplicacion o componente; implica valor para el consumidor.
• El catalogo debe hablar el lenguaje del cliente y del negocio, no de la infraestructura.
• Una ficha de servicio necesita owner, alcance, soporte y parametros de nivel de servicio.
• Catalogo y SLM son procesos interdependientes que se disenan conjuntamente.
• Una taxonomia buena reduce ambiguedad y solicitudes mal dirigidas.
• El catalogo es la base operativa sobre la que SLM define y mide compromisos.

Checklist operativa

• Elige cinco servicios reales y clasificalos distinguiendo servicio, componente y peticion.
• Redacta para cada uno una descripcion orientada a valor con lenguaje de negocio.
• Define que elementos son componentes y cuales son servicios consumibles.
• Asigna service owner y consumidor principal para cada servicio.
• Incluye parametros orientativos de nivel de servicio en cada ficha.
• Verifica que la taxonomia permite al usuario encontrar lo que necesita sin conocer la estructura TI.

Errores frecuentes

• Incluir infraestructura tecnica como entrada principal del catalogo.
• Escribir descripciones orientadas a TI y no al usuario.
• No aclarar que queda fuera del servicio ni las exclusiones.
• Duplicar servicios por areas sin taxonomia comun.
• Catalogar servicios sin pensar en parametros de SLM.
• Crear un catalogo sin owners que respondan por la calidad del servicio.

Practica sugerida

Toma un portal de peticiones existente y reagrupalo en servicios, peticiones y componentes, eliminando ambiguedades de nomenclatura. Para cada servicio resultante, redacta una ficha minima que incluya descripcion de valor, owner, horario, canales de soporte, criticidad y parametros orientativos de disponibilidad y tiempos de respuesta que serviran de base para el diseno de SLAs.

Preguntas de autoevaluacion

• Que hace que algo sea un servicio y no solo una herramienta, y como se refleja en la ficha de catalogo.
• Por que un servicio necesita owner visible y como se relaciona ese owner con SLM.
• Que riesgos aparecen si se catalogan componentes en lugar de servicios.
• Como contribuye el catalogo a que SLM pueda definir SLAs medibles y operativos.

Cierre

Un catalogo util empieza por nombrar bien el servicio, explicar su valor con claridad y establecer los parametros minimos que habilitaran un proceso de SLM efectivo. Sin catalogo estructurado, los acuerdos de nivel de servicio carecen de objeto; sin SLM, el catalogo es una lista sin compromiso verificable.

Modulo 02. Diseno del catalogo orientado a negocio

Objetivo del modulo

Disenar un catalogo de servicios que sea entendible para negocio, operativo para TI y sostenible en el tiempo, integrando las vistas necesarias para alimentar el proceso de SLM.

Resultados esperados

• Crear una taxonomia orientada a consumidor con categorias estables.
• Diferenciar vistas de negocio, tecnica y de soporte con audiencia y proposito claros.
• Definir campos, agrupaciones y criterios de mantenimiento alineados con SLM.
• Disenar la experiencia del usuario para reducir peticiones mal clasificadas.

Desarrollo teorico

El diseno del catalogo debe partir de la experiencia del consumidor y no de la estructura interna del departamento de TI. Si el portal replica el organigrama, el usuario tendra que adivinar a que equipo pertenece una necesidad. En cambio, si el catalogo agrupa por resultado, como "Puesto de trabajo", "Colaboracion", "Aplicaciones corporativas", "Conectividad" o "Acceso e identidad", la navegacion mejora y disminuyen las peticiones mal clasificadas. Esta decision de diseno tiene impacto directo en SLM porque un catalogo bien organizado permite mapear SLAs a unidades de servicio claras en lugar de a componentes tecnicos dispersos.

Normalmente conviven tres vistas del catalogo que sirven a audiencias distintas. La vista de negocio explica servicios y solicitudes con lenguaje simple, orientada a empleados, managers y clientes internos. Muestra que servicios existen, que valor aportan, como solicitarlos, en que horario estan disponibles y que niveles de servicio se pueden esperar. Esta vista es la cara visible del catalogo y la que mas impacto tiene en la percepcion del usuario. La vista tecnica detalla componentes, dependencias, integraciones, owners tecnicos y relaciones con CIs de la CMDB. Es la vista que usa el service owner para gestionar el servicio y es la base para definir OLAs entre equipos internos. La vista de soporte organiza colas de atencion, modelos de ticket, prioridades, escalados y tiempos comprometidos. Es la vista que usa la mesa de servicio para gestionar incidencias y peticiones conforme a los SLAs y OLAs vigentes.

Un error comun es intentar meterlo todo en una sola pantalla. Es mejor mantener una entrada clara para el usuario en la vista de negocio y relacionarla internamente con taxonomias mas ricas en las vistas tecnica y de soporte. El usuario no necesita ver la topologia de infraestructura; necesita saber si su problema se resuelve, en cuanto tiempo y a traves de que canal.

El diseno tambien requiere definir criterios de inclusion claros. No todo debe publicarse con el mismo nivel de detalle. Hay servicios consumibles (el usuario puede solicitarlos directamente), servicios internos (solo visibles para equipos de TI), peticiones estandar (formularios predefinidos para solicitudes frecuentes) y conocimientos asociados (articulos de autoservicio que resuelven dudas sin ticket). Un portal maduro combina fichas de servicio, formularios de peticion, base de conocimiento y enlaces a estado o interrupciones. La clave es que cada pieza tenga un proposito. Si una entrada no permite solicitar, entender o resolver, probablemente no deberia estar en el nivel principal del catalogo.

El diseno del catalogo influye directamente en la calidad del proceso SLM. Un catalogo con servicios bien delimitados permite que cada SLA tenga un ambito claro. Un catalogo con servicios difusos produce SLAs ambiguos que no se pueden medir ni cumplir. El mapping entre catalogo y SLA debe ser explicito: cada servicio del catalogo tiene un SLA asociado (o al menos parametros de nivel de servicio definidos), y cada SLA referencia un servicio concreto del catalogo. Este vinculo es lo que permite medir cumplimiento, identificar desviaciones y tomar decisiones de mejora.

La ficha de servicio en la vista de negocio debe incluir como minimo: nombre comprensible, descripcion de valor en una o dos frases, que incluye y que no incluye, como solicitarlo, horario de disponibilidad, tiempos orientativos de respuesta y resolucion, canal de soporte y owner visible. La ficha en la vista tecnica anade: componentes y dependencias, integraciones, proveedor principal, metricas de disponibilidad y rendimiento, OLAs internos y plan de contingencia. La ficha en la vista de soporte anade: modelo de ticket, categorias y subcategorias de clasificacion, prioridades y tiempos SLA por severidad, grupo de resolucion y escalado.

La validacion del diseno con usuarios reales es un paso que muchas organizaciones omiten. Antes de publicar el catalogo, conviene probar con un grupo representativo si pueden encontrar los servicios que necesitan, si entienden las descripciones, si los formularios recogen la informacion necesaria sin ser excesivos y si la taxonomia les resulta natural. Los resultados de esta validacion suelen revelar problemas de nomenclatura, servicios mal ubicados y carencia de informacion clave.

Contenido ampliado

Puntos clave

• Un buen catalogo se disena desde la necesidad del usuario, no desde el organigrama de TI.
• Las vistas de negocio, tecnica y soporte pueden ser distintas pero deben estar conectadas.
• La taxonomia debe ser estable, corta y comprensible para reducir clasificaciones erroneas.
• El catalogo no es solo un portal; es el modelo de gobierno sobre el que SLM opera.
• El mapping entre servicio del catalogo y SLA debe ser explicito y bidireccional.
• La validacion con usuarios reales antes de publicar ahorra problemas posteriores.

Checklist operativa

• Revisa si el catalogo actual refleja organigrama o resultados de negocio.
• Disena categorias principales y subcategorias orientadas a necesidad del usuario.
• Define ficha minima por servicio incluyendo parametros de nivel de servicio.
• Crea tres vistas diferenciadas: negocio, tecnica y soporte.
• Mapea cada servicio a su SLA o parametros de SLM correspondientes.
• Valida la navegacion con usuarios reales antes de publicar.

Errores frecuentes

• Publicar demasiadas entradas sin agrupacion ni jerarquia.
• Mezclar conocimientos, peticiones y servicios sin distincion clara.
• Disenar el catalogo solo desde TI sin validar con consumidores.
• No mantener una taxonomia comun entre areas.
• Omitir el vinculo entre servicio del catalogo y SLA correspondiente.
• No iterar el diseno despues de la primera publicacion.

Practica sugerida

Redisena la portada de un catalogo corporativo en 6-8 categorias y prueba si un usuario puede encontrar "alta de portatil", "acceso VPN" y "correo compartido" sin conocer la estructura TI. Para cada servicio encontrado, verifica que la ficha incluye parametros de nivel de servicio y que existe un SLA o borrador de SLA vinculado. Documenta los hallazgos de la validacion con usuarios.

Preguntas de autoevaluacion

• Por que un catalogo basado en equipos internos suele fallar desde la perspectiva del consumidor.
• Que diferencia hay entre vista de negocio y vista tecnica y como cada una alimenta un aspecto distinto de SLM.
• Que campos no deberian faltar en la ficha de un servicio para que SLM pueda operar sobre ella.
• Como afecta una taxonomia inestable a la medicion de SLAs y al reporting de cumplimiento.

Cierre

El diseno del catalogo determina si el servicio resulta visible y gobernable o si queda oculto tras terminologia interna. Un catalogo bien disenado es la condicion necesaria para que SLM defina compromisos medibles, y la validacion con usuarios reales es lo que convierte un diseno teorico en una herramienta efectiva.