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 i dużych systemach infrastrukturalnych. Przed założeniem Doss, był inżynierem założycielem w Siteline, gdzie budował systemy rdzeniowe, w tym architekturę uprawnień, integracje z systemami ERP i ramy automatyzacji, a także przyczyniał się do rekrutacji, operacji finansowych 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 chmurowej, 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 dla przedsiębiorstw, skupiająca się na rewolucjonizowaniu tradycyjnych systemów ERP za pomocą swojej platformy Adaptive Resource Platform (ARP), elastycznej, AI-natywnej platformy operacyjnej zaprojektowanej do ujednolicenia i zautomatyzowania workflow biznesowych. Zbudowana jako komponowalna alternatywa dla rozwiązań ERP legacy, Doss umożliwia firmom zarządzanie zapasami, zakupami, finansami i realizacją w ramach jednego systemu, który dostosowuje się do rzeczywistych operacji, zamiast narzucania sztywnych procesów. Jej platforma łączy scentralizowaną warstwę danych, workflow bez kodu i analitykę w czasie rzeczywistym, pozwalając firmom na szybkie wdrożenie, integrację z istniejącymi narzędziami i ciągłe ewolucjonowanie operacji bez długich wdrożeń lub kosztownych konsultantów.

Motywacja do budowy DOSS sięga do czasów, kiedy Wiley obserwował, jak oprogramowanie legacy zakłócało działalność jego ojca, a później obaj widzieli podobne problemy podczas pracy 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 w startupie FinTech. Powodem, dla którego nasi klienci – CFO, księgowi itd. – nie wybierali naszego rozwiązania, było to, że byli „zbyt zajęci wdrożeniem systemu ERP”. Gdy zagłębiłem się w ten archaiczny świat ERP, byłam zaskoczony istniejącym modelem wdrożeniowym.

To, co widziałem, było tym samym podstawowym problemem: wdrożenie trwa miesiące lub lata, kosztuje setki tysięcy do milionów dolarów i jest w całości uzależnione od ludzkich konsultantów z godzinową opłatą. Następnie, gdy system ERP jest wdrożony, przestaje się zmieniać. To problem architektoniczny, a nie konfiguracyjny. Nie można go naprawić poprzez łatki.

Jako budowniczy oprogramowania, najbliższe porównanie, które mogłem wymyślić, było następujące: 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 kilku lat przez agencję konsultingową. Następnie, gdy produkt jest gotowy, konsultanci odchodzą bez utrzymania, ulepszeń ani wsparcia. Inżynierowie byliby oburzeni.

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

DOSS prezentuje się jako AI-natywna platforma operacyjna zaprojektowana do zastąpienia tradycyjnych systemów ERP, takich jak SAP lub Oracle (ORCL ). Jakie podstawowe różnice architektoniczne sprawiają, że AI-natywny ERP jest możliwy dzisiaj, a nie był możliwy dekadę temu?

Oracle i SAP zostały zbudowane w erze, w której musiały uprościć płaszczyznę konfiguracyjną systemu ERP, aby umożliwić konsultantom dostarczanie go na dużą skalę. Aby zachować najlepsze praktyki, zablokowali duże fragmenty systemów rdzeniowych i pozwolili na kompozowalność tylko na obrzeżach. W rzeczywistości, gdy spojrzy się na spektrum wszystkich firm na świecie, ich aplikacje biznesowe wymagają maksymalnej elastyczności.

Świat AI-natywny umożliwia transformację inżynierii oprogramowania z rzemiosła w zindustrializowaną maszynę. Nie potrzebujemy już rzemieślników oprogramowania, aby ręcznie tworzyć systemy; zamiast tego, przechodzimy do świata, w którym przepływ oprogramowania jest czynnikiem obliczeń i tokenów.

Doss została zaprojektowana z tym właśnie na uwadze.

Zbudowaliśmy ZSL, deklaracyjny język domenowy (DSL), który opisuje całą implementację DOSS w kodzie. Wyobraź sobie, co „Terraform” zrobił dla wysiłku „Infrastructure as Code”, ale zastosowanego do logiki aplikacji biznesowych. Poprzez opisanie systemów ERP w języku programowania o relatywnie niskiej wymiarowości, jesteśmy w stanie 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 jądrowym planistą, aby podjąć się obciążenia natłoku workflow ERP. Ponadto, zbudowaliśmy system HTAP, który łączy najważniejsze części bazy danych transakcyjnej, takiej jak Postgres, i możliwości analityczne magazynu danych.

Poprzez zbudowanie platformy, aby miała wytrzymałość na poziomie przedsiębiorstwa od samego początku, system jest zaprojektowany do całkowicie agentynej dystrybucji. To, co wcześniej zajmowało zespołom konsultantów miesiące i lata, może teraz być równolegle przetwarzane na dużą skalę przy użyciu agentynej infrastruktury 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 dane biznesowe nie są ujednolicone w jednym źródle prawdy?

Największym problemem jest to, że decyzje są podejmowane na podstawie nieświeżych 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ś zmuszony do ręcznego porównywania, powolnego i po fakcie. Dopóki ktoś nie zorientuje się, że zapasy są nieprawidłowe lub dostawca jest opóźniony, jest to już problem w firmie.

Verve Coffee Roasters to dobry przykład, gdzie to się psuje w praktyce. Prowadzą operacje w sklepach spożywczych, hurtowych, DTC i kawiarniach w Stanach Zjednoczonych i Japonii, ale zarządzają wszystkim tym w systemach rozproszonych 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 dużego uruchomienia detalicznego, co zaszkodziło kluczowej relacji detalicznej. 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 w górę a problemem z realizacją w dół, 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 wykonywaniem ręcznych kontroli zamiast zrozumienia, co tak naprawdę się dzieje. Ujednolicony system nie tylko oszczędza czas na porównywaniu, ale także zmienia to, co możesz nawet zobaczyć i o co możesz zapytać.

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ń o informacje.

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

Tradycyjny model wdrożeniowy jest wynikiem praktyk oprogramowania, które mają dziesiątki lat. Nie żyjemy już w tym świecie.

Istnieje odwrotny bodziec w wdrożeniach ERP dzisiaj – im dłużej trwa wdrożenie i im mniej skuteczne jest, tym więcej pieniędzy otrzymują osoby wdrożeniowe. Większość budowniczych nie skorzystałaby z tego; jednak nigdy nie są zachęcani do pracy tempem 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 to bardzo bolesne. Dla firm z rynku średniego jest to prohibicyjne. Zatem albo godzą się na oprogramowanie, które nie naprawdę pasuje do ich operacji, opóźniają projekt lub porzucają go w połowie.

AI zmienia całkowicie ekonomię jednostkową. Zamiast zaangażowania konsultingowego, wdrożenie DOSS jest kodem. Im więcej czasu mija, tym bardziej możemy wywiązywać się z naszych zobowiązań w modelu „płacisz za dostawę” zamiast „płacisz, jak idziesz”. Gdy firma się zmienia, system również się zmienia. Potrzeba pokoi pełnych konsultantów i długich prezentacji nie jest już istotna.

Sukces w Doss oznacza zastąpienie 1,86 biliona dolarów wydatków na usługi IT na całym świecie agentywnym wdrożeniem i utrzymaniem przy użyciu naszego ZSL jako języka oprogramowania aplikacji biznesowych. Sukces w Doss oznacza komodyfikację 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 się nimi zająć.

Każda firma, z którą pracujemy, nagromadziła lata obejść operacyjnych. Dane technicznie istnieją, po prostu nie mieszczą się w miejscu, w którym ich pracownicy, a nawet agenty, mogliby na nie działać.

Jednym z dobrych przykładów jest niemiecki producent mebli, który tworzy elementy na zamówienie. Gdy weszliśmy, mieli 10 lat danych historycznych rozproszonych w 8 niestandardowych formatach plików z 11 różnymi obiektami danych i synchronizacją 3PL uruchamianą ręcznie przez kopiowanie i wklejanie z folderów FTP. Logika biznesowa była specyficzna z niestandardowymi wymiarami, konfiguracjami, metodami płatności i lokalizacjami salonów, 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ą prostą zmianę opcji konfiguracyjnych, takich jak opcje statusu dla zamówienia.

Wyzwaniem nie jest techniczna złożoność poszczególnych elementów. 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 wziąć dokładny odcisk, jak firma naprawdę działa, a nie mapować ich danych na 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żyteczne 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 AI-kopilotów i autonomicznych agentów w oprogramowaniu biznesowym. Gdzie widzisz AI dodając najwięcej wartości w workflow operacyjnych dzisiaj, a gdzie nadzór ludzki pozostaje niezmiennie istotny?

W skali, AI ma możliwość zakłócić wszystkie prace operacyjne.

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

Najbardziej oczywistą wartością dzisiaj jest coś bardziej specyficznego 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 kierowanie decyzjami 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ę.

Dla teraz 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 odpowiednim modelem nie jest zastąpienie decyzji ludzkich agentami w całości; jest to obsługa przez agenci pracy o dużej objętości i dobrze zdefiniowanej, aby ludzie mogli się skoncentrować na decyzjach, które naprawdę wymagają ich osądu.

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

Systemy legacy nie zostały zbudowane, aby AI mogło je rozumieć. Modele danych, API, sposób, w jaki informacje są strukturyzowane, wszystko to zostało zaprojektowane dla interakcji ludzi za pośrednictwem interfejsów. Gdy próbujesz nałożyć AI na to, prosisz je, aby pracowało wokół ograniczeń, które nie były przeznaczone do pracy.

Nawet jeśli spróbujesz umieścić serwer MCP na górze, w rzeczywistości serwer MCP wymaga bardzo specyficznych wzorców projektowych. Większość serwerów MCP dzisiaj wprowadza większy rozrzut okna kontekstowego i pogarsza wydajność.

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 zweryfikować. 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 po to, aby konfiguracja była właściwym kodem: czytelnym, testowalnym i wdrażalnym w zamkniętym systemie. Budujemy w pełni agentywny cykl życia rozwoju oprogramowania (SDLC). To jest przesłanka do tego, aby AI mogło naprawdę działać na systemie, a nie tylko siedzieć na nim.

Jak AI staje się w stanie generować workflow i wchodzi w interakcje z systemami operacyjnymi, jak zmieni się interfejs tradycyjnego oprogramowania przedsiębiorstwa?

Pytanie o interfejs jest naprawdę o to, kto potrzebuje używać systemu. Obecnie 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 komponowalny interfejs, który traktuje interfejs jak budowniczy strony internetowej. Interfejs sam w sobie jest również wspierany przez zamknięty ZSL. Każdy, CFO, menedżer magazynu, analityk łańcucha dostaw, otrzymuje pulpit nawigacyjny 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ą workflow, interfejs staje się mniej o wejściu danych, a bardziej o widoczności i podejmowaniu decyzji. Potrzebujesz zobaczyć, co się dzieje, zrozumieć dlaczego, i podjąć decyzje. Oprogramowanie powinno zajmować się resztą.

Startupy takie jak DOSS wkraczają na rynek zdominowany przez dziesięciolecia stare firmy. Jakie przewagi mają AI-natywne startupy, gdy konkurują z ugruntowanymi platformami przedsiębiorstwa?

Ugruntowane firmy 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; jest 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 konkretną 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 dochodu źródłowego jest nie do przyjęcia dla dużych firm ugruntowanych.

System AI-natywny może być zaprojektowany od samego początku tak, aby AI było częścią architektury podstawowej, 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 pełnoprawnym uczestnikiem. To jest przewaga kumulatywna, gdzie każde wdrożenie sprawia, że system staje się lepszy, a agenci wdrożeniowi stają się bardziej zdolni przy każdym nowym kliencie. Tego rodzaju pętla poprawy nie istnieje w systemie, w którym wdrożenie nadal jest zaangażowaniem konsultingowym.

Spójrzając w przyszłość, jak wyobrażasz sobie transformację „systemu operacyjnego” firmy 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 zautomatyzowane operacje?

Założyliśmy DOSS na przekonaniu, że systemy przedsiębiorstwa 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 przy każdym wdrożeniu.

Kierunek, w którym to zmierza, to system, który jest zawsze zsynchronizowany z firmą. Dzisiaj, luka 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 luka zostaje zamknięta, gdy system dostosowuje się w czasie rzeczywistym, gdy firma się zmienia, jest inna kategoria zdolności operacyjnej. Widoczność w czasie rzeczywistym nie jest tylko szybszym raportowaniem; jest to możliwość przechwycenia zakłóceń łańcucha dostaw, zanim staną się one awarią realizacji. Zautomatyzowane operacje nie są tylko kwestią wydajności; jest to możliwość prowadzenia bardziej złożonej firmy z tym samym zespołem. To wersja oprogramowania operacyjnego, którą budujemy.

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