Telefónica

Telefónica és una empresa espanyola de telecomunicacions amb seu a Madrid. Segons la Wikipedia, es tracta d'una de les principals operadores de telecomunicacions, i no consta com a startup ni com a empresa de programari i SaaS, malgrat que així apareix a les dades de partida que se m'han facilitat. Aquesta discrepància s'ha de fer constar: la classificació sectorial de les dades rebudes no coincideix amb la descripció de la font.

Segons la Wikipedia, Telefónica es va constituir l'any 1924 a Madrid com a Companyia Telefònica Nacional d'Espanya. No consta a la font cap altre detall sobre el capital fundacional, els promotors concrets o l'estructura inicial que pugui citar-se amb precisió.

D'acord amb la Wikipedia, l'empresa presta serveis de telecomunicacions: telefonia fixa i mòbil, i serveis de dades i connectivitat, adreçats tant a particulars com a empreses. No consta a la font disponible el detall de l'evolució de la cartera de serveis ni de la segmentació de clients més enllà d'aquesta descripció general.

La font consultada no ofereix dades concretes de resultats, quotes de mercat ni fites financeres que permetin descriure amb precisió quins van ser els anys de més creixement. Per tant, no puc afirmar res sobre aquest punt sense inventar. El que sí que consta és que l'empresa ha mantingut activitat de forma continuada des de la seva fundació fins a l'actualitat, segons la Wikipedia.

No va tancar. D'acord amb la font i amb l'estat registral de les dades rebudes, Telefónica consta com a empresa activa. Aquest apartat, per tant, no té contingut aplicable en aquest cas: no hi ha cap tancament documentat.

Atès que l'empresa no ha cessat l'activitat, no es pot parlar d'herència en el sentit de llegat d'una empresa desapareguda. La font no recull cap element sobre impacte històric o llegat que es pugui citar de manera específica.

La font disponible no identifica persones fundadores concretes ni el seu parador actual. Aquesta informació no consta. Per obtenir-la caldria consultar fonts registrals (BORME, Registre Mercantil de Madrid) i documentació històrica de la companyia, que no formen part del corpus facilitat.

• Abans de redactar cap informe, cal verificar la classificació sectorial i la naturalesa de l'empresa: les dades de partida qualificaven Telefónica de startup de software i SaaS, cosa que la font no confirma. En recerca econòmica, una etiqueta errònia invalida tota l'anàlisi posterior.
• Cal distingir sempre entre empresa activa, empresa transformada i empresa tancada. Telefónica pertany a la primera categoria, i per tant no és objecte d'un informe de tancament.
• Quan la font disponible és una enciclopèdia general i no aporta dades financeres ni registrals, l'informe ha de limitar-se a allò que la font diu i assenyalar explícitament els buits, en lloc de completar-los amb suposicions.

Cal dir-ho de manera directa: la premissa de partida no es sosté amb les dades disponibles. La font citada ([Wikipedia] Telefónica — Wikipédia, https://es.wikipedia.org/wiki/Telef%C3%B3nica) descriu Telefónica com una operadora de telecomunicacions espanyola, amb seu a Madrid, activa i de gran dimensió. No hi ha cap indici, en la informació verificada, que sigui una startup de Software i SaaS ni que hagi tancat. Així, doncs, no existeix un "fet verificat de tancament" sobre el qual reconstruir res.

Això no vol dir que no es pugui fer l'exercici útil: imaginar què construïria avui un equip petit que volgués operar en el mateix espai de mercat (software i serveis digitals per a empreses, des de Madrid). Aquesta és la meva proposta, i la marco com a tal: un SaaS B2B lleuger que doni a pimes eines de connectivitat i gestió que avui només tenen les grans empreses (per exemple, gestió de línies, consum i incidències de telecomunicacions en un sol tauler). És una idea nova, no una recuperació de res.

El mercat rellevant no és "el mercat de Telefónica" en abstracte, sinó el de les pimes espanyoles que necessiten gestionar serveis digitals i de connectivitat sense departament de TI. La dada verificada que tinc és només que Telefónica existeix i és gran; la mida i el creixement del nínxol de SaaS per a pimes no els tinc verificats i, per tant, no els afirmo. El que sí puc dir és que l'existència d'un operador dominant a Madrid indica que hi ha volum de negoci al voltant de la connectivitat empresarial; quants d'aquests clients són adreçables per a un SaaS lleuger és una estimació a validar amb dades d'INE, informes sectorials i entrevistes, no una xifra que jo pugui donar per bona.

Proposta (no verificada): subscripció mensual per empresa, amb tres plans segons nombre de línies i usuaris, més un mòdul d'informes de consum. Ingressos recurrents, cost d'adquisició baix via vendes sortints i partnerships amb consultores locals. Preus i marges: estimació a validar; no els fixo aquí perquè dependrien d'una recerca que no he fet. El punt sòlid és l'estructura (subscripció + servei), no les xifres.

Fase 0 (1-2 mesos): validació amb 15-20 pimes de Madrid, entrevistes i prototip. Fase 1 (3-4 mesos): producte mínim amb un sol cas d'ús (gestió de línies i incidències). Fase 2 (5-8 mesos): primers 10-20 clients de pagament i mesura de retenció. Fase 3: expansió a Barcelona i València. Tots els terminis són proposta, no calendaris verificats.

Rang estimat, a validar: equip mínim de 2-3 persones durant 8 mesos, entre 90.000 i 180.000 € en sous i càrrecs; desenvolupament i infraestructura, 15.000-40.000 €; màrqueting i vendes inicials, 10.000-30.000 €; legal i administratiu, 5.000-10.000 €. Total orientatiu: 120.000-260.000 € per arribar a primers clients. Són xifres de mercat general, no dades de cap empresa concreta, i caldria ajustar-les amb pressupostos reals.

El risc principal és de premissa: si algú llegeix aquest informe com la reconstrucció d'una empresa tancada, prendrà decisions sobre una base falsa. El segon risc és competir en un espai on l'operador dominant pot absorbir la funcionalitat dins del seu propi producte. El tercer és la dependència de canals de venda lents en un mercat de pimes poc digitalitzat. Cap d'aquests riscos es pot quantificar amb la informació verificada disponible.

La lliçó de l'informe original, aplicada honestament: abans de reconstruir res, verificar que l'empresa està realment morta i que el sector de la fitxa és el correcte. Aquí la fitxa diu "startup / Software i SaaS / activa" i la font diu "operadora de telecomunicacions gran i activa": la contradicció és la dada més important de tot l'exercici. Qui vulgui emprendre en aquest espai hauria de partir d'aquesta verificació, no d'un relat de reconstrucció. I si l'objectiu era un pla per a una empresa realment cessada, caldria tornar-me les dades correctes d'aquella empresa.

Telefónica és un operador de telecomunicacions global amb presència a múltiples països i monedes, i la seva facturació implica milions de línies mensuals amb tarifes, descomptes i impostos variables per país. La font disponible ([Wikipedia] Telefónica — Wikipédia, https://es.wikipedia.org/wiki/Telef%C3%B3nica) descriu l'empresa com un operador integrat de telecomunicacions; la complexitat operativa que se'n deriva és el punt de partida del producte.

El problema concret és la manca d'un flux únic i auditable que uneixi la generació de factures, el registre de despeses i la conciliació de pagaments. Els sistemes heretats solen separar aquests dominis, cosa que obliga a fer conciliacions manuals, dificulta la detecció de frau i retarda el tancament comptable. El producte resol això amb un motor de facturació idempotent i un servei de conciliació basat en esdeveniments que produeix un rastre auditable de cada càrrec.

Proposo una arquitectura de microserveis amb un bus d'esdeveniments (Kafka) com a columna vertebral. Els serveis principals són: `billing-engine` (càlcul i emissió de factures), `expense-service` (registre de despeses), `reconciliation-service` (conciliació de pagaments), `ledger-service` (comptabilitat de doble entrada) i `reporting-service` (consultes analítiques).

El motiu de separar `billing-engine` de `ledger-service` és que la facturació és un càlcul de domini intensiu en CPU i canviant per país, mentre que el llibre major ha de ser immutable i auditable. El bus d'esdeveniments permet que la conciliació consumeixi esdeveniments de facturació i de pagaments sense acoblament temporal.

``` Client (API Gateway) | +--> billing-engine ----+ +--> expense-service ---+--> Kafka (topics: invoice.issued, payment.received, expense.recorded) +--> reconciliation-service <--+ +--> ledger-service <-----------+ +--> reporting-service (llegeix de data warehouse) ```

Cada servei té la seva pròpia base de dades (PostgreSQL) i no comparteix taules amb els altres. La comunicació síncrona es fa per REST intern amb mTLS; la comunicació asíncrona, per Kafka amb esquemes Avro al registry.

El model es dissenya al voltant de l'idempotència i l'auditoria. Cada esdeveniment porta una clau d'idempotència i un `event_id` únic.

• `invoice` (id, account_id, period_start, period_end, currency, status, total_amount, created_at)
• `invoice_line` (id, invoice_id, concept, quantity, unit_price, tax_rate, amount)
• `payment` (id, account_id, external_ref, amount, currency, received_at, status)
• `expense` (id, account_id, category, amount, currency, incurred_at, status)
• `ledger_entry` (id, transaction_id, account_code, debit, credit, currency, posted_at) — només insercions, mai actualitzacions
• `reconciliation_match` (id, invoice_id, payment_id, matched_amount, matched_at, confidence)

El motiu de separar `invoice` de `invoice_line` és permetre factures amb desenes de milers de línies sense desnormalitzar. El motiu de fer `ledger_entry` només d'inserció és garantir l'auditabilitat i permetre reconstruir qualsevol saldo.

L'API pública és REST amb OpenAPI 3.1 i autenticació OAuth2 (client credentials per a sistemes, authorization code per a usuaris).

• `POST /v1/invoices` — crea una factura; requereix capçalera `Idempotency-Key`.
• `GET /v1/invoices/{id}` — retorna la factura amb les línies.
• `POST /v1/payments` — registra un pagament rebut.
• `POST /v1/expenses` — registra una despesa.
• `GET /v1/reconciliations?invoice_id=` — retorna les conciliacions d'una factura.
• `GET /v1/ledger/entries?account_code=` — consulta el llibre major.

Integracions: passarel·la de pagament (Stripe o Adyen) via webhooks signats; ERP del client (SAP/Oracle) via exportació CSV i API de sincronització; proveïdor de taxes per país via API REST. Els webhooks es verifiquen amb HMAC-SHA256 i es processen de manera idempotent.

1. `billing-engine` amb càlcul de línies, impostos per país i emissió idempotent d'esdeveniments `invoice.issued`.
2. `ledger-service` amb escriptures de doble entrada i reconstrucció de saldos.
3. `reconciliation-service` que consumeixi `invoice.issued` i `payment.received` i produeixi `reconciliation_match`.
4. API Gateway amb OAuth2 i el registre d'esquemes Avro.
5. Un client pilot amb una sola moneda i un sol país per validar el flux complet.

El motiu d'aquest ordre és que sense facturació idempotent i llibre major no hi ha res a conciliar; la conciliació és el valor diferencial però depèn dels dos primers.

Mides: el pilot ha de suportar 100.000 factures/mes i 1 milió de línies; l'objectiu de producció és 10 milions de línies/mes amb latència de conciliació inferior a 5 minuts.

Riscos:

• Idempotència incompleta: si un reintent genera una factura duplicada, el llibre major queda inconsistent. Mitigació: clau d'idempotència obligatòria i restricció única a la base de dades.
• Esquemes Avro evolutius: canvis de camp poden trencar consumidors. Mitigació: compatibilitat backward i registry versionat.
• Volum de Kafka: 10 milions d'esdeveniments/mes requereixen particionament per `account_id` i retenció adequada.
• Multi-moneda: els tipus de canvi han de quedar fixats al moment de l'emissió; mitigació: camp `fx_rate` a la factura.

• Tests d'idempotència: enviar la mateixa petició `POST /v1/invoices` dues vegades i verificar que només es crea una factura i un esdeveniment.
• Tests de conciliació: injectar factures i pagaments amb imports coincidents i no coincidents i verificar `reconciliation_match`.
• Tests de reconstrucció del llibre major: recalcular saldos des de `ledger_entry` i comparar amb els saldos calculats en temps real.
• Càrrega: simular 10 milions de línies/mes amb k6 i mesurar latència de conciliació.
• Auditoria: verificar que cap `ledger_entry` s'actualitza ni s'esborra (triggers de base de dades).
• Criteri d'acceptació del pilot: tancament mensual complet en menys de 24 hores amb zero conciliacions manuals.