Arnav Mishra, Dossin Co-Founder ja CTO – Haastattelusarja

Arnav Mishra, Dossin Co-Founder ja CTO, on full-stack -ohjelmistokehittäjä ja tekninen johtaja, jolla on tausta sekä varhaisessa start-up -vaiheessa että suurten infrastruktuurijärjestelmien parissa. Ennen Dossin perustamista hän oli perustajakokoonpanon jäsen Sitelinessa, jossa hän rakensi ydijärjestelmiä, mukaan lukien 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 harjoitti harjoittelijana yrityksissä kuten Uber ja VMware, kehittäen osaamista pilvi-infrastruktuurissa, tietojärjestelmissä ja automaatiossa. Teknisen työn ohella hän on ollut aktiivisesti mukana mentoroinnissa ja kykyjen kehittämisessä organisaatioiden kautta, kuten Techquitable Futures ja Contrary, heijastellen laajempaa sitoutumista tukemaan seuraavan sukupolven insinöörejä.

Doss on moderni yritysohjelmistoyritys, joka keskittyy perinteisten ERP-järjestelmien uudelleenkeksimiseen Adaptive Resource Platform (ARP) -alustan kautta, joka on joustava, AI-ominaisuudet sisältävä operaatioplatformi, joka on suunniteltu yhdistämään ja automatisoimaan liiketoimintaprosesseja. Rakennettu komponentti vaihtoehtona perinteisille ERP-ratkaisuille, Doss mahdollistaa yritysten hallinnoida varastoja, hankintoja, taloutta ja toimituksia yhdessä järjestelmässä, joka mukautuu todellisiin liiketoimintaprosesseihin sen sijaan, että se pakottaisi joustamattomia prosesseja. Sen alusta yhdistää keskitetyn datatason, koodittomat työnkulut ja reaaliaikaisen analytiikan, jolloin yritykset voivat ottaa käyttöön nopeasti, integroida olemassa oleviin työkaluihin ja jatkuvasti kehittää liiketoimintaprosessejaan ilman pitkiä toteutuskausia tai kalliita konsultteja. yritysinfrastruktuuri on suunniteltu nopeuden, skaalautuvuuden ja sopeutumiskyvyn vuoksi.

Dossin rakentamisen motiivi juontuu Wileyyn, joka havaitsi perinteisen ohjelmistoalan häirintään isänsä valmistusliiketoimintaa, ja molemmat näkivät samanlaisia ongelmia myöhemmin työskennellessään tehtailla ja laitteistotoimitusketjuilla. Miten nämä kokemukset muovasivat päätöksenne perustaa Doss ja uudelleenmuokata ERP-järjestelmiä alusta alkaen?

Ennen Dossia olin perustajakokoonpanon jäsen FinTech-startupissa. Syynä siihen, etteivät ostajamme – CFOt, kirjanpitäjät jne – valinneet ratkaisuamme, oli se, että he olivat “liian kiireisiä toteuttamaan ERP:ää”. Kun tutkin syvemmälle vanhanaikaisen ERP-maan, olin hämmästynyt olemassa olevasta toteutusmallista.

Mitä olin jatkuvasti näkemässä, oli sama perusvirhe: toteutus kestää kuukausia tai vuosia, sen kustannukset ovat satoja tuhansia tai miljoonia dollareita, ja se on täysin riippuvainen ihmiskonsulteista, jotka laskuttavat tuntityönsä. Sitten, kun ERP on toimitettu, se lopettaa kehittymisen. Tämä on arkkitehtoninen ongelma, ei konfiguraatio-ongelma. Et voi korjata sitä päällekkäin.

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

Mikään moderni teknologiayritys ei voi toimia tässä mallissa. Wiley ja minä tulimme samaan johtopäätökseen: ainoa keino korjata tämä oli rakentaa alusta alkaen.

Doss asettaa itsensä AI-ominaisuudet sisältävänä operaatioplatformina, joka on suunniteltu korvaamaan perinteiset ERP-järjestelmät kuten SAP tai Oracle. Mitkä ovat perustavanlaatuiset arkkitehtoniset erot, jotka tekevät AI-ominaisuudet sisältävän ERP:n mahdolliseksi tänään, eivätkä ne olleet toteutettavissa kymmenen vuotta sitten?

Oracle ja SAP on rakennettu aikakaudesta, jolloin heidän oli yksinkertaisesti konfiguraatiotasoa ERP:ää GUI-pohjaiseksi editoriksi, jonka suhteellisen ei-tekniset konsultit voivat toimittaa laajasti. Jotta parhaat käytännöt voidaan säilyttää, he lukitsivat suuria osia ydijärjestelmistä ja sallivat vain komposabiliteetin reunoilla. Todellisuudessa kuitenkin, kun tarkastelet kaikkien maailman yritysten soveltamisala, heidän liiketoimintasovelluksensa tarvitsevat maksimaalista joustavuutta.

Mitä AI-ominaisuudet sisältävä maailma mahdollistaa, on ohjelmistokehityksen muuttuminen käsityöstä teolliseksi koneeksi. Emme enää tarvitse ohjelmistokäsityöläisiä käsintehtäisiin koodijärjestelmiin; sen sijaan siirrymme maailmaan, jossa ohjelmistotuotannon läpimeno on tekijä laskennasta ja symboleista.

Doss on suunniteltu täsmälleen tämän vuoksi.

Rakensimme ZSL:n, joka on deklaratiivinen, toimialakohtainen kieli (DSL), joka kuvaa asiakkaan koko Doss-toteutuksen koodissa. Ajattele, mitä “Terraform” teki infrastruktuurin koodauspyrkimykselle, mutta sovelletaan liiketoimintalogiikkaan. Määrittelemällä ERP:t suhteellisen matalan ulottuvuuden ohjelmointikielellä voimme ottaa käyttöön agentteja laajassa mitassa toimittamaan ERP-ratkaisuja.

Kun ZSL oli kirjoitettu, tärkein osa arkkitehtuuria oli sisällyttää parhaisiin käytäntöihin itse alustaan estämään agenttien rakentamasta matalan laatuisia toteutuksia. Tiimimme on toimittanut skaalautuvan, hajautetun järjestelmän, jossa on ytimen tasolla ajoitussuunnittelija käsitelläkseen ERP-työn kuormituksen räjähdysmäisyyttä. Lisäksi rakensimme HTAP-tietokantajärjestelmän, joka yhdistää yhteen transaktiotietokannan tärkeimmät osat, kuten Postgres, ja Data Warehouse -analytiikkakyvyn.

Rakentamalla alustan, jolla on yritystason vahvuus alusta alkaen, järjestelmä on asetettu täysin agenteille jaetaan skaalassa käyttäen agenteille omistettua suljettua järjestelmää.

Monet yritykset luottavat edelleen taulukkolaskentaohjelmiin ja hajanaisiin työkaluihin hankinnan, varastoinnin ja tilaushallinnan osalta. Mitkä ovat suurimmat operatiiviset sokeat pisteet, jotka johtuvat siitä, että keskeinen liiketoimintatieto ei yhdistetä yhteen totuuden lähteeseen?

Suurin ongelma on, että päätökset tehdään vanhentuneesta tai epätäydellisestä tiedosta. Jos varastotiedot sijaitsevat yhdessä paikassa, ostotilaukset toisessa ja myyntitilaukset kolmannessa, olet aina sovittamassa, manuaalisesti, hitaasti ja jälkikäteen. Kun joku käsittää, että varasto on väärä tai toimittaja on myöhässä, on jo ongelma liiketoiminnassa.

Verve Coffee Roasters on hyvä esimerkki siitä, miten tämä menee käytännössä pieleen. He operoivat toimintaa yli kaupan, wholesale, DTC ja kahviloissa Yhdysvalloissa ja Japanissa, mutta hallinnoivat sitä erillisten järjestelmien kautta ilman reaaliaikaista varastotietoa. He loppuivat oman kahvin valmistuspaikoissa ja osui kriittisiin varastotilanteisiin suuren jälleenmyyjän lanseerauksen aikana, mikä vahingoitti avainjälleenmyyjäsuhdetta. Tiedot olivat olemassa jossakin; ne eivät vain olleet yhdistettyinä siten, että kukaan voisi toimia niiden perusteella ajoissa.

Hienovaraisempi ongelma on, että fragmentaatio piilottaa liiketoiminnan todellisen muodon. Et voi nähdä suhdetta viivästyksestä ylös- ja toimitusongelmaan alhaalla, jos nämä kaksi asiaa sijaitsevat eri työkaluissa. Päätät oireiden sijaan, kiirehtimällä tilauksia, rakentamalla turvavarastoja ja suorittamalla manuaalisia tarkastuksia sen sijaan, että ymmärtäisit, mitä todella tapahtuu. Yhdistetty järjestelmä ei pelkästään säästä aikaa sovittamisessa. Se muuttaa sitä, mitä voit edes nähdä ja kysyä.

Ytimessään kuvittele, että operoit yrityksellä ilman pääsyä versiohallintajärjestelmään (Git), havainnollistamistyökaluun (DataDog) tai keskitettyyn tietokantaan, josta voit kysyä tietoa.

ERP-toteutukset ovat perinteisesti vaatineet suuria konsulttitiimejä ja kuukausia – tai jopa vuosia – toteutusaikaa. Miten AI muuttaa operatiivisen ohjelmistojen toteutuksen taloutta ja monimutkaisuutta todellisissa liiketoimintaympäristöissä?

Perinteinen toteutusmalli on vanhojen ohjelmistokäytäntöjen emergoiva tulos.

On olemassa perverssi kannustimme ERP-toteutuksissa tänään – mitä kauemmin toteutus kestää ja mitä vähemmän se on tehokasta, sitä enemmän toteuttajat saavat rahaa. Suurin osa rakentajista ei hyödyntäisi tätä; he eivät kuitenkaan koskaan ole kannustettuja liikkumaan vauhdilla ja laadulla.

Lisäksi konsultointikulujen suhde ohjelmistokuluihin perinteisessä ERP-liiketoiminnassa on noin 9:1, joten käytät yhdeksän dollaria konsulteille jokaista dollaria, jonka käytät itse ohjelmistoon. Suurille yrityksille se on erittäin kivuliasta. Pienille ja keskisuurille yrityksille se on esteettä. Niinpä he joko tyytyvät ohjelmistoon, joka ei todella sovi sille, miten he toimivat, viivästyttävät projektia tai hylkäävät sen kesken.

AI muuttaa tämän yksikköekonomiikan täysin. Sen sijaan, että konsultointiprojekti olisi, Doss-toteutus on koodipohjainen. Kun toteutusajat jatkuvasti lyhenevät, voimme kohdistaa kannustimia “maksa toimituksen mukaan” -malliin sen sijaan, että “maksa mennessä”. Kun liiketoiminta muuttuu, järjestelmä muuttuu sen mukaan. Tarve konsulttien huoneille ja pitkille diaesityksille ei ole enää relevantti.

Menestys Dossissa tarkoittaa korvaamista 1,86 biljoonan dollarin maailmanlaajuista IT-palveluiden kulutusta agenteilla toteutetuilla ja ylläpidetyillä järjestelmillä käyttäen ZSL:ää liiketoimintasovellusohjelmiston kielenä. Menestys Dossissa on kaupallistamista kaikille liiketoimintasovelluksille laajassa mittakaavassa.

Olette toteuttaneet Dossin yrityksissä, jotka toimivat todellisissa ympäristöissä, kuten valmistuksessa, logistiikassa ja kulutushyödykkeissä. Mitkä ovat odottamattomia haasteita, jotka johtuvat siitä, kun AI kohtaa epäjärjestyksessä olevan operatiivisen tiedon?

Haaste ei ole AI. Se on tieto, josta pyydät sitä järkeilemään.

Jokainen yritys, jossa olemme työskennelleet, on kertynyt vuosien varrella operatiivisia kompromisseja. Tiedot ovat teknisesti olemassa, ne eivät vain asu missään, mihin heidän työntekijöillään, saati agenteilla, voidaan luotettavasti vaikuttaa.

Yksi hyvä esimerkki on saksalainen kalustevalmistaja, joka valmistaa mukautettuja osia. Kun tulin sisään, heillä oli 10 vuoden historiatietoja jaetaan kahdeksaan mukautettuun tiedostomuotoon 11 eri tietokohteella ja 3PL-synkronoinnilla manuaalisella kopioimisella FTP-kansioista. Liiketoimintalogiikka oli spesifinen mukautettujen mittojen, konfiguraatioiden, maksutapojen ja näyttelysijaintien osalta, ja koko järjestelmän piti toimia saksaksi. Siinä ei ollut valmiita skeemoja. Heidän piti maksaa tuhansia euroja jokaisesta yksinkertaisesta konfiguraatiovaihtoehdosta, kuten ostotilauksen tilatilasta.

Haaste ei ole yksittäisen osan tekninen monimutkaisuus. Se on, että jokaisella yrityksellä on erilainen versio tästä ongelmaa, eikä sitä voida täysin ennakoida, kunnes olet heidän datassa. Tehtävä on ottaa tarkka jäljennös siitä, miten yritys tosiasiassa toimii, eikä kartoittaa heidän tietojaan geneeriseen malliin ja toivoa, että se sopii.

Rakentaa ratkaisu, joka toimii todellisessa maailmassa, tarvitset alustan, jolla on maksimaalinen joustavuus. Vasta silloin voidaan AI olla hyödyllistä ymmärtämään perustiedon mallia, josta se toimii, ja rakentaa malli, joka toimii kullekin asiakkaalle.

On paljon keskustelua AI-kopioista ja autonomisista agenteista liiketoimintasoftwaressa. Missä AI lisää eniten arvoa operatiivisissa työnkulkuissa tänään, ja missä inhimillinen valvonta säilyy olennaisena?

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

Lähitulevaisuuden horisontissa Dossin omistajamallit ja agentit voivat muuttaa teknisten konsulttien ydintä toteuttaa liiketoimintasovelluksia sekä management-konsulttien toimittaa strategisia suosituksia. Dossilla on suurin repositorio rakennettua ja sijaintitietoa, joka edustaa sekä skeemaa että operatiivista tietoa yrityksille. Agenttimme voivat käyttää tietoa toimittamaan skaalautuvia suosituksia.

Selvin arvo tänään on spesifisempi kuin tämä. Se on toistuvassa, sääntöperusteisessa työssä, jota ihmiset tekevät, joilla on muut, strategisemmat prioriteetit: prosessoida ostotilauksia, sovella varastoa ja reitittää toimituspäätöksiä. Nämä tehtävät ovat hyvin määriteltyjä syötteinä ja tuloksin, ja AI voi käsitellä niitä luotettavasti laajassa mittakaavassa.

Toistaiseksi inhimillinen valvonta on olennaisen, missä virheellisen päätöksen kustannukset ovat korkeat, 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 suurvolyymin, hyvin määriteltyä työtä, jotta ihmiset voivat keskittyä päätöksiin, jotka edellyttävät heidän tuomiovaltaansa.

Monet yritykset yrittävät lisätä AI:ta olemassa oleviin ohjelmistopinoihin. Miten perinteisten järjestelmien muokkaaminen AI:lla usein epäonnistuu verrattuna siihen, että AI on rakennettu suoraan alustan perustaan?

Perinteiset järjestelmät eivät ole suunniteltu AI:n ymmärtämiseksi. Datamallit, API:t, tiedon rakenteiden tapa, kaikki on suunniteltu ihmisten kanssa vuorovaikuttaa käyttöliittymien kautta. Kun yrität lisätä AI:ta päälle, pyydät sitä työskentelemään rajoituksien kanssa, joita se ei ole tarkoitettu työskentelemään.

Vaikka yrität heittää MCP-palvelimen päälle, todellisuudessa MCP-palvelimella on erittäin spesifiset suunnittelumallit. Useimmat MCP-palvelimet nykyään todella esittävät suurempaa kontekstipäätekokoilmaa ja räjähtävät suorituskyvyn.

Syvempi ongelma on toteutusmalli. Perinteisessä ERP:ssä järjestelmän konfiguraatio on tallennettu itse järjestelmään. Se ei ole koodia, jonka voit lukea, testata tai version. 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 koodipohjainen: luettavissa, testattavissa ja käyttöönottokelpoinen suljetussa järjestelmässä. Rakennamme täysin agenteille ohjattavan ohjelmistokehityksen elinkaaren (SDLC). Se on edellytys sille, että AI voi toimia järjestelmällä sen sijaan, että se vain istuisi sen päällä.

Kun AI pystyy generoimaan työnkulkuja ja vuorovaikuttamaan suoraan operatiivisten järjestelmien kanssa, miten arvioitte perinteisten yritysliiketoimintaliittymien tulevan muuttumaan?

Kysymys liittymistyylistä on todella se, kuka tarvitsee käyttää järjestelmää. Tällä hetkellä ERP-liittymät on suunniteltu yhdelle pienelle joukolle valtuutetuille käyttäjille, niille ihmisille, jotka olivat koulutettuina järjestelmään sen toteutuksen aikana. Kukaan muu ei voi käyttää sitä tai saa heikentynyttä versiota siitä.

Mitä olemme rakentamassa, on komponenettinen käyttöliittymä, joka käsittelee liittymän verkkosivun rakentajana. Liittymä itsessään on myös tuettu suljetun ZSL:n kautta. Jokainen, CFO, varastopäällikkö, toimitusketjun analyytikko, saa koostetun dashboardin ja datanäkymän, joka on koostettu siitä, miten he todella toimivat, eikä siitä, miten ohjelmistoa on konfiguroitu. Kun AI käsittelee enemmän järjestelmän alla olevaa työnkulkua, liittymä muuttuu enemmän näkyvyydeksi ja päätöksenteoksi. Sinun on nähtävä, mitä tapahtuu, ymmärrettävä miksi, ja tehtävä tuomio. Ohjelmisto hoitaa loput.

Start-up -yritykset kuten Doss tulevat markkinoille, jota hallitsevat vuosikymmenten ikäiset vakiintuneet toimijat. Mitkä ovat etuja, joita AI-ominaisuudet sisältävät start-up -yrityksillä on kilpaillessaan vakiintuneita yritysliiketoimintaplatfordeja vastaan?

Vakiintuneilla toimijoilla on vastakkainen ongelma kuin start-up -yrityksillä. Heillä on valtavat asennetut tietokannat, joita on suojeltava. Jokainen arkkitehtoninen päätös, jonka he tekevät, on oltava taaksepäin yhdenmukainen. He voivat lisätä AI-ominaisuudet olemassa oleviin tuotteisiin, mutta he eivät voi uudelleenrakentaa perusjärjestelmiä ilman sitä, että rikkoisivat kaiken, mitä heillä on. Se ei ole epäonnistuminen kunnianhimoissa; se on rakenteellinen.

Erityisesti ERP:ssä heillä on myös liiketoimintapäätöksiä, jotka johtivat heidät polulle, jota Doss yrittää korvata – ammattikonsulttien palveluista. Koska käyttäjät käyttävät yhdeksän dollaria konsulteille jokaista dollaria, jonka he käyttävät itse ohjelmistoon, heidän kykynsä muuttaa 90 % lähteistään on mahdotonta vakiintuneille suurille toimijoille.

AI-ominaisuudet sisältävä järjestelmä voidaan suunnitella alusta alkaen siten, että AI on osa ydinkokoonpanoa, ei kerros päällä. Toteutusmalli, datamalli ja konfiguraation tapa on suunniteltu AI:n kanssa yhteistyössä. Se on kertyvä etu, jossa jokainen toteutus tekee järjestelmästä paremman, ja toteutusagentit tulevat kykeneviksi uusien asiakkaiden kanssa. Tällaista parantumisluuppia ei ole järjestelmässä, jossa toteutus on edelleen inhimillinen konsulttien toteutus.

Miten näette AI:n muuttavan “käyttöjärjestelmän” liiketoiminnassa seuraavien viiden-kymmenen vuoden aikana, erityisesti alueilla kuten toimitusketjun näkyvyys, reaaliaikainen päätöksenteko ja automaattinen toiminta?

Perustimme Dossin vakaumuksella, että yritysjärjestelmät voivat rakentaa itsensä. Kolme vuotta myöhemmin olemme siirtymässä Dossin vaiheeseen 2: agenteille ohjattuun toteutukseen. Alusta pystyy jo generoimaan, validoimaan ja kehittämään asiakkaan järjestelmää manuaalisten konsulttien konfiguraation sijaan, ja se paranee jokaisen uuden asiakkaan kanssa.

Suunta, johon tämä on menossa, on järjestelmä, joka on aina liiketoiminnan mukana. Tänään aukko siitä, miten liiketoiminta toimii, ja mitä ohjelmisto tietää siitä, on kuukausia tai vuosia. Järjestelmä on konfiguroitu tietyssä vaiheessa, eikä se ole muuttunut siitä lähtien. Mitä tulee mahdolliseksi, kun tämä aukko sulkeutuu, kun järjestelmä mukautuu reaaliajassa liiketoiminnan muutosten mukaan, on eri luokan operatiivinen kyky. Reaaliaikainen näkyvyys ei ole vain nopeampaa raportointia; se on kyky havaita toimitusketjun häiriö ennen kuin se muuttuu toimitusvirheeksi. Automaattinen toiminta ei ole vain tehokkuutta; se on kykyä operoida monimutkaisempaa liiketoimintaa samalla tiimillä. Se on versio operatiivisesta ohjelmistosta, jota olemme rakentamassa.

Kiitos yksityiskohtaisista vastauksistasi. Lukijat, jotka haluavat oppia lisää, voivat vierailla Doss-sivustolla.