Fer visible el deute tècnic: un model de puntuació lleuger per a decisions de cartera

En moltes organitzacions IT, el deute tècnic fa temps que és un estat permanent: les aplicacions funcionen, els processos rutllen, i tot i així cada canvi és més feixuc, cada release més arriscat i cada incidència més cara. El problema gairebé mai no és que ningú no vegi els riscos, sinó que no són comparables. Si cinc sistemes són alhora «crítics», al final cap no es pot prioritzar. Precisament aquí ajuda un model de puntuació del deute tècnic: un quadre d’avaluació lleuger i repetible que reflecteix els riscos tècnics, l’esforç d’explotació i la pressió de modernització de manera que les decisions de cartera siguin fonamentades.

Aquest article descriu un model de puntuació que prescindeix d’una avaluació mastodòntica, però que funciona en el dia a dia de la direcció d’IT, l’explotació, els administradors, els responsables de projecte i les unitats de negoci. L’enfocament no són els detalls interns del codi, sinó les repercussions sobre Explotació, Seguretat, Dades, Interfícies, Capacitat de lliurament i Manteniment. L’objectiu és una llengua comuna que apacigui les discussions sobre pressupost i priorització i faci planificable la modernització.

Model de puntuació del deute tècnic a la pràctica

El deute tècnic és un terme paraigua per a decisions i llegats històrics que a curt termini van estalviar temps, però que a llarg termini generen costos d’interès. Aquests „interessos“ es manifesten en el funcionament empresarial com a temps de tramitació més llargs, més coordinació, taxes d’error superiors, brexes de seguretat, coneixement especialitzat concentrat en poques persones o dependències de components ja no suportats. El problema: molts d’aquests efectes no apareixen com a partida de cost clara.

Raons típiques per les quals el deute tècnic queda relegat en rondes de cartera:

• Falta de comparabilitat: Un monòlit antic estable, una eina SaaS amb pressió creixent de llicències i una pista d’integració amb tasques nocturnes són difícils de ponderar entre si sense un marc.
• Situació de dades desigual: Per al sistema A hi ha estadístiques d’incidents i monitoratge, per al sistema B només sensacions, per al sistema C no n’hi ha cap.
• Discussió barrejada: El benefici funcional, els riscos tècnics i les preferències personals (tecnologia, preferència de l’equip) acaben al mateix sac.
• Models d’avaluació massa grans: Els models de maduresa extensos tenen sentit, però amb freqüència no es mantenen regularment. Per a decisions de cartera compta la repetibilitat.

Un model de puntuació lleuger no és la veritat absoluta. És una eina per reduir la incertesa i fer que les decisions siguin traçables —incloses les assumpcions que hi ha darrere.

Principis per a un model de puntuació lleuger

Perquè un model de puntuació no acabi com una „exercici d’Excel“, hauria de complir alguns principis bàsics:

• Poc nombre de dimensions, definicions clares: Millor definir acuradament 6–8 dimensions d’avaluació que acumular 20 criteris parcials.
• Mesurable, però no fixat només a mesures: No tot està disponible en forma de nombre. El rellevant és que els criteris s’apliquin de manera consistent.
• Apte per a cartera: L’avaluació ha de funcionar entre sistemes —independentment de si es tracta de programari empresarial a mida, productes estàndard o components d’integració.
• Perspectives explícites: Explotació, seguretat, dades i l’àrea funcional han d’aparèixer al model, perquè no es discuteixi només «tècnica contra negoci».

En la pràctica s’ha demostrat útil tractar el Score com a base per a la conversa: proporciona una llista prioritzada, però no decisions automàtiques. Els òrgans del portafoli continuen sent responsables – i documenten les desviacions de manera conscient.

El model de scoring: 8 dimensions que realment compten en l’explotació

La quadrícula següent utilitza vuit dimensions que es poden recollir bé en paisatges empresarials típics. Cada dimensió s’avaluarà en una escala de 1 a 5 (1 = poc crític/ben controlat, 5 = crític/pressió d’actuació urgent). El que importa no és la perfecció matemàtica, sinó la claredat dels criteris.

1) Estabilitat operativa i perfil d’incidents

Això tracta la qüestió: amb quina freqüència el sistema interromp el funcionament – i quin cost organitzatiu tenen aquestes interrupcions? La base són Incidents (Störungen), tiquets recurrents, escalades on-call i manteniments no planificats. També compta la inestabilitat «silenciosa», per exemple quan cal revisar sovint els processos nocturns.

Punts de referència per a l’avaluació (exemples):

• 1: Incidents rars, Runbooks clars (Betriebshandbücher), procediments de reinici provats.
• 3: Fallades recurrents o problemes de rendiment freqüents, però controlables.
• 5: Caigudes recurrents, alta càrrega de suport, solucions de compromís en lloc de resolució de la causa.

2) Risc de seguretat i compliment normatiu

Aquesta dimensió avalua com de ben protegit està el sistema contra incidents de seguretat i com d’auditable (verificable) és la seva explotació. Inclou la capacitat d’aplicar parches, els components suportats, l’autenticació (p. ex. SSO via SAML/OIDC – inici de sessió centralitzat), la registració (Audit-Trail: cadena d’esdeveniments rastrejable) i la protecció de dades sensibles.

• 1: Actualitzacions regulars, rols/privilegis clars, logs rastrejables, sense components coneguts com a „End-of-Life“.
• 3: Components parcialment obsolets o llacunes en la registració/recertificació, amb mesures compensatòries implementades.
• 5: Retards crítics, parches inexistents, responsabilitats no aclarides, riscos d’auditoria.

3) Modificabilitat i capacitat de release

„Quant de difícil és lliurar canvis de manera segura?“ Això és el nucli de molts dèficits tècnics. Es tracta de la testabilitat (regressió: proves de repetició), el procés de Deploy, la capacitat de Rollback (opció de retorn neta), la dependència d’individus així com el temps des de la petició fins a la posada en producció.

• 1: Releases reproductibles, entorns definits, finestres de manteniment planificables.
• 3: Releases possibles, però amb passos manuals i major esforç de coordinació.
• 5: Cada canvi és un risc, el Deploy només amb „les persones adequades“, Rollback poc clar.

4) Complexitat d’arquitectura i integració

Aquesta dimensió no mesura si una arquitectura és «moderna», sinó si és controlable. Sovint són les integracions les que condueixen el cost: interfícies punt a punt, formats de fitxer específics, processament per lots amb requisits temporals, manca de versionament d’APIs (contractes d’interfície) o acoblament estret a altres sistemes.

• 1: Interfícies clarament documentades, pocs punts d’acoblament, els canvis tenen efecte local.
• 3: Diverses dependències, els canvis requereixen llançaments coordinats.
• 5: Integracions «spaghetti», fluxos de dades desconeguts, alt impacte amb petits canvis.

5) Qualitat de les dades, sobirania de les dades i fluxos de dades

Per a les decisions de portafoli és crucial que les dades s’administrin netament i siguin utilitzables de manera fiable. Sobirania de les dades significa: està clar on es troba la «font de la veritat», com es generen les dades mestres (p. ex. clients, articles, proveïdors) i com repercuteixen els canvis aigües avall. Els fluxos de dades inclouen també exportacions, còpies en ombra i correccions manuals.

• 1: Responsabilitats clares, recorreguts de dades traçables, interfícies definides, claus consistents.
• 3: Diverses fonts de dades o neteges periòdiques, però transparents.
• 5: Veritat incerta, correccions freqüents, informes possibles només amb lògica especial.

6) Risc de cicle de vida: fabricant, plataforma, competències

Els deutes tècnics també sorgeixen per descontinuacions: sistemes operatius, bases de dades, biblioteques, suport del fabricant o disponibilitat de coneixement especialitzat. Aquesta dimensió considera deliberadament l’aspecte organitzatiu: hi ha prou persones que sustentin l’operació i la millora contínua? Hi ha un camí d’actualització sòlid?

• 1: Cicles de suport actius, actualització planificada, competències àmpliament disponibles.
• 3: S’acosta una actualització, la disponibilitat de competències està tensionada, dependència d’unes poques persones clau.
• 5: Fi de vida, sense full de ruta, coneixement concentrat, elevat risc del proveïdor.

7) Impulsors de costos i esforç en l’operació corrent

Aquí no s’avaluen només els costos d’infraestructura, sinó sobretot els costos variables: esforç de suport, tasques manuals, processos especials, creixement de llicències, dependència de proveïdors externs o finestres de manteniment costoses. Especialment en el programari empresarial, aquests costos indirectes sovint són més rellevants que el preu dels servidors.

• 1: Operació estable, poques tasques manuals, costos planificables.
• 3: Augment de l’esforç operatiu o creixement de costos de llicència, però controlable.
• 5: L’explotació consumeix la capacitat, moltes correccions manuals, costos difícils de preveure.

8) Criticitat empresarial i dependència de processos

Els deutes tècnics només són rellevants per a les decisions de portafoli quan s’associen a risc de procés. Aquesta dimensió avalua fins a quin punt el sistema suporta processos claus i quin és el dany en cas de fallada o malfuncionament. Important: la criticitat no és un passaport per a «mai tocar», sinó un argument per a una estabilització i modernització acurades.

• 1: Procés de suport, la fallada és assumible, existeix una solució alternativa.
• 3: Procés important, les fallades generen costos, però són limitables.
• 5: Procés clau, una fallada atura la creació de valor o comporta riscos de compliment normatiu.

Com es converteixen les puntuacions en decisions de portafoli (sense falsa precisió)

Una puntuació només és útil si prepara una decisió. Per això fan falta dos passos: ponderació i categories de decisió.

Ponderació: no tots els criteris tenen la mateixa importància

Moltes organitzacions comencen amb la mateixa ponderació per evitar discussions. Més endavant val la pena una ponderació senzilla segons l’objectiu del portfoli, per exemple:

• Prioritat a la seguretat (p. ex. segons troballes d’auditoria): ponderar doblement el risc de seguretat i de compliment.
• Augmentar la capacitat de lliurament (p. ex. amb un backlog de canvis elevat): ponderar més la capacitat de canvi/llançament.
• Estabilitzar costos (p. ex. amb un augment del suport): ponderar més els factors que incrementen l’esforç en el funcionament.

És important documentar la ponderació de forma transparent i canviar-la només esporàdicament. Si no, els canvis en la puntuació semblaran «polítics» i no pas una millora real.

Categories de decisió: quatre opcions d’actuació clares

De les dimensions se’n poden derivar quatre categories pragmàtiques que es poden discutir bé al Portfolio-Board:

• Estabilitzar: Alts riscos operatius i de seguretat, però no es pot reemplaçar a curt termini. Enfoc en Runbooks, monitoratge, rutes de parcheig, higiene tècnica.
• Modernitzar: Alts riscos de canvi o de cicle de vida amb una alta criticitat. Enfoc en renovació modular, desacoblar interfícies, consolidar models de dades.
• Consolidar/Substituir: Funcions duplicades, esforç elevat, baixa diferenciació. Enfoc en desactivació, migració de dades, unificació de processos.
• Acceptar conscientment: Baixa criticitat o vida RESTant previsible. Enfoc en controls de risc, manteniment mínim, opció d’eixida clara.

Perquè això no sigui teòric, cada aplicació hauria de rebre a més un proper pas raonable — com a màxim 1–2 mesures concretes que siguin realistes en 4–12 setmanes. Així, la gestió del portfoli es converteix en un procés continu de millora en lloc d’un taller anual.

Construir la base de dades de manera pragmàtica: quines fonts solen ser suficients

Un model lleuger viu del fet que l’obtenció de dades no sigui més cara que les primeres mesures. Per a moltes empreses, quatre fonts de dades són suficients per assignar puntuacions sòlides:

• Dades de tiquets/incidents: freqüència, repeticions, temps de tramitació, escalades. Si no hi ha una categorizació clara, al principi és suficient una assignació aproximada (averia, consulta, canvi).
• Monitoratge/disponibilitat: no només „uptime“, sinó també pics de rendiment, temps d’execució de tasques, taxes d’errors, creixement de memòria/disc.
• Informació de seguretat i de cicle de vida: estat de parcheig, dates de fi de vida útil, dependències (p. ex. versió de base de dades, sistema operatiu, autenticació), excepcions conegudes.
• Visió d’arquitectura/integració: un mapa d’aplicacions senzill (mapa del sistema) amb fluxos de dades i interfícies. La completitud és secundària; l’actualitat és la que compta.

Si falten xifres, això hauria de ser visible en la puntuació: „Avaluació 4 a causa de la manca de proves“ és més honest que una mitjana aleatòria. Allò desconegut sovint és més arriscat en el funcionament que allò dolent que, com a mínim, es coneix.

Taller de scoring en 90 minuts: procediment, rols, artefactes de resultat

Un error comú és dur a terme el Scoring de forma individual. Això tendeix a fer-ho o bé massa tècnic o bé massa polític. Millor fer un taller breu per sistema, moderat i amb rols clars. 90 minuts són suficients per a una primera avaluació fiable, si es disposa de les dades bàsiques.

Participants (petits, però complets)

• Responsable del sistema IT: coneix la roadmap, els canvis i els colls d’ampolla tècnics.
• Operacions/Administració: coneix incidències, finestres de manteniment, monitoratge, backup/RESTore.
• Owner funcional o Key User: coneix la criticitat del procés, les solucions alternatives, l’acceptació i els pics d’ús.
• Moderació: vetlla per la fidelitat a les definicions i documenta les assumpcions.

Procés (compacte, repetible)

1. Context (10 min.): propòsit del sistema, grups d’usuaris, interfícies principals, model d’operació (On-Prem/Cloud/Hybrid).
2. Score per dimensió (45 min.): 3–5 minuts per criteri, amb breus evidències (nombre d’entrades, estat dels parches, dependències conegudes).
3. Identificar hotspots (15 min.): quines 2 dimensions impulsen més el risc/cost?
4. Definir accions (15 min.): 1–2 passos concrets següents, amb owner i termini objectiu.
5. Etiqueta del portafoli (5 min.): Estabilitzar / Modernitzar / Consolidar / Acceptar.

Com a resultat, n’hi ha prou amb tres artefactes: taula de puntuacions, una justificació breu per dimensió i un extracte d’accions. La RESTa és opcional.

Errors típics — i com mitigar-los dins el model

Un model de Scoring pot generar incentius erronis si no està ben emmarcat. Segons l’experiència de projecte, aquests són els obstacles més habituals:

Obstacle 1: „Punen els equips per ser transparents“

Si els equips amb bona documentació obtenen pitjors puntuacions perquè posen els problemes sobre la taula, el model està mal plantejat. Mesura correctora: tractar l’desconegut (dades mancants) com un risc propi i reconèixer explícitament la transparència com un valor positiu, per exemple dins el criteri de modificabilitat (rollbacks, runbooks, monitoring).

Obstacle 2: la puntuació es converteix en instrument per retallar pressuposts

Si les puntuacions altes condueixen automàticament a un „aturada de projecte“, el model es polititza. Millor: les puntuacions altes han de generar una proposta de decisió amb opcions (p. ex. estabilitzar vs. modernitzar) i conseqüències clares. El pressupost ha de seguir la decisió — no només la puntuació.

Obstacle 3: barrejar benefici i risc

El benefici funcional (p. ex. potencial de facturació) és important, però és una altra dimensió. Un procediment provat: avaluar el benefici en una graella separada i després combinar-ho en una matriu de portafoli (benefici alt/baix vs. risc/deute (tècnic) alt/baix). Així s’evita discutir si un risc de seguretat „s’hauria de compensar“ amb ingressos.

Obstacle 4: „Modernització“ s’entén com un projecte gran

Les decisions de cartera sovint fracassen per l’assumpció implícita que la modernització només es pot fer amb un Big Bang. A la pràctica, sovint té més sentit una modernització modular: estabilitzar interfícies, estandarditzar els accessos a dades, desacoblar processos parcials i controlar amb netedat el funcionament en paral·lel. Una puntuació ajuda a trobar l’ordre, no a imposar l’estat final.

De la puntuació a la fulla de ruta: com es dimensionen adequadament els paquets de mesures

Quan el model està definit, arriba la feina real: tallar les mesures de manera que funcionin en el dia a dia al costat de l’activitat de projectes. Tres regles ajuden a transformar un «hauríem de…» en elements concrets de fulla de ruta:

1) Primer minimitzar els riscos més costosos

A molts portfolis, els riscos de seguretat i operacionals són les palanques més grans perquè tenen terminis externs (auditoria, end-of-life) i costos secundaris elevats. Les mesures típiques per minimitzar-los són: establir un camí d’actualització, afegir registre/audit-trail, provar backup/RESTore, reduir punts únics de fallada, validar i sanejar permisos.

2) Estabilitzar els nuclis d’integració abans d’ampliar funcionalitats

Els sistemes amb moltes interfícies multipliquen els costos de canvi. Sovint convé començar per: definir contractes d’interfície (versionat, formats de dades, gestió d’errors), afegir monitoratge dels fluxos de dades, desacoblar cadenes de tasques i introduir estratègies de reintents (noves tentatives en cas d’errors). Això rarament és «visible» per al negoci, però redueix mesurablement els temps d’inactivitat i l’estrès en els releases.

3) Fer planificables les mesures com a «millores operatives»

Moltes deutes tècniques es poden resoldre com a millores operatives en petits paquets: runbooks, regles d’alarma, planificació de capacitat, estandardització d’entorns, finestres de patch periòdiques. No són projectes glamorosos, però augmenten la fiabilitat i creen finestres de temps per a passos més grans de modernització.

Així fa que l’avaluació perduri: governança sense burocràcia

Un model només té valor si no s’adorm passats dos trimestres. Per això cal un procés senzill que encaixi amb l’operativa i l’activitat de projectes:

• Responsable per aplicació: Una persona nomenada que manté la puntuació i l’estat de les mesures (no l’implementa sola).
• Triggers en lloc d’obligació de calendari: Revisió de la puntuació després d’un clúster d’incidents, un major release, un resultat d’auditoria o una actualització de plataforma.
• Ritme de cartera: Mensual/bimensual 60 minuts per als riscos principals, no per a tots els sistemes.
• Registre de decisions: Breu documentació del motiu pel qual s’ha acceptat o ajornat un risc. Això evita atribucions de culpa posteriors i fa visibles les hipòtesis.

És important la vinculació amb una governança efectiva: com a mínim, una part de la capacitat (pressupost o temps de l’equip) hauria d’estar explícitament reservada per a estabilització/modernització. Altrament, el model només produeix coneixements sense efecte.

Conclusió: Fer visibles els deutes tècnics sense sobrecarregar l’organització

Un model lleuger de puntuació de deutes tècnics no substitueix un treball d’arquitectura detallat – però serveix per a una cosa que en els portfolis sovint manca: comparabilitat. Amb vuit dimensions clares, anclatges d’avaluació comprensibles i un format de taller breu es poden representar riscos, esforç d’operació i pressió de modernització de manera que IT, el departament funcional i la direcció puguin sostenir la mateixa discussió.

L’efecte més important rarament és el valor numèric exacte. És la transparència sobre on s’originen els deutes tècnics, com carreguen l’operació i quins passos següents són realistes. Si les puntuacions es revisen regularment i s’enllacen amb petites mesures concretes, es genera un full de ruta de modernització que no viu al plànol, sinó que es manté en l’operativa diària.

Si voleu establir el model de puntuació per al vostre portfoli d’aplicacions o fer les primeres valoracions en un format moderat, trobareu aquí l’entrada adequada: Posar-se en contacte.

Per a aquest tema també són importants Avaluar deutes tècnics i Decisions de cartera TI. L’article situa aquests aspectes de manera comprensible i mostra en què cal centrar-se en el dia a dia.

Parlar sobre un projecte o una iniciativa de modernització amb Net-Base.