Nabídky na integraci vypadají navenek podobně: seznam přenášených dat, cena, termín. Průběh projektu se ale od téhle představy dost liší a stojí za to vědět předem, kde se čas reálně tráví. Ušetří to zklamání na obou stranách.
Většinu práce netvoří programování
Tohle je nejdůležitější věta celého článku. Samotné přenášení dat je řemeslo, které se dá odhadnout. Co se odhaduje hůř, je zjišťování, jak přesně u vás věci fungují. A to zabere typicky víc času než samotný vývoj.
Konkrétní příklady otázek, na kterých se projekty zdržují:
- Které skladové místo se má posílat na e-shop, když jich máte víc?
- Co se stane se stavem, když je zboží na cestě mezi sklady?
- Která cenová hladina platí pro zákazníka, který je současně ve dvou skupinách?
- Má se objednávka do ABRY zakládat hned, nebo až po zaplacení?
- Co se stane s objednávkou, kterou zákazník na e-shopu změní poté, co už je v ABŘE?
- Kdo zakládá zákazníka: e-shop, nebo ABRA? A co s duplicitami?
Žádnou z těchhle otázek nemůže rozhodnout dodavatel. Rozhodujete je vy, případně váš konzultant na ABRU. Proto platí, že rychlost projektu je z velké části ve vašich rukách.
Jak projekt probíhá
- Rozbor. Projdeme, co se má přenášet, a hlavně proč. Na tomhle kroku se často zjistí, že polovina požadovaných dat na e-shopu k ničemu není.
- Rozhodnutí o zdroji pravdy. U každého údaje se určí, který systém ho vlastní. Bez toho nemá smysl pokračovat.
- Návrh výměny dat. Co se posílá, jak často, co se stane při výpadku.
- Vývoj a zkušební provoz. Data se přenášejí nanečisto a kontrolují se na vzorku, ne až v ostrém provozu.
- Spuštění. Ideálně mimo sezonu a mimo uzávěrku měsíce v účtárně.
- Dohled. Sledování, jestli výměna běží, a upozornění konkrétnímu člověku, když neběží.
Krok dva je ten, který rozhoduje o tom, jestli bude integrace po roce fungovat. Zkušební provoz a dohled po spuštění se nejčastěji škrtají kvůli rozpočtu. A jsou to přesně ty, jejichž chybění se pozná nejdřív.
Co se obvykle přenáší
| Data | Směr | Poznámka |
|---|---|---|
| Produkty a parametry | ABRA → e-shop | Popisy a fotky obvykle zůstávají na e-shopu |
| Ceny a cenové hladiny | ABRA → e-shop | U B2B nejcennější část celého napojení |
| Skladová dostupnost | ABRA → e-shop | Disponibilní stav, ne fyzický |
| Objednávky | E-shop → ABRA | Včetně poznámek zákazníka |
| Stavy objednávek | ABRA → e-shop | Aby zákazník viděl, co se děje |
| Faktury | ABRA → e-shop | Do zákaznického účtu |
| Zákazníci | Podle dohody | Nejčastější zdroj duplicit, rozhodnout výslovně |
| Vratky a dobropisy | Oběma směry | Nejčastěji vynechaná část zadání |
Pravidlo, které se vyplácí: přenášejte jen to, co někdo na e-shopu opravdu uvidí nebo použije. Každý údaj navíc je něco, co se může rozejít.
B2B: tady se to nejvíc vyplatí
U velkoobchodu je napojení na ABRA Gen obvykle to, co celý portál drží pohromadě. Odběratel se přihlásí a vidí své individuální ceníky, své slevy a svou historii objednávek. A všechno to pochází z ABRY, takže to sedí s tím, co mu potom přijde na faktuře.
Právě tohle je důvod, proč se v B2B nevyplatí ceny do e-shopu kopírovat a udržovat je tam podruhé. Dřív nebo později se rozejdou a rozdíl mezi cenou v portálu a na faktuře je nepříjemnost, která stojí důvěru. Souvisí to s tím, co rozebírá článek o B2B e-shopu. Jak stavíme velkoobchodní portály, popisuje stránka B2B e-shop.
Co bývá největší překvapení
- Uzávěrka měsíce. V účtárně je pár dní v měsíci, kdy se se systémem nehýbe. Do harmonogramu to patří.
- Data v ABŘE nejsou tak čistá, jak se čekalo. Typicky duplicitní karty zboží a zákazníků, které roky nikomu nevadily, protože se pracovalo ručně.
- Chybějící kódy u variant. Produkt se spáruje, velikosti ne.
- Vratky. Objednávka jde do ABRY hladce, ale vratka opačným směrem nikoho v zadání nenapadla.
- Změna objednávky po odeslání do ABRY. Zákazník na e-shopu něco změní a najednou existují dvě verze téže objednávky.
Žádné z těchhle překvapení není neřešitelné. Všechna ale stojí čas, a když se objeví až v půlce projektu, posouvají termín.
Co připravit, než projekt začne
Tohle je nejlevnější způsob, jak si projekt zkrátit. Nic z toho nepotřebuje programátora.
- Člověka, který zná ABRU u vás a má čas. Ne obecně. Konkrétně po dobu projektu.
- Přehled skladů a skladových míst a rozhodnutí, které se týkají e-shopu.
- Popis cenových hladin a pravidlo, co platí při souběhu.
- Seznam stavů objednávek a co který znamená pro zákazníka.
- Rozhodnutí o zákaznících, kdo je zakládá a co s duplicitami.
První bod je nejdůležitější. Projekty, které se u nás protáhly, měly skoro vždycky stejnou příčinu: na straně klienta nebyl nikdo, kdo by uměl na otázky o ABŘE odpovědět, a čekalo se na externího konzultanta.
A co jiné systémy
Postup je stejný pro Pohodu, Helios, Money i další systémy a stejné je i cenové rozpětí. Liší se to, jak systém umí data poskytovat. A to je otázka, kterou má smysl položit hned na začátku, protože rozhoduje o rozsahu práce víc než velikost katalogu.
Totéž platí pro e-shop. Vlastní přístup k Shoptet API, přes který se staví napojení na zakázku, mají jen e-shopy na Shoptet Premium. Na běžných tarifech se ERP napojuje přes hotové doplňky nebo přes importy souborů, a to rozsah i možnosti napojení výrazně mění.
