Hi ha projectes en els quals el repte tècnic i el repte de negoci són exactament el mateix problema formulat des de perspectives diferents. El cas de Rehabmedic és un d'ells. Es tractava de llançar una nova unitat de negoci —el lloguer d'equipament de rehabilitació mèdica— amb un termini de posada en marxa ajustat, una infraestructura heretada que no estava dimensionada per suportar el creixement previst, i la necessitat de posicionament orgànic des del primer dia. El que segueix és la descripció tècnica i de negoci de com es va resoldre.
El repte: visibilitat zero, infraestructura fràgil, plataforma fragmentada
Una nova unitat de negoci sense presència digital
Rehabmedic és una empresa del sector de la salut i l'equipament de rehabilitació amb presència consolidada al seu mercat. En llançar la unitat de lloguer d'equipament mèdic —un segment diferent al de venda, amb el seu propi procés comercial, la seva pròpia lògica de facturació i el seu propi públic objectiu— no existia cap presència digital específica per a aquest servei. El client potencial que buscava a Google «llogar llit articulat» o «lloguer cadira de rodes elèctrica» no trobava Rehabmedic. La visibilitat era literalment zero.
El cost d'oportunitat era immediat i quantificable: cada setmana sense posicionament era una setmana de demanda que anava a la competència. No hi havia temps per construir autoritat de domini de forma orgànica al llarg de mesos; calia trobar la pala tècnica correcta per accelerar la indexació i el posicionament des del primer moment.
Infraestructura heretada sense alta disponibilitat
La infraestructura existent presentava un perfil de risc incompatible amb el creixement previst. Els punts de fallada eren identificables: sense rèplica de base de dades, sense mecanismes de failover automàtic, sense observabilitat proactiva. Una caiguda del sistema en un moment de pic de trànsit o durant una campanya de captació no tenia un temps de recuperació garantit.
Per a una empresa del sector salut en la qual els clients poden estar buscant equipament de forma urgent —alta hospitalària, recuperació postoperatòria— el temps d'inactivitat té un cost directe en experiència d'usuari i, en conseqüència, en conversió i reputació.
Plataforma fragmentada: Navision i Magento com a punt de partida
L'stack tecnològic de partida estava compost per dos sistemes que tampoc es comunicaven de forma fluida:
- Microsoft Dynamics NAV (Navision) per a la gestió ERP: comptabilitat, inventari, proveïdors i l'operativa del negoci de venda.
- Magento com a plataforma de comerç electrònic, desconnectada de l'ERP en gran mesura, amb sincronització de dades manual o mitjançant integracions fràgils.
La nova unitat de lloguer no podia muntar-se damunt d'aquesta arquitectura sense abordar primer la integració. I la integració real exigia plantejar-se si tenia sentit mantenir tres plataformes diferents —Navision, Magento i un nou sistema per a lloguer— o consolidar sobre una arquitectura unificada.
La solució: Odoo Multi-web, Schema.org i arquitectura d'alta disponibilitat real
Odoo Multi-web com a plataforma unificada
La decisió arquitectònica central va ser consolidar sobre Odoo com a plataforma única, aprofitant el seu mòdul Multi-web per gestionar de forma independent la botiga de venda i el nou portal de lloguer des d'una mateixa instància. Aquesta aproximació oferia avantatges concretes:
- Una sola font de veritat per a l'inventari: un producte podia estar disponible per a venda i per a lloguer simultàniament, amb gestió unificada de l'estoc.
- Processos diferenciats en el mateix sistema: el flux de lloguer —contracte, dipòsit, devolució, facturació periòdica— es va implementar com a extensió dels mòduls natius d'Odoo, sense necessitat d'un sistema extern.
- Web específica per a cada unitat de negoci: el portal de lloguer tenia el seu propi domini, la seva pròpia identitat visual i la seva pròpia arquitectura de continguts, però corria sobre la mateixa instància Odoo amb accés al mateix ERP.
Schema.org: la palanca de posicionament accelerat
Aquí és on es troba el cor tècnic del resultat de posicionament. La pregunta que calia respondre era: com aconsegueix un lloc web nou —sense autoritat de domini, sense backlinks, sense historial— posicionar-se al Top 3 de Google per a keywords comercials en menys de 60 dies?
La resposta no va estar en el SEO convencional de continguts. Va estar en l'arquitectura de dades estructurades Schema.org implementada des del primer dia en cada pàgina de producte del portal de lloguer. La lògica és la següent: Google pot tardar mesos a desenvolupar confiança en un domini nou, però pot confiar de forma gairebé immediata en un lloc que li parla en el seu idioma — i l'idioma que Google prefereix per entendre el contingut és Schema.org.
Es van implementar els tipus de marcatge següents:
- Product amb
offers,availability,priceValidUntiliaggregateRatingen cada pàgina de producte de lloguer. - Organization amb informació completa de l'empresa, coordenades de contacte i enllaços a xarxes socials.
- LocalBusiness amb àrea de servei geogràfica i horaris de disponibilitat.
- FAQPage a les pàgines de categoria, responent a les preguntes més freqüents sobre el procés de lloguer.
- BreadcrumbList en tota la jerarquia de navegació per facilitar el rastreig i la comprensió estructural del lloc.
El resultat va ser que Google va poder entendre, des dels primers rastrejos, exactament què era cada pàgina, quin producte oferia, a quin preu, amb quina disponibilitat i en quina àrea geogràfica. Sense ambigüitat, sense inferència. Els rich snippets van aparèixer als resultats gairebé de forma immediata, la qual cosa va augmentar el CTR orgànic i va retroalimentar el posicionament.
«L'ERP ben muntat no és sols operativa interna: és també una màquina de posicionament quan les dades flueixen correctament fins a la capa web.»
Alta disponibilitat: rèplica PostgreSQL en viu
Per resoldre el risc d'infraestructura, es va dissenyar i implementar una arquitectura d'alta disponibilitat amb rèplica PostgreSQL streaming en temps real. Els elements clau:
- Rèplica PostgreSQL en viu: un servidor secundari rep el WAL (Write-Ahead Log) del primari de forma contínua, mantenint una còpia actualitzada en temps real. Si el node primari falla, la rèplica pot promoure's a primari en un temps controlat.
- Balanceig de càrrega per a lectures: les consultes de només lectura —la majoria del trànsit web— es distribueixen entre primari i rèplica, reduint la càrrega sobre el servidor principal.
- Failover supervisat: el procés de promoció de rèplica està documentat i provat, amb un temps de recuperació definit i reproduïble.
Aquesta arquitectura va garantir que durant els pics de trànsit —campanyes, alta hospitalària estacional, esdeveniments— el sistema mantingués rendiment sense degradació perceptible per a l'usuari final.
Observabilitat amb bots de Telegram
El component d'observabilitat mereix menció específica perquè va ser un dels elements que va marcar la diferència en l'operativa real. Es va implementar un sistema d'alertes proactives mitjançant bots de Telegram integrats amb la monitorització del sistema. L'enfocament va ser pragmàtic: no es tracta de tenir el dashboard més sofisticat, sinó que quan alguna cosa falla o està a punt de fallar, la persona responsable ho sàpiga en segons, no en hores.
Les alertes cobreixen múltiples capes:
- Càrrega del servidor i ús de memòria amb llindars configurables.
- Estat de la rèplica PostgreSQL: retard de rèplica, connexió del WAL receiver, longitud de la cua de sincronització.
- Errors crítics als logs d'Odoo: worker crashes, timeouts de base de dades, fallades en cron jobs.
- Disponibilitat del lloc web: verificacions HTTP periòdiques amb alerta immediata si el temps de resposta supera el llindar o el lloc retorna un error.
El resultat és una postura d'operacions proactiva: els problemes es detecten i es resolen abans que l'usuari final els experimenti.
Migració de Navision i Magento
La migració des de Navision a Odoo es va planificar com un procés en fases per evitar el tall operatiu total. La comptabilitat, l'inventari i la gestió de clients es van migrar amb un període d'operació paral·lela controlada, validant la integritat de les dades en cada etapa abans de desconnectar el sistema origen.
La migració des de Magento va presentar el repte habitual d'aquest tipus de plataformes: un esquema de dades de producte i categories amb una estructura pròpia que no mapeja directament sobre el model d'Odoo. Es van desenvolupar scripts de transformació específics per als mestres de productes, les categories, l'historial de comandes i els clients registrats, amb validació creuada de registres per garantir la integritat referencial.
El criteri d'èxit per a ambdues migracions va ser el mateix: zero downtime operatiu. La botiga no va estar tancada en cap moment del procés. Les comandes durant el període de migració es van processar sense interrupció.
Resultats: mètriques reals
Top 3 Google orgànic en 60 dies
El resultat més cridaner i el que genera més preguntes: el portal de lloguer de Rehabmedic va assolir posicions al Top 3 de Google per a les keywords objectiu al mercat espanyol en menys de dos mesos des del llançament. Sense inversió en publicitat de pagament. Sense campanya de link building. Únicament amb l'arquitectura tècnica correcta: Schema.org complet des del dia u, velocitat de càrrega optimitzada, estructura d'URL neta i contingut de producte ben descrit.
Aquest resultat no és reproduïble aplicant qualsevol tàctica SEO estàndard. És el resultat que la plataforma —Odoo amb l'arquitectura de dades estructurades ben implementada— li parla a Google de forma que Google entén i premia.
Zero temps d'inactivitat en pics de trànsit
Durant el període d'operació posterior al llançament, incloent-hi pics de trànsit per campanyes i moments d'alta demanda estacional, la plataforma va mantenir disponibilitat completa. La rèplica PostgreSQL en viu va absorbir la càrrega de lectura addicional sense impacte en el rendiment del node primari. Les alertes de Telegram van permetre resoldre incidències menors de forma proactiva, abans que arribessin a afectar l'usuari.
Plataforma unificada operativa
La substitució de Navision i Magento per Odoo va eliminar la fricció operativa de gestionar múltiples sistemes. L'equip d'operacions treballa sobre una sola interfície per a gestió d'inventari, facturació, CRM i continguts web. El cost de manteniment de dos sistemes addicionals —llicències, integracions, formació— va desaparèixer del P&L.
Lliçons tècniques aplicables al teu projecte
1. Schema.org no és un detall de SEO: és arquitectura de dades
La majoria dels equips tracta Schema.org com un element d'optimització on-page que s'afegeix «quan hi ha temps». En projectes on la visibilitat orgànica és crítica des del llançament, Schema.org ha de ser part del disseny de la plataforma, no un ajust posterior. Si Odoo és la teva plataforma, les dades del producte ja existeixen a l'ERP: només cal fer que flueixin correctament fins al marcatge HTML.
2. L'alta disponibilitat no és opcional per a negocis amb pics de demanda
La rèplica PostgreSQL streaming no és una arquitectura exòtica ni cara. És la resposta correcta al risc de pèrdua de negoci per caiguda del sistema. El cost d'implementar-la és molt inferior al cost d'una caiguda durant un pic de trànsit en un sector on la urgència del client és real.
3. La migració d'ERP ha de ser invisible per al client final
Un procés de migració que interromp la botiga durant hores o dies té un cost directe en vendes i en reputació. La planificació de la migració en fases, amb operació paral·lela i criteris de validació clars abans de cada tall, és l'única manera de garantir que el client final no nota el canvi.
4. L'observabilitat proactiva és més barata que la recuperació reactiva
Un bot de Telegram que alerta quan la rèplica PostgreSQL porta més de 30 segons de retard costa hores de configuració. Un incident de caiguda de base de dades sense monitoratge proactiu pot costar dies de recuperació i pèrdues comercials mesurables. La relació cost-benefici és òbvia.
5. Odoo Multi-web permet escalar unitats de negoci sense multiplicar la complexitat operativa
Quan el negoci creix i apareix una nova línia de producte, un nou mercat geogràfic o un nou canal de distribució, la resposta habitual és afegir una altra plataforma. Amb Odoo Multi-web, la resposta és afegir un nou lloc sobre la mateixa instància, amb accés al mateix ERP i les mateixes dades, sense duplicar la infraestructura ni multiplicar els costos de manteniment.
Tens un projecte similar?
Si tens un projecte de llançament de nova unitat de negoci, una migració de Navision o Magento pendent, o una infraestructura que no està preparada per al següent nivell de creixement, puc revisar la teva situació i dir-te quina arquitectura té sentit per al teu cas concret. Sense fum. Sense propostes de 80 pàgines que triguen tres mesos a executar-se.