Komentář Petra Jaroše. Expanze je velký milník v životě firmy, který za sebou máme i my v OnSinch. Psal se rok 2018, když jsme poprvé překročili české hranice a naší platformu na organizaci nárazové pracovní síly jsme nabídli v dalších evropských zemích. Poté jsme kormidlo otočili i směrem k Americe. A díky tomu nám došlo, že expanze váš tým nejen posune, ale také pořádně otestuje. Jakým nástrahám je potřeba odolat? Na co se při škálování v cizině zaměřit? A co nepodcenit?

Pro upřesnění – náš zákazník je firma, která si do aplikace OnSinch nahraje své brigádníky, administrátory a klienty. Ti všichni mohou mít do ní přístup, byť každý má jinou roli, práva a pohled. Shánění brigádníků přes aplikaci možná nezní jako něco, co se v jiných zemích diametrálně liší. Brzy jsme se ale přesvědčili o opaku.

Jiný kraj, jiná legislativa

Pokud jste v Česku někdy chodili na brigádu, možná si pamatujete, jaké dokumenty jste tehdy podepisovali. Ukázalo se, že v zahraničí to chodí úplně jinak. Legislativa nárazové práce se liší země od země a na větší či menší nuance narazíte kdekoli. My například zjistili, že ve Španělsku, Itálii a Belgii se brigádníci před každou prací musejí hlásit na úřad, v Polsku zase narazí na obrovské množství parametrů, které ovlivňují práci na dohodu.

A tak se vám klidně může stát, že vás legislativní bariéry postaví před nové technologické výzvy. Belgický trh se nám uzavřel až do doby, než zajistíme, aby naše aplikace dokázala komunikovat s tamními úřady sama a nevyžadovala jiné integrace. Stejným způsobem můžete narazit i při škálování svého byznysu. Ověřte si, jak moc se váš core business v daném regionu liší, a než se vrhnete na expanzi, nechte si všechna legislativní specifika dobře zanalyzovat.

Nechte si také poradit od svých potenciálních zákazníků, ideálně od více najednou. Každý může považovat za důležitější něco jiného a dost často vám nepodá celistvý obrázek. My k tomu přistupujeme tak, že v první fázi vždy probíhá diskuze s klientem z dané země a s někým, kdo má ve firmě danou oblast na starosti – většinou je to účetní. Zjistíme rozsah požadavku a dopad na implementaci v OnSinch. Někdy připravíme jen naprostý základ a zbytek dáme do veřejné API, aby si klienti mohli s daty nakládat, jak chtějí.

Reagujte včas. I doma

Na změny nezapomínejte reagovat i doma. Tak jako nám se vám snadno stane, že vláda změní zákon a vy musíte řešit nový technický problém, v některých případech dost zásadní. V Česku jsme často svědky toho, že si politici usnadňují práci a přijmou verzi legislativy, která je v tuzemských podmínkách absolutně nepoužitelná.

Nám konkrétně laxní přijetí evropského nařízení ohledně dohody o provedení práce značně zkomplikovalo jednoduché nárazové zaměstnávání mladých lidí na festivalech, koncertech a jiných kulturních akcích, kde je vysoká poptávka po „bedňácích“, hosteskách či personálu cateringu. Změny s sebou nesou takovou administrativní zátěž a nepředvídatelnost nákladů na brigádníky, že prakticky znemožňují rozumně zaměstnávat na DPP.

OnSinch jako takový generuje pouze podklady pro účetnictví, takže na základně změn v DPP jsme do aplikace museli dodělat naprosté minimum. Nicméně jde o procesy, které nelze řešit dopředu – protože na to, jak se legislativní změny promítnou do fungování našich zákazníků, dopředu nedokážeme zcela odpovědět. Můžeme se na to připravovat, ale i tak musíme být flexibilní a pružně reagovat na konkrétní změny.

U DPP to bylo ještě o to zajímavější, že se sice vědělo, že se chystá novela zákoníku práce, ale její konkrétní podoba se schválila velice rychle. Takže zatímco řešíte, jak se vypořádat s komplikacemi v cizině, ani se nenadějete a máte problém doma. Buďte proto ve střehu a na změny reagujte včas.

Nepodceňte lokalizaci

Další potíží je lokalizace. Přeložit aplikaci do španělštiny nebo italštiny nemusí znít jako něco složitého. Jenže brzy narazíte na spoustu proměnných. Používá váš produkt více skupin uživatelů? Rozumět mu musejí všichni. Pokud svůj produkt lokalizujete nejprve do češtiny, množství pádových koncovek, časů a jazykových výjimek vás dobře připraví na lokalizaci do jiných jazyků.

Problém ale může nastat ve struktuře dat. Vzhledem k tomu, že naše aplikace slouží k organizaci práce, museli jsme třeba zohlednit časová pásma nebo letní a zimní čas. Na změnu narazíte v Evropě klidně co 500 kilometrů. Pak jsou tu další rozdíly – například každá země vyžaduje jiné bankovní údaje nebo formát jmen. Ve Španělsku je ve formulářích běžně vyžadováno prostřední jméno.

Překvapit vás může také lokální terminologie, třeba v různých zemích se krajům říká provincie, departmenty nebo kantony. Narazíte ale i na úplné drobnosti jako různý způsob oddělování desetinných míst. Roli hraje rovněž formát exportů, například český Microsoft Excel bere za výchozí oddělovač desetinných míst v .csv formátu čárku, kdežto ve většině anglofonních zemí je to tečka. Na první pohled triviální problémy. Pokud ale chcete svůj software správně lokalizovat, musíte na ně často přijít sami.

Obecně se říká, že by se to nemělo s vývojem přehánět – vyhnout se tzv. „overengineeringu“. Tedy nepřidávat do aplikace věci, které zatím nikdo nechce. U lokalizace je to naopak. Pokud děláte globální aplikaci, která chce být správně přizpůsobená lokálním trhům, tak je overengineering na místě, protože přidat zpětně fundamentální funkce není triviální. My si lokalizaci vždy děláme interně, využíváme pouze externí překladatele. Nutno podotknout, že lokalizace nejsou jen překlady, ale všechny národní zvyklosti, jak se pracuje s daty.

Škálování za hranice Evropy

V OnSinch jsme následně absolvovali i cestu přes Atlantik. Přestože jsme vstupovali do anglofonní země a angličtina byla první jazyk, do kterého jsme svoji aplikaci přeložili, lokalizaci jsme se nevyhnuli ani zde. Americký trh je obrovský a překvapí vás spoustou byznysových odlišností.

Před nás například postavil úplně jinou tvorbu cen a mezd v nárazových pracích. Zjistili jsme, že ve Spojených státech platí úplně jiné zvyklosti, jinak se pohlíží na přesčasy nebo pauzy. Museli jsme proto sáhnout i na některé základní funkcionality – přestože neposkytujeme účetní systém, pouze předáváme požadovaná data. Z toho vyplývá, že pokud jde o místní zákony, záleží primárně na zkušenostech. Kdo však zažil legislativní marast v Evropě, škálování v USA pro něj bude hračka.

Hojně skloňovaným faktorem při škálování je i cloud. My využíváme Google Cloud a AWS a zatím jsme na limity nenarazili. Za zmínku ale stojí integrace lokálních poskytovatelů služeb, jako jsou například SMS brány. Dává smysl aplikaci připravit na propojení s lokálními poskytovateli, protože mohou nabídnout lepší ceny a pro tamní trh jsou vhodnější a leckdy i spolehlivější.

Z naší zkušenosti je lepší aplikaci připravit na to, aby si do ní mohli zákazníci sami napojit lokální služby, na které jsou zvyklí, než jim vnucovat jednoho nadnárodního poskytovatele. Výběr je hlavně na klientovi, proto aplikaci obecně „otevíráme“ a určité prvky infrastruktury (jako je právě třeba SMS brána) necháváme na volbě klienta.

Důležité ale stále je soustředit se na hlavní byznys zákazníků a ten pokrýt celý – i když se napojení vícero aplikací skrze API může zdát jako skvělé a flexibilní řešení, opak je pravdou. Čím více systémů je na sebe napojených, tím je systém křehčí a vyžaduje mnohem více nákladů na údržbu. Stejně tak nechceme spoléhat na integrační partnery, kteří celé řešení prodraží, a raději spolupracujeme se zákazníkem, aby se dokázal onboardovat sám.

Ať už svůj produkt škálujete do jakékoli země, uvědomte si však, které základní funkce musí stůj co stůj obsahovat. Právě ty jsou páteří jeho přidané hodnoty. Vymezte si i hranice. Například my v OnSinch moc dobře víme, co nikdy vyvíjet nebudeme. V našem případě je to zmiňované účetnictví. Najít si hranice, které při škálování nepřekročíte, je stejně důležité jako produkt sám.