Riadenie firmy v Exceli? Ako prejsť na vlastný B2B portál

Od nolimeo · 10. marca 2026
banner image

Zdieľané excelovské tabuľky sú výborný nástroj pre začínajúcich podnikateľov alebo malé tímy. Keď však firma vyrastie na 20 a viac zamestnancov, začnú sa meniť na prevádzkové riziko.

Predstavte si každodennú realitu stredne veľkej obchodnej alebo výrobnej firmy: obchodníci zapisujú dopyty do jednej tabuľky, skladníci sledujú zásoby v druhej, fakturantka prepisuje dáta do účtovníctva ručne a nákupca objednáva materiál podľa odhadov. Stačí jeden nepozorný prepis, náhodné zmazanie bunky alebo prepísanie riadku kolegom počas súbežnej úpravy a firma čelí chybám, ktoré stoja tisíce eur.

Klienti sa sťažujú na nesprávne ceny, skladníci nevedia, ktoré objednávky majú expedovať prioritne, a vedenie firmy nemá reálny prehľad o maržiach. Celá prevádzka beží na manuálnej energii zamestnancov, ktorí namiesto obchodu trávia hodiny párovaním tabuliek.

V technologickom štúdiu nolimeo pomáhame firmám prekonať túto tabuľkovú paralýzu. Navrhujeme a staviame moderné klientske a B2B portály na stacku Next.js a Supabase (PostgreSQL), ktoré zjednocujú roztrieštené dáta do jedného zdroja pravdy a automatizujú rutinné obchodné procesy.


1. Prechod z chaosu tabuliek na jeden zdroj pravdy (Single Source of Truth)

Najväčším rizikom Excelu je slabé centralizované riadenie prístupov (Role-Based Access Control) a súbežného zápisu. Keď desať ľudí naraz upravuje Google tabuľku, konflikty a prepisovanie dát sú na dennom poriadku.

Riešením je prechod na trojvrstvovú webovú architektúru s transakčnou bezpečnosťou:

┌────────────────────────────────────────────────────────────────────────┐
│                             Klientska Zóna                             │
│                  Next.js Portál (Zákazníci / Partneri)                 │
└────────────────────────────────────────────────────────────────────────┘
          ▲                                                     ▲
          │ (Bezpečné API)                                       │ (Filtrované dáta)
          ▼                                                     ▼
┌────────────────────────────────────────────────────────────────────────┐
│                          Integračný Middleware                         │
│                    Supabase Row Level Security (RLS)                   │
└────────────────────────────────────────────────────────────────────────┘
          ▲                                                     ▲
          │ (SQL Dopyty)                                        │ (Atomické transakcie)
          ▼                                                     ▼
┌────────────────────────────────────────────────────────────────────────┐
│                          Centrálna Databáza                            │
│                        PostgreSQL (Jediný zdroj)                       │
└────────────────────────────────────────────────────────────────────────┘

Prečo je toto riešenie stabilnejšie ako tabuľka?

  1. Atomické transakcie (ACID): Ak zákazník potvrdí objednávku na B2B portáli, databáza zabezpečí, že sa buď vykonajú všetky kroky (odpísanie zo skladu, vytvorenie objednávky, rezervácia prepravy), alebo žiadny. Nestane sa, že tovar zostane predaný, ale sklad o tom nedostane informáciu.
  2. Prísne riadenie prístupov (RLS): Na rozdiel od Excelu, kde môže každý zmazať celú databázu, v Supabase cez Row Level Security (RLS) definujeme prísne pravidlá. Skladník vidí len stavy zásob a dodacie listy, obchodník vidí iba svojich priradených klientov a koncový partner má prístup výhradne k vlastným faktúram a individuálnym cenám.
  3. Zákaznícka samoobsluha (Self-Service): Partneri už nemusia telefonovať vašej asistentke kvôli skladovej dostupnosti alebo cenám. Prihlásia sa do portálu a pri dobre pripravených dátach vidia aktuálne informácie bez ručného overovania.

2. Technické riešenie: Zamedzenie konfliktov (Race Conditions) v Supabase

Klasickým problémom Excelov sú súbežné prepisy. Ak napríklad na sklade zostáva posledných 5 kusov produktu a dvaja partneri v rovnakej sekunde objednajú po 3 kusy, tabuľka nekladie žiadny odpor a zapíše obe objednávky. Výsledkom je predaj do mínusu a nahnevaný zákazník.

V softvéri od nolimea riešime tento problém na úrovni atomických databázových transakcií v PostgreSQL pomocou uložených procedúr (RPC).

Nižšie je zjednodušená ukážka TypeScript kódu, ktorý komunikuje so Supabase API a pomocou Zod validuje vstup pred vykonaním atomického odpísania zásob:

// src/services/stockManager.ts
import { createClient } from "@supabase/supabase-js";
import { z } from "zod";

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL || "";
const supabaseServiceRoleKey = process.env.SUPABASE_SERVICE_ROLE_KEY || "";

// Vytvorenie Supabase klienta s administrátorskými právami pre interné API operácie
const supabase = createClient(supabaseUrl, supabaseServiceRoleKey);

// Validačná schéma pre aktualizáciu skladu
export const StockAdjustmentSchema = z.object({
  productId: z.string().uuid("Neplatný formát identifikátora produktu"),
  quantityOrdered: z.number().int().positive("Množstvo musí byť kladné celé číslo"),
  warehouseId: z.string().uuid("Neplatný formát identifikátora skladu"),
});

export type StockAdjustment = z.infer<typeof StockAdjustmentSchema>;

/**
 * Odpíše skladové zásoby cez kontrolovanú databázovú transakciu.
 * Spúšťa atomickú SQL funkciu (RPC), ktorá pomáha riešiť súbežný predaj (race conditions).
 */
export async function safelyDeductStock(payload: unknown): Promise<{ success: true; newStock: number } | { success: false; error: string }> {
  const parseResult = StockAdjustmentSchema.safeParse(payload);

  if (!parseResult.success) {
    const errorMsg = parseResult.error.errors.map(err => `${err.path.join(".")}: ${err.message}`).join(", ");
    return { success: false, error: `Validačná chyba: ${errorMsg}` };
  }

  const { productId, quantityOrdered, warehouseId } = parseResult.data;

  // Zavoláme PostgreSQL uloženú procedúru v Supabase s kontrolou skladového stavu
  const { data, error } = await supabase.rpc("deduct_stock_atomically", {
    p_product_id: productId,
    p_quantity_ordered: quantityOrdered,
    p_warehouse_id: warehouseId,
  });

  if (error) {
    console.error(`Skladová transakcia zlyhala pre produkt ${productId}:`, error.message);
    return { success: false, error: `Chyba DB transakcie: ${error.message}` };
  }

  // Ak funkcia vráti -1, znamená to nedostatok zásob na sklade
  if (data === -1) {
    return { success: false, error: "Nedostatok zásob. Objednávka nemohla byť dokončená." };
  }

  return { success: true, newStock: data };
}

Prečo toto tabuľka nevie spoľahlivo nahradiť?

  • Kontrolovaná izolácia transakcií: Procedúra deduct_stock_atomically vie uzamknúť riadok daného produktu počas zápisu. Druhý dopyt v rovnakej chvíli dostane odpoveď o nedostatočnom stave a transakcia sa zruší, čím sa výrazne znižuje riziko predaja do mínusu.
  • Type-safety a Zod: Pokus o odoslanie nevalidných hodnôt, napríklad záporného množstva, sa zablokuje na serveri ešte pred zásahom do databázy.

3. Finančný dopad: ROI prechodu na vlastnú webovú aplikáciu

Vybudovanie vlastného B2B portálu nie je len náklad, ale investícia s merateľnou finančnou návratnosťou. Pozrime sa na modelový výpočet stredne veľkej slovenskej obchodnej firmy s 25 zamestnancami:

  • Manuálna réžia: 4 obchodní zástupcovia a 2 asistentky trávia v priemere 2 hodiny denne ručným prepisovaním objednávok z e-mailov a Excelov do lokálneho softvéru a overovaním stavu skladu.
  • Výpočet: 6 ľudí × 2 hodiny × 20 pracovných dní = 240 hodín mesačne stratených rutinnou administratívou.
  • Finančná strata: Pri modelových celkových mzdových nákladoch 18 €/hodina to firmu stojí 4 320 € mesačne v rutinnej administratíve.
  • Chybovosť a reklamácie: Ak časť objednávok obsahuje chybu (zlý rozmer, neplatná cena, popletená dodacia adresa) kvôli preklepom, riešenie reklamácií, spätná doprava a stratená dôvera klientov môžu znamenať ďalšie tisíce eur mesačne.
  • Celkové skryté náklady za rok: (4 320 € + 1 500 €) × 12 mesiacov = 69 840 € ročne.

Pri investícii do vlastného B2B portálu Next.js / Supabase sa dá veľká časť týchto strát postupne znižovať. Pri vhodnom objeme procesov sa portál môže vrátiť v horizonte mesiacov a zároveň otvoriť dvere k expanzii: obchodníci môžu namiesto prepisovania dát reálne predávať a hľadať nových partnerov.


4. Ako vyzerá plynulá migrácia z Excelu s nolimeom

Mnoho firiem neodchádza z Excelu, pretože sa boja zastavenia prevádzky alebo straty historických dát. V nolimeu máme pre tento proces zabehnutú metodiku:

  1. Dátový audit a normalizácia: Analyzujeme vaše súčasné tabuľky. Vyčistíme duplicity, opravíme nekonzistentné formáty (napr. rôzne zapísané mená tej istej firmy) a navrhneme vhodnú relačnú SQL štruktúru.
  2. Prototyp klientskej zóny: Najskôr vyvinieme jednoduché a intuitívne používateľské prostredie, ktoré si vaši zamestnanci a kľúčoví partneri môžu otestovať a pripomienkovať.
  3. Migrácia na pozadí: Údaje z Excelov naimportujeme do Supabase. Systém vieme spustiť do prevádzky postupne, bez zbytočného zastavenia obchodovania.
  4. SLA podpora a expanzia: Po nasadení portálu zostávame vaším stabilným technologickým partnerom. Monitorujeme výkon a priebežne pridávame funkcie na základe rastu vášho biznisu.

Záver: Prestaňte riadiť biznis cez provizórne riešenia

Microsoft Excel a Google Sheets sú výborné skicáre. Ale nemôžete na nich dlhodobo prevádzkovať stabilné podnikanie s miliónovými obratmi. Ak chce vaša firma rásť, potrebuje profesionálne základy: stabilný, rýchly a bezpečný B2B portál na mieru.

V technologickom štúdiu nolimeo nerobíme lacné šablónové weby. Sme seniorné boutique štúdio a s našimi klientmi komunikujú priamo ľudia, ktorí systém navrhujú a vyvíjajú. Dodávame softvér na mieru s čistým, optimalizovaným kódom a dohodnutou SLA podporou.

Chcete prejsť z chaotických tabuliek na stabilnú webovú aplikáciu? Napíšte nám a prejdeme si procesy, dáta aj bezpečný technický smer.

Máte záujem posunúť váš projekt vpred?