Peppol pro vývojáře: Zjednodušené transakce B2B nebo nová zátěž pro IT?

Peppol nepochybně získává na popularitě ve světě obchodní komunikace. Společnosti a vlády stále častěji přecházejí z tradičních technologií na tento nový otevřený standard v oblasti obchodní komunikace, jako jsou elektronické faktury, elektronické objednávky a další transakční toky.

Mnoho článků poskytuje přehled základních informací o Peppolu, proto se jím zde nebudeme zabývat. Shrnutí jeho pozadí najdete v tomto příspěvku o historii Peppolu. Místo toho se podrobněji zaměříme na jeho funkce, technické možnosti a infrastrukturu z pohledu vývojáře a vysvětlíme, proč se stal novým paradigmatem v oblasti B2B.

Business-to-business (B2B) v kontextu IT označuje elektronickou výměnu obchodních zpráv mezi společnostmi. Elektronická komunikace B2B existuje již dlouhou dobu a byla jedním z hnacích faktorů při vývoji stabilní a bezpečné globální sítě – toho, co dnes známe jako internet.

Business-to-business (B2B) v kontextu IT označuje elektronickou výměnu obchodních zpráv mezi společnostmi. Elektronická komunikace B2B existuje již dlouhou dobu a byla jedním z hnacích faktorů při vývoji stabilní a bezpečné globální sítě – toho, co dnes známe jako internet.

Důvod je jednoduchý. Podniky si uvědomily, že s příchodem počítačů musí sdílet data, aby mohly plně využít jejich potenciál. Z této potřeby vznikl B2B.

Když se B2B začalo rozvíjet na konci 70. let, neexistovaly žádné sítě mezi společnostmi a data (jejich ukládání) byla nepředstavitelně drahá, takže se všichni snažili minimalizovat datové modely.

Z těchto počátků se vyvinuly dva hlavní formáty: ANSI X12 (1979) v USA a EDIFACT (1984) v Evropě. Oba byly zamýšleny jako standard pro společnosti, aby mohly používat a ukládat data v co nejkomprimovanější podobě.

O několik desetiletí později jsou tyto formáty stále široce používány po celém světě. X12 je mimo USA méně běžný, ale EDIFACT je velmi rozšířený.

EDIFACT je také základem proUBL, stavební blok Peppol XML.

B2B dnes využívá prakticky každá společnost, protože pro podnikání je nezbytná digitální komunikace.

S rozvojem B2B, konkrétně od poloviny 90. let, kdy došlo k boomu internetu, začalo mnoho společností navazovat „point-to-point“ (P2P) spojení se svými obchodními partnery, protože neexistovaly žádné jiné alternativy pro sdílení jejich B2B dat.

O něco později byly vyvinuty první služby Value-Added-Network (VAN), které měly zmírnit rostoucí potíže s připojením P2P. Společnosti se mohly připojit k jednomu poskytovateli VAN , který se zase připojil ke všem ostatním spolupracovníkům a vytvořil tak síť operátorů B2B. Tito poskytovatelé služeb jsou obecně známí jednoduše jako operátoři (OP).

Bylo založeno stále více OP – některé lokální, zaměřené na konkrétní region nebo zemi, jiné s globálním dosahem. Počet B2B spojení rychle rostl a zároveň se na trhu objevovalo stále více systémů.

Výsledkem byla exploze typů a formátů zpráv, protože podpůrné systémy postrádaly společné standardy.

Poskytovatelé služeb B2B si brzy uvědomili, že potřebují transformace (konverze datových formátů mezi systémy zákazníků a jejich obchodními partnery), což vedlo k vývoji dalších řešení, transformačního softwaru pro firmy a transformačních služeb od VAN .

Jak si asi dokážete představit, způsobilo to chaos v B2B provozu. Pro VAN však bylo toto nastavení velmi výnosné; mohli účtovat poplatky jak odesílateli, tak příjemci, a navíc mohli účtovat příplatky za transformace!

Jistě, „kolaps“ je možná příliš drastický výraz. Nicméně s rostoucím počtem formátů bez centrální koordinace, rychlým šířením internetu a neustálým poklesem cen za ukládání a přenos dat se blížil zlomový bod.

VAN však byli spokojeni. Každý účastník sítě provozovatelů byl pevně zakotven a neměl jinou možnost, než pokračovat v placení účtů VAN , aby mohl pokračovat ve své činnosti.

Když se náklady staly bolestivě vysokými, společnosti začaly uvažovat o zavedení funkcí B2B do svých firem; integrační platforma se tak poprvé dostala na světlo světa.

Integrační platformy byly vyvinuty, aby nahradily funkce mnoha VAN v oblasti zpracování transportů, transformace a směrování. Ti, kteří v tomto oboru působí již několik let, si toto období pamatují jako éruSOA(a nyní se nacházíme v období kolem let 2004–2008). Od té doby se SOA rozrostla, nebo spíše proměnila, ve standard mikroslužeb. Celkově vzato je to skvělý výsledek.

Podniky však často platily značné licenční poplatky poskytovatelům integračního softwaru namísto VAN . Flexibilita integračního softwaru navíc ještě více zvýšila složitost, protože společnosti se nyní mohly přizpůsobit prakticky čemukoli a zpracovávat to ve svých systémech, avšak za vysoké fixní náklady a náklady na konzultanty, manuální zpracování a budování integrací. Tento chaos je něco, čím stále trpíme – integrační spaghetti. Počet formátů, komunikačních protokolů a P2P připojení je ohromující.

Řešení této neefektivní, ale bohužel stále se zhoršující situace přišlo nečekaně. Vzhledem k tomu, že jednotlivé země, regiony a systémy měly své vlastní formáty a protokoly, Evropská unie identifikovala tento problém jako překážku efektivního fungování vnitřního trhu. EU začala vyvíjet systém Peppol, aby vytvořila síť pro spolupráci s přesným a kontrolovaným standardem.

To bylo provedeno nezávisle na kolapsu B2B, ale EU potřebovala nějakou formu společného a efektivního komunikačního standardu, protože na trhu žádný neexistoval.

Ne všichni byli s tímto řešením spokojeni. VAN si uvědomili, že jednoduchost společného standardu radikálně sníží výši vybíraných poplatků, čímž dojde ke ztrátě významného zdroje příjmů.

Nakonec, díky pevné podpoře evropských politiků a pokračujícímu přijímání Peppolu mezi vládami a společnostmi, si většina VAN uvědomila, že udržování jednoho standardu je z dlouhodobého hlediska nákladově efektivnější. Udržování chaosu v oblasti B2B a integrační spaghetti už nestačilo. Podpora ze strany VAN pomohla Peppolu vzlétnout.

Další stranou, která nebyla příliš nadšená, byly společnosti, které investovaly značné prostředky do integrační platformy zajišťující veškerou B2B komunikaci interně. Peppol vyžaduje použití přístupového bodu Peppol (AP), nazývaného také poskytovatel služeb Peppol, jako jediného způsobu výměny zpráv přes Peppol. Toto jediné rozhraní k síti činí stávající P2P připojení a schopnost zpracovávat mnoho přenosových protokolů nadbytečnými.

Uživatelé integrační platformy dospěli ke stejnému závěru jako VAN . Alespoň si to začínají uvědomovat – použití JEDNOHO standardu pomáhá vyřešit většinu problémů. Současně stále více poskytovatelů softwaru, např. ERP systémů jakoSAP, přidává nativní podporu pro Peppol, čímž eliminuje potřebu složitých transformací.

Mnoho integračních platforem a VAN si uvědomilo, že model Peppol je velmi výhodný.

AP zaručuje doručení zprávy; protokol a standard jsou vysoce strukturované a ověřené a každá zpráva přijatá prostřednictvím sítě je plně ověřena a vždy 100% správná z hlediska syntaxe a ověřovacích pravidel.

Tyto kontrolní mechanismy nabízené sítí Peppol mohou výrazně snížit potřebu řešení a sledování chyb, což v dlouhodobém horizontu přináší úsporu finančních prostředků. Zaměstnanci mohou být přeřazeni na jiné úkoly a lze omezit licencování softwaru a systémů.

Když jsem začínal v IT a B2B, jedním z mých prvních úkolů bylo upgradovat tok z EDIFACT D.93A na tehdy nově vydaný D.96A (ti, kteří znají EDIFACT, možná vědí, že D.96A byl vydán v roce 1996) a moje první myšlenka byla:„Co to sakra je? Kdo proboha vymyslel tenhle formát?“ Pak jsem si uvědomil, že to byla Organizace spojených národů, a tak jsem situaci přijal.

Peppol zvolil jako základní standard UBL, který vychází z EDIFACT. Jedná se o osvědčený a široce používaný základ, který splňuje potřeby většiny společností.

Zprávy UBL jsou odesílány pomocíAS4 (ebMS)jako podepsaná a šifrovaná data, což zajišťuje bezpečnost zprávy a přenosu a činí Peppol bezpečnou a spolehlivou komunikační metodou. Peppol je řízen jako otevřený standard, s výborem a členy, kteří stanovují standardy a provádějí změny a doplňky. Každá připojená země má jednu nebo více autorit Peppol, které řídí členy v každé zemi.

Přečtěte si tento příspěvek, abyste se seznámili s terminologií Peppol.

Peppol je soubor standardů a infrastruktura navržená ke zjednodušení elektronických zadávacích řízení v celé Evropě i mimo ni. Jeho přijetí bylo motivováno potřebou standardizovaných a interoperabilních řešení elektronického zadávání veřejných zakázek s cílem zvýšit efektivitu, snížit náklady a podpořit mezinárodní obchod.

Klíčové body týkající se přijetí systému Peppol:

Celkově lze říci, že přijetí standardu Peppol představuje významný pokrok v digitalizaci procesů zadávání veřejných zakázek, který přispívá k větší efektivitě, hospodárnosti a integraci globálního obchodu.

A jeho výzvy?

Přijetí systému Peppol má sice své výhody, ale může narazit na několik překážek. Budu trochu drsný – je důležité se na systém Peppol dívat s otevřenýma očima:

Řešení těchto překážek vyžaduje strategické plánování, adekvátní zdroje a silné zapojení zainteresovaných stran, aby bylo možné úspěšně přijmout a využít výhody systému Peppol.

Peppol se rozrůstá. S přistupováním nových zemí se objevují některé počáteční problémy, ale komunita se snaží co nejlépe kombinovat zdroje, aby vyhovovala potřebám všech.

Standard se rozdělil na Peppol BIS, používaný hlavně v Evropě, a Peppol PINT, používaný mezinárodně. Je to pravděpodobně rozumné, protože předpisy a požadavky týkající se DPH nelze splnit v jediném formátu, ale mapování (transformace) mezi těmito dvěma formáty je jasně stanoveno.

Když se ohlédneme za problémy, se kterými jsme se potýkali před lety, je zřejmé, že Peppol dokáže vyřešit složitosti, pomoci snížit náklady, omezit chyby a poskytnout data vyšší kvality. I když existují oprávněné výzvy, které pro některé mohou být obtížné překonat, je zřejmé, že Peppol bude i nadále růst. V nadcházejících letech budeme svědky větší podpory ze strany systémů a služeb, např. ERP, přidání podpory pro formáty Peppol XML, připojení dalších zemí a neustálého nárůstu transakcí a uživatelů.