Tema 13 · Gestió de serveis

Gestió de la qualitat dels serveis TIC. Norma ISO 20000

Elaboració pròpia: la font és de pagament i no es reprodueix

Sense esquema, expressament

Enunciat oficial. Gestió de la qualitat del serveis TIC. Norma ISO 20000.

1. Qualitat aplicada als serveis TIC

Qualitat (ISO 9000): grau en què un conjunt de característiques inherents d'un objecte compleix els requisits.

Un servei TIC (Tecnologies de la Informació i la Comunicació) té particularitats respecte d'un producte: és intangible, es produeix i consumeix simultàniament, és variable i no s'emmagatzema. Per això la qualitat d'un servei es mesura sobre la percepció de l'usuari i sobre els nivells de servei acordats, no només sobre la conformitat tècnica.

Model SERVQUAL (cinc dimensions de la qualitat percebuda): fiabilitat, capacitat de resposta, seguretat, empatia i elements tangibles.

ISO 9001 i els set principis de la gestió de la qualitat: enfocament al client, lideratge, compromís de les persones, enfocament a processos, millora, presa de decisions basada en l'evidència i gestió de les relacions.

• Objectiu de la ISO 9001: especificar els requisits d'un sistema de gestió de la qualitat quan una organització necessita demostrar la seva capacitat per proporcionar de manera coherent productes i serveis que satisfacin els requisits del client i els legals i reglamentaris aplicables, i aspira a augmentar la satisfacció del client. No certifica productes: certifica el sistema de gestió.
• Pensament basat en el risc: la versió 2015 substitueix les «accions preventives» per la consideració sistemàtica dels riscos i oportunitats en la planificació del sistema.
• Responsabilitat de la direcció: la norma exigeix que l'alta direcció demostri lideratge i compromís — assumir la responsabilitat i obligació de retre comptes (accountability) de l'eficàcia del sistema, establir la política i els objectius de qualitat, assegurar la integració dels requisits en els processos de negoci, promoure l'enfocament a processos i el pensament basat en el risc, assegurar la disponibilitat de recursos, comunicar la importància de la gestió de la qualitat i promoure la millora.
• Estructura d'alt nivell (Annex SL), comuna a totes les normes de sistemes de gestió: 4 Context de l'organització · 5 Lideratge · 6 Planificació · 7 Suport · 8 Operació · 9 Avaluació de l'acompliment · 10 Millora.
• Cicle PDCA (Plan, Do, Check, Act) de Deming: Planificar, Fer, Verificar, Actuar.
• Trilogia de Juran: els tres processos universals de la gestió de la qualitat són planificació de la qualitat, control de la qualitat i millora de la qualitat. L'enfocament projecte a projecte és de la millora —la millora s'assoleix projecte rere projecte—, no una cadena que uneixi els tres processos, encara que l'opció correcta d'algun examen ho enunciï com «un principi bàsic centrat en la successió de projectes». La distractora habitual hi cola la «implantació» en lloc d'un dels tres.

2. ISO/IEC 20000

Què és la ISO: la ISO (International Organization for Standardization) és una organització internacional no governamental i independent, formada pels organismes nacionals de normalització que hi participen de manera voluntària —a Espanya, l'UNE (Una Norma Espanyola), l'Asociación Española de Normalización—. Publica normes de consens voluntàries: no són obligatòries per si mateixes, només quan una llei o un contracte les incorpora. La IEC (International Electrotechnical Commission) n'és la contrapart en electrotècnia; per això moltes normes es codifiquen conjuntament com ISO/IEC, cas de la 20000.

Què és la ISO/IEC 20000: la norma internacional per als sistemes de gestió de serveis (SGS/SMS, Service Management System). És l'única norma certificable en gestió de serveis TI —ITIL (Information Technology Infrastructure Library) és un marc de bones pràctiques, no és certificable per a organitzacions, només per a persones.

Història: neix de la britànica BS (British Standard) 15000 (2000); primera edició ISO el 2005; segona el 2011; tercera edició: ISO/IEC 20000-1:2018, que adopta l'estructura d'alt nivell.

Parts principals:

2.1 Estructura de la ISO/IEC 20000-1:2018

Segueix l'Annex SL:

• 4. Context de l'organització: comprensió de l'organització i del seu context, necessitats i expectatives de les parts interessades, abast del SGS, sistema de gestió de serveis.
• 5. Lideratge: lideratge i compromís, política de gestió de serveis, rols, responsabilitats i autoritats.
• 6. Planificació: accions per abordar riscos i oportunitats, objectius de gestió de serveis i planificació per assolir-los, pla de gestió de serveis.
• 7. Suport del sistema de gestió de serveis: recursos, competència, conscienciació, comunicació, informació documentada, coneixement.
• 8. Operació del sistema de gestió de serveis — el nucli, amb els processos agrupats:
• 8.2 Provisió del servei: catàleg de serveis, gestió dels actius, gestió de la configuració, gestió del nivell de servei, gestió de la demanda, gestió de la capacitat, gestió de la disponibilitat i continuïtat del servei, gestió de la seguretat de la informació.
• 8.3 Relació i acord: gestió de les relacions de negoci, gestió de proveïdors (interns i externs) i gestió de serveis prestats per parts externes.
• 8.4 Subministrament i pressupost dels serveis: pressupost i comptabilitat dels serveis.
• 8.5 Disseny, construcció i transició: gestió del canvi, disseny i transició de serveis nous o modificats, gestió de versions i desplegament.
• 8.6 Resolució i compliment: gestió d'incidents, gestió de peticions de servei, gestió de problemes.
• 8.7 Assegurament del servei: continuïtat, disponibilitat i seguretat.
• 9. Avaluació de l'acompliment: seguiment, mesura, anàlisi i avaluació; auditoria interna; revisió per la direcció; informes de servei.
• 10. Millora: no-conformitat i acció correctiva i millora contínua.

2.2 La millora contínua a la ISO/IEC 20000

Afirmació correcta que cauen a l'examen: la norma exigeix que l'organització determini i seleccioni oportunitats de millora, i estableixi criteris d'avaluació i priorització de les millores; les millores s'han de registrar, avaluar, aprovar, prioritzar, planificar, implementar, mesurar i informar. La millora contínua és un requisit del sistema de gestió, no una recomanació opcional, i s'aplica tant al SGS com als serveis.

Compte amb les distractores: la norma no diu que la millora contínua sigui responsabilitat exclusiva de la direcció, ni que només s'apliqui als processos i no als serveis, ni que requereixi una certificació anual.

2.3 Gestió de la disponibilitat a la ISO/IEC 20000

La norma exigeix determinar i documentar els requisits de disponibilitat i els objectius a partir de les necessitats de negoci, mesurar la disponibilitat dels serveis, investigar la indisponibilitat no planificada i emprendre les accions necessàries. La disponibilitat s'ha de monitorar i registrar, i els resultats s'han de comparar amb els objectius acordats. → tema 21.

2.4 Certificació

• Abast: l'organització defineix l'abast del SGS (serveis, ubicacions, clients). L'abast ha de ser defensable: no es pot certificar allò que es té subcontractat sense demostrar-ne el control (governança de les parts externes).
• Cicle: auditoria de certificació (fase 1 documental + fase 2 in situ), auditories de seguiment anuals i recertificació cada tres anys.
• Beneficis: credibilitat davant clients, marc de millora, alineació amb ITIL, i requisit habitual en plecs de contractació pública.

3. Relació entre ISO 20000, ITIL i altres marcs

Altres normes de la família: ISO/IEC 27001 (seguretat de la informació), ISO 22301 (continuïtat de negoci), ISO/IEC 19770 (gestió d'actius de programari), ISO/IEC 33000 (avaluació de processos, successora de la 15504/SPICE, Software Process Improvement and Capability dEtermination), ISO/IEC 12207 (cicle de vida del programari) i ISO/IEC 25010 (qualitat del producte programari) → tema 46.

Marcs de gestió de serveis digitals que sí que ho són: ITIL, ISO/IEC 20000, COBIT (Control Objectives for Information and Related Technologies), FitSM, MOF (Microsoft Operations Framework), USM (Unified Service Management), VeriSM. No ho són: PMBOK (Project Management Body of Knowledge: direcció de projectes), CMMI (Capability Maturity Model Integration: maduresa de processos de desenvolupament), TOGAF (The Open Group Architecture Framework: arquitectura empresarial), Scrum (marc de desenvolupament de producte) ni Six Sigma (millora de la qualitat). Aquesta és la pregunta «quin NO pot ser considerat un marc de treball de la gestió de serveis digitals».

4. La qualitat dels processos i dels productes

Principi que es pregunta literalment: la qualitat dels productes i serveis està altament influïda per la qualitat dels processos que els produeixen. D'aquí surten els models de maduresa de processos (CMMI, ISO/IEC 33000) i l'enfocament a processos de la ISO 9001.

Enfocament a processos: entendre i gestionar els processos interrelacionats com un sistema contribueix a l'eficàcia i eficiència en l'assoliment dels resultats previstos. Cada procés té entrades, transformació, sortides, propietari, indicadors i controls; el conjunt es representa al mapa de processos → tema 1.

Classificació habitual dels processos: estratègics, fonamentals o clau i de suport —les definicions de cadascuna, al mapa de processos del tema 1.

Auditories: internes (de primera part), de segona part (client sobre proveïdor) i de tercera part (organisme de certificació independent). Cal independència de l'auditor respecte de l'activitat auditada.

Claus d'examen

• SERVQUAL, la paraula al revés: la dimensió és elements tangibles; l'opció incorrecta la converteix en «intangibilitat» o «elements intangibles», el contrari exacte. Ha caigut igual els dos cops que s'ha preguntat, l'específic i la pràctica de 2021 (TS-TIC 2021, p. 26 i TS-TIC 2021, pràctica p. 26).
• «Pensament basat en risc» (ISO 9001) no és eliminar riscos ni auditar més sovint: és planificar accions per abordar riscos i oportunitats, la frase literal de l'Annex SL (TS-TIC 2025, pràctica p. 5).
• La responsabilitat de la direcció és «retre comptes de l'eficàcia del sistema», no una tasca operativa concreta com redactar manuals, auditar internament o controlar proveïdors, que es poden delegar (TS-TIC 2025, pràctica p. 6).
• El PDCA de la ISO 20000 s'aplica a un servei TI, no a un component tècnic aïllat —una base de dades, un programari, un maquinari— que en forma part (TS-TIC 2018, p. 64).
• Els set principis de la ISO 9001 no inclouen «enfocament al servei»: hi ha enfocament al client i enfocament a processos, que són els que es confonen amb «servei» (TS-TIC 2023, pràctica p. 18).

Per recordar

• ISO/IEC 20000-1 és l'única norma certificable de gestió de serveis TI; ITIL no és certificable per a organitzacions.
• La versió vigent és la 2018, amb estructura d'alt nivell (Annex SL): capítols 4 a 10.
• ISO 9001 certifica el sistema de gestió, no el producte; té set principis i pensament basat en el risc; la direcció ha de retre comptes de l'eficàcia del sistema.
• A la ISO 20000, la millora contínua és un requisit i s'aplica al SGS i als serveis; les millores s'han de registrar, avaluar, prioritzar, implementar i mesurar.
• La qualitat dels productes i serveis depèn de la qualitat dels processos que els produeixen.
• PMBOK, CMMI, TOGAF, Scrum i Six Sigma NO són marcs de gestió de serveis digitals.
• Recertificació cada tres anys, amb seguiments anuals.

Tema 14 · Gestió de serveis

Gestió de serveis TIC. Marc ITIL v4

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Gestió de serveis TIC. Marc ITIL v4: conceptes fonamentals, sistema de valor del servei i cadena de valor.

Avís d'edicions. El programa oficial demana ITIL v4, però la major part de les preguntes d'exàmens anteriors —14 de les 25 d'aquest tema, i n'hi ha de 2018, 2021, 2023 i 2025— està redactada sobre ITIL v3, amb el seu cicle de vida de cinc fases i les seves publicacions. Cal saber les dues.

1. Conceptes fonamentals d'ITIL 4

Gestió de serveis (service management): conjunt de capacitats organitzatives especialitzades per generar valor per als clients en forma de serveis. És la definició canònica d'ITIL i cau literalment. La paraula que la sosté és capacitats: no és una unitat organitzativa —això és una funció—, ni una seqüència d'activitats —això és un procés—, ni la direcció de projectes (§1.5). La disciplina que l'aplica a la informàtica s'anomena ITSM (Information Technology Service Management, gestió de serveis de TI), i ITIL n'és el marc de referència més estès.

ITIL no és una norma d'obligat compliment, sinó un marc de bones pràctiques: un conjunt de recomanacions que cada organització ha d'adaptar a les seves necessitats i particularitats, no a l'inrevés. És el principi conegut com «adopt and adapt» (adoptar i adaptar). ITIL no defineix cap «Core Rules» d'obligat compliment per certificar-se: la certificació és de persones, no d'organitzacions.

Origen: ITIL va néixer al Regne Unit a finals dels anys vuitanta, encarregat per la CCTA (Central Computer and Telecommunications Agency), l'agència informàtica del govern britànic, per millorar la qualitat dels seus serveis de TI. Ni va néixer als Estats Units ni és una metodologia.

No tots els marcs de referència fan el mateix, i el tribunal ho aprofita: ITIL i la norma ISO 20000 són marcs de gestió de serveis (→ tema 13), COBIT és de govern de la TI (→ tema 15) i el CMMI (Capability Maturity Model Integration) mesura la maduresa dels processos (→ tema 22). En canvi Scrum és un marc àgil de desenvolupament de programari, no un marc de gestió de serveis (→ tema 12).

1.1 Servei, valor, utilitat i garantia

• Servei: mitjà per possibilitar la cocreació de valor facilitant els resultats que els clients volen assolir, sense que el client hagi de gestionar costos i riscos específics.
• Valor: beneficis, utilitat i importància percebuts d'alguna cosa. El valor es cocrea entre proveïdor i consumidor: no el lliura el proveïdor tot sol.
• Cocreació (o coproducció) del valor: el consumidor hi aporta requisits, informació, decisions i temps, així que la relació de servei és cooperativa i no una simple compra. La conseqüència pràctica és que el valor sempre és percebut pel consumidor: no es pot fixar unilateralment ni es dedueix del cost d'implantació.
• Utilitat (utility): la funcionalitat oferta per satisfer una necessitat concreta; és el «què fa» (fit for purpose). Un servei té utilitat si millora l'acompliment o elimina restriccions.
• Garantia (warranty): l'assegurança que un producte o servei complirà els requisits acordats; és el «com de bé ho fa» (fit for use). Cobreix disponibilitat, capacitat, continuïtat i seguretat.
• Valor = utilitat + garantia. Calen totes dues: un servei amb funcionalitat però indisponible no aporta valor.
• Sortida (output) vs resultat (outcome): la sortida és un lliurable tangible; el resultat és el que el consumidor assoleix gràcies a la sortida.
• Cost i risc: el servei ha d'eliminar costos i riscos del consumidor i n'imposa d'altres.
• Conservar el valor: el valor lliurat es manté i no s'erosiona controlant les desviacions de rendiment respecte de l'acordat —és la garantia en acció—, i aprofitant els actius intangibles (coneixement, relacions, reputació) mitjançant l'eficiència i l'eficàcia operativa, que redueixen costos ocults i consoliden beneficis ocults. El desenvolupament de com es mesura i millora aquesta eficiència és matèria de la mesura i millora contínua.

1.2 Organitzacions i persones

• Proveïdor del servei, consumidor del servei —que es desglossa en client (defineix els requisits i és responsable dels resultats), usuari (fa servir el servei) i patrocinador (autoritza el pressupost)— i altres interessats.
• Relacions de servei: provisió del servei, consum del servei i gestió de la relació de servei.
• Producte: configuració de recursos de l'organització dissenyada per oferir valor a un consumidor.
• Oferta de servei: descripció d'un o més serveis dissenyats per atendre les necessitats d'un grup de consumidors; pot incloure béns, accés a recursos i accions de servei.

1.3 Les quatre dimensions de la gestió de serveis

Les quatre s'han de considerar totes per a cada servei; ignorar-ne una degrada el resultat:

1. Organitzacions i persones — estructura, cultura, competències, rols.
2. Informació i tecnologia — la informació que es gestiona i les tecnologies que la suporten.
3. Socis i proveïdors — relacions amb tercers, contractes, integració.
4. Fluxos de valor i processos — com s'organitzen les activitats per crear valor.

Al voltant hi actuen els factors PESTLE (polítics, econòmics, socials, tecnològics, legals i ambientals).

No s'han de confondre amb els set principis guia (§1.4): les dimensions diuen què s'ha de mirar en cada servei; els principis, com s'ha de decidir. Són quatre i set, i són llistes independents.

1.4 Els set principis guia

Principi guia: recomanació que guia l'organització en qualsevol circumstància, independentment dels canvis en els seus objectius, estratègies, tipus de treball o estructura de gestió. Són universals i perdurables, i apliquen a qualsevol iniciativa:

1. Enfocar-se en el valor.
2. Començar on ets (start where you are): no descartis el que ja existeix sense mesurar-ho.
3. Progressar iterativament amb retroalimentació.
4. Col·laborar i promoure la visibilitat.
5. Pensar i treballar de manera holística.
6. Mantenir-ho senzill i pràctic.
7. Optimitzar i automatitzar — optimitza primer, automatitza després.

1.5 Pràctica, procés i funció

Les tres paraules descriuen «una manera d'organitzar el treball» i no són sinònimes. Les dues primeres són, a més, els distractors amb què el tribunal construeix la pregunta de què és la gestió de serveis.

La diferència que importa: una pràctica és més ampla que un procés, perquè es descriu amb les quatre dimensions —hi entren les persones, la informació i la tecnologia, i els socis, no només les activitats—; un procés és només la seqüència d'activitats, i una funció, només qui les fa. Per això el service desk és una funció a v3 i una pràctica a ITIL 4 → tema 25.

2. SVS: el Sistema de Valor del Servei

Definició: descriu com tots els components i activitats de l'organització treballen conjuntament com un sistema per possibilitar la creació de valor. L'entrada és la demanda i les oportunitats; la sortida, el valor.

Components del SVS:

L'SVS ha de contrarestar els sitges (silos): la seva arquitectura està dissenyada perquè l'organització sigui flexible i adaptable.

SVS i cadena de valor no són el mateix, i confondre'ls és la trampa més barata del tema: el SVS és el sistema sencer —principis guia, governança, pràctiques i millora contínua incloses—, i la cadena de valor n'és un component, el model operatiu de sis activitats que hi ha al centre (§3).

I l'SVS no és el cicle de vida de v3: aquell eren cinc fases en ordre (§5.1) i aquest és un sistema sense seqüència. ITIL 4 va substituir l'un per l'altre.

3. La cadena de valor del servei

Definició: model operatiu que enumera les activitats clau necessàries per respondre a la demanda i facilitar la realització de valor mitjançant la creació i la gestió de productes i serveis. És el component central del SVS.

Sis activitats. No són una seqüència fixa: es combinen en fluxos de valor diferents segons l'escenari.

Flux de valor (value stream): sèrie de passos que una organització realitza per crear i lliurar productes i serveis als consumidors. Cada flux combina activitats de la cadena i pràctiques diferents.

Cadena i flux no són el mateix: la cadena és el model —les sis activitats disponibles, sempre les mateixes i per a tota l'organització—; el flux és un recorregut concret per aquest model per a un escenari determinat —donar d'alta un empleat, resoldre una incidència, publicar una versió—, i decideix quines activitats hi entren, amb quines pràctiques i en quin ordre. Una sola cadena de valor sosté molts fluxos de valor.

4. Les 34 pràctiques d'ITIL 4

Pràctica: conjunt de recursos organitzatius dissenyat per realitzar un treball o assolir un objectiu (§1.5). Substitueixen els 26 processos i les 4 funcions d'ITIL v3. Es divideixen en tres grups:

Pràctiques de gestió general (14): gestió de l'arquitectura, millora contínua, gestió de la seguretat de la informació, gestió del coneixement, mesura i informes, gestió del canvi organitzatiu, gestió de la cartera (portfolio), gestió de projectes, gestió de relacions, gestió de riscos, gestió financera del servei, gestió de l'estratègia, gestió de proveïdors, gestió del talent i de la força de treball.

Pràctiques de gestió del servei (17): gestió de la disponibilitat, anàlisi de negoci, gestió de la capacitat i el rendiment, gestió de canvis (Change enablement), gestió d'incidents, gestió d'actius de TI (Tecnologies de la Informació), monitoratge i gestió d'esdeveniments, gestió de problemes, gestió de versions (release), gestió del catàleg de serveis, gestió de la configuració del servei, gestió de la continuïtat del servei, disseny del servei, service desk, gestió de nivells de servei, gestió de peticions de servei, validació i proves del servei.

Pràctiques de gestió tècnica (3): gestió del desplegament, gestió d'infraestructura i plataformes, desenvolupament i gestió de programari.

Estructura d'una pràctica: propòsit, termes i conceptes, abast, PSF (Practice Success Factors, factors d'èxit de la pràctica), KPI (Key Performance Indicators, indicadors clau de rendiment), fluxos de valor i processos, organitzacions i persones, informació i tecnologia, socis i proveïdors.

5. ITIL v3: el que continua caient

5.1 El cicle de vida del servei

Cinc fases, en aquest ordre — és una pregunta literal habitual:

1. Estratègia del Servei (Service Strategy) → 2. Disseny del Servei (Service Design) → 3. Transició del Servei (Service Transition) → 4. Operació del Servei (Service Operation) → 5. Millora Contínua del Servei (Continual Service Improvement, CSI)

El nucli d'ITIL v3 es compon de cinc publicacions, una per fase, que proporcionen la guia necessària per a un enfocament integrat.

El disseny de les proves d'un servei té per objectiu assegurar que el servei nou o modificat compleix les especificacions de disseny i els requisits del negoci — no només detectar defectes tècnics.

5.2 Les quatre P del disseny del servei

Persones (People), Processos (Processes), Productes (Products, incloent-hi tecnologia i eines) i Socis (Partners).

Propòsit: assegurar que el disseny d'un servei consideri de manera integrada tots quatre elements, perquè un servei ben dissenyat tecnològicament però sense persones formades, sense processos definits o sense els socis adequats fracassarà. És l'expressió al disseny del pensament holístic.

5.3 Cartera i catàleg

• Cartera de serveis (Service Portfolio): tots els serveis del proveïdor, en tots els estats del cicle de vida — Service Pipeline (en concepció o desenvolupament), catàleg (actius) i serveis retirats.
• Catàleg de serveis: només els serveis actius, la part de la cartera visible per al client.
• Per això un servei nou entra per la cartera (al pipeline), no directament pel catàleg.

Aquí hi són perquè la gestió de la cartera de serveis és un procés de l'Estratègia i la gestió del catàleg ho és del Disseny (§5.1). El contingut del catàleg, les seves dues vistes i els acords de nivell de servei es desenvolupen al tema 20.

5.4 Recursos i capacitats

Actius del servei = recursos + capacitats.

• Recursos: entrades tangibles per a la producció — capital, infraestructura, aplicacions, informació, persones (com a nombre). Es compren.
• Capacitats: habilitats intangibles per coordinar, controlar i desplegar recursos — gestió, organització, processos, coneixement, persones (com a competència). Es desenvolupen amb el temps i són la font real de diferenciació.

La pregunta habitual: la diferència és que els recursos es poden adquirir mentre que les capacitats s'han de desenvolupar i són les que transformen els recursos en valor.

5.5 Millora contínua i mètriques

A v3 la millora contínua era una fase sencera del cicle de vida —la cinquena, el CSI— amb el seu procés de millora en 7 passos, el model CSI de sis preguntes i el cicle de Deming (PDCA) com a model de gestió de base. A ITIL 4 ja no hi ha cap fase: és una de les 34 pràctiques i, alhora, un dels cinc components del SVS.

Els set passos, el model, el PDCA i els indicadors amb què es mesura es desenvolupen al tema 22.

6. Governança

Segons ITIL 4, la governança és el mitjà pel qual una organització és dirigida i controlada. Té tres activitats: avaluar, dirigir i monitorar (coincidents amb el domini EDM, Evaluate, Direct, Monitor, de COBIT, Control Objectives for Information and Related Technologies). → tema 15.

Claus d'examen

• «Adopt and adapt»: la pregunta típica busca l'afirmació certa entre distractors sobre l'origen d'ITIL o sobre unes suposades «Core Rules» d'obligat compliment. L'única certa és que cal adaptar ITIL a l'organització, no al revés; els distractors diuen que va néixer als Estats Units (va ser al Regne Unit) i que les Core Rules obliguen a certificar-se (TS-TIC 2018, especific p. 45).
• Les cinc fases de v3, en ordre, són el que més cau d'aquest tema, i cau de tres maneres: com a ordre correcte (TS-TIC 2025, pràctica s2 p. 15), com a les cinc publicacions del nucli (TS-TIC 2018, pràctica s2 p. 27) i com a «quina NO n'és una» (TS-TIC 2023, especific p. 51). El distractor és sempre un nom inventat de fase — Implementació, Transformació, Explotació, Innovació, Arquitectura del Servei.
• «Què és la gestió del servei»: es demana la definició literal, i els tres distractors són sempre els mateixos — una unitat organitzativa (això és una funció), una seqüència d'accions (això és un procés) i la gestió de projectes (TS-TIC 2018, pràctica s2 p. 18).
• Utilitat i garantia és el parell canònic del valor, i els distractors són «funcionalitat» i «infraestructura» (TS-TIC 2018, pràctica s1 p. 13). També es demana com a suma dels dos, percebuda pel client (TS-TIC 2025, pràctica s2 p. 1).
• Conservar el valor ofert al client: la resposta correcta combina controlar desviacions de rendiment, aprofitar actius intangibles i eficiència/eficàcia operativa per reduir costos ocults i consolidar beneficis ocults — no incrementar pressupost ni personal (TS-TIC 2018, pràctica s1 p. 5).
• «Quin NO és un marc de gestió de serveis digitals»: entre CMMI, ITIL i COBIT, el que no hi encaixa és Scrum, que és un marc àgil de desenvolupament (TS-TIC 2023, especific p. 47).

Per recordar

• Gestió de serveis = conjunt de capacitats organitzatives especialitzades que generen valor en forma de serveis. Ni una unitat, ni un procés, ni gestió de projectes.
• Servei = mitjà per cocrear valor facilitant resultats sense que el client gestioni costos i riscos específics.
• Utilitat = adequació al propòsit (què fa); garantia = adequació a l'ús (disponibilitat, capacitat, continuïtat, seguretat). Valor = utilitat + garantia, i sempre percebut pel consumidor.
• Quatre dimensions (què mirar): organitzacions i persones · informació i tecnologia · socis i proveïdors · fluxos de valor i processos. Set principis guia (com decidir); recorda «optimitzar i automatitzar», en aquest ordre.
• Procés (26 a v3) ≠ funció (4 a v3) ≠ pràctica (34 a ITIL 4). El service desk és funció a v3 i pràctica a v4.
• SVS ≠ cadena de valor: el SVS és el sistema sencer i la cadena n'és un dels cinc components. I cadena ≠ flux: la cadena és el model de sis activitats, el flux un recorregut concret per elles.
• Cadena de valor (6 activitats): planificar, millorar, involucrar, dissenyar i transicionar, obtenir/construir, lliurar i donar suport. No és seqüencial.
• ITIL 4 té 34 pràctiques: 14 generals, 17 de servei, 3 tècniques.
• ITIL v3, ordre de les fases: Estratègia → Disseny → Transició → Operació → Millora Contínua. Cinc publicacions al nucli.
• Quatre P del disseny: Persones, Processos, Productes i Socis.
• Cartera de serveis = tots els serveis en tots els estats (pipeline + catàleg + retirats); el catàleg només els actius. Un servei nou entra per la cartera.
• Recursos es compren; capacitats es desenvolupen.

Tema 15 · Gestió de serveis

Governança en el marc ITIL v4

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Governança en el marc ITIL v4 (Governance).

1. Concepte

Governança (ITIL 4): el mitjà pel qual una organització és dirigida i controlada. És un component del Sistema de Valor del Servei i s'exerceix sobre totes les altres parts del sistema: principis guia, cadena de valor, pràctiques i millora contínua.

Governança ≠ gestió, i aquesta és la distinció que més cau:

2. Les tres activitats de governança

ITIL 4 adopta el model EDM (coincident amb COBIT):

• Avaluar (Evaluate): valorar contínuament l'organització, la seva estratègia, les carteres, les relacions amb altres parts i les necessitats i propostes de valor de les parts interessades.
• Dirigir (Direct): assignar responsabilitats i orientar la direcció, les polítiques i l'estratègia; establir prioritats i l'apetit al risc.
• Monitorar (Monitor): supervisar l'acompliment de l'organització i de les seves pràctiques, productes i serveis, i assegurar que s'ajusten a la direcció i a les polítiques establertes.

L'òrgan de govern és el responsable d'aquestes tres activitats i ha de retre comptes (accountable) del compliment de l'organització amb polítiques i regulacions externes.

3. Governança dins del Sistema de Valor del Servei

El SVS (Sistema de Valor del Servei) s'alimenta d'oportunitat i demanda i produeix valor. La governança hi actua de la manera següent:

• Sobre els principis guia: els incorpora a la cultura i vetlla perquè s'apliquin.
• Sobre la cadena de valor: aprova els fluxos de valor, els criteris de priorització i el model operatiu.
• Sobre les pràctiques: estableix quines pràctiques s'adopten, amb quin nivell de formalitat i quins KPI (Key Performance Indicators) les mesuren.
• Sobre la millora contínua: aprova la cartera de millores i assigna els recursos.

Mecanismes concrets: polítiques i estàndards corporatius, comitès (de direcció TIC, d'arquitectura, de canvis, de seguretat), quadres de comandament i informes a la direcció, auditories internes i externes, gestió de riscos i model de delegació d'autoritat (qui pot aprovar què, i fins a quin import o nivell de risc).

Rols de responsabilitat: ITIL assigna rols, no llocs de treball, i és un mecanisme més de governança perquè fixen qui respon de què. El service owner (propietari del servei) és accountable que la prestació del servei i el suport s'ajustin als requeriments acordats amb el client, d'extrem a extrem, encara que no en presti cap component directament. El process owner (propietari del procés) és accountable pel disseny i el rendiment d'un procés o pràctica. El product owner, incorporat des d'Agile, prioritza el backlog d'un producte segons el valor per al client. Els tres decideixen i responen; no executen — la línia que separa governança de gestió (§1).

Model organitzatiu: la governança aprova l'estructura del departament TIC, però ITIL no n'imposa cap ni la declara obligatòria. És un marc adaptable: l'organigrama depèn de la mida, el context i els objectius de cada organització —la dimensió Organitzacions i persones ho desenvolupa a ITIL v4: conceptes fonamentals—. No hi ha, doncs, un organigrama perfecte ni una separació obligatòria entre àrees com Infraestructures, Telecomunicacions o Desenvolupament.

Errors habituals (i respostes falses típiques): confondre governança amb el comitè de canvis, situar la governança dins de la gestió d'operacions, o suposar que la governança executa processos. La governança no executa: dirigeix i controla.

4. Governança de la TI: marcs de referència

4.1 COBIT (ISACA)

COBIT 2019, publicat per l'ISACA (Information Systems Audit and Control Association), és el marc de referència de govern i gestió de la informació i la tecnologia empresarial.

• Separa explícitament governança (domini EDM — Evaluate, Direct and Monitor, amb 5 objectius) de gestió (4 dominis):
• APO — Align, Plan and Organise
• BAI — Build, Acquire and Implement
• DSS — Deliver, Service and Support
• MEA — Monitor, Evaluate and Assess
• 40 objectius de govern i gestió en total.
• Sis principis del sistema de govern: proporcionar valor a les parts interessades; enfocament holístic; sistema de govern dinàmic; govern diferenciat de la gestió; adaptat a les necessitats de l'empresa; sistema de govern d'extrem a extrem.
• Cascada d'objectius: necessitats de les parts interessades → objectius de l'empresa → objectius d'alineació → objectius de govern i gestió.
• Set components del sistema de govern: processos; estructures organitzatives; principis, polítiques i marcs; informació; cultura, ètica i comportament; persones, habilitats i competències; serveis, infraestructura i aplicacions.
• Factors de disseny i àrees de focus permeten adaptar-lo.

4.2 ISO/IEC 38500

Norma internacional de govern corporatiu de la TI (Tecnologies de la Informació), elaborada per ISO i l'IEC (International Electrotechnical Commission). Estableix sis principis: responsabilitat, estratègia, adquisició, acompliment, conformitat i comportament humà, i el mateix model d'avaluar, dirigir i monitorar.

4.3 Altres

• ISO/IEC 20000 exigeix governança dels processos operats per altres parts (apartat 8.2.3): quan un procés el fa un tercer, l'organització ha de mantenir-ne la responsabilitat i demostrar-ne el control.
• Model de tres línies (antic «tres línies de defensa»): 1a línia gestió operativa i controls; 2a línia funcions de risc i compliment; 3a línia auditoria interna independent.

5. La governança al sector públic i a l'Ajuntament

• La governança TIC pública té una capa afegida: legalitat, transparència i retiment de comptes. Els òrgans de control (Intervenció, Secretaria, Sindicatura de Comptes) formen part del sistema.
• Marc normatiu: Llei 19/2013 i Llei 19/2014 (bon govern i transparència), ENS (govern de la seguretat, amb la política de seguretat aprovada per l'òrgan competent i el Responsable de la Informació, del Servei, de la Seguretat i del Sistema), LCSP (govern de la contractació) i RGPD amb el DPD (Delegat de Protecció de Dades).
• A l'Ajuntament de Barcelona: la direcció política correspon als òrgans de govern municipal; la Gerència Municipal i les gerències sectorials i de districte exerceixen la direcció executiva; el BIT (Barcelona Innovació i Tecnologia) és l'operador tecnològic. Instruments de governança TIC: Pla Director de Transformació Digital, comitès de direcció TIC, govern de la demanda, PMO (Project Management Office), comitè d'arquitectura i el marc de principis de la Mesura de digitalització oberta amb els Barcelona Digital Standards.
• El Comitè d'Ètica i la Bústia Ètica (Normes de la Bústia Ètica) formen part del sistema de governança en la vessant d'integritat → tema comú 18.

6. Governança i compliance

• Compliance: conjunt de mesures per assegurar que l'organització compleix la normativa que li és aplicable i les seves pròpies regles internes.
• Programa de compliance ≠ sistema de gestió de compliance: el programa és el conjunt de mesures, polítiques i controls que s'apliquen; el sistema de gestió (per exemple, segons ISO 37301) és l'estructura organitzativa completa i certificable —amb política, òrgan de compliance, avaluació de riscos, controls, formació, canal de denúncies, seguiment, auditoria i millora contínua— dins de la qual s'insereix el programa. La diferència, doncs, és d'abast i formalització: el sistema de gestió és cíclic, documentat i auditable; el programa pot ser puntual.
• Bones pràctiques en la gestió dels codis ètics: que s'elaborin amb la participació dels treballadors i les treballadores —no només des de la direcció—, que estiguin aprovats per l'òrgan de govern, difosos i formats a tota l'organització, aplicables a tercers (proveïdors), amb un canal de consultes i d'alertes, amb un òrgan independent que els interpreti, i revisats periòdicament. El codi ha de ser viu i supervisat, no un document publicat i oblidat.
• Canal d'alertes o canal de denúncies: permet comunicar de manera confidencial —o anònima— incompliments normatius o del codi ètic, amb garantia d'indemnitat per a qui informa de bona fe i prohibició de represàlies. És obligatori des de la Directiva (UE, Unió Europea) 2019/1937 i la Llei 2/2023. La seva funció no és substituir la inspecció ni servir de bústia de suggeriments: és detectar i permetre investigar irregularitats i, amb això, prevenir-les.
• ISO 37001 (antisuborn) i ISO 37301 (compliance) són les normes certificables de referència.

Claus d'examen

• «Obligatòriament» és la paraula trampa: cap enunciat sobre l'organigrama del departament TIC amb aquest to té resposta certa, perquè ITIL no imposa cap estructura —ni departaments separats, ni disjunció entre desenvolupament i operacions, ni prohibició d'àrees transversals. La resposta correcta sol ser la que diu que no hi ha organigrama perfecte (TS-TIC 2018, p. 36).
• El service owner respon del servei sencer davant el client, d'extrem a extrem: no és cap de projecte, no resol incidències en primera línia i no fa de tècnic. Els distractors solen confondre'l amb rols operatius o de projecte (TS-TIC 2018 pràctica, supòsit 1, p. 19).
• En els codis ètics, la bona pràctica que sol distingir-se dels distractors és elaborar-los amb participació de treballadors i treballadores; els distractors solen ser el contrari: redactar-los només des de dalt, fer-los inalterables o limitar-los als alts càrrecs (TS-TIC 2025, p. 30).

Per recordar

• Governança = dirigir i controlar; gestió = executar. La governança respon què i per què; la gestió, com.
• Les tres activitats de govern són avaluar, dirigir i monitorar (EDM).
• COBIT 2019: EDM de govern + APO, BAI, DSS, MEA de gestió; 40 objectius, 6 principis, 7 components, cascada d'objectius.
• ISO/IEC 38500: sis principis — responsabilitat, estratègia, adquisició, acompliment, conformitat, comportament humà.
• Quan un procés l'opera un tercer, la responsabilitat i el control continuen sent de l'organització.
• Programa de compliance = conjunt de mesures; sistema de gestió de compliance = estructura completa, cíclica, documentada i certificable.
• El canal d'alertes serveix per detectar irregularitats de manera confidencial i sense represàlies.

Tema 16 · Gestió de serveis

Gestió de la relació amb els usuaris interns. BRM

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Gestió de la relació amb els usuaris interns. Business Relationship Management (BRM). Gestió d'expectatives.

1. Què és el BRM

Business Relationship Management és la pràctica —gestió de relacions a ITIL 4, gestió de relacions amb el negoci a ITIL v3— que estableix i cultiva els vincles entre l'organització i els seus interessats a nivell estratègic i tàctic.

Propòsit (ITIL 4): identificar les necessitats dels interessats i assegurar que el proveïdor de serveis les satisfà adequadament, prioritzant els serveis i les millores segons el valor que aporten al negoci.

Objectius d'ITIL v3 per al procés BRM:

• Establir i mantenir una relació de negoci entre el proveïdor de serveis i el client, basada en la comprensió del client i de les seves necessitats de negoci.
• Identificar les necessitats del client i assegurar que el proveïdor és capaç de satisfer-les a mesura que canvien amb el temps i les circumstàncies.
• Assegurar alts nivells de satisfacció del client.
• Establir i mantenir una relació constructiva amb el client.
• Identificar canvis en l'entorn del client que puguin afectar el tipus, el nivell o l'ús dels serveis.
• Identificar tendències tecnològiques que puguin afectar els serveis.
• Establir i articular els requisits de negoci per a serveis nous o modificats.
• Assegurar-se que el proveïdor compleix les expectatives del client.
• Assegurar que es tracten adequadament les queixes i els elogis.

El BRM és estratègic i tàctic; no és operatiu. Aquesta és la confusió que els exàmens exploten més.

2. BRM, SLM i Service Desk: qui fa què

La gestió del nivell de servei —SLM (Service Level Management)— és la pràctica veïna amb què més es confon el BRM a examen: totes dues tracten amb el client, però a horitzons i amb artefactes diferents.

Els acords que formalitza l'SLM i el catàleg que els conté es desenvolupen a Catàleg de serveis TIC i acords de nivell de servei; aquí n'hi ha prou amb saber que el BRM gestiona l'expectativa i l'SLA en fa el compromís escrit.

Client, usuari i ciutadà: el client defineix els requisits i és responsable dels resultats del consum del servei —a l'Administració, la gerència o el departament demandant, que és qui assigna el pressupost—; l'usuari intern és qui utilitza el servei en el dia a dia —l'empleat públic, el tècnic, el comandament— i gairebé mai és qui paga: el pressupost el gestiona el client mitjançant el govern de la demanda (→ Gestió de la demanda TIC, que capta i prioritza la necessitat que el BRM ha ajudat a identificar). El ciutadà, finalment, és l'usuari final dels serveis públics que l'Administració presta a través de les TIC, no l'interlocutor directe del BRM.

El BRM també es distingeix de la gestió d'interessades de projecte (PMBOK v7: gestió d'interessades i comunicació estratègica): aquella s'acota a un projecte, amb principi i fi; el BRM és una relació permanent amb la mateixa estructura de negoci, independent de qualsevol projecte concret.

3. Activitats del BRM

1. Coneixement del negoci: entendre els processos, els objectius i el llenguatge de l'àrea client. Un BRM que no entén el negoci no pot traduir necessitats.
2. Captació i qualificació de la demanda: recollir peticions estratègiques, distingir necessitat real de solució preconcebuda, i canalitzar-les cap a la gestió de la demanda i la cartera → tema 17.
3. Definició i articulació dels requisits de negoci per a serveis nous o modificats, que després alimenten el disseny.
4. Gestió de la cartera de clients i del portafoli d'acords.
5. Mesura de la satisfacció: enquestes periòdiques (CSAT), NPS, enquestes post-incident, panells d'usuaris.
6. Gestió de queixes i elogis: canalitzar-les, analitzar-ne les causes i tancar el cicle amb el client.
7. Reunions periòdiques de servei amb el client i informes de valor, no només d'activitat.
8. Gestió d'expectatives (secció següent).
9. Comunicació proactiva dels canvis, incidències majors i evolucions previstes.

Rols: el Business Relationship Manager és el punt de contacte únic de nivell tàctic-estratègic amb una àrea de negoci. A les organitzacions grans hi ha un BRM per gerència o àmbit.

Maduresa de la relació: fora d'ITIL, el BRM Institute —que publica el seu propi cos de coneixement, el BRMBoK (Business Relationship Management Body of Knowledge)— classifica la relació entre proveïdor i negoci en sis nivells de maduresa, del 0 (Ad Hoc) al 5 (Strategic Partner, soci estratègic), passant per estadis intermedis com el 3 (Service Provider, proveïdor de servei, on la innovació encara és un repte) i el 4 (Trusted Advisor, assessor de confiança, amb pensament estratègic compartit). És una escala per distingir «fer tasques de BRM» de «tenir una relació BRM madura», no un estàndard ITIL. En la mateixa línia, COBIT (Control Objectives for Information and Related Technologies) 2019, d'ISACA (Information Systems Audit and Control Association), tracta la matèria a l'objectiu de gestió número 08 del domini APO (Align, Plan and Organise) —Managed Relationships, relacions gestionades—, domini ja vist a Governança en el marc ITIL v4.

4. La gestió d'expectatives

Expectativa: allò que el client creu que rebrà, que no sempre coincideix ni amb el que s'ha acordat ni amb el que és tècnicament possible.

La qualitat percebuda = percepció − expectativa. Es pot millorar per dues vies: elevant la percepció (millor servei) o ajustant l'expectativa (comunicació honesta). Ignorar la segona porta a clients insatisfets amb serveis que compleixen l'SLA.

Model de bretxes (GAP model) de Parasuraman, Zeithaml i Berry — cinc bretxes:

1. Entre les expectatives del client i la percepció que en té la direcció.
2. Entre la percepció de la direcció i les especificacions de qualitat del servei.
3. Entre les especificacions i el servei realment lliurat.
4. Entre el servei lliurat i la comunicació externa al client (promeses).
5. Bretxa del client: entre el servei esperat i el servei percebut — és la suma de les anteriors.

Pràctiques per gestionar expectatives:

• Acordar-les per escrit: l'SLA és l'instrument formal. El que no és a l'acord, no és compromès.
• Comunicar aviat i sovint, especialment les males notícies. Un retard comunicat a temps es gestiona; un retard descobert pel client destrueix confiança.
• No sobrepromentre: és preferible prometre menys i lliurar més que al revés.
• Explicar les restriccions: pressupost, contractació, dependències, prioritats de la cartera.
• Fer visible el valor lliurat amb informes comprensibles per al negoci, no amb mètriques tècniques.
• Tancar el cicle: després de cada lliurament o incident important, verificar la satisfacció.
• Educar el client sobre el catàleg, els canals i els temps de resposta compromesos.

Senyals d'alerta: peticions que arriben pel canal informal saltant-se el procés, escalats freqüents a la direcció, discrepància entre els indicadors d'SLA (verds) i la satisfacció (baixa), i clients que munten pel seu compte «TI (Tecnologies de la Informació) a l'ombra» (shadow IT).

5. Instruments de mesura

• CSAT (Customer Satisfaction Score): satisfacció puntual sobre una interacció, típicament d'1 a 5.
• NPS (Net Promoter Score): «amb quina probabilitat recomanaries…?» de 0 a 10; promotors (9-10) − detractors (0-6), en percentatge. Va de −100 a +100.
• CES (Customer Effort Score): esforç que ha hagut de fer l'usuari.
• SLAM (Service Level Agreement Monitoring): quadre —el «SLAM chart»— de compliment dels objectius de nivell de servei per període, amb codi de colors.
• Enquestes de servei periòdiques i entrevistes qualitatives amb els clients clau.

Compte amb el «paradigma de la sandvitxeria»: complir tots els SLA i tenir clients insatisfets vol dir que els indicadors mesuren el que és fàcil de mesurar, no el que importa al negoci. La resposta és revisar els acords amb el client, no ajustar l'indicador.

6. El BRM al sector públic

• El «client» és una gerència, districte o àrea municipal; l'«usuari» és l'empleat públic i, en darrer terme, la ciutadania.
• La relació no es regeix per un contracte comercial sinó per encàrrecs, convenis i el pressupost municipal, amb el govern de la demanda com a mecanisme d'assignació.
• El valor no és el benefici sinó la missió pública: qualitat del servei al ciutadà, equitat, transparència i compliment normatiu.
• A l'Ajuntament de Barcelona, el BIT (Barcelona Innovació i Tecnologia) exerceix el paper de proveïdor intern i manté interlocutors per gerència; els comitès de direcció TIC (Tecnologies de la Informació i la Comunicació) són l'espai formal de la relació.
• El catàleg de serveis i les cartes de servei són els instruments que fan explícit el compromís davant l'usuari i el ciutadà.

Per recordar

• El BRM és estratègic i tàctic, tracta amb el client, i s'ocupa de necessitats de negoci i valor. El SLM és tàctic i tracta d'acords; el Service Desk és operatiu i tracta amb l'usuari.
• A ITIL v3 el BRM pertany a la fase d'Estratègia del Servei.
• Entre els objectius del BRM hi ha identificar canvis en l'entorn del client i tendències tecnològiques que puguin afectar els serveis, i tractar queixes i elogis.
• Qualitat percebuda = percepció − expectativa.
• Model de bretxes: cinc bretxes, i la del client és la suma de les altres quatre.
• Prometre menys i lliurar més; comunicar aviat, especialment les males notícies.
• NPS = % promotors − % detractors; CSAT mesura una interacció concreta.

Tema 17 · Gestió de serveis

Gestió de la demanda TIC

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Gestió de la demanda TIC. Models de govern de la demanda. Relació TIC-negoci i alineació estratègica en ITIL v4.

1. Concepte de demanda

Demanda (ITIL (Information Technology Infrastructure Library) 4): entrada al sistema de valor del servei, procedent dels consumidors interns i externs, que consisteix en la necessitat o el desig de productes i serveis.

Gestió de la demanda (ITIL v3, fase d'Estratègia del Servei): comprendre, anticipar i influir en la demanda de serveis per part dels clients, i, en cooperació amb la gestió de la capacitat, assegurar que el proveïdor té la capacitat suficient per satisfer-la.

Dos vessants:

• Demanda estratègica: quins serveis nous o evolucions calen. Alimenta la cartera de serveis i el pla director.
• Demanda operativa: volum de transaccions, usuaris concurrents, tiquets, càrrega de treball. Alimenta la gestió de la capacitat.

Conceptes clau d'ITIL v3:

• Patró d'activitat de negoci (PBA — Pattern of Business Activity): perfil de la càrrega de treball que genera un procés de negoci (freqüència, volum, ubicació, durada). És el pont entre la demanda del negoci i la capacitat tècnica.
• Perfil d'usuari (UP — User Profile): caracterització d'un tipus d'usuari o rol pels seus patrons d'activitat.
• Paquet de nivell de servei (SLP — Service Level Package): nivell definit d'utilitat i garantia per a un paquet de servei, associat a uns PBA concrets.

Tècniques per influir en la demanda: preus diferenciats (facturació interna més cara en hores punta), restriccions tècniques (quotes, límits), incentius (finestres de manteniment, càrrega diferida), campanyes i comunicació, i autoservei per desviar demanda del Service Desk.

2. Models de govern de la demanda

El govern de la demanda és el mecanisme que decideix quines peticions s'atenen, en quin ordre i amb quins recursos. Sense ell, la capacitat s'assigna per pressió, per urgència aparent o per proximitat jeràrquica.

Elements d'un model de govern de la demanda:

1. Canal únic d'entrada: totes les peticions entren pel mateix lloc i es registren. El que no entra pel canal, no existeix.
2. Classificació: incident, petició de servei, canvi menor, evolutiu, projecte nou, obligació normativa.
3. Qualificació: anàlisi de la necessitat real, dimensionament de gruix, identificació d'alternatives i de solucions ja existents al catàleg.
4. Criteris de priorització explícits i publicats: valor per al negoci, alineació estratègica, obligació legal, risc de no fer-ho, cost, dependències, disponibilitat de capacitat.
5. Òrgans de decisió: comitè de demanda o comitè de direcció TIC, amb representació del negoci i de TIC, i una cadència fixa de reunions.
6. Capacitat disponible declarada: la priorització només té sentit si es coneix la capacitat real; en cas contrari es prioritza sobre un pastís infinit.
7. Transparència: estat de cada petició visible per al sol·licitant.
8. Mesura: temps d'espera, taxa d'aprovació, valor lliurat, demanda no atesa.

La captació inicial de la demanda estratègica sol fer-la el BRM (→ Gestió de la relació amb els usuaris interns. BRM): identifica la necessitat amb el negoci i l'ajuda a qualificar-la abans que entri pel canal formal. El procés que ve després —classificar, prioritzar i aprovar— és el que es descriu aquí:

Models organitzatius:

Instruments de priorització: matriu valor–esforç, puntuació ponderada multicriteri, MoSCoW, WSJF (Weighted Shortest Job First — cost of delay dividit per la mida del treball), cost of delay, buckets de capacitat (percentatges preassignats a manteniment correctiu, obligacions normatives, evolutius i innovació).

Assignació de capacitat típica: reservar un percentatge fix per a manteniment i correctius, un altre per a compliment normatiu (que no es prioritza: és obligatori) i deixar el marge restant a la priorització de valor. Aquesta reserva evita que l'urgent devori l'important.

3. Relació TIC-negoci i alineació estratègica

3.1 Alineació

Alineació estratègica: grau en què els objectius, l'estructura i els recursos de TIC donen suport i habiliten els objectius de l'organització. Models → tema 1 (SAM (Strategic Alignment Model) de Henderson i Venkatraman, cascada d'objectius de COBIT (Control Objectives for Information and Related Technologies), Balanced Scorecard de TI (Tecnologies de la Informació)).

Símptomes de desalineació: cartera TIC plena de projectes que ningú no reclama, àrees que compren solucions pel seu compte (shadow IT), pressupost consumit en manteniment sense marge per a evolució, indicadors tècnics en verd amb negoci insatisfet.

3.2 Com ho tracta ITIL 4

• L'alineació no és un procés independent: està repartida entre el Sistema de Valor del Servei (governança + principi «enfocar-se en el valor»), l'activitat de la cadena de valor Involucrar (Engage) i les pràctiques de gestió de l'estratègia, gestió de la cartera, gestió de relacions i anàlisi de negoci.
• Cocreació de valor: el proveïdor no «lliura valor», el cocrea amb el consumidor. Això implica que la demanda no és una llista de comandes sinó un diàleg.
• Consum, provisió i gestió de la relació són els tres components de la relació de servei.
• El principi guia «enfocar-se en el valor» obliga a preguntar, davant de cada petició: qui és el consumidor, quin resultat busca i com sabrem que l'hem aconseguit.

3.3 Pràctiques implicades

• Gestió de la cartera (portfolio management): assegura que l'organització té la combinació correcta de programes, projectes, productes i serveis per executar l'estratègia dins de les restriccions de finançament i recursos.
• Anàlisi de negoci (business analysis): analitza el negoci o algun dels seus elements, defineix les necessitats i recomana solucions que aportin valor.
• Gestió de l'estratègia: formula els objectius i com assolir-los.
• Gestió de relacions → tema 16.
• Gestió financera del servei → tema 27.

4. La demanda no governada (shadow IT)

Shadow IT (Information Technology): maquinari, programari o serveis —sovint SaaS al núvol, contractats amb targeta corporativa— que una àrea de negoci adquireix, contracta o posa en marxa sense passar pel canal de demanda ni pel coneixement de l'àrea TIC.

No és un acte de rebel·lia: és el símptoma d'un govern de la demanda que falla. Apareix quan el canal oficial és lent (terminis de contractació llargs, cua de peticions sense resposta), quan la resposta és un «no» sense alternativa, quan el catàleg de serveis no cobreix la necessitat, o quan un autoservei improvisat —una eina gratuïta, un SaaS pagat amb la targeta pròpia— és més ràpid que demanar-ho pel canal formal. La demanda que no troba cauce no desapareix: es desvia.

Riscos:

• Seguretat: sistemes fora del perímetre gestionat, sense pedaços ni monitoratge, fora de l'abast de l'ENS.
• Protecció de dades: dades personals tractades en serveis mai avaluats, sense encàrrec de tractament ni anàlisi de risc, amb risc d'incompliment del RGPD.
• Cost duplicat: diverses àrees paguen eines diferents per a la mateixa necessitat, sense economia d'escala ni negociació centralitzada.
• Dependència i fragilitat: quan la persona que ho va contractar marxa, ningú no en té el control ni el coneixement, i no hi ha pla de continuïtat ni suport formal.
• Pèrdua de visió de cartera: el comitè de demanda prioritza sobre una part de la realitat, no sobre tota.

Com es recondueix: no es combat prohibint —això només l'amaga—, es recondueix absorbint-la: un canal ràpid per a peticions de baix risc i baix cost, un catàleg ampliat amb autoservei governat, i plataformes de baix codi corporatives i catalogades (→ Low-code i no-code, on precisament l'ús no governat d'aquestes mateixes eines és avui una de les vies més esteses de shadow IT). Una auditoria periòdica de contractació i de trànsit de xarxa és el mecanisme per fer-la visible.

5. De la demanda a la capacitat

La demanda i la capacitat són les dues cares del mateix problema:

Demanda de negoci (PBA)  →  Càrrega de treball  →  Requisits de capacitat
                                                  ↕
                        Capacitat disponible (recursos, serveis, components)

Si la demanda supera la capacitat: es prioritza, s'amplia la capacitat (cost) o s'influeix en la demanda (modulació). Si la capacitat supera la demanda de manera sostinguda, hi ha sobredimensionament i malbaratament de recursos. → tema 21.

Al núvol la relació canvia: l'elasticitat permet ajustar la capacitat a la demanda gairebé en temps real, i el problema es desplaça de la planificació de capacitat al control de la despesa (FinOps) → temes 59 i 27.

6. El govern de la demanda a l'Ajuntament de Barcelona

• Les àrees, gerències i districtes generen demanda; el BIT (Barcelona Innovació i Tecnologia) l'ha de qualificar, dimensionar i executar amb la capacitat contractada.
• El model és federat: hi ha interlocutors del BIT per àmbit, criteris corporatius comuns i comitès on es prioritza.
• Restriccions específiques: el pressupost és anual, la contractació té terminis llargs i una part de la demanda és obligació normativa (accessibilitat, ENS, protecció de dades, interoperabilitat) i, per tant, no priorizable.
• La Mesura de digitalització oberta hi afegeix criteris de decisió: preferència pel programari lliure, per la reutilització (Llei 40/2015, art. 158: cal consultar el directori d'aplicacions abans d'adquirir o desenvolupar) i per solucions que preservin la sobirania de les dades. Quan una àrea salta aquest pas i es contracta l'aplicació pel seu compte, és la variant local del shadow IT (→ apartat 4).
• El marc Scrum@IMI (Institut Municipal d'Informàtica, nom previ del BIT) determina com s'executa la demanda un cop prioritzada → tema 12.

Per recordar

• Gestió de la demanda: comprendre, anticipar i influir en la demanda, i assegurar la capacitat en cooperació amb la gestió de la capacitat. És de la fase d'Estratègia del Servei.
• PBA (patró d'activitat de negoci) = pont entre la demanda de negoci i la capacitat tècnica; UP = perfil d'usuari.
• Es pot influir en la demanda amb preus, restriccions tècniques, incentius i autoservei.
• Un model de govern de la demanda necessita canal únic, classificació, criteris explícits, òrgan de decisió, capacitat declarada i transparència.
• Models: centralitzat, descentralitzat i federat; l'habitual a les administracions grans és el federat.
• WSJF = cost del retard / mida del treball.
• El compliment normatiu no es prioritza: es reserva capacitat.
• A ITIL 4 l'alineació es reparteix entre governança, «Involucrar», gestió de l'estratègia, de la cartera, de relacions i anàlisi de negoci; el valor es cocrea.
• El shadow IT és la demanda que no ha trobat cauce: no es combat prohibint, es recondueix ampliant el catàleg i l'autoservei governat.
• La priorització d'inversions TIC és, a COBIT 2019, l'objectiu 05 del domini APO (Align, Plan and Organise) — Managed Portfolio; no es confon amb l'objectiu 01 del domini BAI (Build, Acquire and Implement) — Managed Programs, que gestiona l'execució dels programes ja aprovats, no la priorització.

Tema 18 · Gestió de serveis

Pràctiques ITIL v4 de suport al servei

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Pràctiques ITIL v4 de suport al servei: gestió d'incidents, problemes i sol·licituds de servei.

1. Els quatre conceptes que no s'han de barrejar

ITIL (Information Technology Infrastructure Library) defineix quatre conceptes de suport al servei que no s'han de confondre entre si:

Regla d'or: la gestió d'incidents restaura, la gestió de problemes investiga. Un incident es pot tancar sense conèixer-ne la causa; el problema es manté obert fins que es troba.

2. Gestió d'esdeveniments (monitoring and event management)

Propòsit: observar sistemàticament els serveis i els components del servei, i registrar i informar dels canvis d'estat identificats com a esdeveniments, identificant i prioritzant els d'infraestructura, servei, procés de negoci i seguretat de la informació, i establint la resposta adequada.

Tres tipus d'esdeveniment:

• Informatiu: no requereix acció; es registra per a auditoria o estadística (un lot que acaba correctament, un usuari que es connecta).
• Advertència (warning): un llindar s'apropa al límit; permet actuar abans que hi hagi impacte (disc al 80 %).
• Excepció (exception): s'ha vulnerat un llindar o s'ha produït una fallida; normalment genera un incident.

Monitoratge i gestió d'esdeveniments no són sinònims: el monitoratge comprova l'estat d'un component encara que no es produeixi cap esdeveniment —per exemple, verificar que un servidor respon dins del llindar acceptable—; la gestió d'esdeveniments és la que genera i detecta les notificacions significatives sobre aquest estat i en decideix la resposta.

Dos eixos del monitoratge, independents l'un de l'altre:

• Actiu vs. passiu (com es capta la dada): actiu, el sistema consulta periòdicament l'estat dels elements (polling) i fa proves sintètiques; passiu, els elements envien els seus esdeveniments a la consola (traps SNMP, syslog, agents) i el sistema els correlaciona.
• Reactiu vs. proactiu (per a què serveix): reactiu és el monitoratge dissenyat per sol·licitar o provocar una acció després d'un determinat tipus d'esdeveniment o fallida ja produïts —per exemple, reiniciar automàticament un dispositiu quan deixa de respondre—; proactiu busca patrons en una sèrie d'esdeveniments per anticipar-se a una fallada futura i actuar abans que es produeixi.

Un monitoratge pot ser alhora actiu i reactiu, o passiu i proactiu: els dos eixos es combinen lliurement, no en formen un de sol.

Correlació: motor que agrupa esdeveniments relacionats, elimina duplicats i decideix quan crear un incident. Sense correlació, una caiguda genera centenars d'alarmes.

SNMP (Simple Network Management Protocol): el protocol que fa possible el monitoratge passiu — els agents envien esdeveniments (traps) al gestor, l'NMS (Network Management System), que els interpreta contra la MIB (Management Information Base) de cada dispositiu. SNMPv3 hi afegeix autenticació i xifratge, absents a les versions 1 i 2c, que només tenen community strings en clar. El detall del protocol —gestor, agent, MIB i notificacions— el desenvolupa la plataforma d'observabilitat..

3. Gestió d'incidents

Propòsit: minimitzar l'impacte negatiu dels incidents restaurant l'operació normal del servei al més aviat possible.

3.1 Cicle de vida

Detecció → registre → categorització → priorització → diagnòstic inicial → escalat (si cal) → investigació i diagnòstic → resolució i recuperació → tancament.

• Registre: tots els incidents s'han de registrar, també els resolts al primer contacte i els detectats per monitoratge.
• Categorització: permet dirigir l'incident i, després, analitzar tendències; l'esquema de categories ha de ser compartit amb la gestió de problemes, perquè totes dues pràctiques treballin sobre les mateixes dades a l'hora de buscar patrons.
• Priorització: prioritat = impacte × urgència. L'impacte és l'abast del dany (nombre d'usuaris, criticitat del servei, pèrdua econòmica, reputació); la urgència és la rapidesa amb què el negoci necessita la resolució. La matriu típica és de 3×3 o 5×5 i dona prioritats de 1 (crítica) a 5 (planificació).
• Escalat: funcional (a un grup amb més coneixement tècnic — nivell 2, nivell 3, proveïdor) i jeràrquic (a la línia de comandament, per manca de recursos o per la gravetat). No són alternatius: sovint es fan tots dos.
• Model d'incident: procediment predefinit per a tipus d'incident coneguts i recurrents.
• Solució temporal (workaround): mitjà per reduir o eliminar l'impacte d'un incident sense resoldre'n la causa. Es documenta al registre d'errors coneguts.
• Tancament: només amb confirmació de l'usuari que el servei està restaurat, i amb la categorització i la solució documentades.

3.2 Incidents que afecten múltiples serveis i usuaris

La bona pràctica davant un incident d'alt impacte (incident major):

1. Declarar-lo formalment com a incident major i activar el procediment específic.
2. Assignar un gestor d'incident major i un equip dedicat, separat del flux ordinari.
3. Convocar una sala de crisi (war room) amb els especialistes necessaris.
4. Comunicar proactivament a usuaris i interessats: què passa, què n'està afectat, quina és l'estimació i quan hi haurà la propera actualització. La comunicació és periòdica i pautada, no a demanda.
5. Restaurar el servei com a prioritat absoluta, encara que sigui amb un workaround.
6. Registrar un problema associat per investigar la causa arrel després de la restauració.
7. Revisió post-incident (post-incident review) sense buscar culpables (blameless), amb accions de millora.

La resposta correcta a l'examen combina coordinació centralitzada, comunicació proactiva i restauració prioritària, obrint un problema per a la causa. Les distractores solen proposar tractar-lo com un incident ordinari, o aturar la restauració fins a trobar la causa — que és exactament el que no s'ha de fer.

3.3 Mètriques

Pròpies de la gestió d'incidents: MTTA (Mean Time To Acknowledge, temps mitjà d'acceptació — quant triga a agafar-se la incidència), MTBF (Mean Time Between Failures, temps mitjà entre fallides — la fiabilitat d'un component) i MTBSI (Mean Time Between Service Incidents, temps mitjà entre incidents de servei — si les fallides s'acumulen o s'espaien). La resta —FCR (First Contact Resolution), compliment de l'SLA (Service Level Agreement, acord de nivell de servei), incidents reoberts, backlog— són les mateixes mètriques del Service Desk (tema 25).

4. Gestió de problemes

Propòsit: reduir la probabilitat i l'impacte dels incidents identificant-ne les causes reals i potencials i gestionant els workarounds i els errors coneguts.

4.1 Les tres fases

1. Identificació del problema: anàlisi de tendències d'incidents, detecció de problemes recurrents, informació dels proveïdors, anàlisi d'incidents majors.
2. Control del problema: anàlisi del problema per determinar-ne la causa arrel i documentar solucions temporals i errors coneguts. Un error conegut és un problema que ha estat analitzat però no resolt: no és el mateix que el workaround —el workaround és l'acció que redueix l'impacte; l'error conegut és l'estat del problema, ja diagnosticat, que aquell workaround documenta. Pot haver-hi workaround sense diagnòstic (davant un incident aïllat); no hi ha error conegut sense diagnòstic.
3. Control de l'error: gestionar els errors coneguts, reavaluar-ne l'impacte i, quan es justifiqui, promoure una sol·licitud de canvi per a la solució definitiva.

4.2 Reactiva i proactiva

• Gestió de problemes reactiva: parteix d'incidents ja ocorreguts.
• Gestió de problemes proactiva: analitza dades i tendències per evitar incidents futurs. És on hi ha el valor real de la pràctica.

Un cop adreçada l'obertura de problemes amb un procediment clar —equips formats i eines adaptades als nous procediments—, el pas que cal abordar és implementar-lo de manera regular: analitzar les incidències i problemes per identificar tendències, no aturar-se ni parlar encara de la imputació de costos, que és prematur. És l'efecte esperat de fer-ho bé: un cop redreçada la situació, fent-ne el seguiment corresponent, el nombre d'incidències repetitives es reduirà.

4.3 Tècniques d'anàlisi de causa arrel

No totes serveixen per al mateix cas: els cinc perquès funcionen quan la cadena de causes és lineal i cal arribar-hi de pressa; el diagrama d'Ishikawa (espina de peix), quan les causes possibles s'agrupen per categories (persones, procés, tecnologia...); l'anàlisi de Pareto, quan cal prioritzar entre moltes causes candidates i atacar primer les que més pesen; i l'aïllament per bisecció, quan el sistema es pot dividir per parts i descartar-ne la meitat a cada pas. Menys freqüents: l'anàlisi cronològica, la de Kepner-Tregoe, l'FTA (Fault Tree Analysis, arbre de fallides) i l'FMEA (Failure Mode and Effects Analysis, anàlisi de modes de fallida i efectes).

Davant d'incidències recurrents, la pràctica correcta és obrir un problema i fer anàlisi de causa arrel, no seguir resolent els incidents un per un. Aquesta és la pregunta literal de l'examen.

Relació amb la gestió del coneixement: cada workaround i cada error conegut alimenta la KEDB (Known Error Database, base de dades d'errors coneguts) i el SKMS (Service Knowledge Management System, sistema de gestió del coneixement), i redueix el temps de resolució dels incidents futurs.

5. Gestió de peticions de servei

Propòsit: donar suport a la qualitat acordada del servei gestionant totes les peticions de servei predefinides i iniciades per l'usuari d'una manera efectiva i amable.

Característiques:

• Les peticions són part de la prestació normal del servei: no són incidents, no hi ha degradació.
• Han d'estar estandarditzades i automatitzades tant com sigui possible, amb fluxos de treball predefinits i, si escau, aprovacions i autoritzacions.
• Es publiquen al catàleg de serveis amb els seus temps de lliurament compromesos.
• Es beneficien de l'autoservei: portal amb formularis, aprovació automàtica i provisió automatitzada.
• Exemples: alta d'usuari, sol·licitud d'accés, petició d'un equip, instal·lació d'un programari estàndard, canvi de contrasenya, sol·licitud d'informació, reserva d'una sala.

Peticions vs canvis estàndard: el que l'usuari viu com una petició de servei, per dins pot tramitar-se com un canvi estàndard —preautoritzat, de risc baix— si toca un element de configuració (instal·lar programari, obrir un port); si no en toca cap (una consulta, una reserva), es queda en petició. El detall dels tipus de canvi és al tema 19.

6. Model integrat de suport

Nivells de suport: nivell 1 (Service Desk, resolució al primer contacte), nivell 2 (especialistes per àmbit), nivell 3 (experts, desenvolupament, arquitectura) i nivell 4 (proveïdors i fabricants). El Service Desk manté la titularitat de l'incident encara que l'escali: és el responsable davant l'usuari fins al tancament. → tema 25.

Gestió del coneixement: la pràctica que manté i millora l'ús efectiu, eficient i convenient de la informació i el coneixement a tota l'organització. SKMS i KEDB en són els repositoris.

Front a una fusió de departaments —dos edificis o organitzacions que s'integren—, la bona pràctica és centralitzar, no duplicar: establir un únic Service Desk sota un únic responsable, i nomenar un únic responsable tècnic central per als equips de Suport Tècnic dels dos edificis, en lloc de mantenir estructures separades per ubicació o externalitzar-ho tot per evitar la complexitat.

Per sostenir una operació 24×7, cal també assignar responsables de torn que es facin càrrec de la cobertura contínua a cada franja horària —no n'hi ha prou amb centralitzar la titularitat si ningú respon fora d'horari—. És un canvi organitzatiu diferent d'acotar un rol a la integració puntual (un gestor de problemes només per als incidents de la fusió) o de traslladar la responsabilitat operativa fora de l'equip (superusuaris externs, o canviar de marc de treball sencer per un problema puntual d'organització).

7. L'Operació del Servei: fase en ITIL v3, sense fase en ITIL v4

7.1 El domini de l'Operació del Servei (ITIL v3)

ITIL v3 organitza la gestió del servei, com a metodologia, en cinc fases del cicle de vida: Estratègia, Disseny, Transició, Operació i Millora Contínua del Servei. Cada un dels processos pertany a una fase concreta, i en aquest context és fonamental saber a quina: la gestió d'esdeveniments, la gestió d'incidents, la gestió de problemes i la gestió de peticions —el domini d'aquest tema— juga el seu paper dins l'Operació del Servei, la fase que s'encarrega d'implementar i operar el servei ja en producció, dia a dia. La gestió de la disponibilitat i de la capacitat pertanyen a Disseny del Servei perquè es planifiquen abans de posar-se en marxa (→ tema 21), i la gestió del canvi i de versions pertanyen a Transició del Servei (→ tema 19).

ITIL v4 no té fases: la metodologia les substitueix per un conjunt de pràctiques que s'activen des de qualsevol punt de la cadena de valor del servei (SVC, Service Value Chain), sense estar lligades a una seqüència fixa. Per això el títol d'aquest tema parla de «pràctiques» i no de «processos de l'Operació del Servei»: és la nomenclatura v4. → tema 17.

7.2 Equilibris de l'Operació del Servei

L'Operació del Servei (ITIL v3) manté quatre tensions en equilibri constant:

• Visió interna de TI vs. visió externa de negoci: gestionar bé els components tecnològics no és el mateix que gestionar el servei que aquests fan possible.
• Estabilitat vs. capacitat de resposta: canviar el servei quan el negoci ho demana sense perdre'n la fiabilitat.
• Qualitat del servei vs. cost del servei: més qualitat sol implicar més cost; cal el nivell acordat, no el màxim possible.
• Reactiu vs. proactiu: reaccionar davant els incidents i, alhora, anticipar-se'ls.

8. Gestió d'accessos

Propòsit (ITIL v3): concedir als usuaris autoritzats el dret a utilitzar un servei, alhora que se n'impedeix l'accés als usuaris no autoritzats. Executa, no defineix, les polítiques que marca la gestió de la seguretat de la informació.

Les seves activitats pròpies són verificar la identitat de qui sol·licita l'accés i concedir els drets que li corresponen segons el rol autoritzat —la sol·licitud arriba normalment via la gestió de peticions de servei. El que no li pertoca: definir les polítiques de seguretat (és gestió de la seguretat de la informació, que la gestió d'accessos només executa) ni monitorar la disponibilitat dels sistemes (és gestió de la disponibilitat). El detall de l'autenticació, l'autorització i els seus protocols és al tema 64.

Claus d'examen

• Actiu/passiu (com es capta la dada) i reactiu/proactiu (per a què serveix) són eixos independents del monitoratge: la descripció «dissenyat per sol·licitar o provocar una acció després d'un esdeveniment» és reactiu, no proactiu (TS-TIC 2023 específic, p. 33).
• Monitoratge ≠ gestió d'esdeveniments: el monitoratge també vigila quan no hi ha esdeveniment; la gestió d'esdeveniments és la que genera i detecta les notificacions significatives (TS-TIC 2023 pràctica, p. 14).
• L'equilibri de l'Operació del Servei combina qualitat de servei acordada i requisits canviants de negoci i tecnologia: no és un únic parell aïllat, sinó els quatre equilibris junts (TS-TIC 2018 pràctica, p. 22).
• L'objectiu de la gestió d'incidents és restaurar; el de la gestió de problemes és eliminar la causa i prevenir, no la rapidesa. Per això, davant incidències recurrents, la resposta correcta és sempre obrir un problema i fer anàlisi de causa arrel, mai seguir resolent-les una a una (TM-TIC 2021-OP pràctica, p. 7-9, p. 26 i p. 30).
• Gestió d'accessos: verifica identitat i concedeix permisos; no defineix polítiques de seguretat ni monitora la disponibilitat (TS-TIC 2018 específic, p. 47).
• En un supòsit pràctic, la resposta correcta sol ser la que estabilitza primer, sense prometre xifres taxades: considerant la problemàtica del cas descrit i tenint en compte el marc de referència d'ITIL, el principal problema d'una organització pública no és la percepció interna, sinó l'impacte extern —caigudes en aplicacions crítiques causant un greu perjudici a la imatge d'Operacions i de tot TI en general, que en resta molt baixa—; i, com a responsable d'Operacions, cal focalitzar i centrar-se en els aspectes operacionals, que és la teva responsabilitat en aquell moment, no ampliar infraestructura sense diagnosticar-ne abans la causa (TS-TIC 2018 pràctica, p. 1 i p. 2).

Per recordar

• Incident = interrupció o degradació no planificada; problema = causa d'un o més incidents; error conegut = problema analitzat però no resolt; workaround = redueix l'impacte sense resoldre la causa.
• Prioritat = impacte × urgència.
• Escalat funcional (més coneixement tècnic) vs escalat jeràrquic (línia de comandament).
• Davant un incident major: coordinació centralitzada, comunicació proactiva i periòdica, restaurar primer (fins i tot amb workaround) i obrir un problema per a la causa.
• Davant incidències recurrents: gestió de problemes i anàlisi de causa arrel.
• Tres tipus d'esdeveniment: informatiu, advertència i excepció (la que genera incident).
• Monitoratge actiu = consulta (polling); passiu = rep esdeveniments. Reactiu = actua després de l'esdeveniment; proactiu = s'hi anticipa. Són dos eixos independents.
• Les peticions de servei no són incidents: són part de la prestació normal i s'han d'estandarditzar i automatitzar.
• El Service Desk manté la propietat de l'incident encara que l'escali.
• Equilibris de l'Operació del Servei: visió interna/externa, estabilitat/resposta, qualitat/cost i reactiu/proactiu, tots quatre alhora.
• Gestió d'accessos: verifica identitat i concedeix drets; no defineix polítiques de seguretat ni monitora la disponibilitat.

Tema 19 · Gestió de serveis

Pràctiques ITIL v4 de lliurament de serveis

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Pràctiques ITIL v4 de lliurament de serveis: gestió de canvis, versions, actius i configuració (CMDB).

1. Què cobreix aquest tema

L'ITIL (Information Technology Infrastructure Library) és el marc de bones pràctiques de gestió de serveis de TI (Tecnologies de la Informació). El títol diu «lliurament», però els quatre àmbits que enumera —canvis, versions, actius i configuració— són exactament els que l'ITIL v3 agrupava a la fase de transició del servei: el pont entre el disseny i l'operació.

Sonen a lliurament i no són d'aquí: incidents, problemes i peticions, el catàleg i l'SLA, la capacitat i la disponibilitat, la continuïtat, la cadena de valor i la canonada tècnica de desplegament. Aquí es tracta la pràctica de gestió: qui autoritza, què es registra, qui respon.

2. Control de canvis

Propòsit (ITIL 4): maximitzar el nombre de canvis de productes i serveis reeixits assegurant que els riscos s'avaluen adequadament, autoritzant els canvis a procedir i gestionant el calendari de canvis.

Canvi: addició, modificació o eliminació de qualsevol cosa que pugui tenir un efecte directe o indirecte sobre els serveis. A l'ITIL v3 la definició s'enuncia sobre el servei —no sobre el projecte ni sobre el programari— i els canvis poden ser estratègics, tàctics o operatius.

La sol·licitud formal que el dispara és la RFC (Request For Change, petició de canvi): descriu què es vol canviar, per què, amb quin impacte i amb quin pla de retorn. No s'ha de confondre amb la RFC de l'IETF (Internet Engineering Task Force), un document d'estandardització d'internet.

2.1 Els tres tipus de canvi

Un canvi d'emergència no és un canvi sense control: se'n redueix la burocràcia, no la traçabilitat.

El model de canvi és el procediment predefinit per a una categoria de canvis repetitius: passos, ordre, responsabilitats i terminis. Un canvi estàndard és, precisament, un canvi amb model aprovat.

2.2 Autoritat de canvi, CAB i calendari

• Autoritat de canvi (change authority): qui autoritza el canvi. L'ITIL 4 recomana descentralitzar l'autorització segons tipus i risc, per no crear un coll d'ampolla.
• CAB (Change Advisory Board, comitè assessor del canvi): òrgan assessor que ajuda a avaluar, prioritzar i planificar els canvis. No decideix per si mateix: assessora l'autoritat de canvi. Hi participen negoci, desenvolupament, operació, seguretat i proveïdors.
• Calendari de canvis (change schedule): agenda dels canvis aprovats i previstos; serveix per detectar col·lisions i per comunicar-los.
• Períodes de congelació (freeze): finestres on no s'admeten canvis (tancament comptable, eleccions, campanyes crítiques).
• Pla de retorn (back-out plan o rollback): obligatori; un canvi sense pla de retorn no s'hauria d'autoritzar.

2.3 Les set erres del canvi

Per avaluar l'impacte, els beneficis i els riscos d'un canvi, l'ITIL 2011 proposa set preguntes conegudes com les set erres. Cauen tal com estan escrites, en anglès i en aquest ordre:

• Raised: qui presenta el canvi.
• Reason: quina és la raó del canvi.
• Return: quin retorn s'espera del canvi.
• Risks: quins riscos comporta.
• Resources: quins recursos calen per lliurar-lo.
• Responsible: qui és el responsable de construir-lo, provar-lo i implementar-lo.
• Relationships: quina relació té amb altres canvis.

La distractora habitual substitueix la darrera per Report o la tercera per Rejoin. Les set són preguntes prèvies a l'autorització, no informes posteriors.

2.4 Avaluació del canvi i revisió posterior

L'avaluació del canvi és el procés que dona a l'autoritat de canvi un dictamen formal sobre l'efecte previst i real d'un canvi significatiu, contrastant el rendiment previst amb el real.

La PIR (Post Implementation Review, revisió posterior a la implementació) es fa després de desplegar i comprova que el canvi ha assolit l'objectiu i no ha causat efectes col·laterals. Quan el canvi venia justificat per un cas de negoci, el que es torna a mirar en una anàlisi post mortem són els riscos i les contingències que s'hi van declarar: si es van materialitzar i si les contramesures van funcionar. L'abast, els costos i els beneficis es revisen amb la realització de beneficis, no amb l'anàlisi de la fallida. El cas de negoci sencer és a prospecció de solucions.

3. Gestió de versions i desplegament

Definicions que es pregunten literalment i que cal no confondre:

• Versió o release: una o més modificacions d'un servei de TI que es construeixen, es proven i es despleguen conjuntament. És la unitat lògica del que s'entrega: el paquet, el conjunt de components i la seva documentació.
• Desplegament o deployment: el moviment de maquinari, programari, documentació o processos cap a un entorn productiu (o a un entorn de prova). És l'acte tècnic de posar els components allà on han d'anar.

Diferència: la release és què s'allibera —un conjunt coherent de canvis, provats i empaquetats junts, amb la decisió de negoci de posar-los a disposició—; el deployment és com i on s'instal·la tècnicament. Es pot desplegar sense alliberar (desplegar el codi a producció amb la funcionalitat desactivada per feature flag) i es pot alliberar sense desplegar de nou (activar una funcionalitat ja desplegada).

Una diferència de versió entre l'ITIL v3 i l'ITIL 4: la v3 tenia un sol procés, «gestió de versions i desplegaments», dins la transició del servei. L'ITIL 4 el parteix en dues pràctiques separades, amb propòsits diferents:

• Gestió de versions: fer disponibles serveis i funcionalitats, nous o modificats, per al seu ús.
• Gestió del desplegament: moure components de maquinari, programari, documentació, processos o qualsevol altre component nous o modificats als entorns productius.

Aquesta separació és la base del desplegament continu: el desplegament passa a ser un acte tècnic freqüent i de baix risc, i l'alliberament una decisió de negoci independent.

Models de desplegament: big bang (tothom alhora), per fases (phased), continu*, pull (l'usuari se'l baixa quan vol) i push* (l'organització l'empeny). Les estratègies avançades —blau-verd, canari, rolling, A/B— són a DevOps i CI/CD.

Entorns: desenvolupament → integració → proves o QA (Quality Assurance, assegurament de la qualitat) → preproducció (staging) → producció.

Repositoris autoritzats, que cauen com a parella:

• DML (Definitive Media Library, biblioteca definitiva de mitjans): repositori segur de les versions autoritzades de tot el programari i les seves llicències, incloent-hi suports físics i documentació.
• DSL (Definitive Software Library): el nom que rebia a l'ITIL v2, limitat al programari. La DML és la successora i té l'abast més ampli.

3.1 La posada en marxa

Desplegar els components no és posar el servei en marxa. El pla de formació es té a punt abans o durant, mai després: ajornar-lo fins a l'acceptació tècnica de l'equip d'operació —que no és el final de la posada en marxa— és la distractora clàssica. El pla de suport s'executa durant i després (early life support). La documentació de lliurament inclou la funcional, el disseny tècnic, els manuals d'usuari, tècnics i d'administració i el full d'escalats per al servei d'atenció. I la instal·lació «cega» —desplegar a producció sense publicar l'accés, per comprovar configuració i components— és correcta: és el cas concret de «desplegar sense alliberar».

4. Validació i proves del servei

Propòsit (ITIL v3): assegurar que un servei nou o modificat coincideix amb el disseny i satisfà les necessitats del negoci, proporcionant la confiança que una entrega crearà un servei que lliurarà els resultats i el valor esperats dins dels costos i restriccions previstos.

Objectiu del disseny de les proves: desenvolupar models de proves i casos de prova que mesurin els aspectes correctes, per establir si el servei complirà amb el seu ús pretès dins de les restriccions especificades. És a dir, el disseny de proves decideix què s'ha de mesurar, no els límits tècnics d'una màquina ni el nombre de peticions per minut d'una base de dades.

El que NO és propòsit d'aquest procés: registrar els canvis dels actius i elements de configuració al sistema de gestió de la configuració —això és de la gestió de la configuració—, aprovar el canvi o mesurar la satisfacció de l'usuari en producció.

4.1 El model V del servei

A cada nivell d'especificació li correspon un de prova, i es dissenyen alhora, no un després de l'altre:

4.2 Tipus de prova

Provar no és només l'acceptació d'usuari:

• Funcionals i d'acceptació d'usuari: fa el que ha de fer, segons qui ho ha demanat.
• De càrrega i de rendiment: aguanta el volum previst. És la prova que falta quan un servei nou cau el dia de la difusió massiva → capacitat i disponibilitat.
• De seguretat: confidencialitat, control d'accés, vulnerabilitats.
• De regressió: el que ja funcionava continua funcionant.
• De continuïtat i de retorn: els plans de recuperació i de retorn s'han provat de veritat.
• De preparació operativa (operational readiness): els equips de suport tenen documentació, coneixement i eines per operar-lo.

4.3 Què passa si no es prova prou

Introduir a producció un servei insuficientment provat incrementa les incidències del propi servei i genera impactes en altres serveis que comparteixen infraestructura, amb costos de correcció més alts i pèrdua de confiança. La confiança i la identificació anticipada de riscos són el resultat de provar, no de no provar: aquesta inversió de sentit és la distractora clàssica.

5. Gestió d'actius de TI

Propòsit: planificar i gestionar el cicle de vida complet de tots els actius de TI, per maximitzar-ne el valor, controlar-ne els costos, gestionar riscos, donar suport a la presa de decisions sobre compra, reutilització i retirada, i complir els requisits legals i regulatoris.

Actiu de TI: qualsevol component financerament valuós que pugui contribuir al lliurament d'un producte o servei de TI. La pràctica es coneix com ITAM (Information Technology Asset Management).

Cicle de vida de l'actiu: planificació → adquisició → desplegament → operació i manteniment → retirada i disposició segura. A cada baula hi ha una decisió econòmica: comprar o llogar, quan amortitzar, quan surt més a compte substituir que mantenir. El número que es compara entre alternatives és el TCO (Total Cost of Ownership, cost total de propietat) → gestió financera.

Àmbits:

• HAM (Hardware Asset Management): maquinari, garanties, ubicació, obsolescència.
• SAM (Software Asset Management): programari i llicències, normalitzat per la ISO (International Organization for Standardization) / IEC (International Electrotechnical Commission) 19770.
• Gestió de contractes, d'actius al núvol i d'actius de dades.

Auditoria de llicències: revisió —interna o del fabricant— que compara les llicències adquirides amb les instal·lacions i els usos reals. Un dèficit es paga amb regularització i sovint penalització; un excedent vol dir que s'ha pagat de més.

Altres riscos que cobreix l'ITAM: maquinari fora de suport, actius fantasma (pagats i no localitzats) i fuita de dades en la retirada, que exigeix esborrat segur o destrucció certificada.

6. Gestió de la configuració del servei i la CMDB

Propòsit: assegurar que hi ha disponible informació precisa i fiable sobre la configuració dels serveis i sobre els elements de configuració que els suporten, quan i on calgui, incloent-hi informació sobre com estan configurats els CI i sobre les relacions entre ells.

6.1 Conceptes

• Element de configuració (CI, Configuration Item): qualsevol component que calgui gestionar per lliurar un servei de TI. Poden ser maquinari, programari, documentació, serveis, persones, edificis i contractes.
• Model de configuració: model lògic que representa els serveis, els actius i la infraestructura, i com es relacionen entre si. És el model que dona la vista extrem a extrem d'un servei: quins components el sostenen i de què depenen.
• CMDB (Configuration Management Database, base de dades de gestió de la configuració): base de dades on es registren els CI i, sobretot, les seves relacions. No hi van ni el pressupost ni les factures: hi van els actius de TI i les relacions entre ells.
• CMS (Configuration Management System, sistema de gestió de la configuració): conjunt d'eines i bases de dades —pot haver-hi diverses CMDB federades— que integren, mantenen i presenten la informació de configuració. La CMDB és el magatzem; el CMS és el sistema que el fa útil.
• SKMS (Service Knowledge Management System, sistema de gestió del coneixement del servei): la capa superior, que integra el CMS, la KEDB (Known Error Database, base de dades d'errors coneguts), la cartera de serveis i tot el coneixement del proveïdor.
• Línia base de configuració (baseline): configuració formalment revisada i acordada, que serveix de referència per a activitats futures i com a punt de retorn.
• Instantània (snapshot): estat de la configuració en un moment donat, registrat per comparació posterior.

6.2 Activitats

Identificació dels CI i del seu model de dades → control (cap CI canvia sense un canvi autoritzat) → registre i informe de l'estat → verificació i auditoria, que compara la CMDB amb la realitat. El descobriment automàtic (discovery) escaneja la infraestructura i l'alimenta; sense ell, la deriva de configuració creix sola.

6.3 Diferència entre actiu i element de configuració

Un mateix element pot ser actiu i CI alhora; però hi ha CI que no són actius (un procés documentat, una relació entre components) i actius que no són CI rellevants (una llicència en desús, una impressora sense paper al magatzem). A l'ITIL v3 les dues coses anaven juntes en un únic procés, la SACM (Service Asset and Configuration Management).

6.4 Per a què serveix la CMDB

• Anàlisi d'impacte dels canvis: quins serveis cauran si toco aquest servidor.
• Diagnòstic d'incidents: quins components suporten el servei afectat.
• Disponibilitat i continuïtat: identificar punts únics de fallida.
• Compliment i seguretat: inventari per a l'anàlisi de riscos de l'ENS i el registre d'activitats de tractament del RGPD, art. 30.
• Planificació de capacitat i gestió financera.

6.5 Reptes i riscos de la gestió d'actius i configuració

Els reptes que fan fracassar les implantacions reals, i que l'examen recull:

• Falta de compromís de la direcció, que no entén el paper que hi juga la pràctica.
• Resistència del personal tècnic a treballar amb registre i autorització, perquè ho percep com a burocràcia que frena la resposta.
• Falta de finançament, perquè el benefici no és visible per a qui paga.
• Sobrecàrrega de dades: recollir-ho tot «perquè es pot», amb un volum desproporcionat i impossible de mantenir.

El risc que se'n deriva és la degradació de l'exactitud de la informació amb el temps, cara i difícil de corregir. Una CMDB desactualitzada és pitjor que no tenir-ne: indueix decisions errònies amb aparença de fonament.

7. La transició del servei a l'ITIL v3

Propòsit de la fase: construir, provar i desplegar els serveis nous o modificats, assegurant que compleixen els requisits documentats a l'etapa de disseny, i gestionar el risc del canvi per minimitzar-ne l'impacte en l'operació.

7.1 Els set processos

1. Planificació i suport a la transició
2. Gestió de canvis
3. Gestió d'actius de servei i configuració (SACM)
4. Gestió de versions i desplegament
5. Validació i proves del servei
6. Avaluació del canvi
7. Gestió del coneixement

Pregunta habitual: quin procés NO forma part de la Transició del Servei? Les distractores són incidents i esdeveniments (Operació), capacitat i nivell de servei (Disseny) i demanda (Estratègia).

El seu lloc al cicle de vida: la transició se situa entre el disseny del servei i l'operació del servei. No entre el projecte i l'operació: el projecte no és una fase del cicle de vida de l'ITIL.

7.2 Beneficis

La resposta correcta ajunta sempre tres coses: satisfacció del client i de l'usuari, reducció de les taxes d'incidències i errors dels serveis en transició i reducció dels costos de la transició.

7.3 Riscos i reptes

Els riscos documentats són l'alienació del personal de suport —canvien responsabilitats i pràctiques, i això desmotiva—, costos excessius per una pràctica exageradament aversa al risc i endarreriments inacceptables per al negoci. La resposta correcta és aquesta terna, no cap versió que negui que hi hagi riscos. Els reptes principals: cadena de subministrament complexa, equilibri entre estabilitat i capacitat de resposta, processos dispars i sistemes heretats.

7.4 Què mesurar quan els recursos són limitats

L'ITIL demana decidir explícitament què és més important, la velocitat de la transició o el cost, i establir després una jerarquia aplicable de mesures: velocitat, diners i funcionalitat. I s'ha de conscienciar i implicar tota l'organització dels requisits: sense això cada equip optimitza el seu paràmetre i cap prioritat es compleix.

Claus d'examen

• La transició és el bloc que més cau. Al pràctic de 2018 hi ha un supòsit sencer sobre la transició del servei: processos, beneficis, riscos, mesures i les set erres (TS-TIC 2018, pràctic, supòsit 2). No l'estudiïs com a història de la v3.
• «Model de configuració» és la resposta a la vista de serveis, actius i infraestructura. Ha caigut dues vegades amb el mateix enunciat i les mateixes distractores (TS-TIC 2021, p. 46; TM-TIC 2021-OP, pràctic, p. 29).
• Release i deployment es pregunten com a parella. La release és el conjunt de canvis que es lliuren junts; el deployment, l'acte físic d'instal·lar-los (TS-TIC 2025, p. 26). Que la v4 les separi és la variant moderna.
• Validació i proves = «confiança que l'entrega lliurarà el valor esperat». Aquesta formulació identifica el procés (TS-TIC 2023, p. 67); la pregunta següent demana l'objectiu del disseny de proves: models i casos que mesurin els aspectes correctes (TS-TIC 2023, p. 68).
• A la CMDB hi van actius i relacions. Ni pressupost, ni factures, ni plantilla del centre d'atenció: són les distractores fixes (TS-TIC 2018, p. 46).
• Compte amb la RFC. Aquí és Request For Change; en un tema de xarxes és un document de l'IETF.

Per recordar

• Canvi estàndard = preautoritzat; normal = avaluat i autoritzat; d'emergència = procediment abreujat però documentat, amb ECAB.
• El CAB assessora; l'autoritat de canvi decideix. La RFC és la sol·licitud que ho engega tot.
• Les set erres: Raised, Reason, Return, Risks, Resources, Responsible, Relationships. És l'única llista del tema que cal saber literalment i en anglès.
• Release = què s'allibera; deployment = moviment tècnic a un entorn. Es pot desplegar sense alliberar. La v3 les tenia en un sol procés; la v4 les separa.
• La DML és el repositori de versions autoritzades i llicències; la DSL és el seu antecessor de la v2, només de programari.
• Validació i proves = confiança que l'entrega lliurarà el valor esperat; el disseny de proves decideix què es mesura. No provar prou = més incidències i impacte en altres serveis.
• CI = component que cal gestionar per lliurar el servei; la CMDB registra els CI i les seves relacions; el CMS integra CMDB federades; el SKMS hi afegeix el coneixement.
• ITAM = què tinc i què val (financer i contractual); configuració = com està muntat i de què depèn (tècnic i relacional). Un element pot ser les dues coses, o només una.
• L'auditoria de llicències compara el comprat amb l'instal·lat: és el risc que sosté el SAM, normalitzat per la ISO/IEC 19770.
• Una CMDB desactualitzada és pitjor que cap. Reptes de la SACM: direcció, resistència tècnica, finançament i excés de dades.
• Processos de Transició: planificació i suport, canvis, SACM, versions i desplegament, validació i proves, avaluació del canvi i coneixement. Incidents, capacitat, demanda, nivell de servei i esdeveniments NO hi són. Va entre disseny i operació.
• Amb recursos limitats: decidir velocitat o cost i establir la jerarquia velocitat, diners, funcionalitat. Els riscos de la transició són alienació del personal, costos excessius i endarreriments.

Tema 20 · Gestió de serveis

El catàleg de serveis TIC i els acords de nivell de servei

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Catàleg de serveis TIC. Definició, manteniment i publicació. Acords de nivell de servei (SLA/OLA/UC).

1. Cartera i catàleg de serveis

Aquest tema parteix d'ITIL (Information Technology Infrastructure Library), el marc de gestió de serveis de TI (Tecnologies de la Informació) més estès i la font que manda en aquesta matèria (sin-fuente-oficial: no és d'accés lliure).

Cartera de serveis (service portfolio): el repositori superior amb tots els serveis d'un proveïdor, en qualsevol estat del seu cicle de vida. Tres blocs: el pipeline (allò que encara s'està avaluant, dissenyant o desenvolupant), el catàleg (el que ja està actiu i disponible) i els serveis retirats. Les tres fases hi entren: un servei que només està planificat, un que ja s'està lliurant i un que s'ha donat de baixa formen part igualment de la cartera.

Catàleg de serveis (service catalogue): el subconjunt de la cartera amb només els serveis actius i disponibles, és a dir, la part que es mostra a qui els pot demanar. La formulació canònica d'ITIL v3, que ha caigut més d'un cop amb paraules gairebé idèntiques, és aquesta: «una única font d'informació consistent sobre tots els serveis acordats, i garantir que està completament disponible per a qui se li hagi autoritzat l'accés». Una segona manera de dir el mateix, també literal: «una base de dades o document estructurat amb informació sobre tots els serveis TI en explotació, incloent-hi els que ja estan preparats per al desplegament».

El catàleg no és cap d'aquestes tres coses, amb què es confon sovint:

• Un inventari de maquinari. Els servidors, estacions de treball i impressores són elements de configuració; qui els inventaria és la CMDB (Configuration Management Database), no el catàleg. (Un enunciat oficial la desenvolupa com «Change Management Data Base»: és una errada del text de l'examen, no la traducció correcta.)
• El llistat de demandes tecnològiques del negoci. Això és matèria de la gestió de la demanda TIC.
• Un registre d'incidències obertes o de projectes en curs. El catàleg descriu el servei ja acabat, no el seu estat operatiu d'un instant ni el projecte que el crea o el modifica.

El primer pas perquè un servei nou hi entri no és donar-lo d'alta al catàleg: és justificar-lo amb un cas de negoci que n'avaluï el valor i el risc per a l'organització. Amb el cas de negoci aprovat, el servei entra al pipeline de la cartera; només quan ja està operatiu, o llest per desplegar-se, passa a formar part del catàleg. Definir l'SLA o assignar-hi un gestor de canvis són passos posteriors, un cop decidit que el servei tira endavant.

El procés o pràctica que manté aquest moviment és la gestió del catàleg de serveis, diferent de la gestió del portfoli (que decideix, a nivell estratègic, què entra i què surt de la cartera sencera) i de la gestió del nivell de servei (que regula els acords, no l'inventari). Qui l'exerceix —el gestor del catàleg— respon de la precisió del catàleg i de la seva coherència amb el portfoli i amb els serveis realment operatius; no respon del flux de creació de serveis, que és responsabilitat del disseny del servei (§4).

2. Les dues vistes del catàleg

Les dues vistes conviuen sempre: ITIL no en desaconsella cap ni prohibeix «en cap cas» barrejar-les, i cap de les dues formulacions absolutes és la seva. El catàleg tècnic ha d'incloure els serveis infraestructurals necessaris per proporcionar els de negoci, precisament perquè són transparents per al client —aquest no els veu ni els necessita veure.

3. Contingut d'una entrada del catàleg

Per a cada servei actiu, el catàleg recull:

• Nom i descripció en llenguatge d'usuari.
• Propietari o responsable del servei.
• A qui va adreçat i requisits d'elegibilitat.
• Com se sol·licita: canal, formulari, autoritzacions.
• Nivells de servei compromesos: disponibilitat, temps de resposta i de resolució.
• Cost o model de repercussió interna.
• Elements de configuració dels quals depèn, i contractes (UC) que el sostenen.
• Estat del cicle de vida i data de la darrera revisió.

No hi entra: sondes de monitoratge en temps real ni l'estat de disponibilitat instant a instant —això és matèria de la plataforma d'observabilitat—, ni els grups resolutoris i les incidències obertes, ni la llista de projectes que crearan, modificaran o retiraran el servei.

4. Gestió del catàleg: definició, manteniment i publicació

Definició. Els serveis s'identifiquen des de la perspectiva del client, mai des de l'estructura interna de TI. Ni un catàleg de centenars d'entrades que ningú llegeix (excés de granularitat) ni un de cinc línies que no serveix per a res (manca de detall).

Manteniment. El catàleg s'ha de mantenir viu: cada canvi que afecti la descripció, l'elegibilitat, els compromisos, les dependències o l'estat del cicle de vida d'un servei l'hauria d'actualitzar, amb revisions periòdiques i un propietari responsable de la seva vigència. Un catàleg desactualitzat perd credibilitat de seguida.

Publicació. Al portal d'autoservei o a la intranet, amb cercador i integració amb l'eina de tiquets: sol·licitar un servei ha de ser el mateix gest que consultar-lo. El catàleg de negoci es publica a les persones usuàries autoritzades —el mateix «qui se li hagi autoritzat l'accés» de la formulació d'ITIL v3 citada a l'inici—; el tècnic, només internament.

Governança. Segons ITIL v3, la gestió del catàleg de serveis és un procés que es descriu dins el llibre de Disseny del Servei (Service Design) —no dins Estratègia, que tracta la cartera a nivell estratègic; ni dins Transició, que desplega els canvis; ni dins Operació, que gestiona el dia a dia—. En ITIL 4 el mateix contingut es reformula com a pràctica de gestió del servei, sense el marc dels quatre llibres. Té com a interfícies la gestió del nivell de servei (§6), la gestió de la capacitat i la disponibilitat, la gestió de la demanda i la gestió financera dels serveis.

5. Les cartes de servei

Instrument propi del sector públic, que no s'ha de confondre amb el catàleg: mentre el catàleg informa de portes endins de què disposa l'organització, la carta de servei és el compromís que es fa davant la ciutadania. La Llei 19/2014, de transparència, accés a la informació pública i bon govern, regula les cartes de servei dins el marc dels serveis públics bàsics (art. 59) i en fixa el contingut mínim, els compromisos de qualitat i les regles d'aprovació i publicació aplicables —no és un deure incondicional per a qualsevol administració i qualsevol servei.

Contingut típic: dades identificatives de l'organisme, serveis prestats, compromisos de qualitat mesurables, els indicadors per verificar-los, drets dels usuaris i el sistema de queixes i suggeriments.

Es classifiquen per l'abast del compromís, mai per un altre criteri: de servei concret, d'unitat o organisme, d'àmbit territorial i interadministratives (quan diverses administracions es comprometen juntes sobre un servei compartit). No existeix —i és el distractor habitual— una classificació per «processos interns»: la carta és un document adreçat al ciutadà, no una eina de gestió interna.

A l'Ajuntament de Barcelona, qui les aprova de manera efectiva és la Comissió de Govern, no el Consell Plenari ni l'alcaldia: és una dada de règim especial municipal, i el reflex d'atribuir-ho a l'òrgan de màxima representació política és, precisament, el parany.

Relació amb l'SLA: la carta és el compromís públic; l'SLA és l'acord negociat amb un client concret. Els compromisos de la carta s'han de poder sostenir sobre els SLA i OLA de rerefons —si la carta promet un termini que cap acord intern garanteix, el compromís és fals.

6. Els acords de nivell de servei

La gestió del nivell de servei (SLM, Service Level Management) té un objectiu concret i únic: assegurar que es proporciona el nivell de servei acordat per als serveis de TI actuals. No és el mateix que:

• assegurar la capacitat suficient perquè els rendiments es puguin complir —això és la gestió de la capacitat, el distractor més freqüent—;
• crear i difondre el catàleg —això és la gestió del catàleg (§4)—;
• fer les tasques operatives del dia a dia —això és l'operació del servei.

I és l'SLM, no cap altra pràctica veïna, qui negocia, fa seguiment i informa de si els serveis assoleixen els seus objectius davant el client. La millora contínua identifica i implementa millores, però no reporta el compliment; la gestió de relacions amb el negoci —BRM— gestiona la relació estratègica, no els informes de rendiment; i la gestió de la disponibilitat només cobreix un dels atributs (§6.6), no el conjunt dels objectius del servei.

6.1 Qui signa amb qui: SLA, OLA i UC

Els tres acords no es distingeixen pel que prometen, sinó per amb qui es firmen:

En un plec públic d'adquisició, l'element que fixa indicadors de qualitat mesurables i el grau de consecució exigible a l'adjudicatari és sempre un acord de nivell de servei —de vegades anomenat ANS (Acord de Nivell de Servei) als plecs, la mateixa sigla en la seva forma catalana—, no unes fites de facturació (que regulen quan es paga, no amb quina qualitat) ni un model d'excel·lència com l'EFQM (European Foundation for Quality Management), que no és cap mecanisme contractual. El parany hi és en la perspectiva: si l'Administració el signa com a client d'un adjudicatari extern, és un SLA; si es mira des dels serveis que la unitat de TI presta després als seus propis usuaris, el mateix contracte fa de UC que els sosté per fora. Un OLA mai hi encaixa quan les dues parts són organitzacions diferents: és, per definició, l'acord de dues unitats de la mateixa casa.

6.2 Contingut d'un SLA

Un SLA ha d'incloure sempre objectius de servei mesurables —disponibilitat, temps de resposta, temps de resolució, rendiment— amb el seu procediment de mesura, l'horari de cobertura, les exclusions i el procediment d'escalat i revisió. No n'hi ha prou amb només penalitzacions (§6.5), ni és un lloc per a detalls tècnics interns de la solució —això és documentació tècnica, no un SLA—, ni es limita a informes històrics de rendiment, que són una sortida de la seva mesura i no un contingut fundacional de l'acord.

6.3 Estructures d'un SLA

• Per servei: un SLA per servei, igual per a tots els clients.
• Per client: un SLA per client, que cobreix tots els serveis que consumeix.
• Multinivell: nivell corporatiu (comú a tota l'organització) + nivell de client + nivell de servei. És l'estructura que millor escala.

Negociar un SLA es complica quan a l'altra banda no hi ha un interlocutor definit per parlar amb l'organització de TI. En canvi, ajuden a l'acord: personal habituat a expressar les seves necessitats de servei, serveis TI ja ben definits i avaluacions sistemàtiques del seu ús —si aquestes tres condicions es donen, l'acord és fàcil; la mancança d'interlocutor és, de les quatre, l'única que el dificulta.

6.4 Del requisit a l'indicador: SLR, SLO i SLI

Abans que existeixi cap acord signat, el negoci ja sap què necessita: això es recull en l'SLR (Service Level Requirements). Un cop negociat, cada objectiu concret que entra a l'SLA és un SLO; i la xifra real que es mesura per comprovar si es compleix un SLO és l'SLI. L'ordre és sempre el mateix: es defineix el requisit, es pacta l'objectiu, es mesura l'indicador i és l'acord —no l'indicador— el que es dona per complert o incomplert.

6.5 Penalitzacions per incompliment

Un SLA sense conseqüència per l'incompliment és una declaració d'intencions. Al sector públic, les penalitzacions no es pacten lliurement: les regula la Llei 9/2017, de contractes del sector públic, que exigeix que estiguin previstes al plec i que siguin proporcionals a la gravetat de l'incompliment, sense caràcter sancionador.

• Compliment defectuós (LCSP, art. 192): cada penalitat no pot superar el 10 % del preu del contracte, IVA (Impost sobre el Valor Afegit) exclòs, ni el conjunt de totes superar el 50 %.
• Demora (LCSP, art. 193): l'escala supletòria és de 0,60 € per cada 1.000 € del preu i dia de retard; cada vegada que l'acumulat arriba a un múltiple del 5 %, l'òrgan de contractació pot optar per resoldre el contracte o continuar-ne l'execució amb noves penalitats.

En el mercat privat i al núvol, el mecanisme habitual són els crèdits de servei (service credits): no es paga una multa, es descompta un percentatge de la factura del període incomplert, com a compensació i no com a indemnització del dany.

6.6 La relació amb la disponibilitat i la capacitat

L'SLA fixa l'objectiu —per exemple, un 99,9 % de disponibilitat—; qui l'ha de fer possible és la gestió de la capacitat i la disponibilitat, que dissenya la redundància, dimensiona la infraestructura i mesura si el compromís se sosté. Comprometre un objectiu de disponibilitat o de rendiment sense un pla de capacitat que l'aguanti és el mateix error que un SLA sense OLA ni UC de rerefons: una promesa que no té qui la sostingui per darrere.

Claus d'examen

• La formulació literal d'ITIL v3 del catàleg de serveis ha caigut amb dues redaccions gairebé calcades: «única font d'informació consistent sobre tots els serveis acordats» (TS-TIC 2023, pràctica, s2-p002) i «base de dades o document estructurat... incloent-hi els preparats per al desplegament» (TS-TIC 2025, pràctica, s2-p003). És la que cau, no una paràfrasi del propòsit.
• Cartera ≠ catàleg, i és el distractor més repetit del tema: la cartera té les tres fases (pipeline + catàleg + retirats), el catàleg només els actius (TS-TIC 2021, específic, s0-p064; TS-TIC 2023, pràctica, s2-p028).
• SLA, OLA i UC es diferencien per qui signa, no pel que prometen. En un plec públic, l'acord amb l'adjudicatari és un SLA vist des de l'Administració com a client, i pot ser alhora el UC que sosté els serveis interns (TM-TIC 2021-OP, pràctica, s3-p006).
• CMDB és Configuration Management Database, no «Change Management Data Base». Un enunciat oficial la desenvolupa malament: l'errada és seva, no es corregeix, però convé no aprendre-se-la (TS-TIC 2025, pràctica, s2-p003).
• L'SLR és anterior a l'SLA: recull el que el negoci necessita abans que hi hagi cap acord signat (TS-TIC 2023, pràctica, s2-p012).
• Les cartes de servei es classifiquen per l'abast del compromís, mai per un criteri de gestió interna (TS-TIC 2023, específic, s0-p026); a Barcelona, les aprova la Comissió de Govern (TS-TIC 2018, específic, s0-p025).

Per recordar

• Cartera = tot el cicle de vida (pipeline + catàleg + retirats). Catàleg = només els actius i disponibles.
• El catàleg té dues vistes: de negoci (client) i tècnica (interna, mai visible al client).
• La gestió del catàleg és, segons ITIL v3, un procés de Disseny del Servei; en ITIL 4, una pràctica.
• SLA = amb el client. OLA = amb una unitat interna. UC = amb un proveïdor extern.
• Abans de l'acord hi ha l'SLR (requisit); dins l'acord, cada SLO (objectiu) es comprova amb un SLI (indicador).
• Un SLA ha de portar objectius mesurables: no n'hi ha prou amb penalitzacions ni amb informes històrics.
• Penalització pública: proporcional, mai sancionadora; per compliment defectuós, 10 % com a màxim per penalitat i 50 % en total; per demora, 0,60 € per cada 1.000 € i dia.
• Les cartes de servei es classifiquen per abast (servei, unitat, territori, interadministratiu), no per processos interns; a Barcelona les aprova la Comissió de Govern.
• Estructures d'SLA: per servei, per client i multinivell (corporatiu + client + servei).
• L'obstacle clàssic per pactar un SLA és no tenir un interlocutor definit a l'altra banda.