Arnav Mishra, spoluzakladatel a technický ředitel společnosti Doss – Interview Series

Arnav Mishra, spoluzakladatel a technický ředitel společnosti Doss, je full-stack inženýr a technický leader s bohatými zkušenostmi z počátečních fází startupů a velkých infrastrukturních systémů. Předtím, než se stal spoluzakladatelem společnosti Doss, byl jedním z founding inženýrů ve společnosti Siteline, kde vyvinul jádrové systémy, včetně architektury oprávnění, integrací ERP a automatizačních rámců, a zároveň se podílel na náboru, revenue operacích a firemní kultuře. V počáteční fázi své kariéry pracoval jako inženýr ve společnostech Rubrik a absolvoval stáže ve společnostech Uber a VMware, kde získal odborné znalosti v oblasti cloud infrastruktury, datových systémů a automatizace. Kromě své technické práce se aktivně podílel na mentorování a rozvoji talentů prostřednictvím organizací jako Techquitable Futures a Contrary, což odráží širší závazek k podpoře příští generace inženýrů.

Doss je moderní podnikový software zaměřený na reinvenci tradičních ERP systémů prostřednictvím své Adaptive Resource Platform (ARP), flexibilní, AI-nativní operační platformy navržené pro sjednocení a automatizaci obchodních workflow. Postaven jako kompozitní alternativa k tradičním ERP řešením, Doss umožňuje společnostem spravovat sklad, nákup, finance a plnění v rámci jednoho systému, který se přizpůsobuje reálným operacím, místo aby vynucoval rigidní procesy. Jeho platforma kombinuje centralizovanou datovou vrstvu, workflow bez kódu a analýzy v reálném čase, což umožňuje podnikům nasadit rychle, integrovat s existujícími nástroji a nepřetržitě rozvíjet své operace bez zdlouhavých implementací nebo nákladných konzultantů.

Motivace pro stavbu DOSS sahá zpět k Wiley, který pozoroval, jak legacy software narušil jeho otcovu výrobní firmu, a oba jste později viděli podobné problémy při práci s továrnami a dodavatelskými řetězci. Jak tyto zkušenosti ovlivnily vaše rozhodnutí založit DOSS a předefinovat ERP systémy od základu?

Předtím, než jsem se stal spoluzakladatelem DOSS, jsem byl founding inženýr ve FinTech startupu. Hlavním důvodem, proč naši zákazníci – CFO, účetní atd. – nešli s naší řešením, bylo to, že byli „příliš zaneprázdněni implementací ERP“. Když jsem se více ponořil do archaické oblasti ERP, byl jsem šokován stávajícím modelem implementace.

Co jsem neustále viděl, byla stejná základní chyba: implementace trvala měsíce nebo roky, stála stovky tisíc až miliony dolarů a byla zcela závislá na lidských konzultantech s hodinovou sazbou. Poté, co byl ERP dokončen, přestal se měnit. Podnik stále evolvoval; systém ne. To je architektonický problém, ne konfigurační problém. Nemůžete to opravit pomocí patche.

Jako softwarový vývojář jsem si uvědomil, že nejbližší srovnání by bylo následující: představte si svět, ve kterém je nejdůležitější nástroj, který používáte – jako vývojář, řekněme GitHub – postavený speciálně pro vaši společnost během let třetí stranou konzultační agenturou. Poté, co je produkt dokončen, konzultanti odcházejí bez údržby, vylepšení nebo podpory. Inženýři by se bouřili.

Žádná moderní technologická společnost nemůže fungovat v tomto modelu. Wiley a já jsme dospěli k stejnému závěru: jediný způsob, jak to opravit, je postavit od základu.

DOSS se позициuje jako AI-nativní operační platforma navržená k nahrazení tradičních ERP systémů, jako je SAP nebo Oracle. Jaké jsou základní architektonické rozdíly, které činí AI-nativní ERP možnou dnes, a které nebyly proveditelné před deseti lety?

Oracle a SAP byly postaveny v éře, kdy musely zjednodušit konfigurační rovinu ERP, aby ji mohli relativně netechničtí konzultanti dodávat ve velkém měřítku. Aby zachovali osvědčené postupy, uzamkli velké části jádrových systémů a umožnili kompozici pouze na okrajích. Ve skutečnosti, když se podíváte na spektrum všech podniků na světě, jejich obchodní aplikace potřebují maximální flexibilitu.

Co umožňuje svět AI, je transformace softwarového inženýrství z řemesla na industrializovanou mašinu. Už nemusíme mít softwarové řemeslníky, kteří ručně vytvářejí kódové systémy; místo toho se přesouváme do světa, ve kterém je softwarový průtok faktorem výpočetní techniky a tokenů.

Doss byl navržen přesně s tímto v mente.

Vyvinuli jsme ZSL, deklarativní doménově specifický jazyk (DSL), který popisuje implementaci zákazníka v kódu. Představte si, co „Terraform“ udělal pro úsilí Infrastructure as Code, ale místo toho aplikované na obchodní aplikaci logiku. Definováním ERP v relativně nízkorozměrném programovacím jazyce jsme schopni nasadit agenty ve velkém měřítku, aby dodávali ERP řešení.

Jakmile byl ZSL napsán, nejvýznamnější částí architektury bylo vměstnat osvědčené postupy do platformy samotné, aby se zabránilo agentům budovat nízkokvalitní implementace. Náš tým dodal škálovatelný distribuovaný systém s jádrovým plánovačem, aby se ujal zátěže bursty ERP workflow. Kromě toho jsme postavili HTAP databázový systém, který kombinuje nejdůležitější části transakční databáze, jako je Postgres, a analytické schopnosti Data Warehouse.

Postavením platformy, aby měla podnikový standard od samého začátku, je systém nastaven pro plnou agentic distribuci. Co dříve trvalo týmy konzultantů měsíce nebo roky, může být nyní paralelizováno ve velkém měřítku pomocí agentic infrastruktury v našem proprietárním uzavřené smyčce.

Mnohé společnosti stále spoléhají na tabulky a fragmentované nástroje pro nákup, sklad a řízení objednávek. Jaké jsou největší provozní slepá místa, která vznikají, když nejsou jádrové obchodní údaje sjednoceny do jediného zdroje pravdy?

Největší problém je, že rozhodnutí jsou učiněna na základě zastaralých nebo neúplných informací. Pokud vaše údaje o skladu žijí na jednom místě, vaše nákupní objednávky na jiném a vaše prodejní objednávky na třetím, vždycky jste v režimu reconciliation, manuálně, pomalu a až poté, co je pozdě. Do té doby, než někdo uvědomí, že sklad je pryč nebo dodavatel je pozadu, už je to problém v podniku.

Verve Coffee Roasters je dobrým příkladem, kde se to rozpadá v praxi. Provozují operace napříč obchody, velkoobchodem, DTC a kavárnami v USA a Japonsku, ale spravovali všechna tato data v nespojených systémech bez reálné viditelnosti skladu. Docházelo k tomu, že jim docházel jejich vlastní káva na místech s vysokou návštěvností a měli kritické problémy se skladem během majoritní retailer launch, což poškodilo klíčový maloobchodní vztah. Data existovala někde; prostě nebyla spojena tak, aby na nich někdo mohl jednat včas.

Jemnější problém je, že fragmentace skrývá skutečný tvar vašich operací. Nemůžete vidět vztah mezi zpožděním na horním toku a problémem s plněním na spodním toku, pokud tyto dvě věci žijí v samostatných nástrojích. Nakonec spravujete symptomy, urychlujete objednávky, budujete bezpečnostní sklad a spouštíte manuální kontroly místo toho, abyste rozuměli, co se skutečně děje. Sjednocený systém vám neonly ušetří čas na reconciliation, ale změní to, co můžete vidět a na co se můžete ptát.

Ve své podstatě si představte, že provozujete podnik bez přístupu k verzionálnímu systému (Git), nástroji pro pozorovatelnost (DataDog) nebo centralizované databázi, ze které můžete dotazovat informace.

Implementace ERP historicky vyžadovaly velké konzultační týmy a měsíce – nebo dokonce roky – nasazení. Jak AI mění ekonomiku a složitost implementace provozního softwaru uvnitř skutečných podniků?

Tradiční model implementace je výsledkem generací starých softwarových postupů. Už nežijeme v tom světě.

Existuje perverzní pobídka v implementacích ERP dnes – čím déle implementace trvá a čím méně účinná je, tím více peněz implementátoři dostávají. Většina vývojářů by tuto situaci nevyužila; nicméně nikdy nejsou motivováni k tomu, aby se pohybovali s tempem a kvalitou.

Kromě toho je poměr konzultačních výdajů k softwarovým výdajům v tradiční ERP angažovanosti zhruba 9:1, takže utratíte devět dolarů za konzultanty za každý dolar, který utratíte za software samotný. Pro velkou korporaci je to extrémně bolestivé. Pro podniky středního trhu je to prohibitive. Takže buď se usadí s softwarem, který skutečně neodpovídá tomu, jak fungují, nebo projekt odloží, nebo ho opustí cestou.

AI mění jednotkovou ekonomiku úplně. Místo konzultační angažovanosti je implementace DOSS kódová báze. Jak naše doby implementace pokračují ve zkracování, jsme schopni sladit pobídky s modelem „platit za dodání“ místo „platit, jak jdete“. Když se podnik změní, systém se změní s ním. Potřeba pokojů plných konzultantů a dlouhých prezentací již není relevantní.

Úspěch u Doss znamená nahradit 1,86 bilionu dolarů globálních IT služeb agentic implementací a údržbou pomocí našeho ZSL jako jazyka pro obchodní aplikaci software. Úspěch u Doss je komoditizace všech obchodních aplikací ve velkém měřítku.

Můžete nasadit DOSS u společností, které fungují v reálných prostředích, jako je výroba, logistika a spotřební zboží. Jaká jsou některá z nečekaných výzev, které vznikají, když AI potkává špinavá provozní data?

Výzvou je zřídka AI. Je to data, o kterých se ptáte, aby je rozuměly.

Každý podnik, se kterým pracujeme, nahromadil roky provozních workaroundů. Data technicky existují, prostě nežijí nikde, kde by je mohli zaměstnanci, natož agentic systémy, spolehlivě jednat.

Jedním dobrým příkladem je německý výrobce nábytku, který vyrábí kusy na míru. Když jsme přišli, měli 10 let historických dat rozložených napříč 8 vlastními formáty souborů s 11 různými datovými objekty a 3PL synchronizací běžící na manuálním kopírování z FTP složek. Obchodní logika byla specifická s vlastními rozměry, konfiguracemi, platebními metodami a umístěními showroomů, a celý systém potřeboval fungovat v němčině. Neexistuje žádný off-the-shelf schéma pro to. Museli platit tisíce eur každý čas, když chtěli změnit jednoduché konfigurační možnosti, jako jsou stavové možnosti pro nákupní objednávku.

Výzvou není technická složitost žádné jedné části. Je to to, že každý podnik má jinou verzi tohoto problému, a nelze jej plně předpovědět, dokud nejste uvnitř jejich dat. Práce spočívá v tom, aby se vytvořila přesná kopie toho, jak podnik skutečně funguje, a ne mapovat jejich data do generického šablony a doufat, že to bude fungovat.

Abyste postavili řešení, které funguje pro skutečný svět, potřebujete platformu s maximální flexibilitou. Teprve tehdy může AI být užitečná při porozumění základnímu datovému modelu, na kterém pracuje, a budování modelu, který funguje pro každého zákazníka.

Existuje mnoho diskusí o AI kopilotů a autonomních agentů v obchodním softwaru. Kde vidíte, že AI přidává největší hodnotu v provozních workflow dnes, a kde zůstává lidský dohled stále nezbytný?

Ve velkém měřítku má AI schopnost narušit všechny provozní práce.

V blízké budoucnosti by proprietární modely a agenti Doss měli transformovat jádro technických konzultantů při implementaci obchodních aplikací, stejně jako roli management konzultantů při dodávání strategických doporučení. Doss bude mít největší repozitář strukturovaných a současně umístěných dat, představujících jak schéma, tak provozní informace pro podniky. Naši agenti budou moci použít tato data k dodání škálovatelných doporučení.

Nejbližší hodnota dnes je specifičtější než to. Je to v práci, která je opakující se, založená na pravidlech a目前 dělána lidmi, kteří mají jiné, strategičtější priority: zpracování nákupních objednávek, reconciliation skladu a směrování rozhodnutí o plnění. Tyto úkoly mají dobře definované vstupy a výstupy, a AI je může zpracovat spolehlivě ve velkém měřítku.

Prozatím je lidský dohled nezbytný, kdykoli je cena špatného rozhodnutí vysoká, a systém ještě nemá dostatečnou kontext, aby byl jistý. Dnes není správný model autonomní agenti, kteří nahrazují lidské rozhodování celkově; je to agenti, kteří zpracovávají vysokovýkonnou, dobře definovanou práci, aby lidé mohli soustředit na rozhodnutí, která skutečně vyžadují jejich úsudek.

Mnohé podniky se snaží vrstvit AI na stávající softwarové stohy. Proč často selhává retrofitting legacy systémů s AI ve srovnání s tím, že se AI staví přímo do základny platformy?

Legacy systémy nebyly postaveny tak, aby byly rozuměny AI. Datové modely, API, způsob, jakým je informace strukturována, vše bylo navrženo pro interakci lidí prostřednictvím rozhraní. Když se pokusíte vrstvit AI na top, žádáte ji, aby pracovala kolem omezení, pro která nebyla navržena.

I když se pokusíte přidat MCP server na top, ve skutečnosti MCP server potřebuje velmi specifické návrhové vzory. Většina MCP serverů dnes actually introdukuje větší kontextové okno a zhoršuje výkon.

Hlubší problém je model implementace. V tradičním ERP je konfigurace systému uložena v systému samotném. Není to kód, který můžete číst, testovat nebo verzovat. Není způsob, jak by agent mohl pochopit, co systém dělá, natož aby to mohl bezpečně změnit. Vyvinuli jsme ZSL speciálně tak, aby konfigurace byla správnou kódovou základnou: čitelnou, testovatelnou a nasaditelnou v uzavřené smyčce. Stavíme plně agentic softwarový vývojový životní cyklus (SDLC). To je předpoklad pro to, aby AI mohla skutečně pracovat na systému, místo aby seděla pouze na jeho vrcholu.

Jak se AI stává schopnou generovat workflow a interagovat přímo s provozními systémy, jak vidíte budoucnost tradičních podnikových softwarových rozhraní?

Otázka rozhraní je vlastně o tom, kdo potřebuje systém používat. Nyní jsou ERP rozhraní postavena kolem malé skupiny power uživatelů, lidí, kteří byli vyškoleni na systém během implementace. Každý jiný buď nemůže systém použít, nebo dostane zhoršenou verzi.

Co stavíme, je kompozitní UI, které zachází s rozhraním jako s webovým stavitelem. Rozhraní samotné je také podporováno uzavřenou smyčkou ZSL. Každý, od CFO po skladového manažera, po supply chain analytika, dostane dashboard a datové pohledy komponované kolem toho, jak skutečně pracují, ne kolem toho, jak byl software nakonfigurován. Jak AI zpracovává více podkladových workflow, rozhraní se stává méně o datové vstup a více o viditelnost a rozhodování. Potřebujete vidět, co se děje, pochopit proč, a učinit úsudky. Software by měl zpracovat zbytek.

Startupy jako DOSS vstupují na trh, který dominují desetiletí staré etablované společnosti. Jaké výhody mají AI-nativní startupy, když soutěží proti zavedeným podnikovým platformám?

Etablované společnosti mají opačný problém než startupy. Mají enormní instalované základny, které musí chránit. Každé architektonické rozhodnutí, které činí, musí být zpětně kompatibilní. Mohou přidat AI funkce do stávajících produktů, ale nemohou přestavět základní systémy, aniž by rozbili vše, co na nich běží. To není selhání ambice; je to strukturální.

V ERP specificky jsou také zatíženy obchodními rozhodnutími, která je vedla po cestě, kde je výnos generován z konkrétní funkce, kterou DOSS cílí eliminovat – profesionální konzultační služby. Vzhledem k tomu, že uživatelé utratí devět dolarů za konzultanty za každý dolar, který utratí za software samotný, schopnost transformovat 90 % jejich zdrojového výnosu je neudržitelná pro velké etablované společnosti.

AI-nativní systém může být navržen od začátku tak, aby AI byla součástí jádrové architektury, ne vrstva na top. Model implementace, datový model a způsob, jak funguje konfigurace, jsou všechny navrženy s AI jako první třídou účastníkem. To je komponující výhoda, kde každé nasazení dělá systém lepší, a implementační agenti se stávají více schopnými s každým novým zákazníkem. Takový zlepšovací smyček neexistuje v systému, kde implementace je stále lidská konzultační angažovanost.

Pohledem do budoucnosti, jak si představujete, že AI transformuje „provozní systém“ podniku v příštích pěti až deseti letech, zejména v oblastech, jako je viditelnost dodavatelského řetězce, rozhodování v reálném čase a automatizované operace?

Založili jsme DOSS na přesvědčení, že podnikové systémy budou moci postavit sami sebe. Tři roky poté, co jsme vstoupili do fáze 2 Doss: agentic self-driving implementace. Platforma již může generovat, ověřovat a rozvíjet systém zákazníka, místo aby spoléhala na manuální konfiguraci konzultantů, a stává se lepší s každým nasazením.

Směr, kterým se to ubírá, je systém, který je vždy v souladu s podnikem. Dnes je mezera mezi tím, jak podnik funguje, a tím, co systém ví o něm, měsíce nebo roky. Systém byl nakonfigurován v určitém okamžiku a od té doby se nezměnil. Co se stane možným, když se tato mezera uzavře, když se systém přizpůsobí v reálném čase, jak se podnik mění, je jiná kategorie provozní schopnosti. Viditelnost v reálném čase není pouze rychlejší reporting; je schopnost chytit dodavatelskou rupturu, bevor se stane plněním selháním. Automatizované operace nejsou pouze o efektivitě; je schopnost provozovat komplexnější podnik se stejným týmem. To je verze provozního softwaru, na kterou jsme se zaměřili.

Děkujeme za vaše podrobné odpovědi, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Doss.