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 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 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:
- Un repositori central de mètriques (el mapa global de KPI), accessible per a tothom, amb versions i auditable.
- Un procés formal de definició, amb un responsable que aprova cada mètrica i els seus canvis.
- 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
- Triar les mètriques més crítiques, una vintena.
- Reunir totes les àrees que les fan servir i acordar-ne les definicions.
- Documentar-les amb la plantilla abans d'implementar res.
- Incorporar validacions automàtiques a les càrregues.
- Formar els equips en l'ús del repositori de mètriques.
- 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 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. I si necessites ajuda per ordenar els teus indicadors, a Bidatia dissenyem quadres de comandament amb Power BI i Microsoft Fabric 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.