Arnav Mishra, Co-Founder dan CTO dari Doss – Seri Wawancara

Arnav Mishra, Co-Founder dan CTO dari Doss, adalah insinyur full-stack dan pemimpin teknis dengan latar belakang yang mencakup startup tahap awal dan sistem infrastruktur skala besar. Sebelum menjadi co-founder Doss, ia adalah insinyur pendiri di Siteline, di mana ia membangun sistem inti termasuk arsitektur izin, integrasi ERP, dan kerangka kerja otomatisasi, sambil juga berkontribusi pada perekrutan, operasi pendapatan, dan budaya perusahaan. Pada awal karirnya, ia memegang posisi insinyur di Rubrik dan magang di perusahaan seperti Uber dan VMware, mengembangkan keahlian di infrastruktur cloud, sistem data, dan otomatisasi. Selain pekerjaannya di bidang teknis, ia telah terlibat aktif dalam mentorship dan pengembangan bakat melalui organisasi seperti Techquitable Futures dan Contrary, mencerminkan komitmen yang lebih luas untuk mendukung generasi insinyur berikutnya.

Doss adalah perusahaan perangkat lunak modern yang fokus pada mereinventasi sistem ERP tradisional melalui Adaptive Resource Platform (ARP), platform operasional yang fleksibel dan asli AI yang dirancang untuk mempersatukan dan mengotomatisasi alur kerja bisnis. Dibangun sebagai alternatif komposabel untuk solusi ERP warisan, Doss memungkinkan perusahaan untuk mengelola inventori, pengadaan, keuangan, dan pengiriman dalam satu sistem yang beradaptasi dengan operasi dunia nyata daripada memaksa proses kaku. Platform ini menggabungkan lapisan data terpusat, alur kerja tanpa kode, dan analitik waktu nyata, memungkinkan bisnis untuk mengirimkan dengan cepat, mengintegrasikan dengan alat yang ada, dan terus mengembangkan operasional tanpa implementasi yang lama atau konsultan yang mahal.

Motivasi untuk membangun DOSS berasal dari Wiley yang melihat perangkat lunak warisan mengganggu bisnis manufaktur ayahnya, dan keduanya kemudian melihat masalah serupa secara langsung saat bekerja dengan pabrik dan rantai pasokan perangkat keras. Bagaimana pengalaman tersebut membentuk keputusan Anda untuk menjadi co-founder DOSS dan merancang ulang sistem ERP dari awal?

Sebelum DOSS, saya adalah insinyur pendiri di sebuah startup FinTech. Alasan #1 mengapa pembeli kami – CFO, Akuntan, dll – tidak akan menggunakan solusi kami adalah karena mereka “terlalu sibuk mengimplementasikan ERP”. Ketika saya menyelidiki lebih dalam ke tanah ERP yang kuno, saya terkejut dengan model implementasi yang ada.

Apa yang saya lihat adalah kegagalan fundamental yang sama: implementasi membutuhkan waktu berbulan-bulan atau bertahun-tahun, biaya ratusan ribu hingga jutaan dolar, dan terhalang sepenuhnya oleh konsultan manusia dengan tagihan per jam. Kemudian, setelah ERP dikirim, itu berhenti berubah. Bisnis terus berkembang; sistem tidak. Itu adalah masalah arsitektur, bukan masalah konfigurasi. Anda tidak bisa memperbaikinya dengan patch.

Sebagai pembangun perangkat lunak, perbandingan terdekat yang bisa saya pikirkan adalah sebagai berikut: bayangkan sebuah dunia di mana alat paling penting yang Anda gunakan – sebagai pengembang, katakanlah GitHub – dibangun khusus untuk perusahaan Anda selama bertahun-tahun oleh agen konsultasi pihak ketiga. Kemudian, setelah produk selesai, konsultan meninggalkan tanpa pemeliharaan, perbaikan fitur, dan dukungan. Insinyur akan memberontak.

Tidak ada perusahaan teknologi modern yang bisa beroperasi dengan model seperti itu. Wiley dan saya sama-sama menyimpulkan bahwa satu-satunya cara untuk memperbaikinya adalah dengan membangun dari awal.

DOSS memposisikan diri sebagai platform operasional asli AI yang dirancang untuk menggantikan sistem ERP tradisional seperti SAP atau Oracle. Apa perbedaan arsitektur fundamental yang membuat ERP asli AI memungkinkan hari ini yang tidak memungkinkan satu dekade yang lalu?

Oracle dan SAP dibangun di era di mana, untuk mencapai distribusi yang dimaksimalkan, mereka perlu menyederhanakan bidang konfigurasi ERP menjadi editor berbasis GUI yang relatif non-teknis yang dapat dikirimkan oleh konsultan secara besar-besaran. Untuk melestarikan praktik terbaik, mereka mengunci sebagian besar sistem inti dan hanya memungkinkan komposabilitas di tepi. Namun, dalam kenyataan, ketika Anda melihat spektrum semua bisnis di dunia, aplikasi bisnis mereka membutuhkan fleksibilitas maksimal.

Apa yang dunia asli AI enable adalah transformasi rekayasa perangkat lunak dari kerajinan menjadi mesin industri. Kami tidak lagi memerlukan pengrajin perangkat lunak untuk membuat sistem kode; sebaliknya, kami bergerak menuju dunia di mana throughput perangkat lunak adalah faktor komputasi dan token.

Doss telah dirancang dengan tepat ini dalam pikiran.

Kami membangun ZSL, bahasa domain khusus deklaratif (DSL) yang menjelaskan implementasi Doss pelanggan secara keseluruhan dalam kode. Pikirkan apa yang “Terraform” lakukan untuk upaya Infrastruktur sebagai Kode, tetapi diterapkan pada logika aplikasi bisnis. Dengan mendefinisikan ERP dalam bahasa pemrograman relatif rendah-dimensi, kami dapat mengirimkan agen secara besar-besaran untuk mengirimkan solusi ERP.

Setelah ZSL ditulis, bagian paling penting dari arsitektur adalah memasukkan praktik terbaik ke dalam platform itu sendiri untuk mencegah agen membangun implementasi berkualitas rendah. Tim kami telah mengirimkan sistem terdistribusi yang dapat diskalakan dengan scheduler inti untuk mengambil beban kerja ERP yang berubah-ubah. Selain itu, kami membangun sistem database HTAP yang menggabungkan bagian paling penting dari database transaksional seperti Postgres dan kemampuan analitis dari Gudang Data.

Dengan membangun platform untuk memiliki kekuatan kelas perusahaan sejak awal, sistem ini disiapkan untuk distribusi agen sepenuhnya. Apa yang dulunya membutuhkan waktu berbulan-bulan atau bertahun-tahun untuk dilakukan oleh tim konsultan sekarang dapat diparalelisasi secara besar-besaran menggunakan infrastruktur agen dalam sistem loop tertutup kami.

Banyak perusahaan masih mengandalkan spreadsheet dan alat terfragmentasi untuk pengadaan, inventori, dan manajemen pesanan. Apa blind spot operasional terbesar yang muncul ketika data bisnis inti tidak disatukan menjadi satu sumber kebenaran?

Masalah paling umum adalah bahwa keputusan dibuat berdasarkan informasi yang sudah ketinggalan atau tidak lengkap. Jika data inventori Anda hidup di satu tempat, pesanan pembelian di tempat lain, dan pesanan penjualan di tempat ketiga, Anda selalu melakukan rekonsiliasi, secara manual, lambat, dan setelah fakta. Ketika seseorang menyadari inventori salah atau supplier tertinggal, itu sudah menjadi masalah dalam bisnis.

Verve Coffee Roasters adalah contoh yang baik di mana ini rusak dalam praktek. Mereka menjalankan operasi di seluruh grosir, wholesale, DTC, dan kafe di AS dan Jepang, tetapi mengelola semuanya di sistem yang terputus dengan tidak ada visibilitas inventori waktu nyata. Mereka kehabisan kopi mereka sendiri di lokasi lalu lintas tinggi dan mengalami stok kritis selama peluncuran ritel besar yang merusak hubungan ritel kunci. Data itu ada di suatu tempat; itu hanya tidak terhubung dengan cara yang memungkinkan siapa pun untuk bertindak tepat waktu.

Masalah yang lebih halus adalah bahwa fragmentasi menyembunyikan bentuk sebenarnya dari operasi Anda. Anda tidak bisa melihat hubungan antara keterlambatan di hulu dan masalah pengiriman di hilir jika kedua hal tersebut hidup dalam alat yang terpisah. Anda berakhir dengan mengelola gejala, mempercepat pesanan, membangun stok pengaman, dan menjalankan pemeriksaan manual daripada memahami apa yang sebenarnya terjadi. Sistem yang terunifikasi tidak hanya menyelamatkan waktu pada rekonsiliasi. Ini mengubah apa yang bisa Anda lihat dan tanyakan.

Pada intinya, bayangkan menjalankan bisnis perusahaan tanpa akses ke sistem kontrol versi (Git), alat observabilitas (DataDog), atau database terpusat untuk mengquery informasi.

Implementasi ERP secara historis memerlukan tim konsultan besar dan bulan – atau bahkan tahun – pengiriman. Bagaimana AI mengubah ekonomi dan kompleksitas implementasi perangkat lunak operasional di dalam bisnis nyata?

Model implementasi tradisional adalah hasil emergen dari praktik perangkat lunak yang berusia beberapa generasi. Kami tidak lagi hidup di dunia itu.

Ada insentif yang menyimpang dalam implementasi ERP hari ini – semakin lama implementasi dan semakin tidak efektif, semakin banyak uang yang diterima oleh pelaksana. Sebagian besar pembangun tidak akan memanfaatkan ini; namun, mereka tidak pernah termotivasi untuk bergerak dengan kecepatan dan kualitas.

Selain itu, rasio pengeluaran konsultasi terhadap pengeluaran perangkat lunak dalam keterlibatan ERP tradisional berjalan sekitar 9:1, sehingga Anda menghabiskan sembilan dolar untuk konsultan untuk setiap dolar yang Anda habiskan untuk perangkat lunak itu sendiri. Untuk perusahaan besar, itu sangat menyakitkan. Untuk bisnis pasar menengah, itu menghambat. Jadi mereka baik-baik saja dengan perangkat lunak yang tidak benar-benar sesuai dengan cara mereka beroperasi, menunda proyek, atau meninggalkannya di tengah jalan.

AI mengubah ekonomi unit ini sepenuhnya. Sebagai gantinya untuk keterlibatan konsultasi, implementasi Doss adalah basis kode. Ketika waktu implementasi kami terus menyusut, kami dapat menyelaraskan insentif dengan model “bayar pada pengiriman” daripada “bayar saat Anda pergi”. Ketika bisnis berubah, sistem berubah dengannya. Kebutuhan akan ruang konsultan dan slide deck panjang tidak lagi relevan.

Keberhasilan di Doss berarti menggantikan pengeluaran jasa TI global sebesar $1,86 triliun dengan implementasi dan pemeliharaan agen menggunakan ZSL sebagai bahasa untuk perangkat lunak aplikasi bisnis. Keberhasilan di Doss adalah mengkomoditisasi semua aplikasi bisnis secara besar-besaran.

Anda telah mengirimkan Doss dengan perusahaan yang beroperasi di lingkungan dunia nyata seperti manufaktur, logistik, dan barang konsumsi. Apa tantangan yang tidak terduga yang muncul ketika AI bertemu dengan data operasional yang kacau?

Tantangan itu jarang AI. Ini adalah data yang Anda minta untuk bernalar tentang.

Setiap bisnis yang kami kerjakan telah mengumpulkan tahun-tahun pekerjaan operasional. Data secara teknis ada, itu hanya tidak hidup di mana pun karyawan, apalagi sistem agen, dapat bertindak secara andal.

Salah satu contoh yang bagus adalah produsen furnitur Jerman yang membuat potongan buatan. Ketika kami datang, mereka memiliki 10 tahun data sejarah yang tersebar di 8 format file khusus dengan 11 objek data yang berbeda dan sinkronisasi 3PL yang berjalan pada salinan manual dari folder FTP. Logika bisnisnya spesifik dengan dimensi khusus, konfigurasi, metode pembayaran, dan lokasi showroom, dan seluruh sistem perlu berfungsi dalam bahasa Jerman. Tidak ada skema siap pakai untuk itu. Mereka harus membayar ribuan euro setiap kali mereka ingin mengubah opsi konfigurasi sederhana, seperti opsi status untuk pesanan pembelian.

Tantangan bukanlah kompleksitas teknis dari setiap bagian. Ini adalah bahwa setiap bisnis memiliki versi yang berbeda dari masalah ini, dan Anda tidak dapat sepenuhnya mengantisipasinya sampai Anda berada di dalam data mereka. Pekerjaan adalah mengambil cetakan akurat tentang bagaimana bisnis sebenarnya beroperasi, bukan memetakan data mereka ke dalam template generik dan berharap itu sesuai.

Untuk membangun solusi yang bekerja untuk dunia nyata, Anda memerlukan platform dengan fleksibilitas maksimum. Hanya kemudian AI dapat berguna dalam memahami model data yang mendasarinya dan membangun model yang bekerja untuk setiap pelanggan.

Ada banyak diskusi tentang kopilot AI dan agen otonom dalam perangkat lunak bisnis. Di mana Anda melihat AI menambahkan nilai terbesar dalam alur kerja operasional hari ini, dan di mana pengawasan manusia masih tetap penting?

Pada skala, AI memiliki kemampuan untuk mengganggu semua pekerjaan operasional.

Dalam cakrawala dekat, model dan agen Doss harus dapat mengubah inti konsultan teknis dalam mengimplementasikan aplikasi bisnis serta konsultan manajemen dalam memberikan rekomendasi strategis. Doss akan memiliki repositori terstruktur dan terkait terbesar yang mewakili skema dan informasi operasional untuk bisnis. Agen kami dapat menggunakan data itu untuk memberikan rekomendasi yang dapat diskalakan.

Nilai paling jelas hari ini lebih spesifik daripada itu. Ini ada dalam pekerjaan yang berulang, berbasis aturan, dan saat ini dilakukan oleh orang-orang yang memiliki prioritas strategis lain: memproses pesanan pembelian, merekonsiliasi inventori, dan mengarahkan keputusan pengiriman. Tugas-tugas ini memiliki input dan output yang terdefinisi dengan baik, dan AI dapat menanganinya secara andal pada skala besar.

Untuk saat ini, pengawasan manusia penting di mana biaya keputusan yang salah tinggi, dan sistem belum memiliki konteks yang cukup untuk percaya diri. Hari ini, model yang tepat bukanlah agen otonom yang menggantikan pengambilan keputusan manusia secara keseluruhan; itu adalah agen yang menangani pekerjaan volume tinggi, terdefinisi dengan baik sehingga orang dapat fokus pada keputusan yang sebenarnya memerlukan penilaian mereka.

Banyak perusahaan mencoba melapisan AI di atas tumpukan perangkat lunak yang ada. Menurut Anda, mengapa memasang sistem warisan dengan AI sering kali gagal dibandingkan dengan membangun AI secara langsung ke dalam fondasi platform?

Sistem warisan tidak dibangun untuk dipahami oleh AI. Model data, API, cara informasi disusun, semuanya dirancang untuk interaksi manusia melalui antarmuka. Ketika Anda mencoba melapisan AI di atasnya, Anda meminta AI untuk bekerja di sekitar keterbatasan yang tidak dimaksudkan untuk bekerja di sekitarnya.

Bahkan jika Anda mencoba melemparkan server MCP di atasnya, dalam kenyataan, server MCP memerlukan pola desain yang sangat spesifik. Sebagian besar server MCP saat ini sebenarnya memperkenalkan bloat jendela konteks yang lebih besar dan meledakkan kinerja.

Namun, masalah yang lebih dalam adalah model implementasi. Dalam ERP tradisional, konfigurasi sistem disimpan dalam sistem itu sendiri. Ini bukan kode yang dapat dibaca, diuji, atau di versi. Tidak ada cara bagi agen untuk memahami apa yang dilakukan sistem, apalagi mengubahnya dengan aman. Kami membangun ZSL secara khusus sehingga konfigurasi adalah basis kode yang tepat: dapat dibaca, diuji, dan diterapkan dalam sistem loop tertutup. Kami sedang membangun siklus pengembangan perangkat lunak agen sepenuhnya. Itu adalah prasyarat untuk AI untuk benar-benar beroperasi pada sistem daripada hanya duduk di atasnya.

Bagaimana Anda melihat antarmuka perangkat lunak perusahaan tradisional akan berkembang ketika AI dapat menghasilkan alur kerja dan berinteraksi secara langsung dengan sistem operasional?

Pertanyaan antarmuka sebenarnya tentang siapa yang perlu menggunakan sistem. Saat ini, antarmuka ERP dibangun di sekitar sejumlah kecil pengguna kuat, orang-orang yang dilatih pada sistem selama implementasi. Semua orang lain baik tidak dapat menggunakannya atau mendapatkan versi yang terdegradasi.

Apa yang kami bangun adalah antarmuka komposabel, yang memperlakukan antarmuka seperti pembangun situs web. Antarmuka itu sendiri juga didukung oleh loop tertutup ZSL. Setiap orang, CFO, manajer gudang, analis rantai pasokan, mendapatkan dasbor dan tampilan data yang disusun di sekitar cara mereka benar-benar bekerja, bukan di sekitar cara perangkat lunak dikonfigurasi. Ketika AI menangani lebih banyak eksekusi alur kerja yang mendasarinya, antarmuka menjadi kurang tentang entri data dan lebih tentang visibilitas dan pengambilan keputusan. Anda perlu melihat apa yang terjadi, memahami mengapa, dan membuat keputusan penilaian. Perangkat lunak harus menangani sisanya.

Startup seperti DOSS memasuki pasar yang didominasi oleh pendahulu yang berusia beberapa dekade. Apa kelebihan yang dimiliki startup asli AI ketika bersaing dengan platform perusahaan yang mapan?

Pendahulu memiliki masalah yang berlawanan dengan startup. Mereka memiliki basis yang dipasang yang besar untuk dilindungi. Setiap keputusan arsitektur yang mereka buat harus kompatibel ke belakang. Mereka dapat menambahkan fitur AI ke produk yang ada, tetapi mereka tidak dapat membangun kembali sistem yang mendasarinya tanpa merusak semua yang berjalan di atasnya. Itu bukan kegagalan ambisi; itu struktural.

Dalam ERP secara khusus, mereka juga dibebani dengan keputusan bisnis yang mengarah mereka ke jalur di mana pendapatan didorong dari fungsi spesifik yang DOSS cari untuk menghilangkan – konsultan jasa profesional. Mengingat pengguna menghabiskan sembilan dolar untuk konsultan untuk setiap dolar yang mereka habiskan untuk perangkat lunak itu sendiri, kemampuan untuk mengubah 90% dari pendapatan sumber mereka tidak dapat diterima untuk pendahulu besar.

Sistem asli AI dapat dirancang dari awal sehingga AI adalah bagian dari arsitektur inti, bukan lapisan di atasnya. Model implementasi, model data, dan cara konfigurasi bekerja semua dirancang dengan AI sebagai peserta kelas satu. Itu adalah kelebihan yang menggandakan di mana setiap pengiriman membuat sistem lebih baik, dan agen implementasi menjadi lebih mampu dengan setiap pelanggan baru. Loop perbaikan seperti itu tidak ada dalam sistem di mana implementasi masih merupakan keterlibatan konsultasi manusia.

Menghadap ke depan, bagaimana Anda membayangkan AI mengubah “sistem operasi” bisnis selama lima hingga sepuluh tahun ke depan, terutama dalam bidang seperti visibilitas rantai pasokan, pengambilan keputusan waktu nyata, dan operasi yang diotomatisasi?

Kami mendirikan DOSS dengan keyakinan bahwa sistem perusahaan akan dapat membangun diri mereka sendiri. Tiga tahun kemudian, kami telah memasuki Fase 2 dari Doss: implementasi mandiri agen. Platform sudah dapat menghasilkan, memvalidasi, dan mengembangkan sistem pelanggan daripada mengandalkan konfigurasi konsultan manual, dan itu menjadi lebih baik dengan setiap pengiriman.

Arah ini menuju sistem yang selalu sejalan dengan bisnis. Hari ini, celah antara cara bisnis beroperasi dan apa yang sistem ketahui tentang itu adalah bulan atau tahun. Sistem dikonfigurasi pada titik waktu dan tidak berubah sejak itu. Apa yang menjadi memungkinkan ketika celah itu ditutup, ketika sistem beradaptasi secara real-time ketika bisnis berubah, adalah kategori kemampuan operasional yang berbeda. Visibilitas waktu nyata bukan hanya pelaporan yang lebih cepat; itu adalah kemampuan untuk menangkap gangguan pasokan sebelum menjadi kegagalan pengiriman. Operasi yang diotomatisasi bukan hanya tentang efisiensi; itu adalah kemampuan untuk menjalankan bisnis yang lebih kompleks dengan tim yang sama. Itu adalah versi perangkat lunak operasional yang kami bangun menuju.

Terima kasih atas tanggapan yang terperinci, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi Doss.