Přechod z ABRA: Jak vypadá celý proces

Kde ABRA začíná brzdit firmy

ABRA funguje dobře ve svém původním rozsahu: účetnictví, základní skladové hospodářství, fakturace. Tento rozsah byl navržen pro menší podniky před deseti lety. Jak firmy rostou, začínají se objevovat některé opakující se problémy.

• Reportování vyžaduje exporty do Excelu: Business intelligence v ABRA znamená export dat a manuální tvorbu reportů. V produktu nejsou žádné dashboardy v reálném čase, multidimenzionální analýzy ani nic podobného živému přehledu.
• Žádná skutečná vrstva CRM: ABRA sleduje zákazníky jako účetní entity, nikoli jako vztahy. Neexistuje žádný prodejní trychtýř, žádné zaznamenávání aktivit, žádné automatizované následné kroky. Prodejní týmy nakonec spravují potenciální zákazníky v tabulkách vedle ABRA, což vytváří dva zdroje pravdy a ani jeden není spolehlivý.
• Integrace jsou křehké: Propojení ABRA s e-shopem, tržištěm nebo logistickým systémem vyžaduje buď middleware od Stormware, nebo drahé vlastní XML konektory. Při aktualizaci druhého systému se rozbijí. Údržba je neustálá.
• Mobilní přístup je dodatečný nápad: Terénní pracovníci, skladníci a manažeři, kteří potřebují schválit dokument mimo pracoviště, narážejí na reálná omezení. Mobilní řešení ABRA nedrží krok s tím, jak firmy skutečně fungují.
• Složitost více entit a více měn: Firmy rozšiřující se přes hranice nebo spravující více právních entit shledávají ABRA stále nepohodlnější. Konsolidace je manuální cvičení.

Nic z toho neznamená, že ABRA je špatný systém. Znamená to, že ABRA byla postavena pro specifický okamžik růstu firmy a některé firmy ji přerostly.

Co skutečně migrujeme (a co ne)

Jednou z prvních konverzací, které s klienty vedeme, je rozsah dat. Ne vše v ABRA stojí za migraci. Přesun špinavých nebo nerelevantních historických dat do čistého nového systému je jeden z nejrychlejších způsobů, jak zajistit, aby se nový systém cítil jako ten starý.

Co obvykle migrujeme:

• Aktivní zákazníci a dodavatelé: včetně kontaktů, platebních podmínek a kreditních limitů
• Katalog produktů: položky, jednotky, ceny, vztahy s dodavateli
• Aktuální zásoby: stavy zásob, lokace, čísla šarží a sériová čísla, pokud jsou relevantní
• Otevřené transakce: prodejní objednávky, nákupní objednávky, otevřené faktury
• Počáteční stavy účetnictví: pohledávky, závazky a počáteční stav hlavní knihy

Co obvykle necháváme za sebou:

• Historické transakce starší než 2-3 roky: tyto jsou archivovány v ABRA a zůstávají přístupné pro účetní/daňové účely, aniž by žily v novém systému
• Uzavřené objednávky a faktury: pokud neexistuje specifický regulační nebo analytický důvod pro jejich přenos
• Staré vlastní reporty: tyto jsou znovu vytvořeny na nové platformě, kde je architektura skutečně podporuje

Datový audit je prvním výstupem jakéhokoli migračního projektu. Přesně definuje, co se přesune, co zůstane a co se před přesunem vyčistí.

Migrace dat z ABRA: Technická realita

ABRA exportuje data přes XML (formát Pohoda/ABRA XML) a CSV. XML export je komplexní, ale vyžaduje transformační práci: mapování polí, čištění kódování, deduplikaci a validaci proti datovému modelu cílového systému.

Tři věci činí migrace z ABRA složitějšími než u jednodušších systémů:

• Přizpůsobení: Mnoho instalací ABRA bylo roky přizpůsobováno, přidány další pole, upraveny pracovní postupy, firemní šablony dokumentů. Tyto se neexportují čistě a vyžadují manuální rozhodnutí o mapování.
• Struktura účetní historie: nastavení účtové osnovy a nákladových středisek v ABRA je často specifické pro firmu. Mapování tohoto na novou účtovou osnovu je účetní práce, nejen technická. Klienta vždy zapojujeme do tohoto kroku.
• Kvalita kmenových dat: Po 10 letech v jakémkoli systému se záznamy zákazníků hromadí duplicity, zastaralé kontakty a nekonzistentní kódování. Před migrací provádíme průchod čištění dat, ne po ní.

Používáme kombinaci automatizovaných skriptů a manuálního ověřování pro zpracování transformace. Migrace nejprve probíhá proti staging prostředí, takže klient může ověřit integritu dat, než se cokoli dotkne produkce.

The Migration Process: 5 Phases

Phase 1: Discovery and Scoping (2–3 weeks)

We map the current ABRA setup, business processes, and integration dependencies. Every customization gets documented. The output is a fixed scope, a migration plan, and a budget. No project starts without a signed scope document.

Phase 2: Data Audit and Cleansing (1–2 weeks)

We export the ABRA data and run an audit: volume, quality, completeness, duplicates. The client reviews the audit and makes decisions about what migrates. Cleansing happens here, before anything is moved.

Phase 3: System Build and Data Migration to Staging (3–6 weeks)

We configure the new system to match the agreed scope and migrate all data to a staging environment. The client's key users access the staging instance and run through their daily workflows. This is UAT , user acceptance testing , and it typically produces a punch list of adjustments.

Phase 4: Parallel Run (1–2 weeks)

For a defined period, both systems run simultaneously. New transactions are entered in the new system; ABRA is kept as a fallback. This de-risks the cutover and gives the team confidence before the old system is switched off.

Phase 5: Go-Live and Hypercare (2–4 weeks post-launch)

Cutover happens on a planned date, typically a month-end or quarter-end for accounting cleanliness. We provide intensive support for the first weeks after go-live , response time measured in hours, not days.

Timeline and Investment

Total project duration ranges from 8 to 20 weeks depending on company size, number of users, and integration complexity. Cost estimates for Czech market in 2026:

Tyto částky zahrnují definici rozsahu, projektové řízení, konfiguraci, migraci dat, testování, školení a podporu po spuštění. Licence platformy jsou samostatné a závisí na zvoleném systému.

Největší proměnnou v nákladech je přizpůsobení. Společnosti, které v průběhu let ABRA silně přizpůsobily, přenášejí tuto složitost do migrace. Vždy to zdůrazňujeme ve fázi průzkumu, aby později nedocházelo k překvapením.

Nejčastější rizika a jak je řešíme

• Problémy s kvalitou dat zjištěné v polovině projektu: Audit dat provádíme včas, abychom je našli brzy. Pokud je potřeba rozsáhlé čištění, prodlužuje to časový plán, než se prodlouží rozpočet.
• Rozšiřování rozsahu projektu: Každá migrace přináší požadavky typu „když už jsme u toho“. Tyto požadavky zaznamenáváme jako žádosti o změnu s odděleným oceňováním, místo abychom je zahrnovali do původního rozsahu. Tímto způsobem je původní projekt včas dokončen.
• Odpor uživatelů: Lidé, kteří léta používají ABRA, ji dobře znají. Nový systém je jim neznámý. Naplánujeme si včas školení a zapojíme klíčové uživatele do UAT, aby měli pocit vlastnictví výsledku, místo aby jim byl vnucen.
• Sladění účetních období: Migrace v polovině roku způsobuje bolesti hlavy při vyrovnávání. Od začátku plánujeme termíny přechodu s klientovým účetním.