PIM, díl 2: Proč potřebujeme Chytrý Produktový Katalog?

V minulém díle blogu jsme řešili, co je Chytrý Produktový Katalog (neboli PIM – Product Information Management) a k čemu je dobrý. Dnes si položíme otázku: kdo vůbec takový nástroj potřebuje a k čemu.

Než se propracujeme ke složitějším scénářům, jako jsou banky, srovnávače, telco nebo on-line trhy, začněme tím nejjednodušším – e-shopem. V zásadě existují dvě možnosti. Buď může mít e-shop svou nabídku pevně “zadrátovanou”, zakódovanou ve svých stránkách (dost absurdní představa), nebo se nabídka mění a potom musí někde v infrastruktuře e-shopu existovat systém, který tuto nabídku udržuje. Ano, to je on – produktový katalog nebo-li PIM (Product Information Management).

Jak taková věc může vypadat? V jednoduchém případě může jako produktový katalog sloužit sada tabulek v nějaké relační databázi. Na každý dotaz zákazníka e-shopu vyhledá databáze buď relevantní seznam zboží, nebo detailní informaci o konkrétním zboží.

Kde takový systém vzít? Nejjednodušší samozřejmě je, když k nějaké existující databázi přihodíme pár nových tabulek a data si dáme do nich. Za měsíc zařadíme do nabídky nový druh zboží, tak přihodíme novou tabulku. A pak další. A programátoři budou mít spoustu práce a my si s každým novým zbožím pár dnů počkáme (nebo pár týdnů, když bude mít programátor zrovna jinou práci). Tím jsme narazili na první důležitý parametr produktového katalogu, a to je flexibilita. Nabídka e-shopů (a nejen jich) se v čase mění a katalog musí pro takové změny poskytovat dostatečnou flexibilitu. Volat na každou změnu programátora je drahé a časově náročné.

Takže požádáme našeho programátora, aby nám umožnil zadávat ke zboží nové druhy informací sami, aniž bychom ho pokaždé museli volat na pomoc. Programátor přidá další tabulku pro generické atributy, která nám umožní kdykoliv k čemukoliv přidat nové pole a dát mu jakýkoliv obsah. Moc pěkné. Ale jen na chvíli. Jak se nám nabídka produktů rozrůstá, systém musí dohledávat víc a víc informací v těchto nových polích. A zpomaluje a zpomaluje … Tím jsme se dostali ke druhému důležitému parametru produktového katalogu – rychlosti. Zákazník u mobilu nebude chtít několik vteřin čekat, než náš systém sesbírá potřebné informace a laskavě mu je ukáže.

Zpátky do reality. Podívali jsme se na dva ilustrativní příklady špatného řešení. V reálu by žádného střízlivého programátora (a ani většinu těch nestřízlivých) nenapadlo navrhnout systém podobným způsobem. Použité příklady jsou úmyslně absurdní, aby zjednodušeně ukázaly možné problémy. Problémy, které jsou naopak velmi reálné – jen se k nim ve skutečnosti dostaneme později a složitější cestou. Produktový katalog potřebuje být flexibilní a rychlý zároveň. Flexibilní, abychom mohli rozšiřovat nabídku a zavádět nové produkty. Rychlý, aby zákazník na naši nabídku nemusel dlouho čekat. Tyhle dva požadavky jdou do značné míry proti sobě. To neplatí jen pro e-shopy a produktové katalogy – to platí obecně pro software (a nejen pro něj).

Skutečné řešení tohoto problému už není tak jednoduché. Skrývá se ve skutečnosti, že rychlost a flexibilitu potřebujeme v jiných situacích. Zatímco flexibilita je důležitá při sestavování popisu produktů, tak rychlost je kritická při jejich poskytování zákazníkovi. Řešení? Produktový katalog má dvě samostatné komponenty – designer a run-time. Designer je určený pro popis produktů a poskytuje především flexibilitu. Pracuje s ním jen několik lidí a rychlost není takový problém. Run-time dostává z designeru hotová data a ukládá si je ve struktuře optimální pro rychlé poskytování zákazníkům. Každá komponenta je postavená na úplně jiných technologiích, optimálních pro její specifický účel.

Tím, že jsme si uvědomili, že rychlost a flexibilitu potřebujeme v jiných situacích, vyřešili jsme zdánlivě neřešitelný problém. A získali jsme tím ještě jeden bonus v podobě škálovatelnosti. Když už máme dvě komponenty (designer a run-time) a mezi nimi rozhraní, můžeme poměrně snadno k jednomu designeru připojit více run-time komponent. Pokud nám naroste provoz e-shopu, spustíme další
run-time komponentu, která si přes existující rozhraní bude brát existující data z designeru. Vláda zavře obyvatele doma a oni se nám nahrnou do e-shopu? Spustíme další run-time komponentu a hotovo. Můžeme se věnovat skutečným problémům jako je sklad a doprava.

To jsou tři ze čtyř základních parametrů produktového katalogu – rychlost dodávání informací, flexibilita datového modelu a škálovatelnost. Tím posledním kritériem je integrace na jiné systémy. Katalog pracuje s informacemi, které už z veliké části někde existují. O ručním opisování se asi nemusíme bavit. Katalog potřebuje automaticky dostávat informace o produktové nabídce z jiných systémů, které už tyto informace mají – ERP, výroba, sklad, subdodavatelé. Velmi často je jeden katalog integrovaný na několik takových systémů. Informace z nich spojuje dohromady (například přes EAN), obohacuje o další informace vložené uživateli (obrázky, kalkulace) a svižně poskytuje do e-shopu nebo jiných prodejních kanálů.

Když jsme zmínili integraci na ERP, automaticky se nabízí otázka:

K čemu potřebujeme chytrý produktový katalog, když většina informací už je připravená v ERP?

Důvody jsou především dva:

• ERP řeší spoustu různých agend, které katalog řešit nepotřebuje – finance, personalistiku, nákup, dispečink, nebo zákaznickou podporu. Navíc je optimalizovaný na práci uživatelů přes uživatelské rozhraní. Naopak není optimalizovaný na rychlost při poskytování informací prodejním kanálům. V takovém scénáři ERP systém ve své výkonnosti značně pokulhává. Produktový katalog je specializovaný na rychlé poskytování informací prodejním kanálům a většinou má za tímto účelem specializovanou run-time komponentu, která má informace předpřipravené k rychlému poskytování ven. U jednotek zákazníků je rozdíl zanedbatelný u tisíců už je znát. U vyšších čísel upadá běžný ERP systém do smrtelné křeče.
• ERP je obvykle složitý, a tudíž drahý systém. A jako takový se těžko škáluje, pokud provoz na e-shopu začne růst. Zvýšení výkonu ERP systému obvykle znamená dokoupení nového serveru a nových drahých licencí. Naproti tomu, “přifouknutí” produktového katalogu znamená spuštění další runtime komponenty (obvykle v cloudu nebo na virtuálním serveru), která se připojí na existující jádro, vytáhne si z něj informace a během pár minut už poskytuje data zákazníkům.

Mezi dalšími důvody bychom neměli zapomenout:

• ERP není určený k prodeji a obvykle neposkytuje podporu pro různé prodejní scénáře. K takovým scénářům patří například dynamická cenotvorba závislá na různých časově omezených akcích nebo aktuálních skladových zásobách. Nebo sestavování existujících produktů do balíčků, které se potom dají prodávat jako nové produkty (a můžou být klidně sestavené z produktů více dodavatelů).
• ERP obvykle obsahuje mnohé produktové informace, ale ne všechny. Takže pro prodej stejně potřebujeme integrovat jiné systémy (ať už uvnitř vlastní firmy, nebo systémy dodavatelů) a spojovat produktové informace z různých zdrojů dohromady. Potom už je ale jednodušší udělat to v dedikovaném systému, než na to draze upravovat CRM.

To je asi schované někde uvnitř našeho e-shopu

Přesně tak. Drtivá většina e-shopových “krabicových” řešení v sobě zahrnuje nějakou formu produktového katalogu. Pro malý e-shop je to nejlepší řešení. Všechno dostaneme pohromadě, nemusíme řešit integraci. Pro větší e-shopy, nebo takové, které v budoucnu plánují růst a expandovat, je to zásadní omezení. Pokud jim nějaká část e-shopové krabice přestane vyhovovat (třeba při expanzi na nový trh), musí nahradit celý systém. Proto střední a větší e-shopy stále častěji preferují modulární systém sestavený ze samostatných komponent před monolitickým systémem. V budoucnu si výhody a nevýhody monolitického a modulárního řešení rozebereme podrobněji.

Uzavřeno a shrnuto: E-shop potřebuje odněkud brát data. K tomu slouží produktový katalog. ERP obsahuje data o produktech, ale na poskytování dat do e-shopu je neefektivní (pomalý a drahý). Chytrý produktový katalog (PIM) potřebuje být rychlý, flexibilní, škálovatelný a integrovaný na jiné systémy. To umožňuje růst a expandovat.

A příště už se konečně dostaneme k příkladům využití chytrého produktového katalogu v jiných oblastech než jsou e-shopy. Podíváme se na banky, srovnávače, mobilní operátory, energetiku a další.