Models i registres · ISO 20000 · Apartat 8.5.1
Model de sol·licitud de canvi (RFC) segons ISO 20000-1
Cada modificació d'un servei o d'un element sota control: què es canvia, per què, quin risc té, qui l'aprova, com es torna enrere si surt malament i si va funcionar.
En una frase
Una sol·licitud de canvi registra la descripció i el motiu del canvi, la seva classificació, l'avaluació de riscos, beneficis, viabilitat i impacte econòmic, l'aprovació de qui té autoritat, la data planificada comunicada, el pla de marxa enrere, el resultat de les proves i la revisió de la seva eficàcia, perquè l'apartat 8.5.1 d'ISO/IEC 20000-1 exigeix registrar i classificar cada sol·licitud i prendre les decisions amb les parts implicades segons la política de gestió del canvi.
- On ho demana la norma
- ISO 20000 · Apartat 8.5.1 Els apartats se citen amb la numeració d'ISO/IEC 20000-1:2018, l'edició vigent i la mateixa que fa servir l'Acadèmia.
- Tipus d'informació
- Registre obligatori Registre i classificació de les sol·licituds de canvi (8.5.1.2), amb la política documentada (8.5.1.1)
- Qui l'emplena
- Gestor del canvi Aprova qui fixi la política; els canvis importants passen per un comitè amb les parts implicades
- Quan
- Abans de qualsevol canvi controlat Els d'emergència es poden aprovar per via ràpida, però es registren igualment
- Quant de temps es conserva
- El fixa l'organització La norma demana controlar la conservació i l'eliminació de la informació documentada (7.5.3) sense fixar terminis. L'habitual és cobrir almenys el cicle de certificació de tres anys, o el termini del contracte amb el client si és més llarg.
Què demana la norma
El que exigeix ISO 20000 i el que deixa al teu criteri
La norma demana una política de gestió del canvi que defineixi quins elements de configuració estan sota el seu control, els criteris per identificar els canvis amb un impacte potencial greu —que es gestionen amb el disseny i la transició de serveis del 8.5.2— i com es tracten els canvis d'emergència.
Cada sol·licitud es registra i es classifica. La decisió es pren amb les parts implicades, valorant riscos, beneficis, viabilitat i impacte econòmic. Les dates planificades es comuniquen, es preparen i, si és possible, es proven les activitats de marxa enrere, i si el canvi falla s'apliquen.
Després de la implantació es revisa l'eficàcia del canvi, i els registres de sol·licituds s'analitzen periòdicament per detectar tendències.
Estructura
Camps que ha de tenir el model
- Número, data i sol·licitant
- Descripció i motiu
- Serveis i elements de configuració afectats
- Classificació: estàndard, normal, d'emergència o d'impacte greu
- Avaluació de riscos, beneficis, viabilitat i impacte econòmic
- Aprovació i qui decideix
- Finestra planificada i comunicació
- Pla de marxa enrere i si s'ha provat
- Resultat de les proves i implantació
- Revisió de l'eficàcia i tancament
Exemple
Exemple: inventari de certificats amb avís
Empresa, persones i xifres inventades: l'exemple només mostra com queda un registre ben emplenat.
| Camp | Contingut |
|---|---|
| Canvi | CHG-26-077 · 22 d'abril de 2026 · origen: problema PRB-26-021 |
| Descripció | Alta dels 46 certificats de servidor com a elements de configuració i avís automàtic a 30 dies |
| Afecta | Base de dades de configuració i eina de monitorització |
| Classificació | Normal · risc baix |
| Avaluació | Sense interrupció del servei · cost intern de 3 jornades · evita caigudes com la d'abril |
| Aprovació | Comitè de canvis del 24 d'abril |
| Finestra | 28 d'abril, de 19 a 21 h · comunicada al client el 24 |
| Marxa enrere | Desactivar la regla d'avís · provada en preproducció |
| Eficàcia | Primer avís rebut el 12 de juny, 30 dies abans de la caducitat · eficaç |
A l'auditoria
Errors que solen assenyalar els auditors
- Canvis aplicats en producció sense sol·licitud registrada.
- Canvis d'emergència que no es registren mai després.
- Plans de marxa enrere que no existeixen o no s'han provat.
- Sense revisió posterior de si el canvi va funcionar.
- La política no defineix quins elements estan sota el control del canvi.
A Kimobox
Com es porta aquest registre a Kimobox
- 1Les sol·licituds de canvi es gestionen com a flux d'aprovació.
- 2Cada canvi queda amb la seva aprovació, les seves proves i el seu resultat documentats al mateix flux.
- 3Els elements de configuració es registren com a actius versionats.
Preguntes freqüents
El que ens pregunten abans de començar
Què és un canvi estàndard?
Un canvi de risc baix, freqüent i amb un procediment conegut, que es preaprova i no passa pel comitè cada vegada. ISO/IEC 20000-1 no fa servir aquest terme, però permet definir a la política quins canvis es tracten així.
Què es fa amb un canvi d'emergència?
La política de gestió del canvi ha de definir com es gestionen. L'habitual és una aprovació ràpida per part d'una persona autoritzada i el registre complet després, amb la seva revisió.
Porta els registres de ISO 20000 sense plantilles soltes
Et mostrem el mòdul funcionant amb dades semblants a les teves.
Continua explorant
Pàgines relacionades
Disseny i transició de serveis
Tot canvi en un servei TI ha de planificar-se i provar-se abans de passar a producció per minimitzar el risc.
Model de catàleg de serveis TI segons ISO 20000-1
Què ha d'incloure el catàleg de serveis que demana ISO/IEC 20000-1: descripció, resultats previstos…
Model d'acord de nivell de servei (SLA) ISO 20000-1
Què ha de recollir un SLA segons ISO/IEC 20000-1 (8.3.3): serveis, objectius de nivell, límits de càrrega…
Model d'informe de nivell de servei ISO 20000-1
Què ha de contenir l'informe de servei que demana ISO/IEC 20000-1: compliment dels SLA, càrrega, incidències…