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.

Migrační proces: 5 fází

Fáze 1: Analýza a vymezení rozsahu (2–

Zmapujeme aktuální nastavení ABRA, obchodní procesy a integrační zá

Fáze 2: Audit a čištění dat (1–2 týdny)

Exportujeme data z ABRA a provedeme audit: objem, kvalita, úplnost

Fáze 3: Sestavení systému a migrace dat do Stagingu (3–6 týdnů)

Nakonfigurujeme nový systém podle odsouhlaseného rozsahu a migrujeme

Fáze 4: Paralelní běh (1–2 týdny)

Po definovanou dobu běží oba systémy souběžně. Nové trans

Fáze 5: Go-Live a Hypercare (2–4 týdny

Přechod na nový systém probíhá v plánovaném termínu, obvykle na

Harmonogram a investice

Celková délka projektu se pohybuje v rozmezí 8 až 20

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.