Modulo 01. Del valor a la operacion: enfoque CDS

Objetivo del modulo

Entender con precisión qué cubre 'Del valor a la operacion: enfoque CDS', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.

Desarrollo teorico

ITIL 4 Create, Deliver and Support (CDS) es el módulo de especialista que traduce los conceptos generales del Service Value System (SVS) en capacidades operativas concretas para crear, entregar y dar soporte a servicios de TI. Mientras que ITIL 4 Foundation establece el marco conceptual, CDS se centra en la ejecución: cómo se organiza el trabajo, cómo fluye una demanda desde que se identifica hasta que el servicio está operativo y cómo se mantiene y mejora de forma continua.

El SVS como punto de partida operativo

El Service Value System de ITIL 4 integra todos los componentes necesarios para la co-creación de valor: los principios guía, la gobernanza, la Service Value Chain (SVC), las prácticas y la mejora continua. CDS aterriza este modelo en la realidad operativa. No basta con conocer las seis actividades de la SVC (planificar, mejorar, involucrar, diseñar y transicionar, obtener/construir, entregar y dar soporte); es necesario entender cómo esas actividades se combinan en value streams específicos para cada tipo de demanda. Por ejemplo, la actividad de diseño y transición no opera de forma aislada: necesita entradas de la actividad de involucrar (requisitos del stakeholder), produce salidas hacia obtener/construir (especificaciones técnicas) y se retroalimenta de entregar y dar soporte (incidencias de operación temprana).

Las cuatro dimensiones en el contexto CDS

Toda decisión operativa debe evaluarse a través de las cuatro dimensiones de la gestión de servicios. La dimensión de organizaciones y personas determina qué estructura de equipo y qué cultura colaborativa se necesita para crear y soportar el servicio. La dimensión de información y tecnología define qué herramientas ITSM, qué datos de configuración y qué plataformas de automatización permiten ejecutar el servicio. La dimensión de socios y proveedores establece cómo se integran terceros en el value stream sin generar cuellos de botella ni zonas de responsabilidad ambigua. La dimensión de flujos de valor y procesos es la más visible en CDS, porque define la secuencia real de pasos que convierte demanda en valor entregado. Un servicio que ignora cualquiera de estas dimensiones genera desequilibrios: exceso de tecnología sin personas capacitadas, o procesos bien documentados pero sin socios que los ejecuten.

Prácticas CDS clave y su interrelación

CDS trabaja con un subconjunto relevante de las 34 prácticas de ITIL 4. Las prácticas de gestión de servicios más directamente implicadas en la creación y entrega incluyen: service design, que asegura que el servicio se conciba con todos los requisitos funcionales y no funcionales; software development and management, que gobierna el ciclo de vida del código; deployment management, que controla la puesta en producción; release management, que coordina la disponibilidad de nuevas funcionalidades para el usuario; change enablement, que autoriza cambios minimizando riesgo; incident management, que restaura el servicio ante interrupciones; problem management, que investiga causas raíz; y service desk, que actúa como punto único de contacto con el usuario.

Estas prácticas no operan en silos. Un cambio autorizado por change enablement se despliega mediante deployment management, se libera a través de release management y, si genera incidencias, se detecta mediante incident management y se analiza con problem management. CDS enfatiza que el diseño de esta cadena debe ser explícito, medible y mejorable.

Value streams como eje central

El concepto de value stream es el hilo conductor de CDS. Un value stream describe la secuencia de pasos, actividades de la SVC, prácticas y personas que transforman una demanda en un resultado de valor. CDS distingue al menos dos tipos de value streams principales: los de creación de nuevo servicio (desde la idea hasta la entrega operativa) y los de resolución (desde la detección de un incidente o problema hasta su cierre y aprendizaje). Cada organización debe mapear sus propios value streams, identificar handoffs entre equipos, localizar esperas innecesarias y definir métricas de flujo como lead time o throughput.

Diseño y transición de servicios

CDS profundiza en cómo se diseña un servicio para que sea operable, soportable y mejorable desde el primer día. Esto implica considerar desde la fase de diseño aspectos como la capacidad de monitorización, la existencia de runbooks para el equipo de soporte, la definición de niveles de servicio iniciales y la estrategia de despliegue (big bang, por fases, canary release o blue-green). La transición del servicio no es un evento puntual sino un proceso que incluye pruebas de aceptación, formación al equipo de soporte, documentación operativa y un período de soporte reforzado (early life support) que permite detectar problemas antes de que el servicio se estabilice.

Escenario realista

Ejemplo aplicado: Una organización lanza un nuevo servicio de gestión documental en la nube. El value stream de creación comienza con la captura de requisitos del área legal y de cumplimiento (involucrar), pasa por el diseño de la arquitectura y los controles de seguridad (diseñar y transicionar), sigue con la construcción e integración con el directorio corporativo (obtener/construir) y termina con el despliegue por fases a cada sede (entregar y dar soporte). Durante la transición se detecta que el equipo de service desk no conoce los procedimientos de recuperación de documentos eliminados, lo que obliga a añadir una sesión de formación y un runbook antes de completar la transición. Esta situación ilustra cómo CDS conecta diseño, soporte y mejora en un flujo continuo.

Tabla de referencia

Procedimiento recomendado

1. Identificar la demanda y el tipo de value stream aplicable
2. Mapear las actividades de la SVC involucradas y las prácticas que participan
3. Evaluar las cuatro dimensiones para detectar carencias
4. Definir métricas de flujo y puntos de control

Métrica o evidencia útil

Lead time desde la captura de la demanda hasta la entrega operativa del servicio, complementado con el porcentaje de incidencias en las primeras dos semanas de operación (early life support).

Artefacto recomendado

Mapa de value stream del servicio con actividades SVC, prácticas participantes, roles responsables y métricas de flujo asociadas.

Contenido ampliado

Este módulo se relaciona con el resto del curso 'ITIL 4 Create, Deliver & Support (CDS)' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.

Puntos clave

• CDS traduce el SVS y la SVC en capacidades operativas reales de creación, entrega y soporte.
• Las cuatro dimensiones deben evaluarse en cada decisión operativa para evitar desequilibrios.
• Los value streams son el eje central: definen cómo fluye el trabajo desde la demanda hasta el valor entregado.
• Las prácticas no operan en silos; su integración explícita es lo que diferencia una operación madura.

Checklist operativa

• Identificar el tipo de value stream (creación o resolución)
• Mapear actividades SVC y prácticas participantes
• Evaluar las cuatro dimensiones para cada servicio
• Definir métricas de flujo (lead time, throughput)
• Planificar early life support en cada transición

Errores frecuentes

• Diseñar servicios sin considerar su operabilidad y soportabilidad desde el inicio.
• Tratar las prácticas de ITIL como funciones aisladas en lugar de componentes integrados del value stream.
• No mapear value streams reales y trabajar solo con organigramas o procesos teóricos.

Practica sugerida

Mapa de value stream del servicio con actividades SVC, prácticas, roles y métricas de flujo.

Preguntas de autoevaluacion

• ¿Cómo se relacionan las actividades de la SVC con las prácticas de ITIL en un value stream de creación de servicio?
• ¿Qué riesgo existe si se diseña un servicio sin evaluar las cuatro dimensiones?

Cierre

Si al terminar puedes explicar cómo CDS traduce el SVS en operación real, mapear un value stream con sus prácticas y actividades SVC, y justificar decisiones usando las cuatro dimensiones, el módulo ya te habrá dado una base aplicable y no solo vocabulario.

Modulo 02. Estructuras organizativas, roles y cultura

Objetivo del modulo

Entender con precisión qué cubre 'Estructuras organizativas, roles y cultura', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.

Desarrollo teorico

La creación, entrega y soporte de servicios no depende solo de procesos y herramientas: depende fundamentalmente de cómo se organizan las personas, qué roles asumen y qué cultura prevalece en la organización. ITIL 4 CDS dedica atención explícita a este tema porque la dimensión de organizaciones y personas es una de las cuatro dimensiones de la gestión de servicios, y su desalineamiento con las demás dimensiones produce disfunciones operativas graves.

Modelos de estructura organizativa

Las organizaciones de TI pueden adoptar distintos modelos de estructura, cada uno con ventajas y limitaciones en el contexto CDS. La estructura funcional agrupa a las personas por especialidad técnica (redes, servidores, aplicaciones, seguridad). Facilita la profundidad técnica pero genera silos y handoffs costosos entre equipos. La estructura por producto o servicio agrupa capacidades multidisciplinares alrededor de un servicio o producto concreto. Reduce handoffs y acelera la entrega, pero puede duplicar competencias y dificultar la gobernanza transversal. La estructura matricial combina ambas: las personas reportan tanto a un responsable funcional como a un responsable de servicio o proyecto. Ofrece flexibilidad pero puede generar conflictos de prioridad y confusión en la rendición de cuentas.

ITIL 4 no prescribe un modelo único. Lo que exige es que la estructura elegida facilite los value streams en lugar de bloquearlos. Si un value stream de creación de servicio requiere la participación coordinada de desarrollo, seguridad, infraestructura y soporte, la estructura debe permitir que esa coordinación ocurra con fluidez y sin escalaciones innecesarias.

Roles clave en CDS

CDS identifica roles que son críticos para la operación integrada de servicios. El service owner es responsable de extremo a extremo del servicio, asegurando que cumple los niveles acordados y que evoluciona según las necesidades del negocio. El practice owner gobierna una práctica específica (por ejemplo, incident management) y asegura su madurez, adopción y mejora. El process owner, cuando existe como rol diferenciado, se centra en la eficiencia y cumplimiento de un proceso concreto dentro de una práctica. El product owner, frecuente en entornos ágiles, prioriza el backlog y asegura que el desarrollo entrega valor incremental alineado con las necesidades del usuario.

Más allá de estos roles formales, CDS reconoce que en los value streams participan múltiples personas que deben entender su contribución al flujo completo. Un desarrollador que no entiende el impacto de su código en la operación generará problemas que incident management tendrá que resolver. Un agente de service desk que no conoce la arquitectura del servicio dará respuestas incorrectas al usuario. La claridad de roles no es burocracia: es una condición para que el value stream funcione.

Cultura organizativa y colaboración

La cultura organizativa determina si las estructuras y roles funcionan en la práctica. ITIL 4 promueve una cultura de colaboración, transparencia y mejora continua alineada con los principios guía. El principio de colaborar y promover la visibilidad significa que los equipos comparten información sobre el estado de los servicios, las incidencias y los cambios, en lugar de proteger su territorio. El principio de pensar y trabajar holísticamente implica que cada persona entiende su contribución al value stream completo, no solo su tarea aislada.

En CDS, la cultura tiene impacto directo en la calidad operativa. Una cultura de culpa genera ocultamiento de errores, lo que impide que problem management identifique causas raíz. Una cultura de silos genera conflictos entre desarrollo y operaciones que ralentizan los despliegues. Una cultura de aprendizaje permite que las retrospectivas y las revisiones post-incidente produzcan mejoras reales.

La adopción de prácticas como DevOps, Site Reliability Engineering (SRE) o equipos de producto requiere transformación cultural, no solo reorganización de organigramas. Shared ownership, blameless postmortems y la responsabilidad compartida sobre la disponibilidad del servicio son manifestaciones culturales que CDS considera necesarias para entornos de entrega moderna.

Integración con la Service Value Chain

La estructura organizativa afecta directamente a la ejecución de las actividades de la SVC. La actividad de involucrar requiere roles orientados al stakeholder (service owner, relationship manager). La actividad de diseñar y transicionar requiere equipos multidisciplinares capaces de considerar las cuatro dimensiones. La actividad de obtener/construir puede requerir equipos de producto ágiles con autonomía para decidir aspectos técnicos. La actividad de entregar y dar soporte necesita equipos de soporte con conocimiento del servicio y herramientas adecuadas.

Cuando la estructura organizativa no soporta estas necesidades, los value streams se fragmentan. Los handoffs se multiplican, las esperas crecen y la experiencia del usuario se degrada. CDS recomienda revisar periódicamente si la estructura organizativa sigue siendo coherente con los value streams actuales, especialmente cuando se incorporan nuevos servicios o se transforman los existentes.

Escenario realista

Ejemplo aplicado: Una empresa de seguros tiene un equipo de infraestructura, un equipo de desarrollo y un service desk independientes. Cuando se lanza un nuevo servicio de cotización online, el equipo de desarrollo entrega el código sin runbooks ni documentación operativa, infraestructura despliega sin entender los requisitos de rendimiento y el service desk recibe llamadas que no sabe resolver. Tras analizar el value stream, se crea un equipo de servicio que incluye representantes de las tres áreas, se nombra un service owner que coordina extremo a extremo y se establece una retrospectiva mensual conjunta. El resultado es una reducción del lead time de resolución de incidencias y una mejora visible en la satisfacción del usuario.

Tabla de referencia

Procedimiento recomendado

1. Evaluar si la estructura actual soporta los value streams existentes
2. Identificar handoffs innecesarios entre equipos
3. Definir roles claros (service owner, practice owner) y sus responsabilidades
4. Promover prácticas culturales de colaboración y transparencia

Métrica o evidencia útil

Número de handoffs por value stream y tiempo medio de espera entre equipos en el flujo de entrega.

Artefacto recomendado

Matriz RACI del value stream principal con roles, responsabilidades y puntos de decisión.

Contenido ampliado

Este módulo se relaciona con el resto del curso 'ITIL 4 Create, Deliver & Support (CDS)' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.

Puntos clave

• La estructura organizativa debe facilitar los value streams, no bloquearlos con silos funcionales.
• Los roles clave (service owner, practice owner, product owner) dan claridad de responsabilidad extremo a extremo.
• La cultura de colaboración, transparencia y aprendizaje es condición necesaria para la operación CDS eficaz.
• La revisión periódica de la alineación entre estructura y value streams previene disfunciones operativas.

Checklist operativa

• Evaluar estructura actual frente a los value streams
• Definir y comunicar roles clave
• Identificar y reducir handoffs innecesarios
• Fomentar prácticas de retrospectiva y postmortem sin culpa

Errores frecuentes

• Reorganizar organigramas sin cambiar la cultura de colaboración.
• Asignar roles de service owner sin autoridad real sobre el servicio.
• Mantener silos funcionales que fragmentan los value streams de entrega y soporte.

Practica sugerida

Matriz RACI del value stream principal con roles, responsabilidades y puntos de decisión.

Preguntas de autoevaluacion

• ¿Qué impacto tiene una estructura funcional pura sobre los value streams de CDS?
• ¿Por qué la cultura organizativa es tan importante como los roles formales para la entrega de servicios?

Cierre

Si al terminar puedes explicar cómo la estructura organizativa, los roles y la cultura impactan en los value streams de CDS, y puedes proponer ajustes concretos para mejorar la colaboración entre equipos, el módulo ya te habrá dado una base aplicable y no solo vocabulario.