Arnav Mishra, współzałożyciel i CTO Doss – seria wywiadów

Arnav Mishra, współzałożyciel i CTO Doss, jest inżynierem full-stack i liderem technicznym z doświadczeniem w startupach we wczesnej fazie i dużych systemach infrastrukturalnych. Przed założeniem Doss był inżynierem założycielem w Siteline, gdzie zbudował podstawowe systemy, w tym architekturę uprawnień, integracje z ERP i ramy automatyzacji, a także przyczynił się do rekrutacji, operacji przychodów i kultury firmy. Wcześniej w swojej karierze pracował jako inżynier w Rubrik i odbywał staże w firmach takich jak Uber i VMware, rozwijając umiejętności w zakresie infrastruktury chmury, systemów danych i automatyzacji. Wraz z pracą techniczną, był aktywnie zaangażowany w mentorowanie i rozwój talentów poprzez organizacje takie jak Techquitable Futures i Contrary, co odzwierciedla szerszy zobowiązanie do wspierania następnej generacji inżynierów.

Doss to nowoczesna firma oprogramowania przedsiębiorstw, której celem jest rewolucjonizacja tradycyjnych systemów ERP za pomocą swojej platformy Adaptive Resource Platform (ARP), elastycznej, rodzimej platformy operacyjnej zaprojektowanej w celu ujednolicenia i zautomatyzowania workflowów biznesowych. Zbudowana jako kompozytowa alternatywa dla rozwiązań ERP, Doss umożliwia firmom zarządzanie zapasami, zakupami, finansami i realizacją zamówień w ramach jednego systemu, który dostosowuje się do rzeczywistych operacji, zamiast narzucania sztywnych procesów. Jej platforma łączy scentralizowaną warstwę danych, workflowy bez kodu i analitykę w czasie rzeczywistym, umożliwiając firmom szybkie wdrożenie, integrację z istniejącymi narzędziami i ciągłe ewoluowanie operacji bez długich wdrożeń lub kosztownych konsultantów.

Motywacja do budowy Doss sięga do czasów, gdy Wiley obserwował, jak oprogramowanie legacy zakłócało działalność jego ojca w branży produkcyjnej, a potem obaj zobaczyli podobne problemy na własne oczy, pracując z fabrykami i łańcuchami dostaw. Jak te doświadczenia ukształtowały Twoją decyzję o założeniu Doss i przemyśleniu systemów ERP od podstaw?

Przed Doss byłem inżynierem założycielem startupu FinTech. Powodem, dla którego nasi klienci – CFO, księgowi itp. – nie wybrali naszego rozwiązania, było to, że byli “zbyt zajęci wdrożeniem ERP”. Gdy zagłębiłem się w archaiczną dziedzinę ERP, byłam zaskoczony istniejącym modelem wdrożeniowym.

To, co widziałem, było tym samym podstawowym błędem: wdrożenie trwa miesiące lub lata, kosztuje setki tysięcy do milionów dolarów i jest całkowicie uzależnione od ludzkich konsultantów z godzinową opłatą. Następnie, gdy ERP jest dostarczony, przestaje się zmieniać. Biznes nadal ewoluuje; system nie. To problem architektoniczny, a nie konfiguracyjny. Nie możesz go naprawić łataniem.

Jako budowniczy oprogramowania, najbliższa porównywalna rzecz, o której mogłem pomyśleć, była następująca: wyobraź sobie świat, w którym najważniejsze narzędzie, które używasz – jako deweloper, powiedzmy GitHub – zostało zbudowane specjalnie dla Twojej firmy w ciągu lat przez agencję konsultingową. Następnie, gdy produkt jest gotowy, konsultanci odchodzą bez konserwacji, ulepszeń ani wsparcia. Inżynierowie byliby zbuntowani.

Żadna nowoczesna firma technologiczna nie może funkcjonować w tym modelu. Wiley i ja doszliśmy do tego samego wniosku: jedynym sposobem, aby to naprawić, było zbudowanie wszystkiego od podstaw.

Doss pozycjonuje się jako platforma operacyjna AI-native zaprojektowana w celu zastąpienia tradycyjnych systemów ERP, takich jak SAP lub Oracle. Jakie podstawowe różnice architektoniczne sprawiają, że platforma ERP AI-native jest możliwa dzisiaj, a nie byłafeasible dziesięć lat temu?

Oracle i SAP zostały zbudowane w erze, w której, aby osiągnąć maksymalną dystrybucję, musiały uproszczyć płaszczyznę konfiguracyjną ERP, aby była edytorem opartym na GUI, który mogliby dostarczyć na dużą skalę stosunkowo nietechniczni konsultanci. Aby zachować najlepsze praktyki, zablokowali duże części podstawowych systemów i pozwolili tylko na kompozytę na obrzeżach. W rzeczywistości, gdy spojrzy się na spektrum wszystkich firm na świecie, ich aplikacje biznesowe wymagają maksymalnej elastyczności.

To, co umożliwia świat AI-native, to transformacja inżynierii oprogramowania z rzemiosła w zindustrializowaną maszynę. Nie musimy już mieć rzemieślników oprogramowania, którzy ręcznie tworzą systemy kodowe; zamiast tego wkraczamy w świat, w którym przepływ oprogramowania jest czynnikiem komputera i tokenów.

Doss został zaprojektowany z myślą o tym.

Zbudowaliśmy ZSL, język DSL deklaratywny, który opisuje całą implementację Doss w kodzie. Pomyśl, co “Terraform” zrobił dla wysoru Infrastructure as Code, ale zastosowane do logiki aplikacji biznesowych. Definiując ERP w języku programowania o relatywnie niskiej wymiarowości, możemy wdrożyć agenci na dużą skalę, aby dostarczyć rozwiązania ERP.

Gdy tylko ZSL został napisany, najważniejszą częścią architektury było wbudowanie najlepszych praktyk w samą platformę, aby zapobiec agentom budowaniu niskiej jakości implementacji. Nasz zespół dostarczył skalowalny system rozproszony z harmonogramem jądra, aby podjąć się obciążenia zadań ERP. Ponadto zbudowaliśmy system HTAP, który łączy najważniejsze części bazy danych transakcyjnej, takiej jak Postgres, i możliwości analityczne Data Warehouse.

Budując platformę, aby miała wytrzymałość na poziomie przedsiębiorstwa od samego początku, system jest zaprojektowany do całkowicie agentynej dystrybucji. To, co zajmowało zespołom konsultantów miesiące i lata, może być teraz równolegle przetwarzane na dużą skalę przy użyciu infrastruktury agenty w naszym zamkniętym systemie.

Wiele firm nadal polega na arkuszach kalkulacyjnych i fragmentowanych narzędziach do zakupów, zarządzania zapasami i zarządzania zamówieniami. Jakie są największe błędy operacyjne, które pojawiają się, gdy podstawowe dane biznesowe nie są ujednolicone w jednym źródle prawdy?

Największym problemem jest to, że decyzje są podejmowane na podstawie starych lub niepełnych informacji. Jeśli Twoje dane dotyczące zapasów znajdują się w jednym miejscu, zamówienia zakupu w innym, a zamówienia sprzedaży w trzecim, zawsze jesteś w trakcie rekonsolidacji, ręcznie, powoli i po fakcie. Do momentu, gdy ktoś zorientuje się, że zapasy są niewłaściwe lub dostawca jest opóźniony, jest to już problem w biznesie.

Verve Coffee Roasters to dobry przykład, gdzie to się psuje w praktyce. Prowadzą operacje w sklepach, hurtowniach, DTC i kawiarniach w USA i Japonii, ale zarządzali wszystkim w systemach niepołączonych bez widoczności zapasów w czasie rzeczywistym. Zabrakło im własnej kawy w miejscach o wysokim natężeniu ruchu i doszło do krytycznych braków podczas uruchomienia dużego detalicznego, co zaszkodziło kluczowej relacji handlowej. Dane istniały gdzieś; po prostu nie były połączone w sposób, który pozwoliłby komukolwiek działać na czas.

Mniej oczywistym problemem jest to, że fragmentacja ukrywa prawdziwy kształt Twoich operacji. Nie możesz zobaczyć relacji między opóźnieniem na górze a problemem z realizacją na dole, jeśli te dwie rzeczy znajdują się w oddzielnych narzędziach. Kończysz zarządzaniem objawami, przyspieszaniem zamówień, budowaniem zapasów bezpieczeństwa i ręcznymi kontrolami zamiast zrozumienia, co tak naprawdę się dzieje. Ujednolicony system nie tylko oszczędza czas na rekonsolidacji. Zmienia to, co możesz nawet zobaczyć i o co możesz pytać.

W swojej istocie wyobraź sobie prowadzenie firmy bez dostępu do systemu kontroli wersji (Git), narzędzia obserwacyjnego (DataDog) lub scentralizowanej bazy danych do zapytań.

Wdrożenia ERP historycznie wymagały dużych zespołów konsultingowych i miesiąców – lub nawet lat – wdrożenia. Jak AI zmienia ekonomię i złożoność wdrażania oprogramowania operacyjnego w rzeczywistych firmach?

Tradycyjny model wdrożeniowy jest wynikiem praktyk oprogramowania z pokoleń.

Istnieje perwersyjna zachęta w wdrożeniach ERP dzisiaj – im dłużej trwa wdrożenie i im mniej skuteczne jest, tym więcej pieniędzy otrzymują osoby wdrażające. Ogromna większość budowniczych nie skorzystałaby z tego; jednak nigdy nie są zachęcani do działania z szybkością i jakością.

Ponadto stosunek wydatków na konsulting do wydatków na oprogramowanie w tradycyjnym zaangażowaniu ERP wynosi około 9:1, więc wydajesz dziewięć dolarów na konsultantów za każdy dolar, który wydajesz na samo oprogramowanie. Dla dużej firmy jest to bardzo bolesne. Dla firm z rynku średniego jest to zabronione. Zatem albo godzą się na oprogramowanie, które nie pasuje do tego, jak działają, opóźniają projekt lub porzucają go w połowie.

AI zmienia jednostkową ekonomię tego całkowicie. Zamiast zaangażowania konsultingowego, wdrożenie Doss jest kodem. Gdy nasz czas wdrożenia się skraca, możemy wyrównać zachęty z modelem “płacisz za dostawę” zamiast “płacisz, jak idziesz”. Gdy biznes się zmienia, system się zmienia z nim. Potrzeba pokoi pełnych konsultantów i długich prezentacji nie jest już istotna.

Sukces w Doss oznacza zastąpienie 1,86 bln globalnych wydatków na usługi IT agentywnym wdrożeniem i konserwacją przy użyciu naszego ZSL jako języka dla oprogramowania aplikacji biznesowych. Sukces w Doss to komodyfikacja wszystkich aplikacji biznesowych na dużą skalę.

Wdrożyliście Doss w firmach działających w środowiskach rzeczywistych, takich jak produkcja, logistyka i dobra konsumpcyjne. Jakie są nieoczekiwane wyzwania, które pojawiają się, gdy AI spotyka się z niechlujnymi danymi operacyjnymi?

Wyzwaniem rzadko jest AI. To dane, o które prosisz go, aby je rozważył.

Każda firma, z którą pracujemy, nagromadziła lata operacyjnych rozwiązań. Dane technicznie istnieją, po prostu nie mieszkały w miejscu, w którym ich pracownicy, a nawet agenty, mogliby na nich polegać.

Jednym z dobrych przykładów jest niemiecki producent mebli, który tworzy elementy na zamówienie. Gdy przybyliśmy, mieli 10 lat danych historycznych rozproszonych w 8 niestandardowych formatach plików z 11 różnymi obiektami danych i synchronizacją 3PL uruchomioną ręcznie za pomocą kopii i wklejania z folderów FTP. Logika biznesowa była specyficzna z konfiguracjami niestandardowymi, wymiarami, metodami płatności i lokalizacjami salonu, a cały system musiał działać w języku niemieckim. Nie ma gotowego schematu dla tego. Musieli płacić tysiące euro za każdą zmianę prostych opcji konfiguracyjnych, takich jak opcje statusu dla zamówienia.

Wyzwaniem nie jest techniczna złożoność poszczególnych elementów. To to, że każda firma ma inną wersję tego problemu, a nie możesz go w pełni przewidzieć, dopóki nie znajdziesz się w ich danych. Praca polega na tym, aby uzyskać dokładny odcisk, jak firma naprawdę działa, a nie mapować ich danych w ogólny szablon i mieć nadzieję, że pasuje.

Aby zbudować rozwiązanie, które działa w świecie rzeczywistym, potrzebujesz platformy o maksymalnej elastyczności. Dopiero wtedy AI może być użyteczny w zrozumieniu podstawowego modelu danych, na którym pracuje, i budowaniu modelu, który działa dla każdego klienta.

Istnieje wiele dyskusji na temat pilotów AI i autonomicznych agentów w oprogramowaniu biznesowym. Gdzie widzisz AI dodając najwięcej wartości w workflowach operacyjnych dzisiaj, a gdzie nadzór ludzki pozostaje niezmiennie istotny?

W skali AI ma możliwość zakłócić wszystkie operacje.

W horyzoncie krótkoterminowym modele i agenci Doss powinni być w stanie przekształcić rdzeń konsultantów technicznych wdrażających aplikacje biznesowe, a także zespołu konsultantów zarządzających dostarczających zalecenia strategiczne. Doss będzie miał największy zbiór danych ustrukturyzowanych i skojarzonych reprezentujących zarówno schemat, jak i informacje operacyjne dla firm. Nasi agenci mogą użyć tych danych, aby dostarczyć zalecenia skalowalne.

Najbardziej oczywistą wartością dzisiaj jest coś bardziej szczegółowego niż to. Jest to praca, która jest powtarzalna, oparta na regułach i obecnie wykonywana przez ludzi, którzy mają inne, bardziej strategiczne priorytety: przetwarzanie zamówień zakupu, uzgadnianie zapasów i routing decyzji o realizacji. Te zadania mają dobrze zdefiniowane dane wejściowe i wyjściowe, a AI może je obsłużyć niezawodnie na dużą skalę.

Na razie nadzór ludzki jest niezmiennie istotny, gdzie koszt złej decyzji jest wysoki, a system nie ma jeszcze wystarczającej ilości kontekstu, aby być pewnym. Dzisiaj właściwy model nie polega na tym, że autonomiczne agenci zastępują ludzkie podejmowanie decyzji w całości; to agenci zajmują się pracą o wysokiej objętości i dobrze zdefiniowaną, aby ludzie mogli się skoncentrować na decyzjach, które wymagają ich osądu.

Wiele firm próbuje nakładać AI na istniejące stosy oprogramowania. Dlaczego retrofitting systemów legacy z AI często nie spełnia oczekiwań w porównaniu z budowaniem AI bezpośrednio w podstawie platformy?

Systemy legacy nie zostały zbudowane, aby być rozważanymi przez AI. Modele danych, API, sposób, w jaki informacje są strukturyzowane, wszystko to zostało zaprojektowane dla ludzi, aby interakcjonowali z interfejsami. Gdy próbujesz nałożyć AI na to, prosisz go, aby pracował wokół ograniczeń, których nie miałby pracować.

Nawet jeśli spróbujesz rzucić serwer MCP na górze, w rzeczywistości serwer MCP wymaga bardzo specyficznych wzorców projektowych. Większość serwerów MCP dzisiaj tak naprawdę wprowadza większy rozdęcie kontekstu i wybuch wydajności.

Jednak głębszym problemem jest model wdrożeniowy. W tradycyjnym ERP konfiguracja systemu jest przechowywana w samym systemie. Nie jest to kod, który możesz przeczytać, przetestować lub wersjonować. Nie ma sposobu, aby agent mógł zrozumieć, co system robi, nie mówiąc już o tym, aby go bezpiecznie zmienić. Zbudowaliśmy ZSL specjalnie, aby konfiguracja była właściwym kodem: czytelnym, testowalnym i wdrożonym w zamkniętym systemie. Budujemy w pełni agentywny cykl życia rozwoju oprogramowania (SDLC). To jest warunek wstępny, aby AI mogło naprawdę działać na systemie, a nie tylko siedzieć na jego górze.

Jak AI staje się w stanie generować workflow i interakcji bezpośrednio z systemami operacyjnymi, jak myślisz, że tradycyjne interfejsy oprogramowania przedsiębiorstw będą ewoluować?

Pytanie interfejsu jest naprawdę o to, kto potrzebuje używać systemu. Dzisiaj interfejsy ERP są zbudowane wokół niewielkiej grupy użytkowników o wysokich uprawnieniach, ludzi, którzy zostali przeszkoleni na systemie podczas wdrożenia. Każdy inny albo nie może go używać, albo otrzymuje zdegradowaną wersję.

To, co budujemy, to kompozytowy interfejs, który traktuje interfejs jak budowniczy witryn. Interfejs sam w sobie jest również wspierany przez zamknięty ZSL. Każdy, CFO, menedżer magazynu, analityk łańcucha dostaw, otrzymuje pulpit i widoki danych skomponowane wokół tego, jak naprawdę pracują, a nie wokół tego, jak oprogramowanie zostało skonfigurowane. Gdy AI zajmuje się coraz większą częścią podstawowej wykonania workflow, interfejs staje się mniej dotyczący wprowadzania danych i bardziej dotyczący widoczności i podejmowania decyzji. Oprogramowanie powinno zajmować się resztą.

Startupy takie jak Doss wkraczają na rynek zdominowany przez dziesięciolecia stare firmy. Jakie przewagi mają startupy AI-native, gdy konkurują z ustanowionymi platformami przedsiębiorstw?

Firmy ustanowione mają odwrotny problem niż startupy. Mają ogromne bazy instalacji, które muszą chronić. Każda decyzja architektoniczna, którą podejmują, musi być wstecznie kompatybilna. Mogą dodać funkcje AI do istniejących produktów, ale nie mogą odbudować podstawowych systemów bez złamania wszystkiego, co na nich działa. To nie jest porażka ambicji; to strukturalne.

W ERP specyficznie są również obciążone decyzjami biznesowymi, które poprowadziły ich w kierunku, w którym dochód jest napędzany przez specyficzną funkcję, którą Doss próbuje wyeliminować – konsultanci profesjonalni. Biorąc pod uwagę, że użytkownicy wydają dziewięć dolarów na konsultantów za każdy dolar, który wydają na samo oprogramowanie, możliwość przekształcenia 90% ich przychodu źródłowego jest nie do przyjęcia dla dużych firm ustanowionych.

System AI-native może być zaprojektowany od samego początku, aby AI było częścią podstawowej architektury, a nie warstwą na górze. Model wdrożeniowy, model danych i sposób, w jaki konfiguracja działa, są wszystkie zaprojektowane z AI jako pierwszorzędny uczestnik. To jest przewaga kumulatywna, gdzie każde wdrożenie sprawia, że system staje się lepszy, a agenci wdrożeni stają się bardziej zdolni z każdym nowym klientem. Tego rodzaju pętla poprawy nie istnieje w systemie, w którym wdrożenie jest nadal ludzkim zaangażowaniem konsultingowym.

Spójrzając w przyszłość, jak wyobrażasz sobie, że AI przekształci “system operacyjny” biznesu w ciągu najbliższych pięciu do dziesięciu lat, szczególnie w obszarach takich jak widoczność łańcucha dostaw, podejmowanie decyzji w czasie rzeczywistym i automatyzacja operacji?

Założyliśmy Doss na przekonaniu, że systemy przedsiębiorstw będą mogły zbudować same siebie. Trzy lata później weszliśmy w fazę 2 Doss: agentywną, samosterującą implementację. Platforma może już generować, walidować i ewoluować system klienta, zamiast polegać na ręcznej konfiguracji konsultantów, i staje się lepsza z każdym wdrożeniem.

Kierunek, w którym to zmierza, to system, który jest zawsze zsynchronizowany z biznesem. Dzisiaj przerwa między tym, jak firma działa, a tym, co system wie o niej, wynosi miesiące lub lata. System został skonfigurowany w pewnym momencie i nie zmienił się od tego czasu. To, co staje się możliwe, gdy ta przerwa się zamyka, gdy system dostosowuje się w czasie rzeczywistym, jak biznes się zmienia, jest inną kategorią zdolności operacyjnej. Widoczność w czasie rzeczywistym nie jest tylko szybszym raportowaniem; to możliwość przechwycenia zakłóceń łańcucha dostaw, zanim staną się one awarią realizacji. Automatyzacja operacji nie jest tylko kwestią wydajności; to możliwość prowadzenia bardziej złożonego biznesu z tym samym zespołem. To wersja oprogramowania operacyjnego, które budujemy.

Dziękujemy za szczegółowe odpowiedzi, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Doss.