Arnav Mishra, spoluzakladatel a technický ředitel Doss – rozhovor

Arnav Mishra, spoluzakladatel a technický ředitel Doss, je full-stack inženýr a technický lídr s bohatými zkušenostmi z počátečních fází startupů a velkých infrastruktur. Předtím, než spoluzaložil Doss, byl jedním z founding inženýrů ve společnosti Siteline, kde vyvíjel jádro systému, 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čátcích své kariéry pracoval jako inženýr ve společnostech Rubrik a Uber a VMware, kde získal zkušenosti s cloudovou infrastrukturou, datovými systémy a automatizací. Kromě své technické práce se aktivně podílel na mentorství a rozvoji talentů prostřednictvím organizací jako Techquitable Futures a Contrary, což odráží jeho širší závazek k podpoře další generace inženýrů.

Doss je moderní podnikový software, který se zaměřuje na přepracování 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 procesů. Postaven jako kompozitní alternativa k tradičním ERP řešením, Doss umožňuje společnostem spravovat inventář, nákup, finance a plnění v rámci jednoho systému, který se přizpůsobuje reálným provozním podmínkám, místo aby vynucoval rigidní procesy. Jeho platforma kombinuje centralizovanou datovou vrstvu, bezkódové pracovní postupy a analýzy v reálném čase, umožňující firmám rychle nasadit, integrovat s existujícími nástroji a kontinuálně vyvíjet své operace bez zdlouhavých implementací nebo drahých konzultantů.

Co vás motivovalo k vybudování Doss? Jaké zkušenosti vás vedly k rozhodnutí založit Doss a přepracovat ERP systémy od základu?

Předtím, než jsem spoluzaložil Doss, jsem pracoval jako founding inženýr ve FinTech startupu. Hlavním důvodem, proč naši zákazníci – finanční ředitelé, úč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á fundamentální 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 fakturací. Poté, co byl ERP systém nasazen, přestal se vyvíjet. Podnik pokračoval v evoluci, ale systém ne. To je architektonický problém, ne konfigurační problém. Nemůžete se z něj vymanit pomocí patchů.

Jako softwarový vývojář jsem si uvědomil, že nejbližší srovnání, které jsem mohl udělat, bylo následující: představte si svět, ve kterém nejvýznamnější nástroj, který používáte – jako vývojář, řekněme GitHub – byl 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í funkcí a 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, bylo postavit vše 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 (ORCL ). Jaké jsou základní architektonické rozdíly, které činí AI-nativní ERP možným dnes, na rozdíl od před deseti lety?

Oracle a SAP byly postaveny v éře, kdy pro maximální distribuci potřebovaly zjednodušit konfigurační rovinu ERP na GUI-založeného editora, který by mohli relativně netechničtí konzultanti dodávat ve velkém měřítku. Aby zachovali osvědčené postupy, uzamkli velké části jádra systému a umožnili kompozici pouze na okrajích. Ve skutečnosti, když se podíváte na spektrum všech firem na světě, jejich obchodní aplikace vyžadují maximální flexibilitu.

Co umožňuje AI-nativní svět, 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 pohybujeme do světa, ve kterém je softwarový průtok faktorem výpočetní techniky a tokenů.

Doss byl architektonicky 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 infrastrukturu jako kód, ale místo toho aplikované na obchodní aplikaci logiku. Definováním ERP v relativně nízkorozměrové programovací řeči 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 zabudování osvědčených postupů do platformy samotné, aby se zabránilo agentům budovat nízkokvalitní implementace. Naše tým dodal škálovatelný distribuovaný systém s jádrovým plánovačem, aby se ujal zátěže nárazových ERP úloh. Kromě toho jsme postavili HTAP databázový systém, který kombinuje nejvýznamnější části transakční databáze, jako je Postgres, a analytické schopnosti Data Warehouse.

Postavením platformy s podnikovou třídou od začátku je systém nastaven pro plně 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 vlastním uzavřené smyčce.

Mnohé společnosti stále spoléhají na tabulky a fragmentované nástroje pro nákup, inventář a řízení objednávek. Jaké jsou největší provozní slabiny, které vznikají, když jádrové obchodní údaje nejsou 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 inventáři žijí na jednom místě, vaše nákup objednávky na druhém a vaše prodejní objednávky na třetím, jste vždycky ručně sjednocujete, pomalu a až po skutečnosti. Až někdo uvědomí, že inventář je mimo nebo dodavatel je pozadu, je to již problém v podniku.

Verve Coffee Roasters je dobrým příkladem, kde se to rozpadá v praxi. Provozují operace napříč maloobchodem, velkoobchodem, DTC a kavárnami ve Spojených státech a Japonsku, ale spravovali všechna tato data v nespojených systémech bez reálné viditelnosti inventáře. Byli vyprodáni svého vlastního kávy na místech s vysokým provozem a narazili na kritické problémy se zásobami během spuštění významného maloobchodního partnera, což poškodilo klíčový maloobchodní vztah. Data existovala někde, ale nebyla propojena tak, aby na ně někdo mohl včas reagovat.

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 dolním toku, pokud tyto dvě věci žijí v oddělených nástrojích. Končíte tím, že spravujete symptomy, urychlujete objednávky, budujete bezpečnostní zásoby a spouštíte manuální kontroly místo toho, abyste pochopili, co se skutečně děje. Sjednocený systém neonly šetří čas na sjednocení, ale mění to, co můžete vidět a na co se můžete ptát.

V jádru si představte, že provozujete podnik bez přístupu k verzi kontrolnímu systému (Git), nástroji pro pozorovatelnost (DataDog) nebo centralizované databázi pro dotazování informací.

Implementace ERP tradičně 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 firem?

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

Existuje perverzní pobídka v implementaci ERP dnes – čím déle implementace trvá a čím méně efektivní je, tím více peněz konzultanti obdrží. Většina vývojářů by této pobídky nezneužila; nicméně nejsou nikdy motivováni k pohybu 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 přibližně 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 středně velké podniky je to prohibitive. Takže buď se usadí s softwarem, který skutečně nefunguje, nebo projekt odloží nebo opustí část cesty.

AI mění jednotkovou ekonomiku úplně. Místo konzultační angažovanosti je implementace Doss kódová báze. Jak naše časy 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 slide decků již není relevantní.

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

Vy jste nasadili Doss u společností, které operují ve skutečných prostředích, jako je výroba, logistika a spotřební zboží. Jaké jsou některé neočekávané výzvy, 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 rozumně zpracovala.

Každá společnost, se kterou pracujeme, nahromadila roky provozních řešení. Technicky existující data žijí někde, ale nejsou dostupná tak, aby na ně mohli spolehlivě reagovat zaměstnanci, natož agentic systémy.

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 místy prodeje, 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 pokaždé, když chtěli změnit jednoduché konfigurační možnosti, jako jsou stavové možnosti pro nákup objednávky.

Výzvou není technická složitost jednotlivých částí. Je to to, že každá společnost má jinou verzi tohoto problému, a nelze jej plně předvídat, dokud nejste uvnitř jejích dat. Úkolem je vytvořit přesnou kopii toho, jak podnik skutečně funguje, a ne mapovat svá 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 pak může AI být užitečné při porozumění základnímu datovému modelu, se kterým pracuje, a budování modelu, který funguje pro každého zákazníka.

Jak vidíte největší přínos AI v provozních pracovních postupech dnes, a kde zůstává lidský dohled stále nezbytný?

V blízké budoucnosti by měly naše proprietární modely a agenti transformovat jádro technických konzultantů při implementaci obchodních aplikací, stejně jako roli manažerských konzultantů při poskytování strategických doporučení. Doss bude mít největší repozitář strukturovaných a lokalizovaných dat, zastupují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í.

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

Prozatím je lidský dohled nezbytný všude, kde 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ží přidat AI na stávající softwarové stavy. Proč přidání AI do stávajících systémů často selhává ve srovnání s postavením AI přímo do základny platformy?

Stávající 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 lidskou interakci prostřednictvím rozhraní. Když se pokusíte přidat AI na vrchol, žádáte ji, aby pracovala kolem omezení, pro která nebyla navržena.

Dále je problém, že implementační model. 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í žádný způsob, jak by agent mohl pochopit, co systém dělá, natož aby jej mohl bezpečně změnit. Postavili jsme ZSL speciálně tak, aby konfigurace byla řádným kódovým základem: čitelným, testovatelným a nasaditelným v uzavřené smyčce. Budujeme plně agentic softwarový vývojový životní cyklus (SDLC). To je předpoklad pro to, aby AI skutečně pracovala na systému, místo aby seděla pouze na vrcholu.

Jak se podle vás bude vyvíjet tradiční podnikový software rozhraní, když AI bude generovat pracovní postupy a interagovat přímo s provozními systémy?

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

Co budujeme, je kompozitní UI, který zachází s rozhraním jako s webovým stavitelem. Rozhraní samo je také podporováno uzavřenou smyčkou ZSL. Každý, finanční ředitel, manažer skladu, analytik dodavatelského řetězce, dostane dashboard a datové pohledy složené kolem toho, jak skutečně pracují, ne kolem toho, jak byl software nakonfigurován. Jakmile AI zpracuje více podkladových pracovních postupů, rozhraní se stane méně o vstupu dat a více o viditelnosti a rozhodování. Musíte 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é firmy. Jaké výhody mají AI-nativní startupy, když soutěží s etablovanými podnikovými platformami?

Etablované firmy mají opačný problém než startupy. Mají enormní instalované základy, které musí chránit. Každé architektonické rozhodnutí, které udělají, 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 porušili 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ý, je schopnost transformovat 90 % jejich zdrojového výnosu neudržitelná pro velké etablované firmy.

AI-nativní systém může být navržen od začátku tak, aby AI byla součástí jádra architektury, ne pouze vrstva na vrcholu. Implementační model, datový model a způsob, jak funguje konfigurace, jsou všechny navrženy s AI jako první třídou účastníka. To je kompenzační výhoda, kde každé nasazení dělá systém lepší, a implementační agenti se stávají schopnějšími s každým novým zákazníkem. Takový zlepšovací cyklus 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 vyvíjet zákaznický systém, místo aby se spoléhala na manuální konzultační konfiguraci, a zlepšuje se 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, 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 to schopnost chytit dodavatelskou rupturu, než se stane plněním selháním. Automatizované operace nejsou pouze o efektivitě; je to schopnost provozovat komplexnější podnik se stejným týmem. To je verze provozního softwaru, kterou budujeme.

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.