--- title: "Modelar per a Power BI (I): datamarts, KPI i una única versió de la veritat" description: "Abans d'obrir Power BI: quin paper té el datamart, com definir KPI sense ambigüitats, anomenar-los amb criteri i tractar els casos extrems de cada fórmula." url: https://bidatia.com/ca/idees/modelar-para-power-bi-i-kpis-y-mapa-de-indicadores lang: ca date: 2026-11-05 updated: 2026-11-05 author: "Santos Vicente" keywords: ["power bi", "datamart", "kpi", "mapa d'indicadors", "diccionari de mètriques", "govern de les dades", "modelatge de dades", "assegurances"] publisher: Bidatia --- # Modelar per a Power BI (I): datamarts, KPI i una única versió de la veritat > Abans d'obrir Power BI: quin paper té el datamart, com definir KPI sense ambigüitats, anomenar-los amb criteri i tractar els casos extrems de cada fórmula. ## Resum executiu - Un bon model de Power BI comença molt abans de Power BI: en què es vol mesurar i com es defineix cada indicador. - El datamart és el pont entre el data warehouse corporatiu i el negoci: una vista temàtica, ràpida i comprensible d'una àrea. - Cada KPI necessita un mapa: definició de negoci, fórmula, dades necessàries i regles per als casos especials. - Una única versió de la veritat: la fórmula s'implementa una sola vegada i tots els informes la reutilitzen. - Una nomenclatura comuna (fórmula, concepte, categoria, període) fa que els noms tècnics s'expliquin sols. - Les fórmules aparentment senzilles, com una variació percentual, amaguen divisions per zero i canvis de signe que cal acordar per escrit. Quan un informe de Power BI no quadra, el problema gairebé mai no és al gràfic. És abans: en un indicador que cada àrea calcula a la seva manera, en una taula amb més detall del necessari o en una fórmula que ningú no va decidir com s'havia de comportar quan el denominador és zero. Aquesta sèrie recorre com modelar bé per a Power BI, de principi a fi. En aquesta primera part ens centrem en el que cal resoldre **abans de construir cap taula**: el paper del datamart i la definició dels indicadors. A la [segona part](/ca/idees/modelar-para-power-bi-ii-datamart-y-modelo-semantico) passem al disseny dimensional i al model semàntic. Farem servir com a fil conductor el sector assegurador (pòlisses, primes, sinistres i reserves), però els principis serveixen per a qualsevol negoci. ## El datamart: el pont entre el data warehouse i el negoci Un **datamart** és un subconjunt temàtic del data warehouse corporatiu, orientat a una àrea de negoci concreta. En una asseguradora n'hi pot haver un de sinistres, un altre de producció comercial i un altre de reserves tècniques. Mentre el data warehouse integra la informació de tota l'organització, cada datamart ofereix una vista depurada i optimitzada del que necessita un equip. Els avantatges són pràctics: - **Velocitat.** Com que només conté les dades d'un domini, les consultes i els informes responen molt més de pressa que sobre el magatzem complet. - **Senzillesa i autoservei segur.** Una estructura en estrella amb taules com Sinistres, Client, Producte i Data és comprensible per a un analista de negoci; un model corporatiu amb centenars de taules, no. - **Adaptació a l'àrea.** Pot incorporar càlculs propis, com provisions acumulades o segmentacions de risc de l'àrea actuarial, sense deixar de partir de les dades oficials. - **Govern local.** Hereta la qualitat del magatzem corporatiu i hi afegeix les regles de l'àrea (per exemple, treballar només amb els darrers cinc anys) sense tocar el model global. Un datamart ben concebut és l'equilibri entre el govern corporatiu i l'agilitat departamental. ## Dependent o independent Hi ha dues maneres de construir-los: | | Datamart dependent | Datamart independent | |---|---|---| | Origen | El data warehouse corporatiu | Directament les fonts operacionals o externes | | Avantatge | Dades ja integrades i depurades: una sola font de veritat | Agilitat: es pot començar sense un magatzem central | | Risc | Creure que la coherència dels KPI està garantida | Definicions diferents entre departaments | L'enfocament dependent és el més recomanat quan hi ha un data warehouse. L'independent, associat a l'enfocament incremental de Kimball, és vàlid per atendre necessitats urgents i créixer per parts. Però en tots dos casos hi ha un parany: **que les dades vinguin de la mateixa font no garanteix que els indicadors es calculin igual**. Això només ho assegura un mapa global de KPI, un glossari compartit i un [govern de les dades](/ca/capacitats/govern-de-les-dades) que els mantingui. ## Primer els KPI, després les taules Abans de dissenyar res cal aclarir **què vol mesurar el negoci**. Això vol dir seure amb qui fa servir les dades (responsables de sinistres, de vendes, de riscos, actuaris i direcció) i recórrer tres passos: identificar quins indicadors necessiten, documentar com es calcula cadascun i validar-ne la interpretació abans d'implementar. Els indicadors d'un sector semblen obvis fins que se'n pregunten els detalls: - **Pòlisses cancel·lades al mes**: inclou les no renovacions o només les cancel·lacions anticipades? - **Primes emeses al trimestre**: brutes o netes de comissions? - **Ràtio de sinistralitat per producte**: (indemnitzacions pagades + reserves) / primes meritades, però amb quines reserves i a quina data? - **Temps mitjà de resolució de sinistres**: des de l'obertura fins al tancament o fins al primer pagament? - **Taxa de conversió de cotitzacions** i **valor de vida del client**: en quina finestra de temps? Cada pregunta sense resposta és una xifra diferent en dos informes. ## El mapa d'indicadors Amb les respostes es construeix el **mapa d'indicadors** de l'àrea: una fitxa per KPI que guia tot el disseny posterior del datamart i del model, i que altres datamarts poden reutilitzar quan comparteixen indicadors. | Camp | Què recull | |---|---| | Definició de negoci | Què mesura l'indicador i per què importa, en llenguatge de negoci | | Fórmula de càlcul | Numerador, denominador i filtres, sense ambigüitat | | Dades necessàries | Taules, camps i transformacions del data warehouse | | Regles de negoci | Exclusions, casos especials, nuls i valors atípics | Per exemple, la **taxa de cancel·lació de pòlisses** quedaria així: percentatge de pòlisses cancel·lades en el període sobre el total de pòlisses actives a l'inici; exclou les no renovacions naturals per venciment; inclou només les cancel·lacions sol·licitades pel client o per impagament. ## Una única versió de la veritat Imagina que la direcció financera demana la taxa de retenció de clients i rep tres informes amb tres xifres: 87 %, 82 % i 91 %. Vendes compta compres repetides, Finances mira ingressos retinguts i Màrqueting, fidelitat per campanyes. Les tres són «la taxa de retenció». El resultat és conegut: desconfiança en les dades, hores perdudes conciliant números i decisions preses sobre la xifra equivocada. La solució és que **cada KPI tingui una única definició acordada** i que aquesta lògica s'implementi **una sola vegada**, al datamart com a camp calculat o al model semàntic com a mesura DAX, perquè tots els informes la reutilitzin. Es recolza en tres pilars: 1. **Un repositori central de mètriques** (el mapa global de KPI), accessible per a tothom, amb versions i auditable. 2. **Un procés formal de definició**, amb un responsable que aprova cada mètrica i els seus canvis. 3. **Coherència entre datamarts**: mateix nom de mètrica, mateix càlcul a tot arreu; validació centralitzada i comprovacions automàtiques a les càrregues. ## Anomenar els KPI amb criteri Una convenció de noms fa que el nom tècnic expliqui què representa. Un esquema que funciona bé combina quatre peces: **FÓRMULA_CONCEPTE_CATEGORIA_PERÍODE**. - **Fórmula**: Num (recompte), Suma, Mitjana, DiferenciaPerc (variació percentual), Delta (variació relativa). - **Concepte**: què es mesura (Cancel·lacions, Sinistres, Primes, Reserves, Saldo). - **Categoria**: producte o segment (AUTO, LLAR, VIDA, SALUT, EMPRESES). - **Període**: Fa0 (mes actual), Ult3, Ult12, 0i5 (mes actual davant de fa cinc mesos). | Nom tècnic | Significat | |---|---| | Num_Cancellacions_AUTO_Fa0 | Pòlisses d'Auto cancel·lades al mes actual | | Suma_Sinistres_LLAR_Ult12 | Import de sinistres de Llar dels darrers 12 mesos | | Mitjana_Saldo_VIDA_Ult3 | Saldo mitjà de reserves de Vida dels darrers 3 mesos | | Delta_Reserves_EMPRESES_0i12 | Variació de reserves d'Empreses davant de fa un any | No és l'única convenció possible i, si l'organització ja en té una, convé partir-ne. Aquest exemple suposa períodes mensuals; si un mateix model barreja escales, s'hi afegeix la unitat (Fa3M, Ult7D). ## Els casos extrems: l'exemple de la variació Les fórmules de variació semblen trivials: `Delta = (valor actual − valor anterior) / valor anterior` Si les reserves passen de 300 a 100 milions, la variació és −67 %. Fins aquí, tot clar. Però a la pràctica apareixen situacions que la fórmula no sap interpretar: | Abans | Ara | Resultat de la fórmula | Regla que cal acordar | |---|---|---|---| | −200 M | +100 M | −150 % | Passar de dèficit a superàvit no és una caiguda: «recuperació» o «∞» | | +200 M | −100 M | −150 % | Comunicar-ho com a pèrdua total (−100 %) | | 0 | +100 M | Divisió per zero | «Nou» o creixement no definit | | +100 M | 0 | −100 % | Pèrdua total, interpretació clara | Cap d'aquestes decisions no és tècnica: les pren el negoci i es documenten al mapa de KPI. Després s'implementen amb lògica condicional en SQL (CASE WHEN) o en DAX: ``` Delta Reserves 0i2 = VAR Actual = [Saldo Reserves] VAR Anterior = CALCULATE ( [Saldo Reserves], DATEADD ( 'Data'[Data], -2, MONTH ) ) RETURN SWITCH ( TRUE (), ISBLANK ( Anterior ) || Anterior = 0, BLANK (), -- de res a alguna cosa: es mostra com a «nou» Anterior < 0 && Actual >= 0, BLANK (), -- canvi de signe: regla acordada Anterior > 0 && Actual < 0, -1, -- pèrdua total DIVIDE ( Actual - Anterior, Anterior ) ) ``` I si diversos datamarts calculen variacions (sinistres, primes, reserves), tots han de tractar aquests casos igual. ## Altres indicadors amb parany La variació és només un exemple. Gairebé totes les mètriques habituals tenen casos que cal decidir: - **Taxa de conversió**: què passa sense visites o cotitzacions? Compta dues vegades el mateix client? En quina finestra de temps? - **Creixement interanual**: productes nous sense any anterior, productes retirats, negocis estacionals amb mesos a zero. - **Temps mitjà de resolució**: casos oberts, valors atípics, hores hàbils o naturals, expedients reoberts. - **Marge**: ingressos negatius per devolucions, períodes sense ingressos, quins costos s'imputen. ## Una plantilla per documentar cada mètrica Perquè el mapa sigui útil, totes les fitxes segueixen la mateixa plantilla: - **Identificació**: nom tècnic, nom de negoci, categoria, responsable, data d'aprovació i versió. - **Definició de negoci**: què mesura, per què importa, qui la fa servir i amb quines mètriques es relaciona. - **Especificació tècnica**: fórmula exacta, fonts, filtres, nivell d'agregació, freqüència d'actualització i històric disponible. - **Casos especials**: nuls, denominadors zero, negatius, atípics, canvis de signe i dades sospitoses. - **Regles de validació**: rang esperat, comprovacions creuades (retenció + abandonament ≈ 100 %), tendències i conciliació amb una altra font. - **Notes d'implementació**: on es calcula (SQL o DAX), consideracions de rendiment, limitacions conegudes i historial de canvis. ## Com començar 1. Triar les mètriques més crítiques, una vintena. 2. Reunir totes les àrees que les fan servir i acordar-ne les definicions. 3. Documentar-les amb la plantilla abans d'implementar res. 4. Incorporar validacions automàtiques a les càrregues. 5. Formar els equips en l'ús del repositori de mètriques. 6. Crear un comitè de govern de les dades que aprovi altes i canvis. Amb els indicadors definits, ja sabem quines dades calen i com s'han de comportar. A la [segona part](/ca/idees/modelar-para-power-bi-ii-datamart-y-modelo-semantico) veiem com derivar el datamart des del data warehouse, dissenyar l'esquema en estrella i portar-lo a un model semàntic a Power BI. Si vols anar més enllà del modelatge, també tenim una guia de [bones pràctiques de modelatge de dades a Power BI](/ca/idees/modelado-power-bi-buenas-practicas). I si necessites ajuda per ordenar els teus indicadors, a Bidatia dissenyem [quadres de comandament amb Power BI i Microsoft Fabric](/ca/capacitats/quadres-de-comandament-power-bi) partint precisament d'aquí. ## Preguntes freqüents ### Quina diferència hi ha entre un data warehouse i un datamart? El data warehouse integra la informació de tota l'organització. El datamart és un subconjunt temàtic, pensat per a una àrea concreta (sinistres, vendes, finances), amb només les dades que aquesta àrea necessita i una estructura senzilla de consultar. ### On es documenten les definicions dels KPI? En un diccionari o mapa global de mètriques, accessible per a tots els equips i amb control de versions: pot viure a SharePoint o Confluence, o en una eina de govern de les dades com Microsoft Purview, Collibra o OpenMetadata. ### És obligatori fer servir una nomenclatura com FÓRMULA_CONCEPTE_CATEGORIA_PERÍODE? No. És un exemple provat, però l'important és que hi hagi una convenció i que s'apliqui igual en tots els models. Si l'organització ja té costums propis, convé partir-ne. ### Per quants KPI convé començar? Pels més crítics: una vintena d'indicadors ben definits i acordats aporten més que cent amb interpretacions diferents. La resta s'hi incorpora amb el mateix procés.