Tema 36 · SAP, desenvolupament i ERP

SAP FI i EA-PS

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

Enunciat oficial. SAP FI (Financial Accounting) i EA-PS (Enterprise Aplication for Public Sector).

1. Context: SAP a l'Administració

SAP ERP (Enterprise Resource Planning) és la plataforma de gestió econòmica, financera i de recursos humans de l'Ajuntament de Barcelona i de bona part de les grans administracions espanyoles. L'evolució tecnològica és SAP R/3 → SAP ERP (ECC 6.0, ERP Central Component) → SAP S/4HANA, aquest últim sobre la base de dades en memòria SAP HANA (High-performance ANalytic Appliance) → tema 50.

Estructura organitzativa financera (imprescindible per entendre la resta):

2. SAP FI — Financial Accounting

Què és: el mòdul de comptabilitat financera externa de SAP. Registra tots els fets econòmics amb rellevància comptable i produeix els estats financers legals (balanç, compte de pèrdues i guanys) i la informació per a tercers (hisenda, auditors, proveïdors).

Quan la pregunta és quin mòdul cal parametritzar per gestionar la comptabilitat financera dins d'un entorn SAP, la resposta és FI.

Submòduls de FI:

Conceptes clau de FI:

• Document comptable: tot moviment genera un document amb capçalera (data, tipus, societat, període) i posicions (compte, import, deure/haver, centre de cost). SAP no permet modificar ni esborrar un document comptabilitzat: només anul·lar-lo amb un document invers. Aquesta és la base de la traçabilitat i l'auditoria.
• Classe de document (document type): clau de dos caràcters que classifica els documents comptables, determina els rangs de numeració, els tipus de compte permesos i el comportament del document. Exemples estàndard: KR (Kreditorenrechnung: factura de proveïdor), KZ (Kreditorenzahlung: pagament a proveïdor), DR (Debitorenrechnung: factura de client), SA (Sachkontenbeleg: document comptable general).
• Clau de comptabilització (posting key): determina si la posició és deure o haver i el tipus de compte.
• Pla de comptes (chart of accounts) i comptes de major.
• Període comptable i exercici fiscal; els períodes s'obren i es tanquen per controlar les comptabilitzacions.
• Partida oberta / compensació (clearing): una factura queda com a partida oberta fins que el pagament la compensa.
• Tancament comptable (mensual i anual): abans de tancar un període a FI cal tancar els subperíodes dels mòduls que hi alimenten (MM, SD, AA); el tancament inclou la conciliació de partides obertes a AP/AR, els assentaments de regularització (devengaments, provisions, amortitzacions) i la generació dels informes financers legals de sortida (balanç, compte de pèrdues i guanys). Un cop tancat, un període no admet noves comptabilitzacions fins que es reobre.
• Reconciliació FI-CO: FI és la comptabilitat externa i legal; CO (Controlling) és la interna i analítica (centres de cost, ordres internes, comptabilitat de costos). A S/4HANA la separació física desapareix amb el Universal Journal.

Integració: FI rep automàticament els fets econòmics d'MM (compres i logística), SD (vendes), HCM (nòmina), AA i PS (projectes). El principi és que el document es genera on passa el fet i FI el recull.

3. SAP EA-PS — Enterprise Extension Public Services

Què és: l'extensió (Enterprise Extension) de SAP ERP específica per al sector públic — el prefix EA (Enterprise Add-On) designa la família de mòduls opcionals de SAP ERP. Adapta el nucli financer a la lògica de la comptabilitat pressupostària pública, que és radicalment diferent de la comptabilitat empresarial.

Funcionalitat directament relacionada amb EA-PS dins d'un entorn SAP ERP per al sector públic: la gestió pressupostària pública —elaboració, aprovació i control de l'execució del pressupost, amb les seves fases de despesa i el control de disponibilitat de crèdit—, juntament amb la gestió de subvencions i les competències específiques del sector públic. Aquesta és la resposta a la pregunta d'examen.

Components principals d'EA-PS:

Estructura pressupostària a FM:

• Centre gestor (fund center): on es gasta — l'estructura orgànica.
• Posició pressupostària (commitment item): en què es gasta — la classificació econòmica.
• Fons (fund): d'on venen els recursos (finançament afectat, subvenció).
• Programa de finançament (funded program): projecte o programa concret.
• Àrea de comptabilitat pressupostària (FM area): àmbit del pressupost.

El cicle pressupostari a SAP té quatre etapes: elaboració i aprovació del pressupost (dotacions inicials a FM), execució (les fases de la despesa, taula següent), i liquidació i tancament (romanents, compte general → tema comú 13, que en desenvolupa el marc normatiu). Aquí ens centrem en l'etapa d'execució: les fases de la despesa pública i el seu reflex a SAP FM —la correspondència que cal saber:

Cada fase consumeix crèdit i FM en fa el control de disponibilitat: si no hi ha crèdit suficient a la posició, el sistema bloqueja l'operació. Aquesta és la diferència essencial amb un ERP privat, on no hi ha crèdit pressupostari limitatiu.

Altres especificitats del sector públic: exercici pressupostari i romanents, modificacions de crèdit (transferències, crèdits extraordinaris, suplements, generacions, incorporacions de romanents), plurianualitat, finançament afectat, liquidació i compte general → tema comú 13.

4. Altres mòduls SAP rellevants

5. Aspectes tècnics i de gestió

• Personalització (customizing): la parametrització es fa a la transacció SPRO (SAP Project Reference Object), que obre la guia d'implementació, IMG (Implementation Guide). La regla és parametritzar abans que desenvolupar: el desenvolupament a mida (ABAP (Advanced Business Application Programming), ampliacions, user exits, BAdI, enhancement points) encareix les actualitzacions.
• Sistema de tres paisatges: DEV (Development) → QAS (Quality Assurance System) → PRD (Production), amb ordres de transport que propaguen els canvis. Cap canvi es fa directament a producció.
• Autoritzacions: perfils i rols amb objectes d'autorització; la segregació de funcions (qui comptabilitza no paga) és un requisit d'auditoria i de control intern.
• Integració amb l'administració electrònica: factura electrònica (FACe/e-FACT, format Facturae), registre comptable de factures, comunicació amb la Plataforma de Contractació i la PLACSP (Plataforma de Contratación del Sector Público), i intercanvis amb l'AEAT (Agencia Estatal de Administración Tributaria) i la Seguretat Social.
• Auditoria i traçabilitat: cada document conserva usuari, data i hora; els canvis a dades mestres queden registrats. És un requisit del control intern i de l'ENS.

Claus d'examen

• EA-PS es cita amb formulacions diferents i cap coincideix exactament amb el nom del component (SAP Enterprise Extension Public Services): el programa oficial diu «Enterprise Aplication for Public Sector», una pregunta diu «Enterprise Extension for Public Sector» (TS-TIC 2025 específic, p. 38) i una altra «Enterprise Aplications for Public Sector» (TM-TIC 2021-OP, p. 6); una tercera ni tan sols hi posa espai: «SAP-Financials EAPublicSector» (TS-TIC 2023, p. 4). Cada formulació és literal del document que la conté i no es corregeix (C-17); l'única constant és el que fa: gestió pressupostària del sector públic.
• FI-GL (General Ledger) és la resposta correcta dues vegades amb enunciats diferents: quan es demana quin component porta el llibre major (TS-TIC 2025 pràctica, s3-p25) i quan es demana quin mòdul parametritzar per a la comptabilitat financera (TS-TIC 2023, p. 4, on l'opció literal és «SAP General Ledger Accounting»).
• La distractora FI-BPC (Business Planning and Consolidation) de la pregunta del llibre major (TS-TIC 2025 pràctica, s3-p25) arrossega al final el text «PREGUNTES DE RESERVA», un artefacte del document oficial que es transcriu literalment (C-17): no és part de la descripció del mòdul.

Per recordar

• FI = comptabilitat financera externa i legal (balanç i compte de resultats). Per a la comptabilitat financera es parametritza FI.
• Societat (company code) = unitat mínima amb estats financers complets.
• Submòduls de FI: GL, AP, AR, AA, BL.
• Un document comptabilitzat no es modifica ni s'esborra: s'anul·la amb un document invers.
• La classe de document classifica els documents, determina la numeració i el comportament (KR factura de proveïdor, KZ pagament, DR factura de client, SA general).
• EA-PS aporta la gestió pressupostària pública; el mòdul responsable és Funds Management (FM), amb centre gestor, posició pressupostària, fons i programa de finançament.
• GM = subvencions; PSCD = cobraments i pagaments massius amb ciutadans; BCS = control pressupostari.
• Les fases de la despesa A-D-O-P consumeixen crèdit i FM en fa el control de disponibilitat.
• CO és la comptabilitat interna i analítica; a S/4HANA el Universal Journal (ACDOCA) unifica FI i CO.

Tema 37 · SAP, desenvolupament i ERP

SAP TRM (Tax and Revenue Management)

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

Enunciat oficial. SAP TRM (Tax and Revenue Management).

1. Què és i què no és

SAP TRM és la solució de SAP per a la gestió tributària i d'ingressos de dret públic de les administracions: gestió del padró de contribuents, liquidació, notificació, recaptació voluntària i executiva, fraccionaments, devolucions i inspecció.

Objectiu de SAP TRM: gestionar de manera integrada el cicle complet dels ingressos públics —tributs, taxes, preus públics, multes i altres ingressos de dret públic— des de la determinació del deute fins al seu cobrament o la seva declaració de fallida, amb el compte del contribuent com a eix.

Compte amb la confusió d'acrònims: SAP TRM també és la sigla de Treasury and Risk Management, el mòdul de gestió de tresoreria i risc financer (operacions financeres, instruments, gestió de liquiditat, risc de mercat i de crèdit). Els exàmens hi han jugat: llegeix bé si l'enunciat parla de tributs o de tresoreria. En el context del temari municipal, TRM és Tax and Revenue Management.

1.1 Delimitació respecte a altres mòduls SAP

Davant d'un supòsit de tribut o de taxa, els exàmens ofereixen com a distractors altres mòduls SAP que no hi tenen res a veure. Cap gestiona un compte de contribuent ni un deute públic:

2. Arquitectura

TRM s'assenta sobre PSCD (Public Sector Collection and Disbursement), que al seu torn és l'adaptació al sector públic de FI-CA (Contract Accounts Receivable and Payable), la comptabilitat de comptes contracte dissenyada per a volums massius de deutors.

SAP TRM (gestió tributària)
   └─ PSCD (cobraments i pagaments massius del sector públic)
        └─ FI-CA (comptabilitat de comptes contracte)
             └─ FI (comptabilitat general)  ·  FM (pressupost)

Per què no s'usa FI-AR (Accounts Receivable) clàssic: FI-AR està pensat per a centenars o milers de clients amb factures individuals. Un ajuntament té centenars de milers o milions de contribuents amb desenes de milions de rebuts periòdics. FI-CA/PSCD està dissenyat per a aquest volum: processament massiu, paral·lelització, i un model de dades optimitzat.

3. Conceptes de PSCD

Classe de document a PSCD i a FI-CA: igual que a FI (Financial Accounting, comptabilitat general), classifica el document, determina el rang de numeració i el comportament del procés. La funció de la classe de document en els documents del mòdul financer PSCD associat a TRM és, doncs, identificar el tipus d'operació i determinar-ne el tractament comptable, la numeració i les característiques del procés.

Classe d'operació principal i secundària (main transaction / sub transaction): parell de claus que determina la naturalesa del deute i la seva imputació comptable automàtica (a quin compte de major i a quina posició pressupostària va cada import). És el mecanisme de traducció entre el món tributari i el comptable.

4. El cicle de gestió tributària a TRM

1. Gestió del padró i de les dades mestres: alta i manteniment de contribuents i objectes tributaris, sovint alimentat des de fonts externes (Cadastre, DGT, padró municipal d'habitants, registres d'activitats).
2. Determinació i liquidació: càlcul de la quota a partir de la base imposable, el tipus i els beneficis fiscals. Pot ser per padró (massiva i periòdica: IBI, IVTM, IAE) o per autoliquidació o liquidació individual (ICIO, plusvàlua, taxes).
3. Facturació i emissió: generació massiva dels rebuts o liquidacions.
4. Notificació: individual o col·lectiva per edicte en el cas dels padrons, amb la seva publicació al butlletí oficial. Integració amb notificació electrònica (e-NOTUM) i amb la seu electrònica.
5. Recaptació en període voluntari: domiciliació bancària (SEPA, Single Euro Payments Area, quaderns bancaris), entitats col·laboradores, passarel·la de pagament en línia, TPV (Terminal Punt de Venda), pagament a la carta i fraccionaments i ajornaments.
6. Període executiu: recàrrecs, provisió de constrenyiment, interessos de demora, embargaments (comptes bancaris, salaris, devolucions d'hisenda, vehicles, immobles), subhasta.
7. Devolucions d'ingressos indeguts i compensacions.
8. Inspecció: comprovació, actes, liquidacions complementàries i expedients sancionadors.
9. Recursos i reclamacions: recurs de reposició i, a Barcelona, reclamació davant el Consell Tributari → tema comú 11.
10. Comptabilització: cada moviment genera els documents corresponents a FI i el consum o generació de drets a FM (pressupost d'ingressos).
11. Baixes: crèdits incobrables, prescripció, insolvència.

Processos massius: TRM/PSCD executa la facturació, la domiciliació, la reclamació, la generació de rebuts i la comptabilització en execucions massives paral·lelitzades amb intervals de treball, cosa que permet tractar milions de partides en finestres nocturnes.

5. Integració

• FI i FM: comptabilització dels drets reconeguts, dels ingressos i de les devolucions; imputació al pressupost d'ingressos.
• Bancs: quaderns 19, 43, 57, 60 i SEPA per a domiciliacions, devolucions i extractes; conciliació automàtica.
• Entitats col·laboradores i passarel·les de pagament.
• Cadastre (fitxers FIN, DOC, CAT) per a l'IBI; DGT (Dirección General de Tráfico) per a l'IVTM; AEAT (Agencia Estatal de Administración Tributaria) per a embargaments i cessions d'informació.
• Administració electrònica: seu electrònica, carpeta del contribuent, notificació electrònica, signatura i CSV (Codi Segur de Verificació), registre d'entrada i sortida, i expedient electrònic → tema 4.
• BI (Business Intelligence): explotació analítica de la recaptació, de la morositat i de l'eficiència recaptatòria → tema 35.

6. A l'Ajuntament de Barcelona

• L'IMH (Institut Municipal d'Hisenda) és l'organisme autònom que gestiona, inspecciona i recapta els tributs municipals.
• El Consell Tributari dictamina les reclamacions economicoadministratives en matèria tributària municipal, una singularitat del règim especial de Barcelona (Carta municipal).
• Tributs gestionats: IBI (Impost sobre Béns Immobles), IAE (Impost sobre Activitats Econòmiques), IVTM (Impost sobre Vehicles de Tracció Mecànica) (obligatoris) i ICIO (Impost sobre Construccions, Instal·lacions i Obres), IIVTNU (Impost sobre l'Increment de Valor dels Terrenys de Naturalesa Urbana) (potestatius), més taxes, preus públics, contribucions especials i multes → tema comú 13.
• Canals: seu electrònica, carpeta del contribuent, OAC (Oficina d'Atenció al Ciutadà), 010 i entitats col·laboradores.

Claus d'examen

• TRM no és únic a SAP: n'hi ha dos amb la mateixa sigla — Tax and Revenue Management (tributs) i Treasury and Risk Management (tresoreria). Llegeix bé l'enunciat abans de triar (TS-TIC 2023, p. 3).
• Davant d'un supòsit de taxa o tribut, els distractors solen ser altres mòduls SAP — PCM (rendibilitat), BPC (planificació) o HCM (personal) —: cap gestiona un compte de contribuent (TS-TIC 2023 pràctica, supòsit 4, p. 15).
• La classe de document a PSCD classifica el tipus d'operació (deute, crèdit, ajust), no qui la cobra ni qui hi té accés: no la confonguis amb paràmetres organitzatius o d'autorització (TS-TIC 2025, p. 39).

Per recordar

• SAP TRM (Tax and Revenue Management) gestiona el cicle complet dels ingressos públics, amb el compte del contribuent com a eix. No el confonguis amb Treasury and Risk Management.
• Altres mòduls SAP no gestionen un tribut: PCM (rendibilitat i costos), BPC (planificació i consolidació) i HCM (personal i nòmina).
• TRM s'assenta sobre PSCD, que és l'adaptació al sector públic de FI-CA (comptes contracte), pensada per a volums massius — no sobre FI-AR.
• Conceptes: interlocutor comercial (contribuent), compte contracte (condicions de gestió), objecte tributari (fet imposable) i partides obertes.
• La classe de document identifica el tipus d'operació i en determina la numeració i el tractament comptable.
• La classe d'operació principal i secundària determina la imputació comptable i pressupostària automàtica.
• Cicle: padró → liquidació → notificació → voluntària → executiva → devolucions → inspecció → comptabilització.
• A Barcelona: IMH gestiona i recapta; el Consell Tributari resol les reclamacions economicoadministratives.

Tema 38 · SAP, desenvolupament i ERP

SAP HCM (Human Capital Management)

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

Enunciat oficial. SAP HCM (Human Capital Management).

1. Què és

SAP HCM (Human Capital Management; abans SAP HR, Human Resources) és el mòdul de gestió de recursos humans de SAP ERP: administració de personal, organització, temps, nòmina, contractació, formació, desenvolupament i autoservei.

HCM és un mòdul, no un producte: el producte és l'ERP (Enterprise Resource Planning, planificació de recursos empresarials) de SAP, un sistema integrat que gestiona sobre una única base de dades tots els processos de l'organització —finances, compres, logística i també RRHH (Recursos Humans)— i que es desenvolupa al detall al tema tic/soluciones-erp. Un ERP no és: un CRM (Customer Relationship Management, gestió de la relació amb el client, centrat en vendes i atenció al client), un BPM (Business Process Management, gestió i automatització de processos de negoci) ni una BI (Business Intelligence, intel·ligència de negoci, orientada a l'anàlisi de dades). HCM no és cap d'aquests tres: és el mòdul de l'ERP dedicat als recursos humans.

Pregunta d'examen: quan es parla de SAP-HCM per a la gestió de RRHH, s'està parlant d'un mòdul del producte SAP ERP (històricament SAP R/3 i després SAP ECC, ERP Central Component), no d'un producte independent. L'evolució al núvol és SAP SuccessFactors, i a S/4HANA el component en local es denomina SAP S/4HANA for Human Resources o s'integra amb SuccessFactors.

2. Els infotips

Concepte central del mòdul i pregunta recurrent.

Infotip (infotype): estructura de dades de recursos humans identificada per un codi numèric de quatre dígits que agrupa un conjunt lògic de camps relacionats i que s'emmagatzema amb VALIDESA TEMPORAL, és a dir, amb una data d'inici i una data de fi.

Característiques que cal saber:

• Cada infotip agrupa dades del mateix àmbit (dades personals, adreça, contracte, salari…).
• La gestió temporal és l'essència: cada registre té BEGDA (data d'inici) i ENDDA (data de fi). Quan una dada canvia, no se sobreescriu: es delimita el registre anterior i es crea un de nou. Això permet reconstruir la situació de qualsevol empleat en qualsevol data passada, cosa imprescindible per a la nòmina, l'antiguitat i l'auditoria.
• Subtipus: divideixen un infotip en categories (tipus d'adreça, tipus de comunicació).
• Constel·lacions de temporalitat: cada infotip té un control de solapament que determina si pot haver-hi diversos registres vigents alhora.
• Es mantenen amb les transaccions PA30 (Personnel Administration, manteniment individual), PA40 (Personnel Administration, mesures de personal) i PA20 (Personnel Administration, visualització).

Infotips més coneguts:

3. Submòduls

Les tres estructures de HCM que cal distingir:

• Estructura organitzativa: unitats i llocs (OM).
• Estructura administrativa de personal: societat → àrea de personal → subàrea de personal.
• Estructura organitzativa de personal: grup de personal → àrea de personal (col·lectiu), que determina el conveni i les regles aplicables.

4. La nòmina

• Esquema de nòmina (payroll schema) i PCR (Personnel Calculation Rules, regles de càlcul): el motor de càlcul, altament parametritzable per país (versió espanyola, amb IRPF, Seguretat Social, convenis i particularitats del sector públic).
• Concepte de nòmina (wage type): cada element retributiu o deducció.
• Període de nòmina, àrea de nòmina i control de període.
• Estats del càlcul: alliberament, simulació, càlcul, correccions, tancament i comptabilització. La nòmina té un cicle de bloqueig: mentre s'executa, les dades mestres es bloquegen.
• Comptabilització a FI/CO i imputació a FM (pressupost de personal, capítol 1).
• Integracions externes: Sistema RED (Remisión Electrónica de Datos), SILTRA i Cret@ de la Seguretat Social; AEAT (Agencia Estatal de Administración Tributaria, models 111, 190); entitats bancàries (quaderns SEPA, Single Euro Payments Area); registre horari.

Al sector públic cal, a més: gestió de la RLT (relació de llocs de treball) i de la plantilla, control del capítol 1 del pressupost, triennis i carrera professional, complements específics i de destinació, situacions administratives (TREBEP, art. 85), i tota la casuística del TREBEP → tema comú 14. SAP ofereix per a aquest àmbit l'extensió SAP HCM PSe (Public Sector), que sí inclou processos de selecció i provisió de personal (selecció externa i promoció interna), a banda d'acció social i gestió disciplinària.

5. Evolució i alternatives

• SAP SuccessFactors: la suite HCM al núvol de SAP. Mòduls: Employee Central (nucli), Recruiting, Onboarding, Performance & Goals, Learning, Compensation, Succession & Development, Workforce Analytics. Model híbrid habitual: SuccessFactors per als processos de talent i HCM / ECP (Employee Central Payroll) en local o al núvol per a la nòmina, que és la part més regulada i localitzada.
• ECP (Employee Central Payroll): la nòmina de SAP allotjada al núvol.
• Fi de manteniment: SAP ha anunciat el manteniment de SAP ERP fins al 2027 (amb extensió opcional fins al 2030), cosa que obliga a planificar la migració a S/4HANA o a SuccessFactors.
• Alternatives del mercat: Workday, Oracle HCM Cloud, Meta4/Cegid, Savia, Personio.

6. Protecció de dades

HCM tracta dades personals de categoria especial en alguns casos (salut per a les baixes, afiliació sindical per a les quotes, discapacitat).

• Base de licitud: execució del contracte i compliment d'obligacions legals (RGPD, art. 6), i per a les categories especials, l'RGPD, art. 9.2.b (obligacions en l'àmbit del dret laboral i de la seguretat social).
• Minimització i control d'accés estricte: el model d'autoritzacions de SAP HCM permet limitar l'accés per infotip, subtipus i àmbit organitzatiu.
• Registre d'activitats de tractament (RGPD, art. 30) i terminis de conservació.
• Autoservei: cal assegurar que l'empleat només veu les seves dades i que el comandament només les del seu equip.
• Dret a la intimitat i a la desconnexió digital (LOPDGDD, art. 87 i LOPDGDD, art. 88), i registre horari amb la seva finalitat limitada.

Claus d'examen

• HCM és un mòdul; el producte és l'ERP. Quan l'enunciat demana de quin tipus de producte és un mòdul SAP-HCM, la resposta és ERP, no CRM, BPM ni BI (TS-TIC 2025, pràctica, s3-p030).
• HCM (en local) ≠ SuccessFactors (al núvol). Preguntat directament «quina és la solució de SAP per a la gestió de recursos humans i nòmina?», el tribunal ha triat SAP SuccessFactors com a resposta correcta, no SAP HCM ni S/4HANA: és la confusió més explotada del tema (TS-TIC 2018, p. 3).
• Infotip = estructura de dades amb validesa temporal, no una regla de càlcul de nòmina ni una transacció per generar informes: aquestes són les distractores habituals de la pregunta «què són els “infotips” en SAP HCM?» (TS-TIC 2025, p. 40).
• No confonguis HCM amb els seus veïns sectorials. EA-PS (Enterprise Add-On, Public Services) i PS-CD (comptabilitat pressupostària i recaptació del sector públic → temes tic/sap-fi-y-ea-ps i tic/sap-trm) i SAP Records Management (tramitació d'expedients) no són HCM. La formulació falsa que ha caigut és que HCM PSe no inclou selecció i formació: sí que els inclou (TS-TIC 2021, p. 3).

Per recordar

• SAP HCM és un mòdul de SAP ERP (R/3 / ECC), no un producte independent, i el producte no és ni un CRM, ni un BPM, ni una BI. Al núvol, SuccessFactors.
• Infotip = estructura de dades de RRHH amb codi de quatre dígits i validesa temporal (data d'inici i de fi). Quan una dada canvia, es delimita el registre i se'n crea un de nou: mai no se sobreescriu.
• PA30 manteniment, PA40 mesures, PA20 visualització.
• Infotips clau: 0001 assignació organitzativa, 0002 dades personals, 0008 emoluments bàsics.
• Submòduls: PA, OM, PT, PY, PB/E-Recruiting, PE, PD, ESS/MSS.
• OM treballa amb objectes i relacions: unitat organitzativa (O), lloc (S), funció (C), persona (P).
• La nòmina genera comptabilització a FI/CO i consumeix pressupost (FM, capítol 1).
• HCM tracta categories especials de dades: control d'accés per infotip i mínim privilegi.

Tema 39 · SAP, desenvolupament i ERP

Desenvolupament d'aplicacions mòbils

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

Sense esquema, expressament

Enunciat oficial. Desenvolupament d'Aplicacions Mòbils. (APPS).

1. Tipus d'aplicació mòbil

Abans de començar un projecte cal escollir el tipus d'aplicació, en comparació amb les alternatives, segons els criteris principals que segueixen la taula.

PWA: és la tendència recent de les aplicacions web que aprofiten funcions modernes del navegador per oferir experiències semblants a les de les aplicacions natives; així es coneixen les aplicacions web progressives.

Desavantatge clau de les WebApps davant les natives (pregunta literal): l'accés limitat a les funcionalitats i al maquinari del dispositiu —càmera, GPS d'alta precisió, biometria, NFC (Near Field Communication), Bluetooth, notificacions natives, treball en segon pla— i el rendiment i l'experiència d'usuari inferiors, especialment en interaccions gràfiques intensives.

Criteris de decisió: pressupost i equip disponible, necessitat d'accés al maquinari, exigència de rendiment, previsió de vida de l'aplicació, necessitat de funcionament fora de línia, i estratègia de distribució. Exemple: una app només per a Android que, accedint al micròfon del telèfon, ha de mesurar els decibels i dona prioritat al rendiment per proporcionar una experiència ràpida i bona és un cas clar de nativa: la tecnologia amb l'accés més directe al maquinari.

1.1 Llenguatges de programació

Compilats (C, Java, Swift): el codi font es tradueix sencer a codi màquina abans d'executar-se. Interpretats (Python, JavaScript): un intèrpret llegeix i executa el codi font línia a línia en temps d'execució, sense fase de compilació prèvia; és l'avantatge principal dels interpretats respecte als compilats —a canvi solen ser més lents en execució.

Els llenguatges que es fan servir depenen de la plataforma; el llenguatge tradicionalment més utilitzat a Android va ser Java, encara que avui Kotlin és el recomanat:

2. Cicle de vida i metodologia

Metodologia àgil aplicada a les APP — la característica que la defineix principalment: el desenvolupament es fa en iteracions curtes que lliuren versions funcionals i utilitzables de l'aplicació de manera freqüent, incorporant la retroalimentació de l'usuari a cada cicle i acceptant els canvis de requisits. Això encaixa especialment bé amb el mòbil, on el retorn d'ús real (analítica, valoracions a les botigues, proves A/B) és immediat i abundant.

Fases: descobriment i definició de l'usuari → disseny UX/UI i prototipatge → desenvolupament iteratiu → proves → publicació → analítica i evolució.

Disseny mòbil: els conceptes clau per millorar l'experiència de les persones usuàries són la usabilitat —facilitat d'ús, navegació clara, poques passes per completar una tasca— i l'accessibilitat, i cal prioritzar-les per davant de l'acumulació de funcions o de l'estètica per si sola. mobile first, disseny responsiu i adaptatiu, guies de plataforma (Material Design d'Android, Human Interface Guidelines d'Apple), accessibilitat (WCAG (Web Content Accessibility Guidelines) 2.1 AA, lectors de pantalla VoiceOver i TalkBack, mida de text dinàmica, contrast), i suport de mode fosc i d'orientacions.

Proves: unitàries, d'interfície (Espresso, XCUITest, Appium), en dispositius reals i granges de dispositius (Firebase Test Lab, BrowserStack), i distribució beta (TestFlight, Google Play Internal Testing, Firebase App Distribution).

Publicació: App Store i Google Play, amb els seus processos de revisió, requisits de privadesa (privacy nutrition labels, formulari de seguretat de dades), signatura de l'aplicació i gestió de versions. Per a distribució interna: MDM (Mobile Device Management)/UEM (Unified Endpoint Management) i botigues corporatives → tema 52.

CI/CD mòbil: compilació automàtica, signatura, distribució i publicació (Fastlane, Bitrise, GitHub Actions) → tema 41.

3. Arquitectura i interoperabilitat

Aspecte fonamental per garantir la interoperabilitat d'una APP empresarial o municipal amb altres sistemes: exposar i consumir les dades mitjançant API estàndard, obertes i ben documentades —típicament REST (REpresentational State Transfer, transferència d'estat representacional) amb JSON (JavaScript Object Notation) i especificació OpenAPI—, amb formats de dades i vocabularis estàndard i amb un mecanisme d'autenticació i autorització també estàndard (OAuth 2.0 / OpenID Connect). L'aplicació mòbil ha de ser un client prim sobre serveis reutilitzables, no una integració punt a punt amb la base de dades de cada sistema.

Elements de l'arquitectura:

• BFF (Backend for Frontend) o API Gateway que agrega i adapta els serveis del rerefons per al consum mòbil → tema 48.
• Patrons d'arquitectura de l'aplicació: MVC (Model-View-Controller), MVP (Model-View-Presenter), MVVM (Model-View-ViewModel), MVI, Clean Architecture.
• Sincronització i mode fora de línia: cau local (SQLite, Room, Core Data), cua d'operacions pendents, resolució de conflictes i sincronització diferencial.
• Notificacions push: FCM (Firebase Cloud Messaging) i APNs (Apple Push Notification service).
• Emmagatzematge segur: Keychain a iOS i Keystore/EncryptedSharedPreferences a Android; mai credencials en clar ni a SharedPreferences/UserDefaults.
• Analítica i estabilitat: Firebase Analytics, Crashlytics, esdeveniments de negoci — sempre amb consentiment i base de licitud.

4. Seguretat mòbil

OWASP (Open Web Application Security Project) Mobile Top 10 (2024): ús indegut de credencials · cadena de subministrament insegura · autenticació i autorització insegures · validació d'entrada i sortida insuficient · comunicació insegura · controls de privadesa inadequats · proteccions binàries insuficients · configuració incorrecta de seguretat · emmagatzematge de dades insegur · criptografia insuficient.

Mesures:

• TLS (Transport Layer Security, seguretat de la capa de transport) obligatori amb certificat fixat (certificate pinning) per als serveis crítics; bloqueig de tràfic en clar (ATS, App Transport Security, a iOS, network security config a Android).
• Autenticació: OAuth 2.0 + PKCE (Proof Key for Code Exchange) i OpenID Connect; mai guardar contrasenyes al dispositiu; ús de biometria com a segon factor local. El detall d'aquests mecanismes és a gestió d'identitats.
• Emmagatzematge: xifratge del contingut sensible i ús dels magatzems segurs del sistema.
• Ofuscació del codi i detecció de root / jailbreak i d'entorns manipulats.
• Gestió de permisos amb el principi de mínim privilegi i explicació del propòsit a l'usuari.
• Protecció de dades: base de licitud per a cada tractament, consentiment granular per a analítica i publicitat, transparència sobre els identificadors i les transferències internacionals (RGPD). Al sector públic, també l'ENS i la categorització del sistema.
• Actualització: mecanisme per forçar l'actualització quan hi ha una vulnerabilitat crítica.

5. Aplicacions mòbils al sector públic

Requisits específics:

• Accessibilitat obligatòria: el RD (Reial Decret) 1112/2018 cobreix explícitament les aplicacions per a dispositius mòbils del sector públic — WCAG 2.1 nivell AA, declaració d'accessibilitat publicada i mecanisme de comunicació per a queixes.
• Identificació i signatura: integració amb Cl@ve, idCAT Mòbil i certificats; les operacions que requereixen signatura han de complir la Llei 39/2015, art. 10.
• Notificacions: les push no substitueixen la notificació administrativa; les notificacions fefaents van per la seu i per e-NOTUM → tema 4.
• Multilingüisme: català i castellà com a mínim (EAC, art. 6 i Reglament d'ús de la llengua catalana).
• Neutralitat tecnològica: no es pot obligar el ciutadà a tenir un dispositiu o sistema operatiu concret; sempre hi ha d'haver alternativa web.
• Programari lliure i codi obert com a preferència (Mesura de digitalització oberta), amb reversibilitat i propietat del codi al plec.
• Reutilització (Llei 40/2015, art. 158): consultar el directori d'aplicacions abans de desenvolupar.
• Bretxa digital: l'app és un canal addicional, mai l'únic.

Exemples municipals: Barcelona a la butxaca, apps de mobilitat i aparcament, Decidim (participació), i les apps de la Generalitat i de l'AOC (Administració Oberta de Catalunya).

6. Desplegament massiu a l'organització

Quan l'app és per als empleats i cal desplegar-la a tots els dispositius, la via correcta és el MDM/UEM: Microsoft Intune, Jamf, Workspace ONE, SOTI MobiControl. Permet distribució silenciosa, configuració remota, botiga corporativa, contenidorització del perfil de treball, polítiques de compliment i esborrat remot selectiu. → tema 52.

Programes de les plataformes: Apple Business Manager / Volume Purchase Program i Android Enterprise / Managed Google Play per a la distribució privada d'aplicacions.

Claus d'examen

• El desavantatge de la WebApp és el maquinari, no la connexió. Entre les opcions «requereix connexió constant», «no s'actualitza automàticament» i «no funciona en diverses plataformes», la correcta és sempre l'accés limitat a càmera, GPS (Global Positioning System, sistema de posicionament global) i altres funcions del dispositiu (TS-TIC 2023 pràctica, s4 p. 7).
• PWA no és «aplicació web-nativa» ni «híbrida». Una app web que fa servir funcions modernes del navegador (service worker, manifest) per semblar-se a una nativa és una PWA; la híbrida, en canvi, va empaquetada dins d'un contenidor natiu (TS-TIC 2018 específic, p. 8).
• Interpretats vs. compilats: l'avantatge és no requerir compilació, no ser «més eficients», «més fàcils de mantenir» ni «més segurs» — les tres distraccions habituals (TS-TIC 2023 pràctica, s4 p. 8).
• Un sol sistema operatiu + accés directe a un sensor + rendiment prioritari = nativa, encara que hi hagi pressió per usar una eina cross-platform (TS-TIC 2021 pràctica, s4 p. 9).
• La usabilitat i l'accessibilitat, no els colors ni el nombre de funcions, són el que millora l'experiència d'usuari (TS-TIC 2025 pràctica, s3 p. 2).

Per recordar

• Nativa = millor rendiment i accés complet al maquinari, una base de codi per plataforma. WebApp = una sola base de codi però accés limitat al maquinari i rendiment i UX inferiors.
• Multiplataforma (Flutter, React Native, MAUI) = una base de codi amb rendiment gairebé natiu.
• La metodologia àgil al mòbil es caracteritza per iteracions curtes amb lliuraments funcionals freqüents i retroalimentació contínua de l'usuari.
• La interoperabilitat es garanteix amb API estàndard obertes i documentades (REST/JSON, OpenAPI) i OAuth 2.0 / OIDC (OpenID Connect), no amb integracions punt a punt.
• Mai credencials en clar al dispositiu: Keychain i Keystore; TLS amb pinning; OAuth 2.0 + PKCE.
• El RD 1112/2018 cobreix explícitament les apps mòbils del sector públic: WCAG 2.1 AA, declaració d'accessibilitat i mecanisme de comunicació.
• El desplegament massiu corporatiu es fa amb MDM/UEM, no per botiga pública.

Tema 40 · SAP, desenvolupament i ERP

Eines de desenvolupament: LOW-CODE i NO-CODE

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. Eines de desenvolupament: LOWCODE i NOCODE.

1. Definicions

Les dues són eines de desenvolupament visual: es construeix l'aplicació component a component sobre un llenç, i la plataforma en genera l'execució, les dades i el desplegament. El que les separa és una sola cosa —si es pot escriure codi o no—, i d'aquí surt tota la resta: qui les pot fer servir, fins on arriben i quan es queden curtes.

Tots dos comparteixen: desenvolupament visual (arrossegar i deixar anar), components predefinits, connectors a fonts de dades, plantilles, desplegament automatitzat i cicle de vida gestionat per la plataforma.

Concepte relacionat: el citizen developer és la persona d'una àrea de negoci, sense perfil tècnic, que construeix aplicacions amb aquestes eines dins d'un marc de govern establert per TI (Tecnologies de la Informació). El que el distingeix de qui munta una fulla de càlcul pel seu compte no és l'eina: és que treballa dins d'aquest marc; quan hi treballa fora, el resultat és shadow IT (§5).

2. Quan usar cadascun

El cas natural del no-code és el tràmit intern simple: agilitzar la creació d'un formulari de sol·licitud de material d'oficina, amb la seva aprovació i el seu seguiment, dins d'un projecte corporatiu. S'hi decanta perquè:

• el procés és simple i basat en formulari i aprovació;
• no requereix lògica complexa ni integracions profundes;
• el pot construir i mantenir la mateixa àrea usuària, sense consumir capacitat de l'equip de desenvolupament;
• el temps de lliurament és de dies, no de mesos.

Casos d'ús habituals a una administració: sol·licituds i autoritzacions internes, inventaris i registres d'actius, reserves de sales i vehicles, recollida de dades de camp amb el mòbil (inspeccions, incidències a la via pública), enquestes i formularis de participació, quadres de seguiment d'un servei, i el seguiment intern de peticions que encara viu en una fulla de càlcul compartida. Una aplicació sectorial de tramitació —per exemple la gestió de llicències municipals— hi encaixa si el procediment no és reglat; si ho és, entra en joc el §7.

En canvi, es descarta el no-code quan hi ha requisits de rendiment exigents, lògica de negoci complexa, integracions no cobertes pels connectors, alta criticitat o volums grans.

Regla pràctica de decisió:

3. Plataformes

Power Platform és la més present a les administracions que ja tenen Microsoft 365 (→ tema 51): Power Apps (aplicacions), Power Automate (fluxos), Power Pages (portals), Dataverse (dades) i connectors a centenars de serveis.

Algunes d'aquestes plataformes tenen una modalitat específica per generar aplicacions mòbils natives o multiplataforma (Power Apps, OutSystems, Mendix, Appian); el detall del desenvolupament mòbil es tracta a desenvolupament d'aplicacions mòbils. I encara que el RPA comparteix l'enfocament visual amb poc codi, no construeix aplicació nova: automatitza un procés existent imitant una persona sobre la interfície; es tracta a automatització, orquestració i RPA. La distinció paral·lela amb el BPM és la mateixa vista des de l'altre costat: el BPM modela i orquestra el procés de punta a punta, mentre que el low-code construeix la interfície i l'aplicació que hi participen.

4. Integració amb sistemes existents: connectors i API

El que fa possible que una app low-code/no-code no visqui aïllada és que la plataforma exposa i consumeix serveis en comptes d'obligar a reescriure el que ja hi ha:

• Connectors predefinits: components ja fets per parlar amb un sistema concret (SharePoint, SQL (Structured Query Language) Server, SAP, Salesforce, un servei de correu) sense programar el protocol des de zero; és el cas normal per a integracions habituals. Les plataformes els solen classificar en estàndard i prèmium, i la diferència és de llicència, no de capacitat: els prèmium, els locals i els personalitzats exigeixen un pla de pagament, i per això el catàleg de connectors disponible depèn del que s'hagi contractat.
• Connectors personalitzats: quan no existeix el connector, se'n fa un embolcall d'una API pròpia —s'hi descriu la interfície i les operacions— i a partir d'aquí es fa servir com qualsevol altre. És la via per integrar l'aplicació sectorial de casa que cap fabricant no coneix.
• API (Application Programming Interface, interfície de programació d'aplicacions) REST d'entrada: la plataforma exposa els propis processos i dades com a servei perquè un altre sistema hi pugui trucar.
• API REST de sortida: quan no hi ha connector fet ni se'n vol fer un, un connector genèric HTTP (HyperText Transfer Protocol, protocol de transferència d'hipertext) sobre l'estil REST (REpresentational State Transfer, transferència d'estat representacional) permet trucar qualsevol API que el sistema existent ja publiqui.
• Webhooks: el sistema existent notifica un esdeveniment a la plataforma en temps real, sense que aquesta l'hagi d'anar consultant per sondeig (polling).
• Passarel·la de dades locals (on-premises data gateway): un servei que s'instal·la dins de la xarxa de l'organisme i que fa de pont entre la plataforma al núvol i les fonts internes (una base de dades, un servidor de fitxers). La connexió la inicia la passarel·la cap enfora, així que el sistema intern no s'ha de publicar a internet ni obrir cap port entrant. És la resposta al cas més freqüent a l'administració: l'aplicació és al núvol i les dades no en poden sortir.

Per què això importa especialment a una administració: el sistema ja existent —el padró, el gestor d'expedients, l'ERP (Enterprise Resource Planning, planificació de recursos empresarials) municipal— gairebé mai es pot tocar per adaptar-lo a l'eina nova. La característica d'aquestes plataformes que facilita la integració amb altres sistemes és, doncs, que disposen de connectors i interfícies d'aplicació (API) predefinits; no que calgui codificació manual avançada, ni que la integració sigui impossible, ni que s'hagi d'adaptar el programari existent a la plataforma nova.

El diagrama diu el que el tribunal explota: els tres camins directes exigeixen que el sistema existent sigui accessible, i el quart —la passarel·la— és el que serveix quan no ho és, que a l'administració és el cas normal.

5. Beneficis i riscos

Beneficis: rapidesa de lliurament, reducció del retard acumulat de peticions petites, acostament del negoci a la solució, prototipatge ràpid, menor cost per a aplicacions simples, i estandardització visual i d'accessibilitat si la plataforma ho aporta.

Riscos i límits:

1. Bloqueig de proveïdor (vendor lock-in): el més greu. L'aplicació no és portable: viu dins de la plataforma i sovint no hi ha manera d'exportar-la a codi. La decisió d'assumir aquest risc, o de pagar per evitar-lo, es pren al cas de negoci → tema 3.
2. Shadow IT (Information Technology): aplicacions crítiques construïdes fora del control de TI, sense còpies de seguretat, sense documentació i amb un únic responsable que un dia se'n va.
3. Seguretat i protecció de dades: connectors que treuen dades fora del perímetre, permisos mal configurats, tractaments sense base de licitud ni registre d'activitats.
4. Escalabilitat i rendiment limitats per la plataforma.
5. Cost per usuari i per llicència, que creix amb l'adopció i pot superar el d'un desenvolupament propi. El salt de preu sol arribar quan cal un connector prèmium o la passarel·la (§4).
6. Deute tècnic: no desapareix perquè no hi hagi codi; canvia de forma, i és més difícil de veure. La lògica viu dins d'un llenç visual que no es pot llegir en una revisió de codi ni cercar amb una eina de text; no hi ha proves automàtiques ni control de versions comparables als del desenvolupament tradicional; les mateixes regles es dupliquen d'una aplicació a una altra en comptes de compartir-se; i el coneixement de com funciona se'l queda qui la va fer. El resultat típic és un parc d'aplicacions òrfenes: funcionen, ningú sap com, i cap no es pot refactoritzar.
7. Deute d'integració: cada aplicació nova crea dependències no documentades cap a sistemes que no saben que algú els està consumint.
8. Manteniment i cicle de vida: canvis de versió de la plataforma —que decideix el fabricant, no l'organisme— que trenquen aplicacions ja en producció.

6. Governança

Perquè el low-code/no-code sumi i no fragmenti, cal un marc explícit:

• Catàleg d'entorns: separació de desenvolupament, proves i producció i, en el cas de Power Platform, entorns amb polítiques diferenciades.
• Polítiques de prevenció de pèrdua de dades (DLP, Data Loss Prevention) que restringeixin quins connectors es poden combinar (per exemple, prohibir combinar un connector corporatiu amb un de xarxes socials).
• Classificació d'aplicacions per criticitat: les crítiques passen a ser mantingudes per TI.
• Registre d'aplicacions ciutadanes amb propietari, dades tractades i base de licitud, integrat amb el registre d'activitats de tractament (RGPD, art. 30).
• Formació i comunitat de citizen developers, amb plantilles i components corporatius reutilitzables.
• Revisió de seguretat i d'accessibilitat abans del pas a producció.
• Estratègia de sortida: què es fa si es deixa la plataforma.
• Contractació: exigir reversibilitat, exportació de dades i de definicions, i condicions de sortida (LCSP i Mesura de digitalització oberta).

7. Al sector públic

• Encaix normatiu: qualsevol aplicació que tracti dades personals necessita base de licitud, registre i, si escau, AIPD (Avaluació d'Impacte de Protecció de Dades, RGPD, art. 35); si dicta actes, és actuació administrativa automatitzada (Llei 40/2015, art. 41) amb tot el que comporta —òrgan competent, control de qualitat, auditoria del codi font i òrgan responsable a efectes d'impugnació. Una plataforma que no permeti auditar la lògica és problemàtica en aquest supòsit.
• Accessibilitat: el resultat ha de complir el RD (Reial Decret) 1112/2018 i WCAG (Web Content Accessibility Guidelines) 2.1 AA; no totes les plantilles de les plataformes hi compleixen per defecte.
• Sobirania digital i programari lliure: la Mesura de digitalització oberta estableix la preferència pel programari lliure i els estàndards oberts. Una plataforma propietària de low-code hi entra en tensió: convé valorar les alternatives de codi obert (Budibase, Appsmith, ToolJet, n8n) i, en tot cas, assegurar la portabilitat de les dades.
• Reutilització (Llei 40/2015, art. 158): consultar el directori d'aplicacions abans de construir.
• Ús raonable: el low-code és excel·lent per als tràmits interns i els processos de suport; el nucli de tramitació administrativa, amb els seus requisits d'expedient electrònic, signatura, notificació i arxiu, sol requerir la plataforma corporativa (a Barcelona, el GPA, Gestió de Procediments Administratius) → tema 4.

Claus d'examen

• La integració amb sistemes existents la faciliten els connectors i l'API predefinits, no la codificació manual ni adaptar el sistema existent (TS-TIC 2025 específic, p. 44).
• Diferència real low-code/no-code: no-code no permet gens de codi; low-code sí que pot requerir-ne en casos avançats. No és una qüestió de perfil d'usuari exclusiu ni de límit a pàgines web senzilles (TS-TIC 2025 pràctica, s3 p. 3).
• Tràmit intern senzill sense escriure cap línia de codi = plataforma No-Code, no un framework tradicional (Spring Boot), ni un sistema de gestió de la qualitat del programari (SQMS, Software Quality Management System, tal com ho escriu l'examen), ni un repositori Git: dues d'aquestes tres ni tan sols construeixen aplicacions (TS-TIC 2025 pràctica, s3 p. 4).

Per recordar

• Low-code = perfils tècnics, amb possibilitat d'escriure codi; no-code = usuaris de negoci, exclusivament visual.
• Per a tràmits interns simples (formulari + aprovació) la resposta és no-code / low-code, no desenvolupament tradicional.
• El risc principal és el bloqueig de proveïdor: l'aplicació no és portable.
• El segon risc és el shadow IT: aplicacions crítiques fora del control de TI.
• La governança exigeix entorns separats, polítiques DLP de connectors, registre d'aplicacions, revisió de seguretat i accessibilitat, i estratègia de sortida.
• Si l'aplicació dicta actes administratius, és actuació automatitzada: cal poder auditar-ne la lògica i el codi font.
• Power Platform és la suite més present a les administracions amb Microsoft 365; alternatives lliures: Budibase, Appsmith, ToolJet, n8n.
• La integració amb sistemes existents es fa amb connectors predefinits i API REST (entrada i sortida) i webhooks; és el que permet integrar-se sense tocar el sistema existent, que a l'administració gairebé mai es pot adaptar.
• Quan el sistema intern no és accessible des d'internet, el mecanisme és la passarel·la de dades locals: la instal·la l'organisme i inicia ella la connexió cap enfora, sense obrir cap port entrant.
• El deute tècnic no desapareix per no haver-hi codi: la lògica viu en un llenç visual que no es revisa ni es busca com el codi, i acaba en un parc d'aplicacions òrfenes.
• RPA no és low-code: el RPA automatitza un procés que ja existeix imitant un usuari; el low-code construeix aplicació nova.

Tema 41 · SAP, desenvolupament i ERP

DevOps, CI/CD, contenidors i Kubernetes

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

Enunciat oficial. DevOps i integració/desplegament continus (CI/CD). Contenidors Docker i orquestració Kubernetes.

1. DevOps

Definició: DevOps és una filosofia, un conjunt de pràctiques culturals, organitzatives i tècniques que uneixen desenvolupament (Dev) i operacions (Ops). La seva finalitat principal és millorar la col·laboració entre els dos equips; reduir el temps de lliurament, retallar costos i pujar la qualitat en són conseqüències, no l'objectiu en si.

El problema que resol: el «mur de la confusió» entre un equip de desenvolupament incentivat pel canvi i un equip d'operacions incentivat per l'estabilitat.

DevOps no és una eina ni un producte: és una manera de treballar que després es materialitza en un flux automatitzat. Els components que sí que en formen part són el repositori de codi, la integració i les proves automàtiques i el desplegament automatitzat; tot allò que només observa el resultat —un quadre de comandament d'indicadors de producció— és útil, però no és una peça del cicle.

1.1 Els tres camins i CALMS

1. Flux: optimitzar el flux d'esquerra a dreta, de desenvolupament a producció (lots petits, visualització del treball, eliminació de colls d'ampolla).
2. Retroalimentació: crear cicles de retroalimentació ràpids de dreta a esquerra (proves automàtiques, monitoratge, alertes). Aquest camí és el que exigeix una plataforma d'observabilitat → tema 23.
3. Aprenentatge continu i experimentació: cultura d'aprenentatge, post-mortems sense culpables, injecció de fallides.

CALMS (Culture, Automation, Lean, Measurement, Sharing) és la llista de comprovació d'adopció: cultura, automatització, eliminació del malbaratament, mesura i compartició.

1.2 Les mètriques DORA

DORA (DevOps Research and Assessment) és el grup de recerca —avui a Google— que publica cada any l'informe State of DevOps. Les seves quatre mètriques clau:

La troballa central de DORA és que no hi ha compromís entre velocitat i estabilitat: els equips d'alt rendiment són millors en totes quatre.

1.3 DevSecOps, SRE i plataforma

• DevSecOps: la seguretat entra al pipeline des del primer minut (shift left), en lloc d'auditar-se al final.
• SRE (Site Reliability Engineering): la disciplina de Google que aplica pràctiques d'enginyeria de programari a operacions. DevOps diu què cal aconseguir (cultura i flux); SRE és una implementació concreta amb regles mesurables: SLI (Service Level Indicator, l'indicador mesurat), SLO (Service Level Objective, l'objectiu que se li fixa) i pressupost d'error (error budget), que és el marge de fallida que queda abans d'incomplir l'objectiu i que autoritza o congela els desplegaments nous.
• Enginyeria de plataforma: un equip intern construeix una plataforma d'autoservei perquè la resta desplegui sense demanar permís.

2. Integració contínua

Integració contínua (CI, Continuous Integration): pràctica en què els desenvolupadors integren el seu codi al repositori compartit de manera freqüent —diverses vegades al dia— i cada integració es verifica automàticament amb una compilació i una bateria de proves automatitzades.

Per què és essencial: detecta els errors d'integració i el codi conflictiu en minuts en lloc de setmanes, manté la branca principal sempre desplegable, redueix el cost de la correcció (com més tard es detecta un defecte, més car és), dona retroalimentació ràpida i objectiva, i és la base necessària per a qualsevol grau de lliurament o desplegament continus.

Pràctiques associades: control de versions únic per a tot (codi, configuració, infraestructura), compilacions automatitzades i reproduïbles —mateixa entrada, mateix artefacte—, bateria de proves ràpida, arreglar la compilació trencada com a màxima prioritat i branques de vida curta.

3. Lliurament i desplegament continus

Les dues comparteixen la sigla CD, i és la confusió que més es pregunta: el que canvia no és el grau d'automatització de les proves, sinó qui prem el botó final.

3.1 El pipeline

El pipeline és la cadena automatitzada que porta un canvi del repositori a producció. És la tècnica que implementa el lliurament continu: sense ell, «llest per desplegar en qualsevol moment» és una declaració d'intencions.

commit → build → proves unitàries → anàlisi estàtica i de seguretat →
empaquetat (imatge) → desplegament a proves → proves d'integració i
d'extrem a extrem → preproducció → aprovació → producció → verificació

Quines proves corren a quina etapa és matèria del tema de proves de programari (→ tema 49); aquí importa l'ordre: com més barata i ràpida és una prova, més aviat corre.

Qualitat i seguretat al pipeline: SAST (Static Application Security Testing, anàlisi estàtica del codi), SCA (Software Composition Analysis, dependències de tercers), DAST (Dynamic Application Security Testing, sobre l'aplicació en execució), escaneig de les imatges de contenidor, detecció de secrets i signatura d'artefactes → tema 46.

Artefactes i registre: el pipeline construeix una sola vegada l'artefacte —un fitxer empaquetat o una imatge de contenidor—, el desa en un repositori d'artefactes o registre d'imatges versionat i és aquest mateix artefacte el que puja per tots els entorns. Recompilar per a cada entorn trenca la garantia de que allò provat és allò desplegat.

Eines: Jenkins, GitLab CI/CD, GitHub Actions, Azure DevOps, Tekton, Argo CD i Flux.

3.2 Estratègies de desplegament

• Recreate: aturar i desplegar. Simple, però amb tall de servei.
• Rolling update: substitució progressiva de les instàncies, sense tall. És l'estratègia per defecte de Kubernetes.
• Blau-verd (blue-green): dos entorns idèntics i complets; es commuta el trànsit d'un a l'altre. Retorn immediat, a canvi de duplicar recursos.
• Canari (canary): s'envia un percentatge petit del trànsit a la versió nova i s'incrementa si les mètriques són bones. Limita l'abast de la fallida.
• Feature flags: el codi es desplega desactivat i s'activa per configuració. Desacobla el desplegament de l'alliberament → tema 19.

4. Infraestructura com a codi i GitOps

Infraestructura com a codi (IaC, Infrastructure as Code): gestionar servidors, xarxes i serveis mitjançant fitxers versionats en lloc de configuració manual. La forma correcta de gestionar la infraestructura en un projecte àgil és exactament aquesta: automatitzar-la amb una eina, no configurar-la a mà.

Dues famílies que no s'han de confondre:

• Aprovisionament: crea i destrueix els recursos (Terraform / OpenTofu, Pulumi, CloudFormation).
• Gestió de la configuració: deixa una màquina ja existent en l'estat desitjat —paquets, fitxers, serveis— (Ansible, Puppet, Chef). Ansible és l'exemple de codi obert de referència: sense agent (treballa per connexió remota), descriu infraestructura, aplicacions i xarxa en fitxers de text i serveix tant per a màquines virtuals com per a contenidors.

Distincions que es pregunten:

• Declaratiu vs imperatiu: el declaratiu descriu l'estat desitjat i l'eina calcula els passos; l'imperatiu descriu els passos. Terraform i Kubernetes són declaratius; un guió de consola és imperatiu.
• Idempotència: aplicar la mateixa definició una vegada o deu vegades deixa el sistema en el mateix estat. És el que permet reexecutar sense por.
• Una eina no és un format: YAML i JSON són formats de dades i Python és un llenguatge; cap dels tres és, per si sol, una eina de gestió de la configuració. I kubectl tampoc: és el client de línia d'ordres de Kubernetes, limitat a aquest orquestrador.

Infraestructura immutable: els components no es modifiquen un cop desplegats; quan cal un canvi es construeix una instància nova a partir de la imatge actualitzada i se substitueix la vella. Elimina la deriva de configuració (configuration drift), fa els desplegaments reproduïbles i simplifica el retorn. S'oposa a la infraestructura mutable, on s'apedacen els servidors existents.

GitOps: portar el model anterior fins al final. L'estat desitjat viu a Git, que és l'única font de veritat, i un agent reconciliador dins del clúster compara contínuament l'estat real amb el declarat i el corregeix (Argo CD, Flux). Desplegar és fusionar un canvi; retornar és revertir-lo.

5. Contenidors i Docker

Contenidor: unitat d'empaquetat que conté l'aplicació i totes les seves dependències —biblioteques, configuració i entorn d'execució— i que s'executa aïllada compartint el nucli del sistema operatiu amfitrió.

Avantatges, per ordre del que es pregunta:

• Lleugeresa i eficiència en l'ús dels recursos: no hi ha sistema operatiu convidat, i per tant l'arrencada és de segons i la densitat per servidor és molt més alta.
• Consistència entre entorns: l'aplicació s'executa idènticament al portàtil, a integració i a producció, perquè el paquet inclou les dependències.
• Portabilitat entre amfitrions i entre proveïdors, i encaix natural amb la integració i el lliurament continus i amb els microserveis (un servei, una imatge → tema 48).

5.1 Contenidor, màquina virtual i chroot

La conseqüència pràctica: si cal executar sistemes operatius diferents i complets sobre un mateix maquinari —programari que només funciona sobre Windows al costat d'aplicacions Linux—, la resposta és la màquina virtual, no el contenidor. Les dues tecnologies conviuen: el patró habitual és un clúster de contenidors sobre màquines virtuals.

L'antecessor és chroot, que només canvia el directori arrel que veu un procés: no aïlla processos, ni xarxa, ni usuaris, ni limita recursos, i no és una plataforma de desplegament.

Tecnologia de base a Linux: namespaces —aïllament de processos, xarxa, muntatges, usuaris, comunicació entre processos i nom d'amfitrió— i cgroups —límits de CPU (Central Processing Unit), memòria i entrada/sortida—, més capabilities, seccomp i SELinux/AppArmor.

5.2 La imatge en capes i el contenidor efímer

• Dockerfile: la recepta declarativa que construeix la imatge; cada instrucció genera una capa.
• Imatge: plantilla immutable, formada per capes de només lectura i identificada per una etiqueta i un resum criptogràfic.
• Contenidor: una instància en execució d'una imatge, amb una capa d'escriptura pròpia i efímera al damunt (copy-on-write).

D'aquí surt la regla que més cau: tot el que s'escriu dins d'un contenidor viu en aquesta capa i desapareix quan el contenidor s'elimina. Modificar a mà un fitxer de configuració dins d'un contenidor no toca la imatge: en tornar a instanciar-la reapareix la configuració original i el problema torna. Per això:

• Les dades que han de sobreviure van fora: volums gestionats pel motor, muntatges d'un directori de l'amfitrió o emmagatzematge de xarxa.
• La configuració va fora de la imatge: variables d'entorn, volums i, a Kubernetes, ConfigMap i Secret. Escriure els valors dins del Dockerfile els cou a la imatge i obliga a una imatge per entorn: és precisament l'opció que no val.
• Els registres surten per la sortida estàndard i els recull la plataforma, en lloc d'acumular-se al disc del contenidor.

5.3 Docker, OCI i els altres motors

• Registre (registry): repositori d'imatges, públic o privat (Docker Hub, Harbor, els dels proveïdors de núvol).
• Docker Compose: definició multicontenidor per a entorns de desenvolupament.
• OCI (Open Container Initiative): l'organisme, sota la Linux Foundation, que estandarditza el format d'imatge, el temps d'execució i la distribució. És el que fa que «contenidor» no vulgui dir «Docker»: qualsevol motor conforme executa la mateixa imatge.

5.4 Seguretat dels contenidors

La guia de referència és la NIST SP (Special Publication) 800-190, que ordena els riscos pels components: imatge, registre, orquestrador, contenidor i sistema operatiu amfitrió. Contramesures mínimes:

• Imatges mínimes (Alpine, distroless) i compilació multietapa: menys programari, menys superfície.
• No executar com a arrel ni amb contenidor privilegiat.
• Cap secret dins de la imatge, que és de només lectura i es distribueix.
• Etiquetes immutables —mai latest en producció— i signatura de la imatge.
• Escaneig de vulnerabilitats de la imatge i de les seves dependències, integrat al pipeline.
• Amfitrió endurit: el nucli és compartit, i una fuita del contenidor compromet tots els que hi conviuen.

6. Kubernetes

Definició: plataforma de codi obert per a l'orquestració de contenidors. Automatitza el desplegament, l'escalat, la recuperació i la gestió d'aplicacions contenidoritzades sobre un clúster de màquines. Un contenidor sol no dona alta disponibilitat; l'orquestrador sí: manté el nombre de rèpliques declarat, reprograma els contenidors d'un node caigut i retira del balanceig els que no superen les proves de vida.

6.1 Arquitectura

Model declaratiu i reconciliació: es declara l'estat desitjat i els controladors treballen contínuament perquè l'estat real hi coincideixi. És el fonament de GitOps i el que dona l'autoreparació.

6.2 Objectes de càrrega de treball

• Pod: la unitat mínima desplegable. Un o més contenidors que comparteixen xarxa —una adreça i un espai de ports— i emmagatzematge, i que sempre es programen junts al mateix node. Kubernetes no desplega contenidors solts.
• ReplicaSet: manté el nombre de rèpliques d'un pod.
• Deployment: gestiona ReplicaSets i ofereix actualització progressiva amb retorn (rollback). És l'objecte habitual per a serveis sense estat.
• StatefulSet: per a càrregues amb estat, amb identitat de xarxa i emmagatzematge estables per rèplica.
• DaemonSet: una rèplica per node (agents de registre, de mètriques, de xarxa).
• Job: executa un o diversos contenidors fins que completen amb èxit una tasca puntual —un procés per lots (batch)— i no es torna a llançar. CronJob: llança un Job a una hora programada, puntualment o recurrentment, com el cron d'Unix. Cap dels dos manté rèpliques contínues com Deployment, ni s'executa un cop per node com DaemonSet.

6.3 Xarxa, configuració i emmagatzematge

• Service: adreça i nom estables amb balanceig cap a un conjunt de pods, que van i vénen. Tipus: ClusterIP (intern, el tipus per defecte), NodePort (un port fix a cada node), LoadBalancer (balancejador extern del proveïdor) i ExternalName (àlies a un nom extern).
• Ingress i Gateway API: no són un tipus de Service. Són el punt d'entrada del trànsit web des de fora, amb encaminament per amfitrió i per ruta i acabament de xifratge, i concentren en un sol recurs allò que si no exigiria un balancejador per servei.
• ConfigMap i Secret: configuració i dades sensibles fora de la imatge, injectades com a variables d'entorn o com a fitxers.
• PersistentVolume (PV) i PersistentVolumeClaim (PVC, Persistent Volume Claim): el primer és el volum real que ofereix l'administrador o una classe d'emmagatzematge; el segon és la petició que en fa l'aplicació. Separen qui consumeix de qui proveeix.
• Namespace: separació lògica dins d'un mateix clúster, amb quotes i permisos propis.

6.4 Recursos, escalat, seguretat i ecosistema

• Peticions i límits: la petició (request) és el que el planificador reserva per decidir on cap el pod; el límit és el sostre que no pot passar. Sense petició no hi ha planificació fiable; sense límit, un pod pot ofegar el node.
• Escalat automàtic: HPA (Horizontal Pod Autoscaler, més rèpliques segons una mètrica), VPA (Vertical Pod Autoscaler, més recursos per rèplica) i autoescalat de nodes.
• Sondes: de vida (liveness), de disponibilitat (readiness) i d'arrencada (startup). Són el que converteix les rèpliques en alta disponibilitat real.
• Seguretat: RBAC (Role-Based Access Control) amb mínim privilegi, comptes de servei, NetworkPolicy per a la microsegmentació entre pods, secrets xifrats en repòs, admissió de polítiques (OPA (Open Policy Agent) o Kyverno) i actualització del clúster.
• Ecosistema: Helm (empaquetat i plantilles reutilitzables), Kustomize, operadors (lògica d'operació pròpia mitjançant recursos a mida), service mesh → tema 47, i observabilitat → tema 23. La CNCF (Cloud Native Computing Foundation) allotja i gradua aquests projectes.
• Plataformes i distribucions: OpenShift, Rancher, k3s i els serveis gestionats dels grans proveïdors de núvol. Compte amb els productes veïns que no són plataformes de contenidors: dins de la mateixa família d'un fabricant hi conviuen l'hipervisor i l'emmagatzematge definit per programari —vSAN n'és el cas típic—, que resolen un altre problema.

7. Al sector públic

• Contractació: cal preveure la propietat del codi i de les definicions d'infraestructura, la reversibilitat i la portabilitat entre proveïdors (LCSP, Llei de Contractes del Sector Públic, i Mesura de digitalització oberta).
• Kubernetes com a capa d'abstracció és una de les millors defenses contra el bloqueig de proveïdor de núvol → tema 59.
• Seguretat: l'ENS (Esquema Nacional de Seguretat) exigeix control de canvis, gestió de la configuració, gestió de vulnerabilitats i traçabilitat; el pipeline n'és l'instrument natural.
• Traçabilitat de l'actuació automatitzada (Llei 40/2015, art. 41): auditar el codi font i les versions desplegades es resol amb control de versions i signatura d'artefactes.
• Programari lliure: tot l'ecosistema descrit és de codi obert, cosa que encaixa amb la política municipal.

Claus d'examen

• La pregunta que més ha caigut és la de sempre: quina pràctica executa proves automàtiques cada cop que s'integra codi al repositori compartit. La resposta és integració contínua, no desplegament continu ni gestió de la configuració (TS-TIC 2025, p. 45; i reformulada a TS-TIC 2025, pràctica p. 7).
• El pipeline implementa el lliurament continu de programari, no els contenidors ni els microserveis, encara que hi convisquin (TS-TIC 2018, p. 7).
• El contenidor és efímer: el tribunal ho ha preguntat dues vegades, per les dues cares. Un fitxer creat dins d'un contenidor s'esborra quan aquest s'atura o s'elimina (TS-TIC 2021, p. 8), i per això editar-hi la configuració a mà no arregla res (TM-TIC 2021, pràctica p. 8).
• Quan la pregunta demana executar sistemes operatius complets i diferents sobre el mateix maquinari, la resposta és màquina virtual, mai contenidor: el contenidor comparteix el nucli (TS-TIC 2023, pràctica p. 12).
• Preguntes de tipus «quina NO»: sol colar-s'hi un producte d'una altra categoria —emmagatzematge definit per programari entre plataformes de contenidors (TS-TIC 2023, pràctica p. 13)—, o un valor cuit dins del Dockerfile entre les maneres de configurar des de fora (TM-TIC 2021, p. 15). Classifica el producte abans de respondre.
• Eina no és format: si demanen l'eina de codi obert que desplega i configura infraestructura, aplicacions i xarxa, és Ansible; YAML i JSON són formats i Python és un llenguatge (TM-TIC 2021, pràctica p. 7).

Per recordar

• Integració contínua = integrar sovint i verificar automàticament amb proves a cada integració. Lliurament continu = llest per desplegar, amb botó humà; desplegament continu = a producció sense intervenció.
• Les quatre mètriques DORA: freqüència de desplegament i temps de lliurament (velocitat), temps de recuperació i taxa de fallides dels canvis (estabilitat).
• SRE és una implementació concreta de DevOps: SLI, SLO i pressupost d'error.
• L'avantatge del contenidor és la lleugeresa i l'eficiència de recursos més la consistència entre entorns. Comparteix el nucli de l'amfitrió; la màquina virtual porta el seu propi sistema operatiu complet i és l'única que fa conviure Linux i Windows sobre el mateix maquinari.
• La imatge és immutable i per capes; el contenidor hi afegeix una capa d'escriptura efímera. Dades i configuració, sempre fora: volums, variables d'entorn, ConfigMap i Secret.
• OCI estandarditza imatge, execució i distribució: contenidor no és sinònim de Docker.
• Pod = unitat mínima desplegable; Deployment gestiona rèpliques i actualització progressiva; Service dona adreça estable —ClusterIP per defecte—; Ingress és l'entrada web i no és un tipus de Service; etcd guarda l'estat i tot passa pel servidor d'API.
• Kubernetes és declaratiu i reconciliatiu, i és l'orquestrador —no el contenidor sol— qui aporta alta disponibilitat.
• Infraestructura immutable: no es modifica en calent, es reemplaça; elimina la deriva de configuració. GitOps posa aquest estat desitjat a Git com a única font de veritat.
• Aprovisionament (Terraform) i gestió de la configuració (Ansible) no són el mateix; les dues han de ser idempotents (IaC).
• Blau-verd = commutació entre dos entorns complets; canari = increment progressiu del trànsit; feature flags desacoblen desplegament i alliberament.

Tema 42 · SAP, desenvolupament i ERP

Solucions ERP (Enterprise Resource Planning)

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

Enunciat oficial. Solucions ERP (Enterprise Resource Planning).

1. Definició

ERP (Enterprise Resource Planning, planificació de recursos empresarials): sistema d'informació integrat que gestiona de manera unificada els processos i els recursos de tota l'organització —finances, compres, logística, producció, recursos humans, projectes— sobre una base de dades única i compartida, amb processos estandarditzats i informació en temps real.

Aquesta és la definició que cal saber donar. Els tres elements que la caracteritzen:

1. Integració: els mòduls comparteixen dades; un fet s'introdueix una sola vegada i es propaga a tots els àmbits afectats.
2. Base de dades única: no hi ha còpies ni sincronitzacions; hi ha una sola versió de la veritat.
3. Processos estandarditzats basats en bones pràctiques del sector, parametritzables.

2. Característiques

NO és característica pròpia d'un ERP: «estar format per aplicacions independents amb bases de dades separades», «orientar-se exclusivament a la relació amb el client» (això és el CRM, Customer Relationship Management, gestió de la relació amb el client), «no requerir parametrització» o «ser específic d'una única àrea funcional». Aquestes són les distractores de la pregunta «quina d'aquestes característiques NO seria pròpia d'un sistema ERP».

3. Mòduls habituals

Financers: comptabilitat general, comptes a pagar i a cobrar, immobilitzat, tresoreria, comptabilitat analítica, pressupost. Logístics: compres i aprovisionament, gestió d'inventari i magatzems, vendes i distribució, gestió de la cadena de subministrament. Producció: planificació de materials (MRP, Material Requirements Planning, planificació de necessitats de materials), planificació de la capacitat, ordres de fabricació, qualitat. Recursos humans: administració de personal, nòmina, temps, formació, selecció. Projectes: planificació, imputació de costos, facturació. Manteniment: actius, ordres de treball, preventiu i correctiu. Analítica: informes integrats i connexió amb el BI (Business Intelligence, intel·ligència de negoci).

Al sector públic s'hi afegeixen com a mòduls imprescindibles: gestió pressupostària amb control de disponibilitat de crèdit, gestió de subvencions, gestió tributària i contractació pública. → temes 36 i 37.

4. El mercat

Tendències: ERP al núvol (SaaS) en substitució del model en local; arquitectura composable (nucli ERP prim + solucions especialitzades integrades per API, Application Programming Interface, interfície de programació d'aplicacions, sense modificar-lo); i incorporació d'IA (Intel·ligència Artificial) per a previsió, detecció d'anomalies i automatització. Cada fabricant té el seu propi principi d'extensibilitat del nucli i la seva pròpia plataforma de núvol per a implementar-lo —el cas de SAP es desenvolupa al tema corresponent.

5. Implantació

Fases: preparació del projecte → anàlisi de processos (blueprint) → realització i parametrització → proves i migració de dades → preparació final i formació → arrencada (go-live) i suport → estabilització i millora contínua.

Metodologies: SAP Activate (successora d'ASAP, Accelerated SAP), Oracle OUM (Oracle Unified Method), Microsoft Sure Step.

Estratègies d'arrencada: big bang (tot alhora, més risc i menys cost de convivència), per fases (per mòdul o per unitat, menys risc però amb interfícies temporals) i pilot (una unitat primer).

Factors crítics d'èxit:

• Patrocini de l'alta direcció i governança clara del projecte.
• Gestió del canvi organitzatiu: un ERP canvia com treballa la gent; és la causa de fracàs més freqüent.
• Adaptar l'organització al sistema, no el sistema a l'organització: minimitzar els desenvolupaments a mida.
• Qualitat i neteja de les dades mestres abans de migrar-les.
• Formació dels usuaris i usuaris clau implicats des del disseny.
• Abast controlat: el scope creep és endèmic als projectes d'ERP.

Riscos: sobrecost i retard, excés de desenvolupaments a mida que hipoteca les actualitzacions futures, resistència al canvi, migració de dades deficient, dependència del proveïdor implantador, i pèrdua de coneixement quan marxa el consultor.

6. Model de dades i integració

• Dades mestres: proveïdors, clients/tercers, materials, comptes, centres de cost, empleats. La seva qualitat i unicitat determina la del sistema sencer → tema 31.
• Documents i fluxos: cada procés genera documents encadenats (sol·licitud → comanda → recepció → factura → pagament), amb traçabilitat completa i verificació creuada.
• Integració amb l'exterior: API REST (Representational State Transfer) / SOAP (Simple Object Access Protocol), fitxers estructurats, middleware i bus de serveis (ESB, Enterprise Service Bus) — cada fabricant té la seva pròpia plataforma d'integració; la de SAP es desenvolupa al tema corresponent.
• Al sector públic: integració amb FACe/e-FACT (factura electrònica), PLACSP (Plataforma de Contractació del Sector Públic), AEAT (Agència Estatal d'Administració Tributària) i Seguretat Social, entitats bancàries (quaderns i SEPA, Single Euro Payments Area), Cadastre i DGT (Direcció General de Trànsit), i amb la plataforma de tramitació i l'expedient electrònic → tema 4.
• Marc legal que condiciona l'ERP públic (i el diferencia del privat): la Llei 39/2015 i la Llei 40/2015 regulen el document i l'expedient electrònic: dels documents que genera l'ERP —comandes, factures, resolucions— s'hi incorporen els que, segons el procediment, en siguin antecedent, fonament o execució (art. 70), no tots per defecte, amb interoperabilitat entre administracions i conservació garantida → tema 4. Aquesta interoperabilitat es concreta a l'ENI (Esquema Nacional d'Interoperabilitat, Reial decret 4/2010): estàndards de dades, formats i signatura que l'ERP públic ha de complir per intercanviar informació amb altres administracions. El mòdul financer ha de controlar la disponibilitat de crèdit segons la normativa pressupostària aplicable a cada administració; la Llei orgànica 2/2012 hi aporta el marc d'estabilitat i sostenibilitat financera, no la regla concreta.

7. ERP vs altres sistemes

OLTP (OnLine Transaction Processing, processament transaccional) prioritza transaccions curtes i freqüents; OLAP (OnLine Analytical Processing, processament analític) prioritza consultes agregades sobre grans volums. SCM (Supply Chain Management, gestió de la cadena de subministrament) coordina proveïdors, transport i inventari fora dels murs de l'organització.

Els ERP moderns incorporen mòduls de CRM i de SCM, però la distinció conceptual es manté i es pregunta. → temes 43 i 35.

Un CMS (Content Management System, sistema de gestió de continguts) no és cap dels tres anteriors: és l'eina per crear i mantenir manualment un lloc web —pàgines, indicadors, notícies— sense necessitat de programar. El seu tret distintiu és que separa el contingut de la presentació (disseny/plantilla): cadascun es pot gestionar de manera independent, de manera que qui edita text no toca el disseny i canviar l'aparença no obliga a retocar els continguts. Quan l'enunciat demana l'eina per a un web informatiu de manteniment manual, la resposta és el CMS, no l'ERP: l'ERP gestiona processos i transaccions internes, no publicació de contingut.

Claus d'examen

• Quan l'enunciat descriu un web informatiu de manteniment manual (sense flux transaccional), la resposta és CMS, no ERP: l'ERP gestiona processos i transaccions internes (TS-TIC 2021, pràctica s4 p8).
• «Quina característica NO és pròpia d'un ERP» té diversos jocs de distractors segons la convocatòria: pot sortir Volatilitat (un ERP és traçable i persistent, no volàtil, TS-TIC 2025, pràctica s1 p10) o «no requerir parametrització» / «bases de dades separades» en altres anys.
• «Quina opció NO és un objectiu d'un ERP» — la trampa és gestionar recursos de maquinari: un ERP gestiona processos i recursos de negoci, no infraestructura física (TS-TIC 2023, pràctica s4 p16).
• La definició bàsica d'ERP («com el definiries?») sempre inclou gestió integrada de diversos àmbits (finances, RRHH (Recursos Humans), producció, logística); una resposta que en cenyeix un de sol (vendes, compres en línia) és distractora (TS-TIC 2025, específic p16).
• Un requeriment de nòmina en una administració nova és cas d'ús d'ERP, no de Big Data, Facility Management ni BPM (Business Process Management): la nòmina és un procés de negoci transaccional, no anàlisi de dades ni gestió d'actius físics (TM-TIC 2021-OP, específic p20).

Per recordar

• ERP = sistema integrat que gestiona tots els processos de l'organització sobre una base de dades única, amb processos estandarditzats i informació en temps real.
• Característiques: modular, integrat, adaptable per parametrització, transversal, base de dades única, temps real, traçable.
• No és propi d'un ERP tenir aplicacions i bases de dades separades, ni ser específic d'una sola àrea.
• Al sector públic hi calen gestió pressupostària amb control de crèdit, subvencions, tributs i contractació.
• La causa de fracàs més freqüent és la gestió del canvi, no la tecnologia.
• Adaptar l'organització al sistema: cada desenvolupament a mida hipoteca les actualitzacions.
• ERP = intern i operacional; CRM = client; SCM = cadena de subministrament; BI = anàlisi; CMS = publicació de continguts web amb manteniment manual.
• Al sector públic, la Llei 39/2015, la Llei 40/2015, l'ENI (Reial decret 4/2010) i la Llei orgànica 2/2012 condicionen l'ERP: expedient electrònic, interoperabilitat i control de disponibilitat de crèdit.

Tema 43 · SAP, desenvolupament i ERP

Solucions CRM (Customer Relationship Management)

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

Enunciat oficial. Solucions CRM (Customer Relationship Management).

1. Definició

CRM (Customer Relationship Management — gestió de la relació amb el client): estratègia de negoci, suportada per tecnologia, orientada a gestionar i optimitzar totes les relacions i interaccions d'una organització amb els seus clients actuals i potencials, centralitzant la informació del client en un únic repositori per millorar-ne el coneixement, l'atenció, la fidelització i el valor a llarg termini.

Les tres paraules de la sigla, enteses literalment:

• Customer (client): la persona o organització amb qui es té la relació, no el producte que se li ven ni la venda en si mateixa.
• Relationship (relació): un vincle continuat al llarg del temps, no una transacció puntual — és el que distingeix el CRM d'un simple sistema de facturació o de vendes.
• Management (gestió): el procés sistemàtic de captar, organitzar i explotar la informació d'aquesta relació, no una llista de contactes solta.

Tres nivells del concepte:

• Estratègia: posar el client al centre de les decisions.
• Procés: unificar la manera de captar, atendre i retenir.
• Tecnologia: el sistema que ho suporta.

Un CRM no és una eina de gestió interna de recursos (això és l'ERP — Enterprise Resource Planning), ni una base de dades de màrqueting per enviar correus, ni un sistema de tiquets tècnics (això és l'ITSM — Information Technology Service Management), encara que en comparteixi funcionalitats.

2. Mòduls habituals d'un CRM

Aquesta és la pregunta més freqüent del tema: quins mòduls són propis d'un CRM.

Escenari típic d'examen: cal una solució per automatitzar el màrqueting i la força de venda, així com gestionar el servei al client i el help desk. La resposta és un CRM, no un ERP ni una eina d'ITSM: aquests quatre àmbits —màrqueting, vendes, servei al client i help desk— són precisament els mòduls nuclears d'un CRM.

3. Tipus de CRM

4. Conceptes

• Vista única del client (customer 360): l'objectiu tecnològic central del CRM.
• Contacte potencial (lead) → oportunitat → compte i contacte: el recorregut típic.
• Embut de vendes (pipeline) i fases de l'oportunitat.
• Cicle de vida del client: captació, conversió, creixement, retenció i recuperació.
• CLV (Customer Lifetime Value): valor total que aporta un client al llarg de la relació.
• Taxa de rotació (churn): percentatge de clients que abandonen.
• Omnicanalitat: coherència de la conversa a través de tots els canals; l'usuari no repeteix el context.
• Journey map: mapa del recorregut de l'usuari amb els seus punts de contacte i punts de dolor.
• Qualitat de dades i duplicats: la vista única del client només funciona si no hi ha registres duplicats o desactualitzats; depurar-los és una tasca contínua, no una fase única de la implantació.

5. Modalitats de solució

Suite generalista vs. CRM vertical: la majoria de fabricants (Salesforce, Microsoft Dynamics 365, SAP CX, Oracle CX, HubSpot) ofereixen una suite amb mòduls vàlids per a qualsevol sector; un CRM vertical ve preconfigurat per a un sector concret (banca, salut, sector públic) amb els processos i camps ja modelats, a canvi de menys flexibilitat.

SaaS vs. on-premise: la majoria de CRM actuals es contracten com a SaaS —el fabricant allotja i actualitza el sistema, pagament per usuari i mes—; l'alternativa on-premise, instal·lada i mantinguda per l'organització, és minoritària i típica del codi obert (SuiteCRM, Odoo CRM, EspoCRM), que també permet personalitzar-ne el codi.

Tendència: integració creixent amb l'ERP i incorporació d'IA (Intel·ligència Artificial) generativa per resumir converses i suggerir respostes.

6. CRM al sector públic: la relació amb la ciutadania

L'equivalent públic del CRM és el CzRM (Citizen Relationship Management). Les diferències són substancials:

Aplicacions municipals: sistema d'atenció ciutadana multicanal (OAC (Oficina d'Atenció Ciutadana), 010, seu electrònica, xarxes), gestió d'incidències i suggeriments de la via pública, seguiment d'expedients des de la perspectiva del ciutadà, carpeta ciutadana i comunicació personalitzada de tràmits i venciments.

Cauteles imprescindibles:

• Base de licitud per a cada tractament i registre d'activitats (RGPD, art. 30).
• Minimització: no acumular perfils de ciutadà «per si de cas».
• Transparència: informar del tractament i dels drets.
• Cap segregació desfavorable derivada del perfilat; el principi d'igualtat de l'art. 14 CE (Constitució Espanyola) hi és aplicable.
• Accessibilitat dels canals (RD (Reial Decret) 1112/2018, WCAG (Web Content Accessibility Guidelines) 2.1 AA) i manteniment dels canals no electrònics (Llei 39/2015, art. 14).
• Seguretat segons la categoria del sistema a l'ENS.
• El CzRM no substitueix el registre ni l'expedient electrònic: la relació jurídica formal continua sent la de la Llei 39/2015.

7. Integració ERP–CRM

• El CRM gestiona la relació; l'ERP, la transacció i el recurs. La comanda neix al CRM i s'executa a l'ERP; la factura i el cobrament viuen a l'ERP i el CRM n'ha de veure l'estat.
• Dades mestres compartides: el tercer (client/ciutadà) ha de ser el mateix a tots dos sistemes. Cal MDM (Master Data Management) o, com a mínim, un identificador comú → tema 31.
• Integració per API (Application Programming Interface) i esdeveniments, no per còpia periòdica de taules.
• Al sector públic, la dada mestra de persona sol ser el padró municipal i el NIF (Número d'Identificació Fiscal) o NIE (Número d'Identitat d'Estranger), amb la interoperabilitat de Via Oberta per evitar demanar dades que ja té l'Administració (once-only, Llei 39/2015, art. 28).

Claus d'examen

• Automatitzar màrqueting + força de vendes + servei al client + help desk = CRM, mai ERP, BI ni BPM (Business Process Management): aquests quatre àmbits són els mòduls nuclears del CRM (TS-TIC 2023, p. 11).
• Un mòdul de seguiment d'oportunitats de venda i contactes és CRM; nòmines és RRHH (Recursos Humans)/ERP i compres és logística/ERP: cap dels dos és CRM (TS-TIC 2025, p. 83).
• La definició que dona el tribunal insisteix en vendes, màrqueting i servei postvenda com els tres pilars d'una solució CRM (TS-TIC 2025, p. 17).

Per recordar

• CRM = estratègia + procés + tecnologia per gestionar la relació amb el client, amb la informació centralitzada en un repositori únic.
• Mòduls nuclears: màrqueting, força de vendes (SFA), servei al client i help desk, i analítica de client. Si l'enunciat combina aquests quatre àmbits, la resposta és CRM.
• Tres tipus: operacional, analític i col·laboratiu.
• CRM ≠ ERP: el CRM mira cap enfora (el client); l'ERP, cap endins (els recursos i els processos).
• Al sector públic (CzRM) l'objectiu és qualitat, equitat i accessibilitat, mai la rendibilitat; l'interès legítim no serveix com a base de licitud per a les autoritats públiques.
• El CzRM no substitueix el registre ni l'expedient electrònic.
• ERP i CRM han de compartir la dada mestra del tercer i integrar-se per API.