Tema 21 · Capacitat, millora i risc

Gestió de la capacitat i disponibilitat TIC

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

Enunciat oficial. Gestió de la capacitat i disponibilitat TIC en ITIL v4. Monitoratge, previsió i optimització de recursos.

1. Gestió de la capacitat i el rendiment

Propòsit (ITIL, Information Technology Infrastructure Library, 4): assegurar que els serveis assoleixen l'acompliment acordat i esperat, satisfent la demanda actual i futura de manera rendible.

Objectius d'ITIL v3 per a la gestió de la capacitat:

• Produir i mantenir un pla de capacitat apropiat i actualitzat que reflecteixi les necessitats actuals i futures del negoci.
• Assessorar la resta d'àrees sobre totes les qüestions relacionades amb la capacitat i el rendiment.
• Assegurar que l'acompliment dels serveis assoleix o supera els objectius acordats, gestionant-ne el rendiment i la capacitat.
• Ajudar a diagnosticar i resoldre els incidents i problemes relacionats amb el rendiment i la capacitat.
• Avaluar l'impacte de tots els canvis sobre el pla de capacitat i sobre el rendiment.
• Assegurar que s'implementen mesures proactives per millorar el rendiment allà on sigui justificable en termes de cost.

No és objectiu de la gestió de la capacitat «garantir la disponibilitat del servei» (això és de la gestió de la disponibilitat), ni «reduir el cost de la infraestructura» com a finalitat en si. Aquestes són les distractores habituals de la pregunta «un dels següents NO és objectiu de la gestió de la capacitat».

1.1 Els tres subprocessos (ITIL v3)

1.2 Activitats

• Monitoratge dels recursos i dels temps de resposta.
• Anàlisi de les dades i identificació de tendències.
• Ajust (tuning) i optimització: índexs de base de dades, cachés, balanceig, configuració de la JVM (Java Virtual Machine), compressió.
• Implementació dels canvis de capacitat.
• Dimensionament d'aplicacions (application sizing): estimar els recursos que necessitarà un servei nou abans de posar-lo en producció.
• Modelatge: anàlisi de tendències, modelatge analític, modelatge de simulació i proves de referència (benchmarking).
• Gestió de la demanda, com a palanca alternativa a comprar més capacitat.

1.3 El pla de capacitat

Document que recull la situació actual, les previsions de demanda, els escenaris i les inversions necessàries amb el seu calendari. Es revisa almenys anualment i cada cop que hi ha un canvi rellevant.

CDB (Capacity Database) / CMIS (Capacity Management Information System): repositori amb totes les dades de capacitat i rendiment.

1.4 Proves de rendiment

Eines: JMeter, Gatling, k6, Locust, LoadRunner, Taurus, Artillery. La bona pràctica quan es vol augmentar la visió dels resultats és disposar d'una segona eina independent que validi les mesures de la primera, perquè cada eina té els seus biaixos de mesura i de generació de càrrega.

1.5 Gestió de la demanda i reducció de la incertesa

Una demanda mal gestionada és font de risc en els dos sentits: capacitat de més genera cost sense crear valor (encara que sempre cal un cert marge de reserva per sostenir el nivell de servei), i capacitat de menys degrada la qualitat dels serveis ja aprovisionats i limita el creixement del servei.

Per reduir la incertesa respecte a la demanda, la gestió de la capacitat s'apoia en dues línies:

• ANS (Acord de Nivell de Servei, SLA (Service Level Agreement) en anglès), previsions i planificació: formalitzar la demanda acordada en l'acord de nivell de servei i traduir-la en previsions i plans de capacitat, en lloc de reaccionar a cada pic.
• Coordinació estreta amb el client: mantenir un diàleg continu sobre canvis d'ús previstos —nous serveis, campanyes, creixement d'usuaris— perquè la capacitat es planifiqui amb temps i no per sorpresa.

El procés complet de govern de la demanda —canal d'entrada, classificació, priorització, comitès— es desenvolupa a tic/gestion-de-la-demanda-tic; aquí queda la seva relació directa amb la incertesa que la planificació de capacitat ha d'absorbir.

2. Gestió de la disponibilitat

Propòsit (ITIL 4): assegurar que els serveis lliuren els nivells de disponibilitat acordats per satisfer les necessitats de clients i usuaris.

Objectiu d'ITIL v3: garantir que el nivell de disponibilitat lliurat en tots els serveis iguala o supera les necessitats acordades actuals i futures del negoci, de manera rendible.

Valor per al negoci: la gestió de la disponibilitat aporta que els serveis de TI (Tecnologies de la Informació) estiguin disponibles quan el negoci els necessita, reduint la freqüència i la durada de les interrupcions, i assegurant que els nivells de disponibilitat es dissenyen, mesuren i gestionen de manera proactiva i alineada amb les necessitats i la criticitat de cada procés de negoci, i al cost justificat. Aquesta formulació és la que apareix a l'examen.

2.1 Disponibilitat, fiabilitat, mantenibilitat i servibilitat

• Disponibilitat (availability): capacitat d'un servei o component de realitzar la seva funció acordada quan es requereix.
• Fiabilitat (reliability): capacitat de funcionar sense interrupció durant un període; es mesura amb el MTBF i el MTBSI (Mean Time Between System Incidents).
• Mantenibilitat (maintainability): rapidesa amb què un servei o component es pot restaurar després d'una fallida; es mesura amb el MTRS/MTTR.
• Servibilitat (serviceability): disponibilitat, fiabilitat i mantenibilitat que un proveïdor extern es compromet a lliurar per contracte (UC: Underpinning Contract).
• Funció vital de negoci (VBF — Vital Business Function): la part d'un procés de negoci crítica per a l'èxit del negoci. La disponibilitat s'ha de dissenyar sobre les VBF, no sobre tot per igual.

2.2 Càlcul

Disponibilitat (%) = (TAS − TI) / TAS × 100

on TAS = temps acordat de servei i TI = temps d'indisponibilitat dins del temps acordat.

Regles que decideixen si el càlcul és correcte:

• El denominador és el temps acordat de servei, no el temps natural. Si l'SLA cobreix de 8 a 20 h en dies laborables, les nits i els caps de setmana no compten.
• Les finestres de manteniment planificat i acordades s'exclouen del temps d'indisponibilitat (si així ho diu l'acord).
• La disponibilitat s'ha de mesurar des de la perspectiva de l'usuari (extrem a extrem), no component a component: un servei amb tots els components «disponibles» pot ser inutilitzable.
• MTBF = temps mitjà entre fallides (fiabilitat); MTRS = temps mitjà de restauració del servei (mantenibilitat); MTBSI = MTBF + MTRS.

Forma equivalent del càlcul, expressada amb els temps mitjans:

Disponibilitat = MTBF / (MTBF + MTTR)

on MTTR (Mean Time To Repair) és, a efectes d'aquest càlcul, el mateix temps mitjà de restauració que el MTRS.

La taula dels «nous»: cada nou de disponibilitat redueix la indisponibilitat anual per deu (sobre un any de 365 dies = 525.600 minuts):

Disponibilitat de components en sèrie i en paral·lel: en sèrie es multipliquen les disponibilitats (i el conjunt és menys disponible que qualsevol component); en paral·lel (redundància) la indisponibilitat és el producte de les indisponibilitats, i el conjunt és més disponible.

2.3 Tècniques d'anàlisi

• CFIA (Component Failure Impact Analysis): identifica punts únics de fallida (SPOF: Single Point Of Failure) creuant CI i serveis.
• FTA (Fault Tree Analysis): arbre lògic de causes d'una fallida.
• SOA (Service Outage Analysis): anàlisi estructurada de les interrupcions per identificar millores.
• TOP (Technical Observation Post): equip tècnic dedicat a observar un servei problemàtic.
• Cicle de vida ampliat de l'incident: descompon el temps total en detecció, diagnòstic, reparació, recuperació i restauració, per saber on s'ha de millorar.
• Pla de disponibilitat i AMIS (Availability Management Information System).

2.4 Tècniques de disseny

Redundància (activa/passiva, N+1, 2N), clústers, balanceig de càrrega, replicació, failover automàtic, eliminació de SPOF, desacoblament (cues, circuit breakers, degradació elegant) i desplegament multizona. → temes 55 i 58.

2.5 Rols i responsabilitats: la matriu RACI aplicada

La matriu RACI (Responsible, Accountable, Consulted, Informed) —qui és R (Responsible, executa), A (Accountable, respon del resultat), C (Consulted, es consulta) i I (Informed, s'informa)— no és pròpia d'aquest tema: la teoria completa es desenvolupa a tic/pmbok-liderazgo-equipo-y-recursos. Aplicada al procés de gestió de la disponibilitat:

• A (Accountable): el gestor de la disponibilitat, propietari únic de la qualitat i del resultat final del procés; només n'hi ha un.
• R (Responsible): els equips tècnics i d'aplicacions que executen el disseny, el monitoratge i les mesures de disponibilitat.
• C (Consulted): el gestor del nivell de servei, perquè els objectius de disponibilitat surten de l'SLA.
• I (Informed): el negoci i els usuaris, informats de l'estat i dels incidents de disponibilitat.

3. Monitoratge

Monitoratge: observació sistemàtica i contínua d'un sistema, servei o component per detectar-ne els canvis d'estat. La gestió d'esdeveniments hi actua a sobre → tema 18.

Què es monitora:

Tipus de monitoratge: actiu/proactiu (consulta i provoca accions) vs passiu/reactiu (rep esdeveniments); sense agent (SNMP: Simple Network Management Protocol; WMI: Windows Management Instrumentation; SSH: Secure Shell; API: Application Programming Interface) vs amb agent.

Protocols i formats: SNMP, syslog, NetFlow/sFlow/IPFIX (Internet Protocol Flow Information eXport), WMI, JMX (Java Management eXtensions), OpenTelemetry, Prometheus exposition format, IPMI (Intelligent Platform Management Interface)/Redfish per a maquinari. El detall de SNMP —versions, operacions GET/SET/TRAP, MIB (Management Information Base)— es desenvolupa a tic/plataforma-de-observabilidad.

Eines habituals: Zabbix, Nagios/Icinga, Checkmk, PRTG, Prometheus, Grafana, Elastic Stack, Dynatrace, Datadog, New Relic, AppDynamics, SolarWinds, Centreon, LibreNMS. → tema 23.

Definició de llindars: cal establir-los sobre la tendència i el comportament normal, no sobre valors absoluts arbitraris, i cal evitar la fatiga d'alertes: si tot alerta, res no alerta. Bones pràctiques: alertes accionables (cada alerta té una acció associada), basades en símptomes i no en causes, amb agrupació i supressió durant manteniments, i amb revisió periòdica dels llindars.

4. Previsió i optimització

• Anàlisi de tendències i models predictius sobre les sèries històriques.
• Capacitat i cicle pressupostari: al sector públic, el pla de capacitat ha d'anticipar-se al calendari pressupostari perquè les inversions arribin a temps.
• Optimització abans que ampliació: primer tuning i eliminació de malbaratament, després compra. El principi guia d'ITIL 4 «optimitza i automatitza» va en aquest ordre.
• Al núvol: escalat vertical (més recursos a la mateixa instància) i escalat horitzontal (més instàncies); autoescalat basat en mètriques; instàncies reservades i savings plans per reduir cost; dimensionament correcte (rightsizing) i eliminació de recursos orfes. El control de la despesa al núvol en temps real és el domini del FinOps → temes 27 i 59.
• Green IT (Information Technology): l'eficiència energètica i el PUE (Power Usage Effectiveness) del CPD (Centre de Procés de Dades) són també objectius de l'optimització → tema 55.

Claus d'examen

• «Com reduir la incertesa de la demanda?» (tria dues): ANS/previsions/planificació i coordinació estreta amb el client són les dues correctes; «marketplace de proveïdors» i «proves de qualitat» no ho són (TS-TIC 2018 pràctica, s1-p3).
• «Qui és el propietari de la qualitat i del resultat final del procés» en una RACI: sempre l'A (Accountable), mai l'R —que només executa— (TS-TIC 2023 pràctica, s2-p24).
• «Conjunt estructurat de procediments per permetre el funcionament quan hi ha una interrupció» és un pla de contingència: no és d'aquest tema, és tic/drp-y-bcp (TS-TIC 2021 específic, p60).

Per recordar

• Capacitat = rendiment i dimensionament; disponibilitat = que el servei hi sigui quan cal. Són pràctiques diferents amb objectius diferents.
• Tres subprocessos de capacitat: negoci, servei i components.
• Disponibilitat = (TAS − TI) / TAS × 100, amb el temps acordat com a denominador i mesurada extrem a extrem.
• Fiabilitat → MTBF; mantenibilitat → MTRS; servibilitat → el que garanteix el proveïdor extern.
• VBF = funció vital de negoci; la disponibilitat es dissenya sobre les VBF.
• CFIA identifica punts únics de fallida.
• Components en sèrie: es multipliquen les disponibilitats i el conjunt empitjora; en paral·lel, millora.
• Una segona eina de proves de càrrega serveix per contrastar i ampliar la visió dels resultats.
• Disponibilitat = MTBF / (MTBF + MTTR); cada nou addicional divideix per deu la indisponibilitat anual (99,9 % ≈ 8,76 h/any; 99,99 % ≈ 52,6 min/any).
• RACI de la disponibilitat: l'Accountable és el gestor de la disponibilitat, propietari únic del resultat; la teoria del RACI és d'un altre tema.

Tema 22 · Capacitat, millora i risc

Mesura i millora contínua dels serveis TIC

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

Enunciat oficial. Mesura i millora contínua dels serveis TIC. KPIs, CSFs i quadres de comandament de serveis en el marc de ITIL v4.

1. La millora contínua a ITIL

Millora contínua (ITIL 4 — Information Technology Infrastructure Library): pràctica i component del Sistema de Valor del Servei que consisteix a alinear les pràctiques i els serveis de l'organització amb les necessitats canviants del negoci mitjançant la identificació i millora contínues de serveis, components, pràctiques o qualsevol altre element implicat en la gestió eficient i efectiva dels productes i serveis. Aplicada als serveis TIC (Tecnologies de la Informació i la Comunicació), vol dir mesurar el que es lliura i actuar sobre el que la mesura destapa.

Responsabilitat: la millora contínua és responsabilitat de tothom, no d'un departament. Això no vol dir que no tingui amo: l'organització n'ha de designar un propietari i mantenir un registre d'oportunitats de millora on es prioritzen (§1.6).

El marc general d'ITIL —les quatre dimensions, el Sistema de Valor del Servei, la cadena de valor i les 34 pràctiques— no es desenvolupa aquí: → tema 14.

1.1 El model de millora contínua d'ITIL 4 — set passos

1. Quina és la visió? — es connecta amb la visió i els objectius de l'organització.
2. On som ara? — avaluació objectiva de la situació actual (línia base). Sense línia base no es pot demostrar cap millora: aquest és el pas que més es menysprea.
3. On volem estar? — objectius mesurables.
4. Com hi arribem? — pla.
5. Passa a l'acció — executar.
6. Hem arribat? — verificar amb mesures.
7. Com mantenim l'impuls? — consolidar i institucionalitzar.

Què hi va afegir ITIL 4. El model ve del model CSI d'ITIL v3, que planteja les mateixes preguntes menys la cinquena. ITIL 4 hi intercala «passa a l'acció» entre «com hi arribem?» i «hem arribat?»: és el pas que impedeix que el pla es quedi al paper, i la diferència que es pregunta quan un enunciat contraposa les dues versions.

Compte amb la sigla CIP. El CIP (Continual Improvement Process, procés de millora contínua) és el nom genèric que la gestió de la qualitat dona a la millora per petits passos, hereva del kaizen i emparentada amb el PDCA (§1.3). ITIL no fa servir la sigla: el que ITIL 4 té és la pràctica de millora contínua i el model d'aquests set passos. Si un enunciat parla de «CIP», parla del concepte general de qualitat, no d'un artefacte d'ITIL.

1.2 ITIL v3: la Millora Contínua del Servei (CSI)

A ITIL v3 la millora contínua no era una pràctica sinó una fase sencera del cicle de vida del servei, la cinquena, anomenada Millora Contínua del Servei (CSI — Continual Service Improvement), amb el seu propi llibre. ITIL 4 va eliminar el llibre i el cicle de vida: la matèria hi passa a ser una de les 34 pràctiques de gestió, rebatejada simplement millora contínua. El cicle de vida de v3 sencer, amb les seves cinc fases, es desenvolupa al tema 14.

La distinció importa perquè els dos vocabularis cauen a l'examen, i l'enunciat sol dir de quina versió parla: si diu «v3» o «cicle de vida», la resposta porta les lletres CSI; si diu «ITIL 4» o «pràctica», porta millora contínua.

El gestor de CSI (CSI manager) és el rol propietari de la millora a v3. Les seves responsabilitats clau:

• és responsable del desenvolupament de la CSI, treballa amb el gestor de serveis per identificar els plans de millora de serveis i coordina les activitats de CSI al llarg de tot el cicle de vida del servei;
• identifica i proporciona millores de processos en àrees essencials de negoci, comunica la visió de CSI a tota l'organització i assegura que la gestió del coneixement sigui part integral de l'operativa diària.

El que no és seu: liderar el desenvolupament de serveis nous —això és disseny i transició— ni «crear una organització imaginativa que estimuli la innovació», que és un tret genèric de lideratge. Les dues formulacions són els distractors amb què el tribunal ha construït la pregunta (TS-TIC 2018 pràctica, s2-p30), i les dues frases anteriors són les respostes correctes.

El procés de millora en 7 passos és l'altre artefacte de la fase CSI, i no s'ha de confondre amb el model de §1.1: el model planteja preguntes de direcció, i aquest és el procediment de mesura que les respon.

1. Identificar l'estratègia de millora (visió, necessitat de negoci, objectius).
2. Definir què es mesurarà.
3. Recopilar les dades (qui, com, quan; integritat de les dades).
4. Processar les dades (format, agregació, precisió).
5. Analitzar la informació i les dades — tendències, objectius, millores necessàries.
6. Presentar i utilitzar la informació — resum, plans d'acció.
7. Implementar la millora.

1.3 El cicle de Deming

PDCA — Plan, Do, Check, Act. És el model de gestió en què es basa la millora contínua del servei. Cada volta consolida el nivell assolit (la «falca» que impedeix retrocedir) i n'inicia una de nova.

• Plan: definir objectius i processos necessaris.
• Do: implementar.
• Check: mesurar i comparar amb els objectius.
• Act: actuar sobre les diferències, estandarditzar el que funciona.

S'aplica a qualsevol procés, no només als de gestió de TI (Tecnologies de la Informació) o de qualitat formal: si es planifica un canvi, s'implementa, i se n'avalua l'impacte, el conjunt és un cicle PDCA encara que l'àmbit sigui, per exemple, administratiu o de contractació.

Exemple: unes entrades de dades es recullen a mà de documents, cosa que alenteix el còmput d'uns criteris expressats en fórmules i pot introduir errors. Un grup interdisciplinari avalua la situació, arriba a unes conclusions i decideix proposar automatitzar la recollida; la proposta és acceptada, s'implementa i se n'avalua l'impacte. Això és un PDCA complet — Plan (proposta), Do (implementació), Check (avaluació) i Act (adopció) — encara que l'àmbit no sigui, en sentit estricte, un procés de TI sinó, per exemple, la contractació pública.

1.4 Altres mètodes i tècniques de millora

El catàleg que ITIL recull sota l'etiqueta «mètodes i tècniques de millora contínua» té un tret comú: totes mesuren o comparen contra un referent —un estàndard, una altra organització, un objectiu—. Són:

• Les avaluacions (assessments): comparen l'entorn d'un procés amb estàndards de rendiment per mesurar-ne la capacitat o identificar diferències a abordar. Inclou les avaluacions de maduresa (CMMI — Capability Maturity Model Integration) i les auditories.
• El benchmarking: compara aspectes dels propis processos amb les millors pràctiques del sector per adoptar-les.
• El quadre de comandament integral (Balanced Scorecard, §3): un conjunt de tècniques de mesura amb perspectives equilibrades.
• L'anàlisi DAFO (Debilitats, Amenaces, Fortaleses, Oportunitats) i l'anàlisi de GAP (§1.5): diagnosi de la posició i de la distància fins a l'estat desitjat.
• El cicle de Deming (§1.3) i el procés de millora en 7 passos (§1.2), que són els procediments que ho ordenen tot.

Al costat, i fora d'aquest catàleg, hi ha metodologies de millora nascudes a la indústria i al món àgil que sí que milloren però no són tècniques de mesura o comparació: Lean (eliminació de malbaratament, Kaizen, Value Stream Mapping, 5S), Six Sigma (DMAIC: Define, Measure, Analyze, Improve, Control), la Teoria de les Restriccions, les retrospectives d'esprint i els post-mortems sense culpables. I el pla de millora del servei (SIP — Service Improvement Plan) no és una tècnica sinó el pla que en surt (§1.6).

Pregunta habitual: quin NO és un mètode o tècnica de millora contínua? La distinció que fa servir el tribunal és la del paràgraf anterior: la retrospectiva d'esprint —una reunió d'equip per reflexionar sobre la forma de treballar— no compta com a tècnica de millora contínua, mentre que les avaluacions, el benchmarking i el quadre de comandament integral sí (TS-TIC 2023, específic, s0-p42). També apareixen com a distractors ITIL mateix (que és un marc, no una tècnica), PMBOK (Project Management Body of Knowledge), TOGAF (The Open Group Architecture Framework) o COBIT (Control Objectives for Information and related Technology), i respostes com «gestió d'incidents» o «gestió de canvis», que són pràctiques operatives.

1.5 Anàlisi de GAP

Anàlisi de GAP (gap analysis): eina de negoci que compara l'estat actual d'una organització amb l'estat futur desitjat per identificar les àrees on hi ha marge de millora, i que pot incloure necessitats i aspectes desitjables encara no coberts. La diferència identificada (el «buit» o gap) és la base per construir el pla d'accions que la tanca.

Operacionalitza directament els passos 2 i 3 del model de millora contínua d'ITIL 4 (§1.1): on som ara? és l'estat actual; on volem estar?, l'estat desitjat.

• GAP no és un acord: la paraula és l'anglès gap («buit», «distància»), no una sigla. Un distractor habitual la «desenvolupa» com si ho fos (p. ex. «Guanys, Amenaces, Problemes i Solucions») — és fals, no existeix aquesta expansió.
• GAP no és DAFO: el DAFO (§1.4) classifica fortaleses, debilitats, amenaces i oportunitats; el GAP compara dos estats en el temps (actual i futur) per mesurar-ne la distància. Confondre'ls és el segon parany habitual de l'examen.

1.6 El registre de millores i la priorització d'iniciatives

Registre de millora contínua (CIR — continual improvement register): el registre únic i viu on l'organització apunta i prioritza totes les oportunitats de millora detectades, des que algú les identifica fins que es tanquen o es descarten. Una oportunitat que no s'apunta enlloc es perd, i aquest és l'artefacte que ho impedeix. La sigla depèn de la versió d'ITIL:

Què hi consta de cada iniciativa: la descripció de l'oportunitat i d'on ha sortit (una revisió del servei, un post-mortem, una queixa, una desviació d'un KPI), el benefici esperat, el cost o esforç estimat, el risc d'implantar-la, el propietari, l'estat i la data. El registre serveix precisament per fer visible el conjunt: què s'està fent, què ja està tancat i què s'ha deixat aparcat per revisar-ho més endavant.

Com es prioritza. No hi ha una fórmula normativa, sinó un criteri constant: primer les de benefici alt, urgència alta i cost baix, ponderant a més el risc d'execució i l'alineació amb els objectius de negoci. Aquesta priorització és el que converteix una llista d'idees en una cartera de millora; sense ella el registre és un abocador.

Registre i pla no són el mateix. El registre és la llista prioritzada de candidates; el pla de millora del servei (SIP — Service Improvement Plan) és el pla formal d'una millora ja aprovada, amb accions, responsables i terminis. Del registre surten SIP, no a l'inrevés. I el registre de millores tampoc és el registre de riscos ni la cua de peticions de canvi: aquells recullen amenaces i canvis a autoritzar, aquest recull oportunitats.

A la ISO 20000 el que aquí és bona pràctica és requisit auditable: la norma exigeix determinar i seleccionar oportunitats de millora i establir criteris d'avaluació i priorització. El desenvolupament normatiu és matèria d'aquell tema; aquí n'hi ha prou de saber que ITIL i la ISO diuen el mateix amb força distinta.

2. CSF, KPI i mètriques

2.1 Definicions

• Factor crític d'èxit (CSF — Critical Success Factor): allò que ha de succeir perquè un servei, procés, pla, projecte o altra activitat tingui èxit. Respon a què cal aconseguir. És qualitatiu.
• Indicador clau de rendiment (KPI — Key Performance Indicator): mètrica que s'utilitza per ajudar a gestionar un servei, procés, pla, projecte o altra activitat, i que mesura l'assoliment d'un CSF. És quantitatiu.
• Mètrica: qualsevol cosa que es mesura i es reporta. Tots els KPI són mètriques, però no totes les mètriques són KPI: només ho són les que es fan servir per prendre decisions.

Relació: CSF → KPI → mètriques. Cada CSF té diversos KPI; cada KPI s'alimenta de diverses mètriques.

Exemple: CSF «reduir l'impacte dels incidents en el negoci» → KPI «percentatge d'incidents crítics resolts dins l'SLA (Service Level Agreement)», «MTTR (Mean Time To Repair) dels incidents crítics» → mètriques «hora d'obertura», «hora de resolució», «prioritat».

2.2 Els tres tipus de mètriques d'ITIL

• Mètriques tecnològiques: components i aplicacions — disponibilitat d'un servidor, ús de CPU (Central Processing Unit), latència. Les quatre senyals daurades i els indicadors i objectius de nivell de servei d'una plataforma d'observabilitat (Prometheus, Grafana) en són la font tècnica → tema plataforma d'observabilitat.
• Mètriques de procés: CSF i KPI dels processos de gestió de serveis — temps de resolució, taxa de canvis reeixits, compliment d'SLA.
• Mètriques de servei: resultats del servei extrem a extrem, tal com el percep el negoci — disponibilitat del tràmit, temps de resposta de la seu electrònica, satisfacció.

2.3 La funció dels indicadors en la millora contínua

Els indicadors serveixen per:

• Validar les decisions preses (les millores han funcionat?);
• dirigir i orientar l'activitat cap als objectius;
• justificar amb evidència les accions o inversions;
• intervenir: identificar el punt on cal actuar i disparar accions correctives.

Aquests quatre verbs — validar, dirigir, justificar, intervenir — són la resposta a la pregunta «quina és la funció principal dels indicadors en el context de la millora contínua». Els indicadors no serveixen per avaluar les persones: fer-ho destrueix la fiabilitat de les dades.

2.4 Com han de ser els indicadors

• SMART (Specific, Measurable, Achievable, Relevant, Time-bound): específics, mesurables, assolibles, rellevants i amb termini.
• Pocs: un quadre amb 60 indicadors no es mira. La regla pràctica és entre 5 i 10 per àmbit.
• Amb línia base i objectiu.
• Amb propietari i freqüència definida.
• Equilibrats: si només mesures velocitat, sacrificaràs qualitat. Cal parells contrapesats (temps de resolució i taxa de reobertura).
• Resistents a la manipulació: la llei de Goodhart diu que «quan una mesura es converteix en objectiu, deixa de ser una bona mesura». Exemple clàssic: tancar incidents sense resoldre'ls per complir l'SLA.

2.5 Mètrica vs indicador

Diferència clau que es pregunta: una mètrica és una mesura en brut d'un atribut, sense context; un indicador és una mètrica interpretada respecte d'un objectiu o llindar, que indica si l'acompliment és acceptable i, per tant, suporta una decisió. «250 incidents al mes» és una mètrica; «el 92 % dels incidents crítics resolts dins l'SLA, contra un objectiu del 95 %» és un indicador.

3. Quadres de comandament de serveis

Quadre de comandament (dashboard): representació visual, en temps real o periòdica, dels indicadors rellevants per a un públic concret.

Nivells:

Balanced Scorecard aplicat a TI: perspectives de contribució corporativa, orientació a l'usuari, excel·lència operativa i orientació al futur. Al sector públic la perspectiva superior és la missió/ciutadà.

Bones pràctiques de disseny: una pantalla per audiència, contextualitzar sempre (objectiu, tendència, període comparatiu), evitar la decoració (gràfics 3D, semàfors sense llindar definit), i acompanyar cada indicador de l'acció prevista si es desvia.

Informes de servei: la pràctica de mesura i informes (measurement and reporting) d'ITIL 4 té com a propòsit donar suport a la bona presa de decisions i a la millora contínua reduint els nivells d'incertesa, mitjançant la recopilació de dades rellevants sobre diversos objectes gestionats i la seva avaluació vàlida en el context adequat.

Un informe de rendiment del servei no és un bolcat d'indicadors. Perquè serveixi per decidir ha de portar, com a mínim: el període i l'abast (quins serveis), el compliment respecte dels objectius acordats —no el valor a seques—, la tendència contra períodes anteriors, l'explicació de les desviacions i les accions que se'n deriven amb propietari i termini. Aquestes accions són, precisament, les que alimenten el registre de millores (§1.6): un informe que acaba en un gràfic i no en una entrada del registre no ha tancat el cicle.

Quadre de comandament i informe no són el mateix: el quadre és una vista contínua que es consulta, l'informe és un lliurament periòdic que s'envia, es comenta en una revisió del servei i deixa constància. Un no substitueix l'altre.

4. Mesura al sector públic

• Els indicadors han de reflectir valor públic: temps de tramitació, taxa de tràmits completats en línia, accessibilitat, satisfacció ciutadana, bretxa digital, no només mètriques tècniques.
• Les cartes de servei publiquen compromisos amb indicadors verificables → tema 20.
• La transparència obliga a publicar informació estadística sobre el grau de compliment i la qualitat dels serveis (Llei 19/2013, art. 8).
• L'avaluació de polítiques públiques i el retiment de comptes (Llei 19/2014) donen a la mesura un valor institucional afegit.

Claus d'examen

• L'anàlisi de GAP no és una sigla: és la paraula anglesa per «buit». Un distractor la «desenvolupa» com un acrònim fals («Guanys, Amenaces, Problemes i Solucions») — no existeix. Les respostes certes són sempre les que parlen d'estat actual vs. estat desitjat (TS-TIC 2018 pràctica, s2-p20).
• Qualsevol procés seguint Plan-Do-Check-Act és millora contínua, encara que l'àmbit no sigui formalment «gestió de la qualitat» ni de TI: automatitzar una entrada de dades, implementar-la i avaluar-ne l'impacte compleix el PDCA encara que l'escenari sigui, per exemple, la contractació pública (TS-TIC 2018 pràctica, s4-p29).
• CSF ≠ KPI: el CSF és què cal aconseguir (qualitatiu); el KPI és com es mesura si s'aconsegueix (quantitatiu, i s'alimenta de mètriques).
• El vocabulari de v3 continua caient. Els enunciats que diuen «cicle de vida» o «v3» esperen les lletres CSI (Continual Service Improvement) —fase cinquena (TS-TIC 2025 pràctica, s2-p27)— i els que diuen ITIL 4 esperen millora contínua com a pràctica. La pregunta del gestor de CSI es contesta pel verb: les correctes coordinen i comuniquen la millora d'un servei que ja funciona; els distractors creen serveis nous o parlen d'innovació genèrica (TS-TIC 2018 pràctica, s2-p30).
• Registre ≠ pla: el registre CSI / CIR és la llista prioritzada d'oportunitats; el SIP (Service Improvement Plan) és el pla formal d'una millora ja aprovada. I CIP no és terminologia d'ITIL, sinó el nom genèric de la millora contínua en gestió de la qualitat (§1.1).

Per recordar

• CSF = què cal aconseguir (qualitatiu); KPI = com es mesura (quantitatiu). Relació CSF → KPI → mètriques.
• Tres tipus de mètriques: tecnològiques, de procés i de servei.
• La funció dels indicadors és validar, dirigir, justificar i intervenir. No avaluar persones.
• Mètrica = mesura en brut; indicador = mètrica contextualitzada respecte d'un objectiu, que suporta una decisió.
• PDCA de Deming és el model de gestió de la millora contínua del servei.
• Model de millora d'ITIL 4: set passos; la segona pregunta, «on som ara?», exigeix una línia base. El que ITIL 4 hi va afegir sobre el model CSI de v3 és «passa a l'acció».
• v3 = CSI, fase del cicle de vida; ITIL 4 = millora contínua, una de les 34 pràctiques. El registre és registre CSI a v3 i CIR a ITIL 4; el pla d'una millora aprovada és el SIP.
• Les millores es prioritzen per benefici, urgència, cost i risc; les primeres, benefici alt i cost baix.
• Llei de Goodhart: quan una mesura es converteix en objectiu, deixa de ser una bona mesura.
• ITIL, COBIT, PMBOK i TOGAF són marcs, no tècniques de millora contínua.

Tema 23 · Capacitat, millora i risc

Plataforma d'observabilitat

Abast decidit per nosaltres: l'enunciat oficial no acota la matèria

Enunciat oficial. Plataforma d'Observabilitat: Components, característiques i reptes d'implantació.

1. Concepte

Observabilitat: capacitat de deduir l'estat intern d'un sistema a partir de les seves sortides externes. El terme prové de la teoria de control: un sistema és observable si es pot determinar el seu estat intern observant-ne les sortides.

Observabilitat ≠ monitoratge, i és la distinció que més cau:

L'observabilitat inclou el monitoratge: no el substitueix. Un sistema observable permet seguir fent monitoratge, però també investigar sense haver de desplegar codi nou per obtenir informació.

2. Els tres pilars

L'observabilitat es construeix sobre tres tipus de telemetria —els tres pilars— que responen a preguntes diferents i no se substitueixen entre si: amb només un dels tres, hi ha vigilància, no diagnòstic.

Cada pilar té un cost i una precisió diferents: les mètriques són barates i agregades, els registres són cars i literals, i les traces són les úniques que reconstrueixen el camí d'una petició concreta. Sovint s'hi afegeixen dos senyals més: els perfils (profiling) —consum de CPU (Central Processing Unit) i memòria per funció, que OpenTelemetry està normalitzant com a quart senyal— i els esdeveniments de negoci.

El que fa útil la plataforma no són els tres pilars per separat, sinó la seva correlació: poder saltar d'un pic d'una mètrica a les traces d'aquell moment i, d'allà, als registres del span concret. Sense correlació hi ha tres eines, no una plataforma d'observabilitat.

3. Components d'una plataforma d'observabilitat

Una plataforma d'observabilitat és una cadena: la telemetria es genera al codi, viatja fins a un magatzem i acaba en una pantalla o en una alerta. Cada baula té productes propis, i el disseny consisteix a triar-los de manera que el pas següent segueixi podent correlacionar.

1. Instrumentació: codi i agents que generen la telemetria. Pot ser manual (biblioteques al codi), automàtica (agents que injecten instrumentació sense tocar el codi) o eBPF (extended Berkeley Packet Filter, a nivell de nucli, sense agent ni canvis al codi). S'hi afegeixen el monitoratge d'usuari real —telemetria del navegador de qui fa servir el servei— i el monitoratge sintètic, que simula transaccions des de fora per detectar caigudes abans que hi hagi cap usuari.
2. Recol·lecció i transport: agents i col·lectors (OpenTelemetry Collector, Fluent Bit, Vector, Logstash, Beats), amb buffering i reintent. La recollida pot ser per extracció (pull: el sistema va a buscar les dades, com fa Prometheus) o per empenta (push: l'aplicació les envia).
3. Processament: enriquiment amb metadades, normalització, mostreig (sampling), filtratge, agregació i correlació mitjançant identificadors comuns (trace id, span id).
4. Emmagatzematge: bases de dades de sèries temporals per a mètriques (Prometheus, VictoriaMetrics, InfluxDB, Mimir), índexs de text per a registres (Elasticsearch/OpenSearch, Loki), i magatzems de traces (Tempo, Jaeger).
5. Consulta i visualització: llenguatges de consulta —PromQL i LogQL (Prometheus i Loki), KQL (Kusto Query Language, Microsoft) i SPL (Search Processing Language, Splunk)— i quadres de comandament (Grafana, Kibana).
6. Alerta i resposta: motor de regles, deduplicació, agrupació, encaminament i guàrdies (Alertmanager, PagerDuty, Opsgenie), i integració amb la gestió d'incidents.
7. Capa d'anàlisi avançada: AIOps — detecció d'anomalies, correlació automàtica, agrupació d'alertes i anàlisi de causa arrel assistida.
8. Govern: retenció, control d'accés, anonimització i control de costos.

OpenTelemetry (OTel): projecte de la CNCF (Cloud Native Computing Foundation) que estandarditza la generació, recol·lecció i exportació de mètriques, registres i traces. És agnòstic de proveïdor: instrumentes un cop i pots canviar de rerefons. Ha absorbit OpenTracing i OpenCensus i és avui l'estàndard de facto. Adoptar OTel és la manera d'evitar el bloqueig de proveïdor en observabilitat.

3.1 SNMP, el protocol clàssic de gestió de xarxa

SNMP (Simple Network Management Protocol) és el protocol estàndard de gestió d'elements de xarxa —encaminadors, commutadors, tallafocs—, anterior a l'observabilitat moderna i encara vigent quan aquests dispositius no exposen telemetria d'OpenTelemetry. Intercanvia informació entre un gestor —el NMS (Network Management System), a la solució d'administració de xarxa— i un agent a cada dispositiu.

L'agent exposa les seves variables en una MIB (Management Information Base), una estructura jeràrquica on cada valor té un OID (Object Identifier) únic; la MIB-II en normalitza els objectes bàsics comuns a qualsevol dispositiu. Tres operacions bàsiques: GET (el gestor llegeix un valor), SET (el gestor el modifica) i TRAP (l'agent notifica un esdeveniment sense que li ho demanin — monitoratge passiu).

SNMPv1 i v2c autentiquen amb una community string que viatja en clar; SNMPv3 hi afegeix autenticació i xifratge, i és l'única versió recomanable en producció.

3.2 Alertes i correlació d'esdeveniments

Una regla d'alerta és una condició sobre una consulta mantinguda un temps mínim: no salta al primer pic, sinó quan la condició persisteix. Sobre això, la plataforma ha de reduir el soroll abans de despertar ningú:

• Deduplicació: la mateixa alerta emesa per vint rèpliques és una sola notificació.
• Agrupació: totes les alertes del mateix servei o del mateix clúster arriben juntes, no una per correu.
• Inhibició: una alerta de rang superior —el clúster sencer ha caigut— silencia les que en deriven.
• Silenciament: finestres de manteniment planificat en què no s'avisa.
• Encaminament i escalat: a quin equip, per quin canal i amb quina guàrdia (Alertmanager, PagerDuty, Opsgenie), amb obertura automàtica de l'incident.

La correlació d'esdeveniments és el pas que agrupa esdeveniments relacionats per topologia (quins components depenen de quins), per temps (què ha passat en la mateixa finestra) i per identificador (mateixa petició, mateix servei), i decideix quin d'ells és la causa i quins són conseqüència. És el que evita que una sola caiguda generi centenars d'alarmes; AIOps hi afegeix detecció d'anomalies sense llindar fix i suggeriment de causa arrel.

Sobre què s'alerta: sobre símptomes visibles per l'usuari —latència, errors— i sobre el ritme de consum (burn rate) del pressupost d'error, no sobre llindars de components («CPU > 80 %»), que salten sovint sense que ningú noti res.

Frontera. La pràctica de gestió d'esdeveniments d'ITIL (Information Technology Infrastructure Library) —què és un esdeveniment, els tipus informatiu, advertència i excepció, i els eixos actiu/passiu i reactiu/proactiu— es desenvolupa al tema 18. Aquí hi ha la plataforma tècnica que els genera i els correlaciona.

4. Característiques d'una plataforma d'observabilitat

Aquestes són les propietats que ha de tenir una plataforma perquè sigui d'observabilitat i no un conjunt d'eines de monitoratge. Les tres primeres són les que marquen la diferència; la resta són exigències d'explotació que decideixen si la plataforma és sostenible.

1. Unificació dels tres pilars en un sol producte: mètriques, registres i traces al mateix lloc, amb el mateix model d'accés i el mateix vocabulari d'etiquetes.
2. Correlació per identificadors comuns: trace id i span id a les traces, exemplars que enllacen una mètrica amb una traça concreta, i camps estructurats als registres. És el que permet la navegació guiada —de la gràfica a la traça i d'aquesta al registre— sense canviar d'eina.
3. Alta cardinalitat i alta dimensionalitat: poder etiquetar la telemetria amb identificador d'usuari, de petició, de versió o de client i segmentar-hi després. La cardinalitat és el nombre de valors diferents que pot prendre una etiqueta; l'observabilitat en necessita molta i és justament el que dispara el cost. És la tensió central del disseny.
4. Consulta exploratòria ad hoc: es poden fer preguntes que no s'havien previst, sense definir una mètrica nova ni desplegar codi.
5. Temps real: ingesta i consulta amb latència de segons, perquè serveixi durant l'incident i no només per a l'anàlisi posterior.
6. Instrumentació estàndard i agnòstica de proveïdor: OpenTelemetry i convencions semàntiques comunes d'atributs.
7. Descobriment automàtic de serveis, de dependències i del mapa de serveis, generat a partir de les traces i no d'un inventari mantingut a mà.
8. Escalabilitat elàstica i multi-inquilí: una sola plataforma per a moltes àrees, amb aïllament de dades, de permisos i de quotes entre elles.
9. Retenció per capes i control del cost: dades detallades poc temps, agregades molt temps, i cost visible per equip.
10. Alertes basades en objectius de servei i integrades amb la gestió d'incidents, en lloc de llindars per component.
11. Govern de les dades: control d'accés per rol, anonimització del que pugui ser dada personal i traçabilitat de qui consulta què.

5. Arquitectura per a microserveis

En una arquitectura de microserveis, l'observabilitat escalable requereix:

• Traçat distribuït obligatori: sense traces, una petició que travessa vint serveis és impossible de diagnosticar. Cal propagació de context amb capçaleres W3C (World Wide Web Consortium) Trace Context: traceparent, tracestate.
• Instrumentació estandarditzada amb OpenTelemetry a tots els serveis, amb convencions semàntiques comunes d'atributs.
• Recol·lecció desacoblada: un col·lector com a intermediari (patró sidecar o daemonset), perquè les aplicacions no depenguin del rerefons.
• Mostreig intel·ligent: mostreig de cap (head-based) decideix a l'inici de la traça; mostreig de cua (tail-based) decideix un cop completa, i permet conservar totes les traces amb error o lentes i descartar les normals. El de cua és el que dona escalabilitat sense perdre els casos interessants.
• Emmagatzematge escalable i per capes, amb retencions diferents per pilar, i mapa de serveis derivat de les traces.
• Malla de serveis (service mesh) —Istio, Linkerd—: una capa que envolta cada servei i li aporta telemetria uniforme de totes les crides sense tocar-ne el codi. És l'arquitectura que fa escalable l'observabilitat en microserveis, perquè no depèn que cada equip instrumenti bé el seu servei. Es desenvolupa al tema 47.

6. Eines de visualització

Grafana és l'eina de referència per visualitzar mètriques, registres i traces en temps real en entorns d'observabilitat: és de codi obert, agnòstica de font de dades i s'integra amb Prometheus, Loki, Tempo, Elasticsearch, InfluxDB i desenes més. Alternatives: Kibana (per a l'Elastic Stack), Chronograf i les consoles pròpies dels productes comercials.

Un quadre de comandament tècnic útil no és una paret de gràfiques: porta les senyals daurades de cada servei, un panell d'estat dels objectius de servei amb el pressupost d'error consumit, el mapa de serveis, i enllaços de baixada que porten de la gràfica a la traça i d'aquesta al registre. Les variables de quadre —entorn, servei, versió— eviten haver de mantenir un panell per equip.

Piles habituals:

Plataforma d'observabilitat o eina de monitoratge? Són plataformes d'observabilitat en sentit ple Dynatrace, Datadog, New Relic, Instana (IBM), Splunk Observability, Elastic Observability i Grafana Cloud. Són eines de monitoratge clàssic —comproven disponibilitat i llindars de components, sovint per SNMP o amb agent, i no correlacionen els tres pilars— Nagios, Icinga, Zabbix, Checkmk, Centreon, PRTG (Paessler Router Traffic Grapher), Cacti, LibreNMS i SolarWinds. I no són ni una cosa ni l'altra Ansible o Jenkins, que són d'automatització i integració contínua.

El criteri no és la marca sinó la capacitat: diversos fabricants de monitoratge clàssic venen avui línies pròpies d'«observabilitat», i el que decideix és si el producte correlaciona els tres pilars o només vigila llindars.

Substituir una plataforma de monitorització comercial per codi obert al núvol. Quan el contracte d'administració i manteniment de la plataforma actual de monitorització està proper a finalitzar i es considera que els seus costos econòmics no compensen el rendiment que proporciona, l'opció que cal plantejar als caps és establir una solució similar de monitorització al núvol, on els costos són inferiors i l'administració és més àgil. La solució de codi obert que pot cobrir aquesta necessitat és la pila Prometheus + Grafana: Prometheus per a la recol·lecció i l'emmagatzematge de mètriques, i Grafana com a plataforma de visualització que crea panells combinant les mètriques recollides a diverses fonts en un sol quadre de comandament. Aquesta és la formulació literal que ha caigut, i la resposta són aquestes dues eines.

7. Beneficis

• Reducció del MTTR (Mean Time To Repair, temps mitjà de reparació): es passa d'hores de correlació manual a minuts de navegació guiada. És el benefici directe —diagnosticar més de pressa—, i no s'ha de confondre amb la reducció de costos o la millora de la seguretat, que com a molt en són conseqüències indirectes.
• Diagnòstic de problemes no previstos (unknown unknowns), impossibles de detectar amb llindars predefinits.
• Visibilitat extrem a extrem de la transacció, incloent-hi dependències de tercers.
• Detecció proactiva: anomalies i degradacions abans que l'usuari les percebi.
• Base objectiva per a la gestió de problemes, la capacitat i les decisions d'arquitectura. Les mateixes mesures tècniques alimenten els KPI de servei i la millora contínua → tema 22, i el dimensionament de recursos → tema 21.
• Suport als objectius de servei i al pressupost d'error: l'observabilitat és el que fa mesurable la fiabilitat.
• Alineació entre desenvolupament i operació: la mateixa telemetria serveix a tots dos.

8. Reptes d'implantació

1. Volum i cost: la telemetria creix més de pressa que el negoci. Cal mostreig, retencions per capes, agregació i control actiu de la cardinalitat. El cost de l'observabilitat pot superar el de la infraestructura observada si no es governa.
2. Instrumentació del programari heretat: aplicacions antigues sense instrumentació ni codi disponible; solucions parcials amb agents, eBPF o intermediaris.
3. Heterogeneïtat: entorns híbrids amb mainframe, màquines virtuals, contenidors i SaaS, cadascun amb els seus formats.
4. Estandardització: sense convencions comunes de noms, etiquetes i identificadors, la correlació no funciona. És més un problema de govern que tècnic.
5. Fatiga d'alertes: alertes no accionables, duplicades o sense propietari fan que s'ignorin. Cal alertar sobre símptomes visibles per l'usuari i basar-se en objectius de servei, no en llindars de components.
6. Cultura i competències: l'observabilitat exigeix que els equips de desenvolupament instrumentin el seu codi i mirin les dades. Sense això, la plataforma queda com una eina d'operacions.
7. Privadesa i seguretat: els registres i les traces poden contenir dades personals; cal minimització, emmascarament i control d'accés conforme al RGPD, art. 5 i a l'ENS, amb polítiques de retenció alineades.
8. Bloqueig de proveïdor: la instrumentació propietària dificulta el canvi. La mitigació és OpenTelemetry.
9. Governança del cicle de vida: qui crea els quadres de comandament, qui els manté, qui esborra els obsolets.
10. Impacte de la instrumentació: agents i mostreig consumeixen CPU, memòria i xarxa del sistema observat; una plataforma mal dimensionada degrada allò que havia de vigilar.

9. Observabilitat i SRE

L'enginyeria de fiabilitat del servei —SRE (Site Reliability Engineering), formulada per Google— gestiona la fiabilitat amb mètodes d'enginyeria en comptes de per criteri. Fixa objectius mesurables sobre el servei i decideix amb dades quan cal deixar de desplegar canvis i posar-se a estabilitzar. És el vocabulari que millor connecta l'observabilitat amb la gestió de serveis, perquè és el que converteix la telemetria en un criteri de decisió.

• SLI (Service Level Indicator): la mesura concreta —per exemple, el percentatge de peticions ateses en menys de 300 ms.
• SLO (Service Level Objective): l'objectiu intern sobre l'SLI —99,9 % mensual.
• SLA (Service Level Agreement): el compromís extern amb el client, l'únic dels tres que porta penalització.
• Pressupost d'error (error budget): el marge d'incompliment permès (100 % − SLO). Mentre queda pressupost, es pot innovar i desplegar; quan s'esgota, es congela el canvi i es prioritza la fiabilitat.
• Les quatre senyals daurades (golden signals): latència, trànsit, errors i saturació. Són el mínim que s'ha de mesurar de qualsevol servei.
• Mètode RED (Rate, Errors, Duration) per a serveis i mètode USE (Utilization, Saturation, Errors) per a recursos.

SLI ≠ SLO ≠ SLA: l'SLI és la mesura, l'SLO l'objectiu intern i l'SLA el compromís extern. L'SLO s'ha de fixar sempre més exigent que l'SLA, perquè és el marge que avisa abans d'incomplir el contracte.

SRE ≠ DevOps: DevOps enuncia què cal aconseguir —unir desenvolupament i operació—; SRE és una manera concreta i mesurable de fer-ho, amb l'SLO i el pressupost d'error com a mecanisme d'arbitratge entre canviar i estabilitzar.

Claus d'examen

• «Elements de xarxa no monitoritzats, cal un protocol d'intercanvi amb els dispositius» és sempre SNMP, no SSH (Secure Shell: accés remot xifrat, no gestió de xarxa) ni SMTP (Simple Mail Transfer Protocol: correu) (TS-TIC 2023 pràctica, p. 5).
• La parella Prometheus + Grafana cau junta i en aquest ordre: «solució de monitorització al núvol i de codi obert» → Prometheus; «plataforma de visualització amb panells de diverses fonts» i «visualitzar mètriques, logs i traces en temps real» → Grafana. Les distractores no són del ram (JHipster, Angular, MinIO, Velero, Squid) o són eines d'informes de negoci (Power BI (Business Intelligence), Tableau, Excel) (TS-TIC 2023 pràctica, p. 6 i p. 30; TS-TIC 2025 pràctica, p. 14).
• «Quin producte és una plataforma d'observabilitat?» → Instana, d'IBM, davant d'un client de xarxa privada virtual (GlobalProtect), una eina de bases de dades (SqlDeveloper) i un magatzem d'objectes (MinIO): la tècnica és descartar els que fan una altra cosa (TS-TIC 2023 específic, p. 72).
• «Quina arquitectura facilita una observabilitat escalable en microserveis?» → arquitectura en malla de serveis (service mesh). Les altres tres opcions —monolítica, client-servidor i d'igual a igual— descriuen com es reparteix l'aplicació, no com se n'obté la telemetria (TS-TIC 2025 específic, p. 28).
• El benefici que es demana és el diagnòstic, no l'estalvi: «facilitat per diagnosticar errors i temps de resposta més ràpids» guanya a «augment de la productivitat», «millora de la seguretat» i «reducció de costos», que són conseqüències indirectes (TS-TIC 2025 pràctica, p. 13).
• Monitoratge vs. observabilitat: si l'opció diu «comprovar condicions conegudes amb llindars», és monitoratge; si diu «explorar preguntes no previstes», és observabilitat. I Nagios, Zabbix, Centreon, PRTG, Cacti o SolarWinds són eines de monitoratge, no plataformes d'observabilitat: la distinció és la correlació entre els tres pilars.

Per recordar

• Monitoratge = «funciona?» amb condicions conegudes; observabilitat = «per què?» amb exploració de l'inesperat. L'observabilitat inclou el monitoratge.
• Tres pilars: mètriques, registres i traces — i el valor és la correlació entre ells.
• Les tres característiques que fan plataforma: pilars unificats, correlació per identificadors comuns i alta cardinalitat. La resta —temps real, escalabilitat, retenció per capes, govern— decideixen si és sostenible.
• Components, en cadena: instrumentació → recol·lecció → processament → emmagatzematge → consulta i visualització → alerta i resposta.
• OpenTelemetry és l'estàndard obert de generació i exportació de telemetria; evita el bloqueig de proveïdor.
• En microserveis: traçat distribuït amb propagació de context (W3C Trace Context), mostreig de cua i malla de serveis, que és la resposta oficial a «quina arquitectura facilita l'observabilitat escalable».
• Grafana visualitza i Prometheus recull i guarda. Nagios, Zabbix, Centreon, PRTG i SolarWinds són monitoratge; Instana, Dynatrace, Datadog i New Relic són plataformes d'observabilitat.
• Reptes: cost i cardinalitat, heretat sense instrumentar, estandardització, fatiga d'alertes, cultura i dades personals als logs.
• Senyals daurades: latència, trànsit, errors i saturació. RED per a serveis, USE per a recursos.
• SLI = la mesura, SLO = l'objectiu intern, SLA = el compromís extern amb penalització. L'SLO és més exigent que l'SLA.
• SNMP: gestor, agent i MIB; v3 afegeix autenticació i xifratge; TRAP és la notificació no sol·licitada de l'agent; GET/SET consulten i modifiquen.
• Migrar de contracte comercial a codi obert al núvol → Prometheus + Grafana.

Tema 24 · Capacitat, millora i risc

Automatització i orquestració de serveis TIC. Serveis de RPA

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

Abast decidit per nosaltres: l'enunciat oficial no acota la matèria

Enunciat oficial. Automatització i orquestració de serveis TIC. Serveis de RPA.

1. Automatització i orquestració

• Automatització: execució d'una tasca sense intervenció humana.
• Orquestració: coordinació de múltiples tasques automatitzades, sistemes i decisions en un flux extrem a extrem, amb dependències, condicions, gestió d'errors i reintents.

Una tasca s'automatitza; un procés s'orquestra.

Nivells d'automatització a les TIC:

Beneficis: reducció d'errors humans, rapidesa i repetibilitat, traçabilitat i auditoria, alliberament de temps del personal per a tasques de més valor, i coherència entre entorns. Riscos: automatitzar un procés dolent el fa dolent més ràpidament; dependència de scripts sense manteniment; concentració de privilegis en comptes de servei.

Principi d'ITIL (Information Technology Infrastructure Library) 4: «optimitza i automatitza», en aquest ordre. Automatitzar un procés ineficient consolida la ineficiència: els millors processos a automatitzar són els simples i ben entesos, no els que mouen més gent ni els més crítics per al negoci.

1.1 BPM, BPMN, DMN i CMMN

BPM (Business Process Management, gestió de processos de negoci) és una disciplina, no una eina ni un producte: la disciplina per millorar un procés de negoci d'extrem a extrem fent-ne l'anàlisi, modelant-lo en diferents escenaris, executant-lo, monitoritzant-lo i aplicant-hi millora contínua. Els motors BPMN (Camunda, Flowable, Activiti, UC4/Automic) són el suport tècnic que l'implementa, no la disciplina en si.

BPMN (Business Process Model and Notation) és la notació estàndard de l'OMG (Object Management Group) per modelar processos —diagrames de flux amb esdeveniments, activitats i gateways—, adoptada com a norma ISO (International Organization for Standardization) / IEC (International Electrotechnical Commission) 19510. No és exclusiva d'un tipus de producte (ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), BPM): serveix per modelar qualsevol sistema d'informació basat en procediments definits.

L'OMG manté un trio complementari de notacions, cadascuna per a un tipus de treball diferent:

La pregunta que separa les tres notacions és què és el que varia. Si el que està fixat és l'ordre dels passos, es modela en BPMN; si el que canvia és la regla que es decideix dins d'un pas, aquesta regla es treu fora i es modela en DMN; i si no hi ha ordre predefinit perquè el marca qui porta l'assumpte, es modela en CMMN. Separar la regla del flux és precisament el que aporta el DMN: la regla de negoci canvia sovint —un llindar, un barem—, i el procés que la invoca, no.

2. Planificació i orquestració de treballs: UC4/Automic

UC4 Automation Engine (avui Broadcom Automic Automation) és una plataforma de planificació i orquestració de treballs per lots i de processos de negoci molt implantada a l'administració pública i a entorns SAP.

2.1 Arquitectura

Pregunta literal: el component de UC4 que s'instal·la als servidors remots i hi executa les tasques és l'AGENT. El motor decideix; l'agent executa.

2.2 Objectes i conceptes

• Job (JOBS): unitat mínima executable — un script, un programa, un procés SAP, una consulta. És el que fa una tasca concreta en un sistema concret.
• Workflow (JOBP, job plan): contenidor que agrupa i encadena diversos objectes —jobs i altres workflows— definint-ne l'ordre, les dependències i les condicions d'execució.

Relació Job–Workflow: el workflow orquestra jobs; un job pot formar part de diversos workflows i un workflow pot contenir altres workflows (imbricació). El job és la unitat d'execució; el workflow, la unitat d'orquestració. Aquesta és la resposta correcta.

• Altres objectes: Schedule (JSCH) per a execucions periòdiques, Event (EVNT) per a disparadors, Calendar (CALE), Include (JOBI), Notification (CALL), Sync, Queue i Variables (VARA).
• Condicions i dependències: precondicions, postcondicions, condicions de dependència entre tasques, gestió de codis de retorn (return codes) i reintents.

3. RPA — Robotic Process Automation

RPA (Robotic Process Automation, automatització robotitzada de processos): tecnologia que utilitza robots de programari que imiten les accions d'un usuari humà sobre la interfície gràfica de les aplicacions per executar processos repetitius i basats en regles.

3.1 Com interactua amb els sistemes

Els robots RPA interactuen amb els sistemes informàtics de la mateixa manera que ho faria una persona: a través de la capa de presentació (la interfície d'usuari), fent clics, escrivint, llegint pantalles i navegant per menús. Per això no requereixen modificar les aplicacions existents ni integracions per API (Application Programming Interface, interfície de programació d'aplicacions), i poden treballar amb sistemes heretats que no ofereixen cap altra via d'integració.

Tècniques de reconeixement: selectors de l'arbre d'interfície (UI (User Interface) Automation, HTML (HyperText Markup Language) DOM (Document Object Model), Java Access Bridge), coordenades de pantalla, OCR (Optical Character Recognition, reconeixement òptic de caràcters) i reconeixement d'imatge. Complementàriament poden usar API, bases de dades i fitxers quan estan disponibles, cosa que sempre és preferible per robustesa.

3.2 Tipus

• RPA atès (attended): s'executa a l'escriptori de l'usuari i el complementa; el dispara la persona.
• RPA no atès (unattended): s'executa en servidors sense intervenció humana, planificat o per esdeveniments.
• RPA híbrid.

3.3 Quan és adequat i quan no

Bons candidats: processos d'alt volum, repetitius, basats en regles clares, amb dades estructurades, estables i que travessen múltiples sistemes sense integració.

Mals candidats: processos que exigeixen judici, que canvien sovint, amb entrades no estructurades, amb excepcions freqüents, o de volum baix (no compensa).

3.4 Casos d'ús típics a l'Administració

• Conciliació de dades entre sistemes desconnectats: copiar i verificar dades entre el registre d'entrada, el gestor d'expedients i sistemes de tercers (cadastre, padró) que no tenen API comuna.
• Extracció de dades de formularis i documents cap al sistema de gestió d'expedients, sovint combinada amb IDP per a entrades no estructurades.
• Altes, baixes i modificacions massives en aplicacions sense servei web propi (usuaris, permisos, dades de padró).
• Conciliació i tancament comptable, creuament de factures i pagaments.
• Generació i enviament massiu de notificacions i comunicacions a partir de dades ja validades.
• Migració de dades entre aplicacions heretades durant una substitució de sistema.

El denominador comú: sistemes legacy sense API amb els quals cal interactuar «com si fos una persona», i volum prou alt perquè valgui la pena.

3.5 Limitacions davant la IA

Limitació clau del RPA respecte dels sistemes amb IA (Intel·ligència Artificial): el RPA només executa regles predefinides i no aprèn ni s'adapta. No pot gestionar variabilitat, ambigüitat ni dades no estructurades, i qualsevol canvi a la interfície de l'aplicació (posició d'un camp, canvi d'etiqueta, nova versió) trenca el robot i obliga a reprogramar-lo. La IA, en canvi, generalitza a partir de dades i tolera la variació.

Altres limitacions: fragilitat davant canvis, dificultat d'escalar sense governança, deute tècnic acumulat («automatitzar el caos»), i el fet que el RPA no soluciona el problema de fons: és un pegat sobre la manca d'integració.

3.6 La combinació: automatització intel·ligent

• IPA (Intelligent Process Automation) o hiperautomatització: RPA + IA/ML (classificació, extracció) + IDP (Intelligent Document Processing, OCR + NLP (Natural Language Processing, processament del llenguatge natural)) + process mining + BPM.
• Process mining (Celonis, Disco, ProM): descobreix el procés real a partir dels registres d'esdeveniments dels sistemes, i identifica on hi ha valor a automatitzar. Task mining fa el mateix a l'escriptori.
• Agents d'IA: nova generació que executa tasques amb capacitat de raonament i ús d'eines, superant la rigidesa del RPA clàssic.

3.7 Plataformes

Sigui quin sigui el fabricant, una plataforma de RPA reparteix la feina en tres papers, i cadascun té el seu component:

Els noms canvien de fabricant a fabricant, però els tres papers no, i la confusió que cau a l'examen és sempre entre el primer i el tercer: qui dissenya el flux no és qui l'executa en màquines remotes.

UiPath, Automation Anywhere, Blue Prism, Microsoft Power Automate (Desktop), Robocorp, Automagica.

Arquitectura d'UiPath — component per component:

Dues preguntes literals: el component que dissenya i desenvolupa fluxos és Studio; el que executa robots en màquines remotes i els gestiona centralitzadament és l'Orchestrator.

3.8 Governança del RPA

• Centre d'excel·lència (CoE) que estandarditzi, revisi i mantingui els robots.
• Cicle de vida: identificació → avaluació de viabilitat i ROI (Return On Investment, retorn de la inversió) → disseny (PDD, Process Definition Document) → desenvolupament (SDD, Solution Design Document) → proves → desplegament → manteniment. El manteniment és la partida que més es subestima.

- Seguretat: els robots tenen credencials pròpies i sovint privilegis elevats —un robot és, a efectes de seguretat, un usuari més amb credencials, que sovint ningú revisa amb la mateixa disciplina que les d'una persona—. Cal magatzem de credencials (l'Orchestrator té Assets i Credential Store, integrable amb CyberArk), identitats nominatives per robot, principi de mínim privilegi i segregació de funcions —els mateixos requisits que l'ENS (Esquema Nacional de Seguretat) exigeix per al control d'accés (op.acc) de qualsevol identitat—, i registre d'auditoria complet. - Protecció de dades: si el robot tracta dades personals, l'organització continua sent responsable del tractament; cal incloure'l al registre d'activitats i valorar-ne l'impacte. Si el robot pren decisions automatitzades amb efectes sobre una persona, aplica l'RGPD, art. 22. - Continuïtat: què passa si el robot cau? Ha d'haver-hi procediment manual de reserva. - Fragilitat: es trenca amb qualsevol canvi de la pantalla que imita, i multiplica un error a velocitat de màquina si ningú el revisa: la governança no és un tràmit, és el que evita que un robot dolent faci mal ràpid.

3.9 RPA, automatització de workflow i iPaaS

L'automatització de flux de treball (workflow) és la que fa un motor de procés: executa un procés modelat prèviament —normalment en BPMN— encadenant tasques automàtiques i tasques humanes amb regles, aprovacions, terminis i excepcions. És la implementació tècnica de la disciplina BPM, i no s'ha de confondre amb ella: el BPM és la disciplina; el motor de workflow, l'eina que n'executa el model.

Les tres automatitzen, però a capes diferents i amb un mecanisme diferent:

iPaaS (Integration Platform as a Service, plataforma d'integració com a servei): servei al núvol que connecta aplicacions i fonts de dades entre si mitjançant API i connectors predefinits, sense necessitat d'infraestructura pròpia. No imita cap interfície ni orquestra tasques humanes: connecta sistemes. Comparteix amb el low-code l'enfocament visual amb poc codi, però no és RPA ni construeix aplicació nova → low-code i no-code.

El que les separa és per on entra l'automatisme al sistema de destinació, i per això la tria no és de gust:

• l'aplicació publica una API → la integració es fa per API i és feina de l'iPaaS;
• l'aplicació no publica cap API i només s'hi pot entrar per la pantalla → és feina del RPA;
• el que cal coordinar no són sistemes sinó passos, persones i aprovacions → és feina del motor de workflow.

D'aquí ve que el RPA es descrigui com un pegat davant la manca d'integració: el dia que el sistema publica una API, la integració el substitueix, mentre que el motor de workflow i l'iPaaS no competeixen entre si —resolen problemes diferents i sovint conviuen al mateix procés.

4. Automatització a l'ITSM i AIOps

• Autoservei i compliment automàtic de peticions → tema 18.
• Autoremediació (self-healing): l'esdeveniment dispara automàticament una acció de correcció (reiniciar un servei, ampliar disc, escalar instàncies) i registra l'incident.
• Canvis estàndard automatitzats: preautoritzats i executats per pipeline → tema 19.
• AIOps: aplicació d'IA a les operacions — reducció de soroll d'alertes, correlació, detecció d'anomalies, predicció de fallides i suggeriment de causa arrel → tema 23.
• ChatOps i assistents conversacionals per a l'atenció d'usuari.

5. Al sector públic

• Actuació administrativa automatitzada (Llei 40/2015, art. 41): acte o actuació realitzada íntegrament a través de mitjans electrònics en el marc d'un procediment administratiu i en la qual no hagi intervingut de forma directa un empleat públic. Aquesta definició és el criteri que decideix si un robot hi entra: un robot no atès que dicta l'acte hi entra; un robot que només prepara una proposta que després resol una persona, no —hi ha intervenció directa. Quan hi entra, cal establir prèviament l'òrgan competent per a la definició d'especificacions, programació, manteniment, supervisió i control de qualitat i, si escau, l'auditoria del sistema d'informació i del seu codi font, i indicar l'òrgan responsable a efectes d'impugnació. El règim general d'aquests articles el desenvolupa l'administració electrònica i els serveis digitals; aquí només el que li toca a un robot.
• Sistemes de signatura de l'actuació automatitzada (Llei 40/2015, art. 42) — en són dos, i cada Administració determina en quins supòsits fa servir cadascun: el segell electrònic de l'Administració, òrgan, organisme públic o entitat de dret públic, basat en un certificat electrònic reconegut o qualificat; i el CSV (Codi Segur de Verificació) vinculat a l'Administració, que permet en tot cas comprovar la integritat del document accedint a la seu electrònica. Un robot no signa amb el certificat d'una persona: signa amb el segell de l'òrgan.
• Transparència algorítmica: si l'automatització incorpora decisions basades en algoritmes, són aplicables l'RGPD, art. 22 (decisions individuals automatitzades) i la Mesura de govern d'IA municipal → temes 29 i 30.
• La contractació dels serveis de RPA ha de preveure la propietat dels robots i del codi, la reversibilitat i la documentació de manteniment, segons la Mesura de digitalització oberta.

Claus d'examen

• BPM no és una eina ni un ERP/CRM/BI (Business Intelligence): és la disciplina de millorar un procés d'extrem a extrem amb anàlisi, modelatge, execució i millora contínua (TS-TIC 2018, p. 10).
• BPMN són sigles de «Business Process Model and Notation», no «Protocol» ni «Networking» —el distractor confon la notació amb un protocol de xarxa (TS-TIC 2018, p. 24).
• UC4: l'Agent (no el «Runner» ni el «Client GUI» —Graphical User Interface—) és qui s'instal·la als servidors remots i executa (TS-TIC 2025 específic, p. 36); i un Job és una tasca individual, mentre que un Workflow és la seqüència de Jobs amb dependències (TS-TIC 2025 específic, p. 35).
• UiPath: Studio dissenya fluxos (TS-TIC 2025 pràctica, p. 25); Orchestrator executa i gestiona robots en remot de forma centralitzada (TS-TIC 2025 específic, p. 33).
• La limitació del RPA davant la IA és que no s'adapta a canvis sense reprogramació (TS-TIC 2025 específic, p. 34); i interactua per la interfície gràfica de l'usuari, no cridant API (TS-TIC 2025 pràctica, p. 28).
• Segons ITIL, els millors processos per automatitzar són els simples i ben entesos, no els que mouen més gent ni els més crítics per al negoci (TS-TIC 2021, p. 45).

Per recordar

• Automatització = una tasca; orquestració = un procés amb dependències. Primer optimitza, després automatitza.
• BPM és una disciplina de millora contínua (anàlisi, modelatge, execució, monitoratge); BPMN és la notació de l'OMG —norma ISO/IEC 19510— per modelar-la. El trio de l'OMG: BPMN el procés, DMN la decisió, CMMN el cas.
• UC4: el motor planifica, l'agent s'instal·la als servidors remots i executa. El Job és la unitat executable; el Workflow els agrupa i encadena definint ordre i dependències.
• El RPA interactua per la interfície d'usuari, com ho faria una persona: no cal modificar les aplicacions.
• RPA, workflow i iPaaS no són el mateix, i el que els separa és per on entren al sistema: el RPA per la pantalla (quan no hi ha API), el motor de workflow pel procés modelat (quan cal coordinar passos, persones i aprovacions), i l'iPaaS per l'API (quan dues aplicacions han d'intercanviar dades).
• Tota plataforma de RPA reparteix la feina en tres papers amb noms diferents segons el fabricant: disseny, robot que executa i orquestrador que desplega, planifica i custodia credencials. Qui dissenya no és qui executa en remot.
• Limitació del RPA respecte de la IA: només segueix regles predefinides, no aprèn, i es trenca si canvia la interfície.
• UiPath: Studio dissenya, Robot executa, Orchestrator gestiona i executa robots en màquines remotes de forma centralitzada.
• Els robots necessiten credencials pròpies, mínim privilegi i auditoria —el mateix op.acc que exigeix l'ENS per a qualsevol identitat—.
• És actuació administrativa automatitzada l'acte fet íntegrament per mitjans electrònics sense intervenció directa d'un empleat públic: cal òrgan competent per a especificacions, programació, manteniment, supervisió i control de qualitat, si escau auditoria del sistema i del seu codi font, i òrgan responsable a efectes d'impugnació.

Tema 25 · Capacitat, millora i risc

El servei d'Atenció a l'Usuari

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

Enunciat oficial. El servei d'Atenció a l'Usuari: estructura organitzativa, funcions i eines.

1. Concepte i rol

Service Desk (Centre de Servei a l'Usuari): a ITIL (Information Technology Infrastructure Library) v3 és una funció; a ITIL 4, una pràctica. El seu propòsit és capturar la demanda de resolució d'incidents i de peticions de servei, i ser el punt d'entrada i únic punt de contacte (SPOC — Single Point of Contact) entre el proveïdor de serveis i tots els seus usuaris.

El rol que li correspon és el de punt únic de contacte per a l'usuari i propietari de tots els incidents i peticions durant tot el seu cicle de vida. Això vol dir:

• Rep totes les comunicacions dels usuaris, sigui quin sigui el canal.
• Registra i classifica absolutament tot, també el que resol immediatament.
• Resol el que pot al primer nivell.
• Escala funcionalment o jeràrquicament el que no pot resoldre, però manté la titularitat: continua sent el responsable davant l'usuari fins al tancament.
• Comunica l'estat, gestiona les expectatives i tanca amb la confirmació de l'usuari.

Afirmacions certes que cauen a l'examen sobre el Service Desk:

• És el punt únic de contacte, no un simple centre de trucades.
• Manté la propietat de l'incident encara que l'escali.
• El seu valor principal no és tècnic sinó de relació: és la cara visible de TI (Tecnologies de la Informació) davant l'organització i el que més determina la percepció de qualitat del servei.
• La seva funció no és resoldre-ho tot, sinó garantir que tot es resol i que l'usuari ho sap.
• Ha de tenir habilitats de comunicació i empatia tant com competències tècniques.

El que NO és responsabilitat del Service Desk: gestionar la infraestructura, dissenyar serveis, autoritzar canvis normals, ni fer la gestió de problemes (hi contribueix aportant informació, però no la lidera). Tampoc és responsable dels SLA —això és la gestió del nivell de servei— ni una eina tecnològica que resol sola: és una funció organitzativa, i l'eina ITSM només la sosté.

Les altres tres funcions d'ITIL v3, que són les distractores habituals. A ITIL v3 el Centre de Servei a l'Usuari és una de les quatre funcions de l'Operació del Servei, i el que cau és atribuir-li el que fan les altres:

El marc general d'ITIL —el cicle de vida del servei d'ITIL v3 i la cadena de valor d'ITIL 4— no es repeteix aquí → tema 14.

2. Funcions

1. Registre i categorització de tots els contactes.
2. Priorització segons impacte i urgència.
3. Diagnòstic i resolució de primer nivell, amb l'objectiu de maximitzar la resolució al primer contacte (FCR).
4. Compliment de peticions de servei estandarditzades.
5. Escalat funcional i jeràrquic.
6. Comunicació proactiva: incidències majors, manteniments planificats, canvis que afecten els usuaris.
7. Gestió del cicle de vida del tiquet fins al tancament amb confirmació.
8. Enquestes de satisfacció i recollida de retroalimentació.
9. Alimentació de la base de coneixement amb solucions i preguntes freqüents.
10. Detecció de tendències que alimenten la gestió de problemes.
11. Actualització de la CMDB amb el que descobreix a cada contacte, sota els procediments acordats amb la gestió de la configuració. El Service Desk no en queda al marge: és qui té l'usuari al telèfon i qui detecta que el registre no s'assembla a la realitat.
12. Canalització de les peticions de canvi cap a la gestió de canvis. Les canalitza; no les autoritza, que és la confusió que cau.

3. Estructures organitzatives

Nivells de suport:

• Nivell 0 — autoservei: portal, base de coneixement, FAQ (Frequently Asked Questions), restabliment autònom de contrasenya, xatbot. Desvia volum i és el més barat per contacte.
• Nivell 1 — Service Desk: primer contacte, resolució ràpida amb guions i base de coneixement.
• Nivell 2 — especialistes per àmbit (lloc de treball, xarxa, aplicacions, SAP).
• Nivell 3 — experts, arquitectura, desenvolupament.
• Nivell 4 — proveïdors i fabricants, per contracte de suport (UC, Underpinning Contract) → tema 20.

Objectiu de disseny: desplaçar el volum cap avall (shift left): que el nivell 2 documenti perquè el nivell 1 pugui resoldre, i que el nivell 1 documenti perquè l'usuari pugui autoservir-se.

L'escalat: dues escales que no són alternatives. Quan el nivell 1 no pot tancar el contacte, aquest puja — i puja per dos eixos diferents, que sovint s'activen alhora:

• Escalat funcional (horitzontal): es passa a un grup amb més coneixement tècnic —nivell 2, nivell 3, el fabricant—. El motiu és la competència: aquí no ho saben fer.
• Escalat jeràrquic (vertical): s'avisa la línia de comandament. El motiu no és tècnic: és la gravetat de l'incident, o la manca de recursos o d'autoritat per prendre una decisió (autoritzar una parada, comprometre un pressupost, activar un proveïdor fora d'hores).

Escalar no és transferir: el Service Desk conserva la titularitat del tiquet i segueix sent qui respon davant l'usuari fins al tancament. El cicle de vida complet de la gestió d'incidents i de la gestió de peticions es desenvolupa al tema 18.

Rols: agent de primer nivell, supervisor de torn, gestor del Service Desk, gestor d'incidents majors, gestor de coneixement, analista de qualitat.

Dimensionament: es calcula a partir del volum de contactes, el temps mitjà de gestió (AHT), els horaris de cobertura i el nivell de servei objectiu, amb models de cues (Erlang C per a canal telefònic). Cal preveure ocupació màxima del 75-85 % per absorbir els pics.

4. Canals

Els canals: telèfon, portal web d'autoservei, correu electrònic, xat, xatbot i assistents virtuals, presencial (walk-up / tech bar), aplicació mòbil, integració amb eines de col·laboració (Teams, Slack) i suport remot assistit.

Multicanal no és omnicanal, i la distinció és pregunta clàssica:

• Multicanal només vol dir que hi ha diversos canals oberts. Cadascun pot tenir la seva cua, el seu registre i la seva gent: l'usuari que ha trucat i després escriu, torna a explicar-ho tot.
• L'omnicanalitat vol dir que la conversa és la mateixa canviï el canal que canviï: l'usuari no ha de repetir el context, i l'agent que el recull veu el que va passar als altres canals. La condició tècnica per aconseguir-ho és un únic sistema de tiquets darrere de tots els canals; obrir un canal nou sense integrar-lo hi resta, no hi suma.

Autoservei: el canal de creixement. Requereix una base de coneixement de qualitat, un catàleg de peticions ben publicat i cerca eficaç. La mètrica associada és la taxa de desviament (deflection rate).

Segmentació del missatge: en els canals d'atenció massiva (xarxes socials, portal, campanyes informatives) el missatge no és el mateix per a tothom. La segmentació és la tècnica comunicativa que adapta el contingut, el to i el canal a cada grup de destinataris (per edat, per necessitat, per col·lectiu) en lloc d'emetre un missatge únic. El seu objectiu és reforçar la connexió amb els destinataris, no simplificar el contingut (això és claredat) ni estructurar una narrativa (storytelling) ni avaluar resultats (analítica).

5. Eines

Requisits d'una bona eina ITSM: flux configurable sense programar, catàleg de serveis integrat, portal d'autoservei, base de coneixement, CMDB, gestió d'SLA (Service Level Agreement) amb rellotges que s'aturen (temps d'espera de l'usuari, calendaris laborals), automatització de tasques, informes i API (Application Programming Interface) oberta.

6. Mètriques

FCR i MTTR no mesuren el mateix, i es poden moure en direccions contràries. És la contraposició que cau:

Un Service Desk que escala de seguida tot el que li costa pot lluir un MTTR excel·lent amb un FCR pèssim; i un que reté l'usuari al telèfon mentre el nivell 1 hi rumia pot lluir el contrari. Per això cap de les dues es llegeix sola.

Compte amb la sigla: MTTR s'expandeix de quatre maneres —Resolution, Repair, Recovery i Respond— i no mesuren el mateix; l'enunciat sol dir de quina parla, i aquí s'usa el temps mitjà fins a la resolució.

Equilibri: mesurar només velocitat degrada la qualitat; mesurar només satisfacció amaga la ineficiència. Cal parells contrapesats → tema 22.

7. L'atenció a l'usuari a l'Ajuntament de Barcelona

Cal distingir dos serveis d'atenció diferents:

• Atenció a la ciutadania: la porta la Direcció de Serveis d'Informació i Atenció Ciutadana. És atenció al ciutadà, no suport TIC (Tecnologies de la Informació i la Comunicació).
• Atenció a l'usuari intern (empleat municipal): el CAU (Centre d'Atenció a l'Usuari) del BIT (Barcelona Innovació i Tecnologia, l'antic IMI, Institut Municipal d'Informàtica), que dona suport al lloc de treball, a les aplicacions corporatives i a la infraestructura, normalment amb un model centralitzat amb suport de camp, catàleg propi i eina ITSM corporativa.

Els canals d'atenció ciutadana, que el tribunal pregunta un per un:

La bústia ètica i de bon govern és el canal en línia per comunicar males pràctiques i possibles casos de corrupció, i el que la caracteritza és que garanteix la confidencialitat i l'anonimat de qui informa. És un canal de comunicació ciutadana com els altres, no un servei intern.

Particularitats del sector públic:

• Els compromisos davant el ciutadà es formalitzen en cartes de servei, que es classifiquen per abast → tema 20. La transparència i el dret a la informació que hi ha al darrere són de la Llei 19/2013 i de la Llei 19/2014.
• Els terminis legals de resposta (Llei 39/2015, art. 21) actuen com un SLA no negociable per a la tramitació.
• L'assistència en l'ús de mitjans electrònics és un dret de la ciutadania (Llei 39/2015, art. 12) i una obligació de l'Administració, amb la figura del funcionari habilitat.
• L'accessibilitat dels canals digitals és obligatòria: el RD (Reial Decret) 1112/2018 estableix el nivell WCAG (Web Content Accessibility Guidelines) 2.1 AA.
• La bretxa digital obliga a mantenir canals no electrònics per a les persones físiques, que poden triar el canal (Llei 39/2015, art. 14).

Claus d'examen

• La segmentació és una tècnica comunicativa, no d'anàlisi ni de redacció: serveix per reforçar la connexió amb els destinataris, adaptant el missatge a cada col·lectiu (TS-TIC 2018, p. 65).
• L'Ajuntament de Barcelona gestiona l'atenció ciutadana a les xarxes socials amb Hootsuite: programació de continguts, optimització de temps i recursos, i seguiment mitjançant l'historial (TS-TIC 2021, p. 16).
• L'activitat que és responsabilitat directa del Service Desk a ITIL v3 és registrar totes les incidències i peticions. Les tres distractores són les altres funcions: supervisar l'execució i el monitoratge dels esdeveniments operatius és de la Gestió d'Operacions de TI, aportar els recursos per dissenyar, construir i desplegar tecnologia és de la Gestió Tècnica, i els contractes d'instal·lacions externalitzades, de la Gestió d'Instal·lacions (TS-TIC 2025, p. 29).
• El seu rol és ser el punt únic de contacte, i les altres tres opcions són sempre les mateixes: que «només registra i deriva», que és «una eina tecnològica que automatitza la resolució» i que «gestiona els SLA i la configuració». Cap ho és (TS-TIC 2025 pràctica, s2-p11).
• Sí que participa en la CMDB: la resposta certa és que coordina la gestió d'incidències, manté la CMDB actualitzada i canalitza les peticions de canvi. La distractora fina diu que és el punt únic de contacte «però no participa en la gestió de la CMDB» (TS-TIC 2025 pràctica, s2-p12).
• El 010 no és l'únic canal telefònic de l'Ajuntament amb la ciutadania: aquesta és l'afirmació falsa. Sí que ho són la bústia ètica com a canal en línia, els quioscos de tràmits com a canal presencial i l'existència d'oficines especialitzades d'atenció presencial (TS-TIC 2021, p. 87).

Per recordar

• El Service Desk és el punt únic de contacte i manté la propietat del tiquet encara que l'escali.
• Registra-ho tot, també el que es resol al primer contacte.
• És funció a ITIL v3 i pràctica a ITIL 4.
• Estructures: local, centralitzat, virtual, segueix el sol i especialitzat.
• Shift left: desplaçar la resolució cap a nivells més baixos i, finalment, cap a l'autoservei.
• Escalat funcional (falta coneixement tècnic) ≠ escalat jeràrquic (falta autoritat o hi ha gravetat). No són alternatives: sovint es fan els dos.
• Multicanal és tenir canals; omnicanal és que la conversa no es trenqui en canviar-ne.
• FCR, MTTR, taxa de reobertura, CSAT i taxa de desviament són les mètriques nucli; l'AHT s'ha de vigilar, no optimitzar.
• L'FCR és un percentatge i l'MTTR és un temps: escalar-ho tot de seguida millora l'MTTR i enfonsa l'FCR.
• A l'Ajuntament, l'OAC i el 010 atenen la ciutadania; el CAU del BIT (l'antic IMI) atén l'usuari intern.
• El 010 no és l'únic telèfon municipal, i la bústia ètica és un canal d'atenció ciutadana en línia.
• L'assistència en l'ús de mitjans electrònics és un dret de la ciutadania, amb el funcionari habilitat com a instrument.

Tema 26 · Capacitat, millora i risc

Gestió del risc en ITIL v4

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

Enunciat oficial. Gestió del risc en ITIL v4.

1. Concepte

Risc: esdeveniment possible que podria causar dany o pèrdua, o dificultar l'assoliment dels objectius. També es pot definir com la incertesa del resultat, i pot ser positiu (oportunitat) o negatiu (amenaça).

Gestió de riscos (pràctica d'ITIL 4) — propòsit: assegurar que l'organització comprèn i tracta els riscos de manera eficaç, com a element essencial per garantir la sostenibilitat de l'organització i la cocreació de valor amb els clients.

Termes:

• Apetit al risc (risk appetite): quantitat i tipus de risc que una organització està disposada a assumir per assolir els seus objectius.
• Tolerància al risc: desviació acceptable respecte de l'apetit, per a un risc concret.
• Llindar de risc (risk threshold): nivell a partir del qual cal actuar o escalar.
• Risc inherent: el que existeix abans d'aplicar controls. Risc residual: el que queda després dels controls. Risc secundari: el que apareix com a conseqüència d'una resposta.
• Propietari del risc: qui respon de la seva gestió. Cada risc n'ha de tenir un, i ha de ser una persona, no un departament.

2. El procés

Aquest és, essencialment, el procés de la ISO 31000 (gestió del risc) que ITIL 4 adopta.

1. Establir el context: abast, criteris de risc, apetit, parts interessades.
2. Identificació: pluges d'idees, entrevistes, llistes de verificació, anàlisi de dependències, revisió d'incidents i problemes previs, anàlisi DAFO (Debilitats, Amenaces, Fortaleses, Oportunitats), PESTLE (Polític, Econòmic, Social, Tecnològic, Legal, Ambiental), escenaris.
3. Anàlisi: determinar probabilitat i impacte. Pot ser qualitativa (escales alta/mitjana/baixa, matrius de colors), semiquantitativa (escales numèriques) o quantitativa (valor monetari esperat, ALE (Annualized Loss Expectancy, pèrdua anual esperada) = SLE (Single Loss Expectancy, pèrdua per incident) × ARO (Annualized Rate of Occurrence, freqüència anual), simulació de Monte Carlo).
4. Avaluació: comparar el nivell de risc amb els criteris i prioritzar; decidir quins es tracten.
5. Tractament: aplicar una de les estratègies.
6. Monitoratge i revisió: reavaluar periòdicament, verificar l'eficàcia dels controls i actualitzar el registre.

Registre de riscos (risk register): per a cada risc, descripció, categoria, causa, probabilitat, impacte, nivell, propietari, controls actuals, resposta prevista, risc residual, indicadors i estat.

Matriu de probabilitat i impacte: quadrícula 3×3 o 5×5 que classifica els riscos en zones (baix, moderat, alt, crític). És l'eina d'avaluació qualitativa més usada.

3. Estratègies de tractament

Per a amenaces:

Per a oportunitats: explotar, millorar, compartir, acceptar i escalar.

Tipus de controls: preventius (eviten que passi), detectius (avisen que ha passat), correctius (redueixen l'impacte un cop passat) i dissuasius. Es classifiquen també en tècnics, organitzatius i físics.

4. On viu el risc dins d'ITIL 4

La gestió de riscos no és un procés aïllat: travessa tot el Sistema de Valor del Servei.

• Governança: l'òrgan de govern fixa l'apetit al risc i el monitora → tema 15.
• Principis guia: «progressar iterativament amb retroalimentació» és, de fet, una estratègia de reducció de risc; «pensar i treballar holísticament» evita els riscos de les optimitzacions locals.
• Cadena de valor: cada activitat genera i tracta riscos.
• Altres pràctiques que incorporen risc:
• Control de canvis: avaluació de risc de cada canvi → tema 19.
• Gestió de la seguretat de la informació: risc de confidencialitat, integritat i disponibilitat → tema 66.
• Gestió de la continuïtat del servei: risc de discontinuïtat, amb BIA (Business Impact Analysis, anàlisi d'impacte de negoci) i anàlisi de riscos → tema 58.
• Gestió de proveïdors: risc de tercers i de cadena de subministrament.
• Gestió de la disponibilitat i de la capacitat: risc de saturació i d'indisponibilitat → tema 21.
• Gestió de projectes → tema 11.
• Gestió d'incidents i problemes: materialització del risc i eliminació de causes → tema 18.

5. Marcs de referència del risc

• ISO 31000 — Gestió del risc. Directrius. No és certificable. Aporta principis, marc de referència i procés. Els seus principis: creació i protecció de valor, integrada, estructurada i exhaustiva, adaptada, inclusiva, dinàmica, millor informació disponible, factors humans i culturals, i millora contínua.
• ISO / IEC (International Electrotechnical Commission) 27005 — gestió de riscos de seguretat de la informació, aplicada al SGSI (Sistema de Gestió de la Seguretat de la Informació) de la ISO/IEC 27001.
• MAGERIT v3 — metodologia d'anàlisi i gestió de riscos dels sistemes d'informació de l'Administració espanyola, elaborada pel Consell Superior d'Administració Electrònica (el nom no és un acrònim estricte de lletra per lletra, és el nom propi de la metodologia). Identifica actius, amenaces, vulnerabilitats, salvaguardes, impacte i risc, i distingeix impacte i risc potencial (sense salvaguardes) de residual (amb salvaguardes). L'eina de suport és PILAR, del CCN (Centre Criptològic Nacional) — tampoc un acrònim de lletra per lletra.
• ENS: exigeix anàlisi i gestió de riscos com a primer principi bàsic (art. 6) i com a requisit mínim (art. 12: «gestió de la seguretat basada en els riscos»). La categorització del sistema i la selecció de mesures dels annexos deriven de l'anàlisi de riscos → tema 66.
• COSO (Committee of Sponsoring Organizations of the Treadway Commission) ERM (Enterprise Risk Management) — marc de gestió del risc empresarial.
• NIST (National Institute of Standards and Technology) RMF (Risk Management Framework) i NIST SP (Special Publication) 800-30 — gestió de riscos de seguretat.
• FAIR (Factor Analysis of Information Risk) — quantificació econòmica del risc d'informació.

Frontera amb PMBOK. Aquests són marcs de risc; no és aquí on es desenvolupa el PMBOK (Project Management Body of Knowledge), que és el marc de gestió de projectes del PMI (Project Management Institute). El risc de projecte —amb la mateixa distinció amenaça/oportunitat i termes com apetit o tolerància— es regeix per aquell marc i es desenvolupa a tic/pmbok-rendimiento-riesgos-y-cierre; aquí només el risc de servei que gestiona ITIL (Information Technology Infrastructure Library).

6. Risc i compliment

• El risc de compliment (compliance) és la possibilitat de sancions, pèrdues o dany reputacional per incompliment normatiu. A l'Administració és especialment rellevant: protecció de dades, ENS, contractació, transparència, accessibilitat.
• Programa de compliance vs sistema de gestió de compliance → tema 15: el primer és el conjunt de mesures i controls; el segon és l'estructura certificable, cíclica i documentada (ISO 37301) que el conté i el manté.
• Canal d'alertes: mecanisme confidencial de comunicació d'incompliments, amb prohibició de represàlies, obligatori per la Llei 2/2023 → tema comú 18.
• Tres línies: gestió operativa i controls · funcions de risc i compliment · auditoria interna independent.

7. Riscos típics d'un servei TIC

Categories de risc d'un servei TIC (Tecnologies de la Informació i la Comunicació), amb exemples típics:

Mesures transversals més rendibles: còpies de seguretat provades i immutables (ENS i tema 57), autenticació multifactor, mínim privilegi, gestió de vulnerabilitats i pedaços, segmentació de xarxa, documentació i formació, i plans de continuïtat provats.

Claus d'examen

• No confonguis el risc de projecte amb el risc de servei. Una pregunta que parla del «risc general del projecte i els riscos individuals», o d'una «resposta als riscos» que ha de «reduir al mínim les amenaces i maximitzar les oportunitats», és PMBOK (planificació de la resposta als riscos), no ITIL (TS-TIC 2021, específic, p. 55). Aquí es gestiona el risc de servei.
• Programa de compliance ≠ sistema de gestió de compliance. El programa és el conjunt de mesures i controls; el sistema és l'estructura certificable i documentada (ISO 37301) que el conté (TS-TIC 2025, pràctica, p. 24).
• El canal d'alertes serveix per comunicar possibles incompliments de manera segura i confidencial, no per recollir suggeriments ni per informar de canvis normatius (TS-TIC 2025, pràctica, p. 29).
• Apetit no és tolerància: l'apetit és quant risc es vol assumir en general; la tolerància és la desviació acceptable per a un risc concret.

Per recordar

• Risc = esdeveniment possible que pot causar dany o dificultar l'assoliment d'objectius; pot ser amenaça o oportunitat.
• Apetit = quant risc es vol assumir; tolerància = desviació acceptable; llindar = quan cal actuar.
• Inherent → controls → residual. Les respostes poden generar riscos secundaris.
• Procés (ISO 31000): context, identificació, anàlisi, avaluació, tractament, monitoratge, amb comunicació contínua.
• Estratègies: evitar, reduir, transferir, acceptar, escalar. La responsabilitat última no es transfereix mai.
• Controls: preventius, detectius, correctius i dissuasius.
• MAGERIT és la metodologia de l'Administració espanyola; l'eina és PILAR; distingeix risc potencial i residual.
• L'ENS exigeix la gestió de la seguretat basada en els riscos com a principi bàsic.
• Cada risc ha de tenir un propietari que sigui una persona.

Tema 27 · Capacitat, millora i risc

Gestió financera dels serveis en ITIL v4

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

Enunciat oficial. Gestió financera dels serveis en ITIL v4.

1. Propòsit

Gestió financera del servei (ITIL (Information Technology Infrastructure Library) 4) — propòsit: donar suport a les estratègies i plans de l'organització per a la gestió de serveis assegurant que els recursos i les inversions financeres de l'organització s'utilitzen de manera efectiva.

Funció principal dins de l'Estratègia del Servei (ITIL v3): quantificar en termes econòmics el valor dels serveis de TI i dels actius que els suporten, i proporcionar a la direcció la informació financera necessària per prendre decisions sobre inversió, priorització i prestació dels serveis, assegurant un finançament adequat per al lliurament i el consum dels serveis.

Dit d'una altra manera, la seva funció és traduir la TI (Tecnologies de la Informació) a llenguatge de diners perquè es pugui decidir amb criteri: quant costa cada servei, quant val per al negoci i si val la pena.

1.1 Les dades que aporta a l'estratègia i al disseny

La gestió financera agrega, afina i distribueix dades de cost que serveixen a dues altres pràctiques, i no a d'altres:

• A l'estratègia del servei: per determinar l'impacte financer dels canvis en els serveis TIC (Tecnologies de la Informació i la Comunicació) abans de decidir-los.
• Al disseny del servei: per conèixer el cost del model de gestió triat per a un servei —intern, extern o híbrid.

El que no aporta: fixar l'estructura d'un servei és una decisió de disseny, no una dada financera; i estimar el pressupost d'un projecte concret és gestió de projectes, no gestió financera del servei ja en funcionament.

2. Les tres activitats clàssiques

La comptabilitat de serveis exigeix un model de costos que permeti passar de la comptabilitat pressupostària (per capítols) a la comptabilitat per servei.

2.1 On es fa visible: el catàleg de serveis

La gestió financera no es queda en la comptabilitat interna: el seu resultat es publica al catàleg de serveis (→ tema 20), on cada entrada pot incorporar, a més de la descripció i l'SLA (Service Level Agreement), el cost indicatiu —o la tarifa, quan l'organització factura— d'aquell servei o d'aquella oferta. Coherentment amb el que s'ha dit més amunt, al sector públic el més freqüent és el showback (mostrar el cost sense cobrar-lo), no la tarifa. Quan el model s'aplica, és així com es fa operatiu: no es cobra «TI» de manera genèrica, es cobra o es mostra el cost de cada element concret del catàleg. Aquesta dada de preu és també el que permet al client regular la seva demanda —triar una oferta de servei més bàsica o més àmplia en funció del que costa— i preparar el seu propi pressupost amb la informació del catàleg com a referència.

3. El model de costos

3.1 Tipus de cost

• Directes: imputables íntegrament a un servei (la llicència d'una aplicació concreta).
• Indirectes o compartits: repartits entre diversos serveis (la xarxa, el CPD (Centre de Processament de Dades), el Service Desk).
• Fixos: no varien amb el volum (amortització del maquinari, lloguer del CPD).
• Variables: varien amb el consum (consum al núvol, llicències per usuari, comunicacions per trànsit).
• Capital (CAPEX, Capital Expenditure): inversió amortitzable en diversos exercicis.
• Operatius (OPEX, Operating Expenditure): despesa corrent de l'exercici.

3.2 Elements que componen el cost d'un servei

Maquinari · programari i llicències · allotjament (CPD, energia, refrigeració) · comunicacions · personal propi i extern · manteniment i suport de tercers · formació · assegurances · costos de transició i de retirada.

3.3 TCO i cicle de vida

El cost total de propietat (TCO, Total Cost of Ownership) cobreix tot el cicle de vida: adquisició, implantació, operació, manteniment, evolució, migració i retirada. És el nombre que cal comparar entre alternatives, no el preu de compra. → tema 3.

Costos que s'obliden sistemàticament: migració de dades, integracions, formació, gestió del canvi, sortida del proveïdor i egress de dades al núvol.

3.4 Repercussió interna (chargeback i showback)

• Chargeback: es cobra realment al centre de cost consumidor. Genera responsabilitat però també conflicte i burocràcia.
• Showback: es mostra el cost sense cobrar-lo. És el model habitual al sector públic: aporta transparència i moderació del consum sense els inconvenients del cobrament intern.
• Models de repartiment: parts iguals, per unitat de consum mesurat, per usuari, per transacció, per nivell de servei, amb preus diferenciats per modular la demanda → tema 17.

3.5 Sistemes d'imputació de costos indirectes

• Repartiment per volum: una clau senzilla i única (per exemple, el nombre d'usuaris) reparteix tot el cost indirecte, sense relacionar-lo amb què el genera.
• ABC (Activity Based Costing, càlcul de costos basat en activitats): identifica les activitats que consumeixen recursos (atendre una incidència, desplegar una versió) i imputa a cada servei el cost segons quines activitats li calen i quant en consumeix. És més precís que el repartiment per volum quan els serveis comparteixen recursos de manera molt desigual, i és el sistema que cal triar quan es demana canviar la imputació de costos a un model basat en activitats.

4. Anàlisi d'inversions

• Cas de negoci, VAN (Valor Actual Net), TIR (Taxa Interna de Retorn), ROI (Return on Investment, retorn de la inversió), payback, cost-efectivitat → tema 3.
• Comptabilitat analítica per servei com a base per a la decisió.
• Valor del servei: el cost és només una cara; l'altra és el valor entregat, que a l'Administració es mesura en missió pública, no en marge.
• Model de finançament: al sector privat pot ser per centre de benefici; al públic, pressupost assignat per programes i partides.

5. FinOps: la gestió financera al núvol

Amb el núvol, el cost passa de ser una inversió planificada anualment (CAPEX) a una despesa variable generada per decisions tècniques quotidianes (OPEX). Qualsevol desenvolupador pot provocar despesa. Això trenca el model tradicional de control pressupostari i obliga a un enfocament nou.

FinOps: pràctica cultural i operativa que uneix equips financers, tècnics i de negoci per prendre decisions basades en el valor econòmic del núvol, amb responsabilitat distribuïda sobre el cost.

Els tres principis del cicle FinOps: Informar (Inform) → Optimitzar (Optimize) → Operar (Operate), iteratius i continus.

Pràctiques per controlar la despesa al núvol en temps real — la pregunta d'examen sobre «quina pràctica permet controlar la despesa en el núvol en temps real» respon a aquest conjunt:

• Etiquetatge (tagging) obligatori de tots els recursos amb projecte, servei, entorn i responsable: sense etiquetes no hi ha atribució de cost possible.
• Quadres de comandament de cost en temps quasi real i alertes d'anomalia de despesa.
• Pressupostos amb llindars i alertes automàtiques per compte, projecte o etiqueta.
• Dimensionament correcte (rightsizing) continu i eliminació de recursos orfes o infrautilitzats.
• Apagada programada dels entorns de desenvolupament i proves fora d'horari.
• Instàncies reservades, savings plans i instàncies puntuals (spot) per a càrregues tolerants.
• Autoescalat perquè la capacitat segueixi la demanda.
• Polítiques i quotes per compte i projecte, i governança de la provisió (IaC amb revisió).
• Mostrar el cost a qui el genera (showback), integrat al flux de treball dels equips.

El cost dels serveis gestionats: sovint és més barat un servei gestionat que operar-lo un mateix quan s'hi compta el cost de personal; el TCO ho ha de mostrar.

Cost de sortida (egress): transferir dades cap enfora del núvol es factura; és un factor de bloqueig de proveïdor i s'ha de valorar des del disseny. El Data Act (Data Act) hi ha intervingut, imposant la supressió progressiva de les tarifes de canvi de proveïdor.

6. La gestió financera al sector públic

La lògica pressupostària pública no és la comptabilitat analítica, i això condiciona tota la pràctica:

• Pressupost anual amb especialitat qualitativa, quantitativa i temporal: el crèdit té una destinació concreta i no es pot superar ni traslladar lliurement. El marc general del pressupost local —tramitació, principis, execució— es desenvolupa a Hisendes locals → tema comú 13; aquí només la seva traducció al servei TIC.
• Capítols pressupostaris (TRLRHL, art. 167, que l'Ordre EHA/3565/2008 concreta —EHA és el codi del llavors Ministeri d'Economia i Hisenda dins la numeració oficial de disposicions, no una sigla conceptual que calgui obrir—): el maquinari i les obres sol anar al capítol 6 (inversions reals) i els serveis, subscripcions i llicències recurrents al capítol 2 (despeses corrents en béns i serveis). Aquesta és la traducció real de CAPEX i OPEX en una administració local: no és vocabulari d'empresa privada, és classificació econòmica legal. El pas al núvol trasllada despesa del capítol 6 al 2, cosa que té conseqüències pressupostàries reals i sovint és el principal obstacle intern.
• Plurianualitat: els contractes de diversos exercicis requereixen tramitació anticipada o despesa plurianual autoritzada.
• Contractació: el cost s'articula per contractes (LCSP), amb els seus terminis, pròrrogues i modificacions limitades.
• Estabilitat pressupostària i regla de despesa (LOEPSF — Llei Orgànica d'Estabilitat Pressupostària i Sostenibilitat Financera).
• Transparència: obligació de publicar contractes, execució pressupostària i comptes (Llei 19/2013, art. 8).
• Repercussió: a l'Ajuntament, el BIT (Barcelona Innovació i Tecnologia, abans IMI, Institut Municipal d'Informàtica) és un ens instrumental finançat per transferències i encàrrecs; el model és de showback i d'imputació per encàrrec, no de facturació interna competitiva.
• Control: fiscalització prèvia i posterior de la Intervenció, i control extern del Tribunal de Comptes i de la Sindicatura de Comptes.
• Tres finalitats de control que no s'han de confondre —finalitats, no la classificació legal de modalitats, que a l'àmbit local són la funció interventora i el control financer—, i que cauen com a distractores l'una de l'altra: la legalitat, assegurar que l'actuació s'ajusta a la norma, que és el que fa la funció interventora; la correcció de la despesa, pròpia del control financer i pressupostari; i la gestió, que és distinta de totes dues: detectar i rectificar errors de gestió i fer possible el retiment de comptes, avaluant si els objectius s'han assolit amb eficàcia i eficiència. Les estadístiques i les memòries d'activitat en són un producte, no la finalitat.

7. Indicadors financers de servei

• Cost total del servei i cost unitari (per usuari, per transacció, per tràmit).
• Percentatge de la despesa TIC sobre el pressupost total.
• Repartiment entre manteniment («mantenir les llums enceses») i evolució/innovació: un indicador de salut; si el manteniment consumeix més del 70-80 %, no hi ha marge per transformar.
• Desviació pressupostària i grau d'execució.
• Cost del núvol per servei i tendència mensual.
• Cost dels incidents i cost de la no-qualitat → tema 10.
• Deute tècnic estimat i cost d'oportunitat.

Claus d'examen

• Les dues respostes vàlides sobre què aporten les dades de gestió financera a l'estratègia i al disseny són l'impacte financer dels canvis i el cost del model de gestió; «fixar l'estructura del servei» és disseny i «estimar el pressupost d'un projecte» és gestió de projectes, no gestió financera (TS-TIC 2018, pràctica, s1-p26).
• Quan es demana canviar la imputació de costos a un sistema basat en activitats, la resposta és ABC (Activity Based Costing): els altres noms d'examen (sistemes de Gantt, de Laplace, «Quadratic») són distractors sense relació amb el càlcul de costos (TS-TIC 2023, pràctica, s2-p21).
• La despesa recurrent no és la inversió inicial: una fibra òptica pròpia té CAPEX alt però OPEX mínim després; una connexió llogada a un operador inverteix poc però paga quota indefinidament (TS-TIC 2018, pràctica, s3-p28).
• Al sector públic, CAPEX i OPEX no són un concepte d'empresa privada: es tradueixen literalment als capítols 6 i 2 del pressupost (TRLRHL, Ordre EHA/3565/2008). El pas al núvol trasllada despesa del 6 al 2.

Per recordar

• La funció de la gestió financera a l'estratègia del servei és quantificar econòmicament el valor dels serveis i dels seus actius i donar suport a la decisió.
• Les seves dades agregades, afinades i distribuïdes serveixen a l'estratègia (impacte financer dels canvis) i al disseny (cost del model de gestió); no fixen l'estructura del servei ni el pressupost d'un projecte concret.
• Tres activitats: pressupostar, comptabilitzar i facturar; la facturació és opcional i sovint es substitueix per showback.
• TCO cobreix tot el cicle de vida, inclosa la retirada; el preu de compra no és el cost.
• Directes/indirectes, fixos/variables, CAPEX/OPEX.
• ABC imputa el cost segons les activitats que consumeix cada servei; és més precís que un simple repartiment per volum.
• FinOps: Informar → Optimitzar → Operar, amb responsabilitat distribuïda del cost.
• Controlar la despesa al núvol en temps real exigeix etiquetatge obligatori, pressupostos amb alertes, rightsizing, apagada d'entorns i showback als equips.
• Els costos d'egress són un mecanisme de bloqueig de proveïdor; el Data Act els limita.
• Al sector públic, el pas al núvol trasllada despesa del capítol 6 (inversions) al capítol 2 (corrent) — és la traducció legal de CAPEX i OPEX, no vocabulari d'empresa privada.