Franchise ERP rendszer — 25+ modul, multi-tenant architektúra

Amikor egy országos gépkölcsönző franchise hálózat átkötötte a 12-éves SAP-bérleti rendszerét saját fejlesztésű platformra, nálunk kötött ki. 4 hónapos fejlesztés, 25+ funkcionális modul, 50+ raktárhely-integráció — és minden üzletben napi 3 óra megtakarítás.

A probléma

Az ügyfelünk egy országos gépkölcsönző franchise hálózat, 50+ telephellyel, 500+ alkalmazottal. Az őket kiszolgáló rendszer:

• 12 éves SAP-bérlemény volt, havi 2,8 M Ft licencdíj
• Az egyes telephelyek nem beszéltek egymással — ha egy gép Debrecenben volt és egy győri ügyfél kérte, senki nem tudta
• A szervizfolyamat papíralapú volt — szervizlap, aláírás, scan
• POS és raktárkezelés külön rendszerben → napi 2-3 óra „adatbevitel-szinkronizálás" telephelyenként

Ügyfelünk kitűzött célja: havi 2,8 M Ft → 0 Ft licencdíj, plusz 3 óra/telephely/nap megtakarítás.

A megoldás

Egy multi-tenant ERP platform, ahol minden telephely saját „tenantként" fut, de mindegy látja a többi raktárát (ha engedélyezett). A rendszer 25+ funkcionális modulból áll:

Core modulok (1. fázis, első 2 hónap)

• Eszközkatalógus — minden gép, szerszám, kiegészítő egyedi azonosítóval
• Bérléskezelés — foglalás, átadás-átvétel, visszavétel
• Raktárkezelés — valós idejű készletszám telephelyenként
• POS / számlázás — NAV-kompatibilis, Stripe-integrációval
• Ügyfélkezelés (CRM-light) — privát és céges ügyfelek

Advanced modulok (2. fázis, 3-4. hónap)

• Szervizkezelés — hibajegyek, pótalkatrész-rendelés, garancia-tracking
• Inter-branch transzfer — ha egy gép Debrecenben van, de Győrbe kell, 2 kattintással átkérhető
• Pénzügyi riportok — telephelyenként és össz-hálózat szinten
• Alkalmazottkezelés — jelenlét, jogosultságok, szerep-alapú hozzáférés
• Értékesítési dashboardok — real-time KPI követés

Architekturális döntések

Miért PostgreSQL RLS (Row-Level Security) multi-tenancy?

Három opciót vizsgáltunk:

1. Database-per-tenant — elszigetelt, de skálázhatatlan 50+ DB-vel
2. Schema-per-tenant — még mindig sok 50+ schema
3. Row-Level Security ← ezt választottuk — egyetlen DB, a tenant_id minden sorhoz, a PostgreSQL szinten szűrés

RLS-sel szűkített lekérdezések is gyorsak (<50ms), és a telephely-manager csak a saját adatait látja, a franchise központ mindet.

Miért PWA és nem natív mobil app?

A szerviz-technikus egyik nap Android-on, másnap iPhone-on dolgozik. Natív alkalmazás = 2× fejlesztés. PWA-val egyszer írjuk, mindenhol fut, offline-képes is (service worker). 30%-kal gyorsabb fejlesztés volt ez a döntés.

Kihívás: az átállás a 12-éves SAP-ról

Az ügyfél rettegett az átállástól, jogosan. Egy téves átállás 50 telephely egyhavi pénzforgalmát veszélyeztette.

Stratégiánk:

1. Dual-run 2 hétig: SAP és az új rendszer párhuzamosan fut, minden tranzakció mindkettőbe bekerül
2. Napi reconciliation: minden reggel összehasonlítottuk a 2 rendszer számait
3. Fokozatos telephely-váltás: az első héten csak 3 telephely élesbe, utána heti 10-es hullámban
4. 1 fő állandó helpdesk a fejlesztőtől — azonnali kérdésekre

Eredmény — számokkal

• Havi 2,8 M Ft licencdíj → 0 Ft (saját hosting havi 85 000 Ft-ba kerül)
• Napi 3 óra megtakarítás telephelyenként — országosan 150 munkaóra/nap = havi 3000+ óra
• Inter-branch transzfer: 2 kattintás, 15 perc → 2 óra csökkenés telefonálással
• NPS ügyfél-oldalán +12 pont — gyorsabb kiszolgálás

Tanulságok

1. A multi-tenancy nem bonyolult, ha jól választod az architektúrát (RLS-sel nálunk egyszerűbb volt, mint schema-per-tenanttal).
2. A dual-run 2 hét nem pazarlás — megéri a nyugalom. Az egyik leginkább rettegett lépés (éles átállás) végül stresszmentes volt.
3. A PWA döntés 30%-ot spórolt — minden esetben először ezt mérlegeljük natív app helyett.