Arnav Mishra, Dossin perustaja ja CTO – Haastattelu

Arnav Mishra, Dossin perustaja ja CTO, on full-stack -ohjelmistokehittäjä ja tekninen johtaja, jolla on tausta varhaisessa start-up -vaiheessa ja suurten infrastruktuurijärjestelmien parissa. Ennen Dossin perustamista hän oli perustajajäsen Sitelinessa, jossa hän rakensi ydinjärjestelmiä, kuten käyttöoikeusarkkitehtuuri, ERP-integraatiot ja automaatiokehykset, ja osallistui myös rekrytointiin, liiketoimintaprosessien kehittämiseen ja yrityskulttuuriin. Uransa alussa hän työskenteli insinöörinä Rubrikissa ja harjoittelijana Uberissa ja VMwaressa, kehittäen osaamistaan pilvi-infrastruktuurissa, tietojärjestelmissä ja automaatiossa. Ohjelmistokehityksen ohella hän on ollut mukana mentoroinnissa ja kykyjen kehittämisessä organisaatioissa kuten Techquitable Futures ja Contrary, osoittaen sitoutumista tukemaan seuraavan sukupolven insinöörejä.

Doss on moderni enterprise-ohjelmistoyritys, joka keskittyy perinteisten ERP-järjestelmien uudelleenluomiseen Adaptive Resource Platform (ARP) -alustalla, joka on joustava, AI-ominaisuuksilla varustettu operatiivinen alusta, joka on suunniteltu yhdistämään ja automatisoimaan liiketoimintaprosesseja. Rakennettu komponenttipohjaisena vaihtoehtona perinteisille ERP-ratkaisuille, Doss mahdollistaa yritysten hallinnoida varastoja, hankintoja, taloutta ja toimituksia yhdessä järjestelmässä, joka mukautuu todellisiin liiketoimintaprosesseihin eikä pakota joustamattomia prosesseja. Sen alusta yhdistää keskitetyn tietokerroksen, koodittomat työnkulut ja reaaliaikaisen analytiikan, jolloin yritykset voivat ottaa nopeasti käyttöön, integroida olemassa oleviin työkaluihin ja jatkuvasti kehittää liiketoimintaprosessejaan ilman kalliita konsultteja tai pitkiä toteutusjaksoja.

Mikä oli motiivi Dossin rakentamiselle, ja miten aikaisemmat kokemukset vaikuttivat päätökseenne uudelleenmuokata ERP-järjestelmiä alusta alkaen?

Ennen Dossia olin perustajajäsen FinTech-startupissa. Ostajamme – CFO, kirjanpitäjä jne – eivät hyväksyneet ratkaisuamme, koska he olivat “liian kiireisiä” toteuttamaan ERP-järjestelmää. Kun tutkin vanhanaikaisen ERP-maailman syvemmälle, olin hämmästynyt olemassa olevasta toteutusmallista.

Mitä enemmän tutkin, sitä enemmän näin saman perusongelman: toteutus kestää kuukausia tai vuosia, maksaa satoja tuhansia tai miljoonia dollareita, ja se on täysin riippuvainen ihmiskonsulteista, jotka laskuttavat tuntityöstä. Sitten, kun ERP on valmis, se lopettaa kehittymisen. Liiketoiminta jatkaa evoluutiota; järjestelmä ei. Tämä on arkkitehtoninen ongelma, ei konfiguraatio-ongelma. Et voi korjata sitä päällekkäisyyksillä.

Ohjelmistokehittäjänä lähin vertailukohta, jonka voisin ajatella, oli seuraava: kuvittele maailma, jossa tärkein työkalu, jonka käytät – esimerkiksi GitHub – on rakennettu vain yrityksesi tarpeisiin usean vuoden ajan ulkopuolisen konsultointitoimiston toimesta. Sitten, kun tuote on valmis, konsultit lähtevät ilman ylläpitoa, ominaisuusparannuksia tai tukea. Insinöörit kapinoisivat.

Wiley ja minä tulimme samaan johtopäätökseen: ainoa tapa korjata se oli rakentaa alusta alkaen.

DOSS esittää itsensä AI-ominaisuuksilla varustettuna operatiivisena alustana, joka on suunniteltu korvaamaan perinteiset ERP-järjestelmät kuten SAP tai Oracle (ORCL ). Mitkä ovat perustavanlaatuiset arkkitehtoniset erot, jotka tekevät AI-ominaisuuksilla varustetun ERP:n mahdolliseksi tänään, eivätkä olleet toteutettavissa vuosikymmen sitten?

Oracle ja SAP on rakennettu aikakauteen, jolloin heidän oli saavutettava maksimoida jakelu, ja heidän oli yksinkertaisuttava ERP:n konfiguraatiotasoa GUI-pohjaiseksi editoriksi, jonka suhteellisen ei-tekniikkaa taitavat konsultit voivat toimittaa laajamittaisesti. Jotta he voisivat säilyttää parhaat käytännöt, he lukitsivat suuria osia ydinsysteemeistä ja sallivat komposabiliteetin vain reunoilla. Todellisuudessa, kun tarkastelet liiketoimintasovellusten spektriä maailmassa, niiden liiketoimintasovellusten on oltava maksimaalisesti joustavia.

Mitä AI-ominaisuuksilla varustettu maailma mahdollistaa, on ohjelmistokehityksen muuttuminen käsityöstä teolliseksi koneeksi. Emme enää tarvitse ohjelmistokäsityöläisiä koodijärjestelmien rakentamiseen; sen sijaan siirrymme maailmaan, jossa ohjelmistotuotanto on laskettavissa laskentakapasiteetista ja tokenien määrästä.

Doss on suunniteltu tämän mukaisesti.

Rakensimme ZSL:n, joka on deklaratiivinen, domeenispesifinen kieli (DSL), joka kuvaa asiakkaan koko Doss-toteutuksen koodina. Ajattele, mitä “Terraform” teki infrastruktuurin koodipohjaiselle pyrkimykselle, mutta sovellettu liiketoimintalogiikkaan. Määrittelemällä ERP-järjestelmät suhteellisen matalan dimensiotasoisella ohjelmointikielellä voimme ottaa käyttöön agenteja laajamittaisesti toimittamaan ERP-ratkaisuja.

Kun ZSL oli kirjoitettu, tärkein osa arkkitehtuuria oli sisällyttää parhaat käytännöt itse alustaan estämään agenteja rakentamasta matalan laatuisia toteutuksia. Tiimimme on toimittanut skaalautuvan, hajautetun järjestelmän, jossa on ydin tasolla ajoitettu aikataulu, joka ottaa vastaan ERP-työn kuormituksen. Lisäksi rakensimme HTAP-tietokanta järjestelmän, joka yhdistää yhteen tärkeimmät osat transaktiokannasta, kuten Postgres, ja analytiikan kyvyt, kuten Data Warehouse.

Rakentamalla alustan, jolla on yritystason vahvuus alusta alkaen, järjestelmä on asetettu täysin agenteille jakeluun. Se, mitä aiemmin vaati konsulttitiimien kuukausia ja vuosia, voidaan nyt rinnakkaistaa skaalattavasti agenteilla suljetussa järjestelmässä.

Monet yritykset luottavat edelleen taulukkolaskentaohjelmiin ja hajanaisiin työkaluihin hankinnan, varastoinnin ja tilausten hallintaan. Mitkä ovat suurimmat operatiiviset heikkoudet, jotka johtuvat siitä, että keskeiset liiketoimintatiedot eivät ole yhdistetty yhteen totuuden lähteeseen?

Suurin ongelma on, että päätöksiä tehdään vanhentuneella tai epätäydellisellä tiedolla. Jos varastotiedot sijaitsevat eräässä paikassa, ostotilaukset toisessa ja myyntitilaukset kolmannessa, joudut aina sovittamaan, manuaalisesti, hitaasti ja jälkikäteen. Kun joku tajuaa, että varastot ovat väärin tai toimittaja on myöhässä, se on jo ongelma liiketoiminnassa.

Verve Coffee Roasters on hyvä esimerkki siitä, miten tämä menee käytännössä pieleen. He operoivat toimintaa kaupassa, tukkukaupassa, suoraan asiakkaille ja kahviloissa Yhdysvalloissa ja Japanissa, mutta he hallinnoivat sitä erillään olevissa järjestelmissä ilman reaaliaikaista varastotietoa. He loppuivat omasta kahvistaan suurten liikenteen paikoissa ja osuivat kriittisiin varastopulaan keskeisen jälleenmyyjän lancen aikana, mikä vahingoitti tärkeää jälleenmyyntisuhdetta. Tiedot olivat olemassa jossakin, mutta eivät olleet yhdistettyjä tavalla, joka olisi mahdollistanut toimimisen ajoissa.

Hienovaraisempi ongelma on, että fragmentaatio piilottaa liiketoiminnan todellisen muodon. Et voi nähdä suhdetta viiveen ja toimitusongelman välillä, jos ne asioita sijaitsevat eri työkaluissa. Päädyt hallitsemaan oireita, kiirehtimään tilauksia, rakentamaan turvavaroja ja suorittamaan manuaalisia tarkastuksia ymmärtämisen sijaan, mitä todella tapahtuu. Yhdistetty järjestelmä ei pelkästään säästä aikaa sovittamisessa, vaan se muuttaa sitä, mitä voit edes kysyä.

Ydinasiassa, kuvittele johtavan yrityksen liiketoimintaa ilman pääsyä versiohallintajärjestelmään (Git), havainnollistamistyökaluun (DataDog) tai keskitettyyn tietokantaan, josta voit hakea tietoa.

ERP-toteutukset ovat historiallisesti vaatineet suuria konsulttitiimejä ja kuukausia tai jopa vuosia kestävää toteutusta. Miten AI muuttaa operatiivisen ohjelmistojen taloudellisia ja kompleksisuutta yrityksissä?

Perinteinen toteutusmalli on vanhan ohjelmistokehityksen käytännön seuraus. Emme enää elä siinä maailmassa.

On olemassa perverssi kannustimien toteutuksessa ERP-järjestelmissä tänään – mitä kauemmin toteutus kestää ja mitä vähemmän se on tehokas, sitä enemmän toteuttajat saavat rahaa. Suurin osa rakentajista ei hyödy tästä; kuitenkin he eivät koskaan ole kannustettuja liikkumaan nopeasti ja laadukkaasti.

Lisäksi konsultointikustannusten suhde ohjelmistokustannuksiin perinteisessä ERP:ssä on noin 9:1, joten sinun on maksettava yhdeksän dollaria konsulteille jokaista dollaria, jonka sinä maksat itse ohjelmistosta. Suurille yrityksille se on erittäin kivulias. Keskitason yrityksille se on esteettä.

AI muuttaa tämän kokonaan. Sen sijaan, että toteutus olisi konsultointiprojekti, Doss-toteutus on koodipohjainen. Kun toteutusajat jatkuvasti lyhenevät, voimme kohdistaa kannustimet “toimitusperusteiseen” malliin “maksa ja mene” -mallin sijaan. Kun liiketoiminta muuttuu, järjestelmä muuttuu sen mukana. Tarve konsulttien huoneille ja pitkille diaesityksille ei ole enää relevantti. Onnistuminen Dossissa tarkoittaa korvaamista 1,86 biljoonan dollarin globaalia IT-palveluiden menoa agenteilla toteutetuilla ja ylläpidetyillä ratkaisuilla ZSL:llä liiketoimintasovellusten ohjelmistokielenä. Onnistuminen Dossissa tarkoittaa liiketoimintasovellusten kommodisointia laajamittaisesti.

Olette toteuttanut Dossin yrityksissä, jotka toimivat todellisissa ympäristöissä, kuten valmistuksessa, logistiikassa ja kulutushyödykkeissä. Mitkä ovat odottamattomia haasteita, jotka johtuvat siitä, kun AI kohtaa sekavat operatiiviset tiedot?

Haaste ei ole itse AI, vaan se tieto, josta pyydät sitä päättämään. Jokainen yritys, jossa työskentelemme, on kerryttänyt vuosien varrella operatiivisia kiertoteitä. Tiedot ovat teknisesti olemassa, mutta eivät sellaisessa muodossa, jossa niiden voi luotettavasti toimia.

Yksi hyvä esimerkki on saksalainen kalustevalmistaja, joka valmistaa tilauksesta tehtyjä tuotteita. Kun tulin sisään, heillä oli 10 vuoden historiatiedot jaoteltuna kahdeksaan mukautettuun tiedostomuotoon, 11 eri tietokohteella ja 3PL-synkronoinnilla, joka suoritettiin manuaalisesti kopioimalla ja liittämällä FTP-kansioista. Liiketoimintalogiikka oli spesifinen, ja siinä oli mukana mukautettuja mittoja, konfiguraatioita, maksutapoja ja näyttelysijainteja, ja koko järjestelmän piti toimia saksaksi. Siinä ei ollut valmiita skeemoja. Heidän piti maksaa tuhansia euroja joka kerta, kun he halusivat muuttaa yksinkertaisia konfiguraatiovaihtoehtoja, kuten tilausten tilatietoja.

Haaste ei ole yksittäisen osan tekninen monimutkaisuus. Se on, että jokaisella yrityksellä on oma versio tätä ongelmaa, eikä sitä voi täysin ennakoida, kunnes olet heidän tietojärjestelmissään. Tehtävä on ottaa tarkka jäljennös siitä, miten liiketoiminta todella toimii, eikä yrittää mukauttaa tietoja geneeriseen malliin toivoen, että se sopii.

Rakentaa ratkaisu, joka toimii todellisessa maailmassa, tarvitset alustan, jolla on maksimaalinen joustavuus. Vasta silloin voidaan AI olla hyödyllinen ymmärtäessään perustiedot, joista se toimii, ja rakentaa mallin, joka toimii jokaiselle asiakkaalle.

On paljon keskustelua AI-kopioista ja autonomisista agenteista liiketoimintasovelluksissa. Missä AI lisää eniten arvoa operatiivisissa prosesseissa tänään, ja missä inhimillinen valvonta on edelleen välttämätöntä?

Laajamittaisesti AI:lla on kyky häiritä kaikkea operatiivista työtä.

Lähitulevaisuuden horisontissa Dossin omat mallit ja agentit voivat muuttaa teknisten konsulttien ydintä toteuttaa liiketoimintasovelluksia sekä management-konsulttien strategisia suosituksia. Dossilla on suurin repositorio rakennettua ja sijaittavaa tietoa, joka edustaa sekä skeemaa että operatiivisia tietoja yrityksistä. Agenteimme voivat käyttää tätä tietoa toimittamaan skaalautuvia suosituksia.

Selvin arvo tänään on tarkempi kuin se. Se on toistuva, sääntöpohjainen ja ihmisten tekemä työ, kuten ostotilauksien käsittely, varastojen sovittaminen ja toimitusmääräyksen ohjaus. Nämä tehtävät ovat hyvin määriteltyjä syötteinä ja tuloksin, ja AI voi käsitellä niitä luotettavasti laajamittaisesti.

Inhimillinen valvonta on edelleen välttämätöntä, missä virheellisen päätöksen kustannus on korkea, ja järjestelmällä ei ole vielä riittävästi kontekstia olla varma. Tänään oikea malli ei ole autonomisia agenteja, jotka korvaavat inhimillisen päätöksenteon kokonaan; se on agenteja, jotka käsittelevät suuren volyymisen, hyvin määritellyn työn, jotta ihmiset voivat keskittyä päätöksiin, jotka edellyttävät heidän harkintaa.

Monet yritykset yrittävät lisätä AI:ta olemassa oleviin ohjelmistopinoihin. Miksi vanhojen järjestelmien päällekkäinen AI usein epäonnistuu verrattuna siihen, että AI on rakennettu alustan perustana?

Perinteiset järjestelmät eivät ole suunniteltu AI:n kanssa toimimiseen. Tiedomallit, API, tiedon rakenteiden tapa, kaikki on suunniteltu ihmisten kanssa toimimiseen käyttöliittymän kautta. Kun yrität lisätä AI:ta päälle, pyydät sitä toimimaan rajoitusten kanssa, joita se ei ole tarkoitettu toimimaan.

Vaikka yrität lisätä MCP-palvelimen päälle, MCP-palvelimella on todella spesifiset suunnittelumallit. Useimmat MCP-palvelimet nykyään esittävät suurempaa kontekstipuskurin turvotusta ja rikkovat suorituskyvyn.

Syvempi ongelma on toteutusmalli. Perinteisessä ERP:ssä järjestelmän konfiguraatio on tallennettu itse järjestelmään. Se ei ole koodia, jota voit lukea, testata tai versioida. Ei ole tapaa, jolla agentti voi ymmärtää, mitä järjestelmä tekee, saati muuttaa sitä turvallisesti. Rakensimme ZSL:n nimenomaan siten, että konfiguraatio on oikea koodipohja: luettavissa, testattavissa ja käytettävissä suljetussa järjestelmässä. Rakennamme täysin agenteista ohjelmistokehityksen elinkaaren (SDLC). Se on edellytys sille, että AI voi toimia järjestelmällä, eikä vain istua sen päällä.

Miten arvioitte, että perinteisen yritysliiketoiminnan “käyttöjärjestelmä” muuttuu seuraavien viiden-kymmenen vuoden aikana, erityisesti alueilla kuten toimitusketjun näkyvyys, reaaliaikainen päätöksenteko ja automaattinen operatiivinen toiminta?

Perustimme Dossin vakaumuksen, että yritysjärjestelmät voisivat rakentaa itsensä. Kolme vuotta myöhemmin olemme siirtymässä Dossin vaiheeseen 2: agenteista itseohjautuvaan toteutukseen. Alusta voi jo generoida, validoida ja kehittää asiakkaan järjestelmää manuaalisen konsultointikonfiguraation sijaan, ja se paranee jokaisen toteutuksen myötä.

Suunta, johon tämä on menossa, on järjestelmä, joka on aina liiketoiminnan mukana. Tänään aukko siitä, miten liiketoiminta toimii, ja mitä järjestelmä tietää siitä, on kuukausia tai vuosia. Järjestelmä on konfiguroitu tiettynä ajankohtana eikä ole muuttunut siitä lähtien. Mitä mahdollista, kun tämä aukko sulkeutuu, kun järjestelmä mukautuu reaaliajassa liiketoiminnan muutosten mukana, on eri luokan operatiivinen kyky. Reaaliaikainen näkyvyys ei ole vain nopeampi raportointi; se on kyky havaita toimituskeskeytyksiä ennen kuin ne muuttuvat toimitusvirheeksi. Automaattinen operatiivinen toiminta ei ole vain tehokkuutta; se on kykyä johtaa monimutkaisempaa liiketoimintaa samalla tiimillä. Se on versio operatiivisesta ohjelmistosta, jota rakennamme.

Kiitos yksityiskohtaisista vastauksistasi. Lukijat, jotka haluavat oppia lisää, voivat vierailla Doss:ssa.