Интервью
Арнав Мишра, сооснователь и технический директор Doss – Интервью
Арнав Мишра, сооснователь и технический директор Doss, является полноценным инженером и техническим лидером с опытом работы в ранних стартапах и крупномасштабных инфраструктурных системах. До сооснования Doss он был одним из основателей Siteline, где он построил основные системы, включая архитектуру разрешений, интеграции с ERP и автоматические框架, а также вносил свой вклад в набор персонала, операции по доходам и культуру компании. Ранее в своей карьере он работал инженером в Rubrik и стажировался в компаниях như Uber и VMware, развивая экспертизу в области облачной инфраструктуры, систем данных и автоматизации. В дополнение к своей технической работе, он активно участвовал в наставничестве и развитии талантов через организации như Techquitable Futures и Contrary, отражая более широкую приверженность поддержке следующего поколения инженеров.
Doss – это современная компания по разработке программного обеспечения для предприятий, ориентированная на переосмысление традиционных систем ERP посредством своей адаптивной платформы ресурсов (ARP), гибкой, родной для ИИ операционной платформы, предназначенной для унификации и автоматизации бизнес-процессов. Построенная как составная альтернатива решениям legacy ERP, Doss позволяет компаниям управлять запасами, закупками, финансами и выполнением в рамках единой системы, которая адаптируется к реальным операциям, а не заставляет жесткие процессы. Ее платформа объединяет централизированный слой данных, безкодовые рабочие процессы и аналитику в реальном времени, позволяя бизнесу развертывать быстро, интегрироваться с существующими инструментами и непрерывно развивать свои операции без длительных реализаций или дорогостоящих консультантов.
Мотивация к созданию DOSS восходит к тому, как устаревшее программное обеспечение нарушило производственный бизнес вашего отца, и вы оба позже увидели подобные проблемы лично, работая с фабриками и цепочками поставок оборудования. Как эти переживания сформировали ваше решение стать сооснователем DOSS и переосмыслить системы ERP с нуля?
До DOSS я был одним из основателей стартапа в области финтех. Основная причина, по которой наши покупатели – финансовые директора, бухгалтеры и т. д. – не переходили на нашу систему, заключалась в том, что они были “слишком заняты реализацией ERP”. Когда я глубже погрузился в архаичную область ERP, я был поражен существующей моделью реализации.
То, что я постоянно видел, было одним и тем же фундаментальным провалом: реализация занимает месяцы или годы, стоит сотен тысяч до миллионов долларов и полностью зависит от человеческих консультантов с почасовой оплатой. Затем, когда ERP доставляется, он перестает меняться. Бизнес продолжает развиваться; система не меняется. Это архитектурная проблема, а не проблема конфигурации. Вы не можете исправить ее патчами.
Как разработчик программного обеспечения, ближайшая аналогия, которую я мог придумать, была следующей: представьте себе мир, в котором наиболее важный инструмент, который вы используете – скажем, GitHub – был построен специально для вашей компании за годы работы консалтинговой компании. Затем, когда продукт завершен, консультанты уходят без технической поддержки, улучшений и обслуживания. Инженеры восстали бы.
Ни одна современная технологическая компания не может работать в этой модели. Уайли и я пришли к одному и тому же выводу: единственный способ исправить это – построить все с нуля.
DOSS позиционирует себя как родная для ИИ операционная платформа, предназначенная для замены традиционных систем ERP, таких как SAP или Oracle. Какие фундаментальные архитектурные различия делают родную для ИИ систему ERP возможной сегодня, чего не было возможно десяти лет назад?
Oracle и SAP были построены в эпоху, когда, чтобы добиться максимального распространения, им нужно было упростить плоскость конфигурации ERP до GUI-редактора, с которым могли работать консультанты, не имеющие глубоких технических знаний. Чтобы сохранить лучшие практики, они заблокировали большие участки основных систем и позволили составность только на краях. Однако, в реальности, когда вы смотрите на спектр всех бизнесов в мире, их бизнес-приложения нуждаются в максимальной гибкости.
Мир, родной для ИИ, позволяет преобразовать разработку программного обеспечения из ремесла в индустриальную машину. Нам больше не нужны программные ремесленники, чтобы手工 создавать кодовые системы; вместо этого мы переходим в мир, в котором программная производительность является фактором вычислений и токенов.
Doss была сконструирована именно с этим в виду.
Мы построили ZSL, декларативный язык конкретной области (DSL), который описывает всю реализацию DOSS для клиента в коде. Подумайте о том, что “Terraform” сделал для усилий по коду инфраструктуры, но вместо этого примените это к логике бизнес-приложений. Определяя ERP в относительно низкомерной языке программирования, мы можем развертывать агентов масштабно, чтобы доставлять решения ERP.
Как только ZSL был написан, самой важной частью архитектуры было внедрение лучших практик в саму платформу, чтобы предотвратить создание агентами реализаций низкого качества. Наша команда доставила масштабируемую распределенную систему с планировщиком ядра, чтобы взять на себя нагрузку избыточных рабочих нагрузок ERP. Кроме того, мы построили систему HTAP-базы данных, которая объединяет наиболее важные части транзакционной базы данных, такой как Postgres, и аналитические возможности хранилища данных.
Строить платформу с корпоративной прочностью с самого начала, система готова к полностью агентскому распределению. То, что раньше занимало команды консультантов месяцы и годы, теперь может быть параллелизировано масштабно с помощью агентской инфраструктуры в нашей проприетарной закрытой системе.
Многие компании все еще полагаются на электронные таблицы и фрагментированные инструменты для закупок, управления запасами и управления заказами. Какие самые большие операционные пробелы возникают, когда основные бизнес-данные не объединены в единую истину?
Самой большой проблемой является то, что решения принимаются на основе устаревшей или неполной информации. Если ваши данные об запасах живут в одном месте, ваши заказы на покупку в другом, а ваши заказы на продажу в третьем, вы всегда согласовываете, вручную, медленно и после факта. К тому времени, когда кто-то понимает, что запасы истощаются или поставщик отстает, это уже проблема в бизнесе.
Verve Coffee Roasters – хороший пример того, где это разбивается на практике. Они управляют операциями в рознице, опте, DTC и кафе в США и Японии, но управляли всем этим в несвязанных системах без реального видимости запасов. Они заканчивали свой собственный кофе на высоко посещаемых местах и попадали в критические пробелы в запасах во время запуска крупного ритейлера, что повредило ключевые розничные отношения. Данные существовали где-то; они просто не были связаны так, чтобы кто-то мог действовать на них вовремя.
Более тонкая проблема заключается в том, что фрагментация скрывает реальную форму ваших операций. Вы не можете увидеть связь между задержкой вверх по потоку и проблемой выполнения вниз по потоку, если эти две вещи живут в отдельных инструментах. Вы в конечном итоге управляете симптомами, экспедируете заказы, строите запасы безопасности и выполняете ручные проверки вместо того, чтобы понимать, что на самом деле происходит. Единая система не только экономит время на согласовании. Она меняет то, что вы даже можете увидеть и задать вопросы.
В своей основе представьте себе управление корпоративным бизнесом без доступа к системе контроля версий (Git), инструменту наблюдения (DataDog) или централизованной базе данных для запроса информации.
Реализация ERP исторически требовала больших консалтинговых команд и месяцев – или даже лет – развертывания. Как ИИ меняет экономику и сложность реализации операционного программного обеспечения внутри реальных бизнесов?
Традиционная модель реализации является эмерджентным результатом поколений старых практик программного обеспечения. Мы больше не живем в том мире.
Существует извращенный стимул в реализации ERP сегодня – чем дольше длится реализация и чем она менее эффективна, тем больше денег получают реализаторы. Большинство строителей не воспользуются этим; однако они никогда не стимулируются к движению с темпом и качеством.
Кроме того, соотношение расходов на консалтинг к расходам на программное обеспечение в традиционном взаимодействии ERP составляет примерно 9:1, поэтому вы тратите девять долларов на консультантов за каждый доллар, который вы тратите на само программное обеспечение. Для крупного предприятия это чрезвычайно болезненно. Для бизнеса среднего рынка это запретительно. Итак, они либо соглашаются на программное обеспечение, которое не соответствует тому, как они на самом деле работают, либо задерживают проект, либо отказываются от него на полпути.
ИИ меняет единицы экономики полностью. Вместо консалтингового взаимодействия реализация DOSS является кодовой базой. Когда наши сроки реализации продолжают сокращаться, мы можем согласовать стимулы с моделью “плати по доставке” вместо “плати по мере продвижения”. Когда бизнес меняется, система меняется с ним. Необходимость комнат консультантов и длинных слайд-шоу больше не актуальна.
Успех в Doss означает замену глобального ИТ-расхода в размере 1,86 триллиона долларов на агентскую реализацию и обслуживание с помощью нашего ZSL в качестве языка программного обеспечения для бизнес-приложений. Успех в Doss означает коммодитизацию всех бизнес-приложений масштабно.
Вы развертывали DOSS с компаниями, работающими в реальных средах, таких как производство, логистика и потребительские товары. Какие из неожиданных проблем возникают, когда ИИ встречается с запутанными операционными данными?
Проблема редко заключается в ИИ. Это данные, о которых вы просите его рассуждать.
Каждый бизнес, с которым мы работаем, накопил годы операционных обходов. Данные технически существуют, они просто не живут где-либо, где сотрудники, не говоря уже об агентских системах, могут надежно действовать на них.
Одним из отличных примеров является немецкий производитель мебели, который создает изделия, сделанные на заказ. Когда мы пришли, у них было 10 лет исторических данных, распределенных по 8 настраиваемым форматам файлов с 11 различными объектами данных и синхронизацией 3PL, работающей на ручной копии-пасте из папок FTP. Бизнес-логика была конкретной с настраиваемыми размерами, конфигурациями, методами оплаты и местами показа, и вся система нуждалась в том, чтобы работать на немецком языке. Нет готовой схемы для этого. Им приходилось платить тысячи евро каждый раз, когда они хотели изменить простые параметры конфигурации, такие как параметры статуса заказа на покупку.
Проблема не заключается в технической сложности любой отдельной части. Это то, что каждый бизнес имеет другую версию этой проблемы, и вы не можете полностью предвидеть ее, пока не окажетесь внутри их данных. Работа заключается в том, чтобы получить точный отпечаток того, как бизнес на самом деле работает, а не сопоставить их данные с общей шаблонной.
Чтобы построить решение, которое работает для реального мира, вам нужна платформа с максимальной гибкостью. Только тогда ИИ может быть полезен в понимании лежащей в основе модели данных, над которой он работает, и построении модели, которая работает для каждого клиента.
Есть много обсуждений об ИИ-копилотах и автономных агентах в программном обеспечении для бизнеса. Где, по вашему мнению, ИИ добавляет наибольшую ценность в операционных рабочих процессах сегодня, и где человеческий надзор остается важным?
В масштабе ИИ имеет возможность нарушить все операционную работу.
В ближайшей перспективе проприетарные модели и агенты Doss должны быть в состоянии преобразовать ядро технических консультантов при реализации бизнес-приложений, а также работу менеджеров-консультантов при доставке стратегических рекомендаций. Doss будет иметь самый большой репозиторий структурированных и сопоставленных данных, представляющих как схему, так и операционную информацию для бизнеса. Наши агенты могут использовать эти данные, чтобы доставлять масштабируемые рекомендации.
Самая очевидная ценность сегодня более конкретна, чем это. Это работа, которая повторяется, основана на правилах и в настоящее время выполняется людьми, которые имеют другие, более стратегические приоритеты: обработка заказов на покупку, согласование запасов и маршрутизация решений по выполнению. Эти задачи имеют хорошо определенные входные и выходные данные, и ИИ может обрабатывать их надежно в масштабе.
На данный момент человеческий надзор необходим, где стоимость неправильного решения высока, и система еще не имеет достаточно контекста, чтобы быть уверенной. Сегодня правильная модель не заключается в автономных агентах, полностью заменяющих человеческое принятие решений; это агенты, которые обрабатывают высокообъемную, хорошо определённую работу, чтобы люди могли сосредоточиться на решениях, которые действительно требуют их суждения.
Многие предприятия пытаются наложить ИИ на существующие программные стеки. По вашему мнению, почему наложение legacy-систем с ИИ часто не оправдывает ожиданий по сравнению с построением ИИ непосредственно в основу платформы?
Legacy-системы не были построены для того, чтобы быть рассуждаемыми ИИ. Модели данных, API, способ структурирования информации – все это было разработано для взаимодействия людей с интерфейсами. Когда вы пытаетесь наложить ИИ поверх этого, вы просите его работать вокруг ограничений, для которых он не был предназначен.
Даже если вы попытаетесь бросить сервер MCP поверх, в реальности сервер MCP требует чрезвычайно конкретных моделей проектирования. Большинство серверов MCP сегодня фактически вводят большую разбухание контекстного окна и взрыв производительности.
Однако более глубокая проблема заключается в модели реализации. В традиционной ERP конфигурация системы хранится в самой системе. Это не код, который можно прочитать, протестировать или версионировать. Нет способа для агента понять, что делает система, не говоря уже о том, чтобы изменить ее безопасно. Мы построили ZSL специально, чтобы конфигурация была правильной кодовой базой: читаемой, тестируемой и развертываемой в закрытой системе. Мы строим полностью агентский цикл разработки программного обеспечения (SDLC). Это предпосылка для того, чтобы ИИ мог фактически работать с системой, а не просто сидеть поверх нее.
Как вы думаете, интерфейсы традиционного программного обеспечения для предприятий будут эволюционировать, когда ИИ станет способен генерировать рабочие процессы и взаимодействовать непосредственно с операционными системами?
Вопрос интерфейса на самом деле о том, кто нуждается в использовании системы. Сейчас интерфейсы ERP построены вокруг небольшого набора пользователей-профессионалов, людей, которые были обучены на системе во время реализации. Каждый другой либо не может использовать ее, либо получает ухудшенную версию.
То, что мы строим, – это составной интерфейс, который рассматривает интерфейс как веб-сайт-построитель. Интерфейс сам по себе также поддерживается закрытой петлей ZSL. Каждый, финансовый директор, менеджер склада, аналитик цепочки поставок, получает панель и представление данных, составленные вокруг того, как они на самом деле работают, а не вокруг того, как было сконфигурировано программное обеспечение. Когда ИИ обрабатывает больше лежащей в основе выполнения рабочего процесса, интерфейс становится менее связанным с вводом данных и более связанным с видимостью и принятием решений. Вам нужно видеть, что происходит, понимать, почему, и принимать судебные решения. Программное обеспечение должно обрабатывать остальное.
Стартапы, такие как DOSS, входят на рынок, доминируемый десятилетними инкубентами. Какие преимущества имеют стартапы, родные для ИИ, при конкуренции с устоявшимися платформами для предприятий?
Инкубенты имеют противоположную проблему стартапам. У них есть огромные установленные базы, которые нужно защитить. Каждое архитектурное решение, которое они принимают, должно быть обратно совместимым. Они могут добавить функции ИИ к существующим продуктам, но они не могут перестроить лежащие в основе системы без того, чтобы сломать все, что работает на них. Это не провал амбиций; это структурно.
В ERP конкретно они также обременены бизнес-решениями, которые привели их по пути, где доход генерируется из конкретной функции, которую DOSS пытается устранить – профессиональные консультанты по услугам. Учитывая, что пользователи тратят девять долларов на консультантов за каждый доллар, который они тратят на само программное обеспечение, способность преобразовать 90% их дохода от источника является невозможной для крупных инкубентов.
Родная для ИИ система может быть разработана с самого начала так, чтобы ИИ был частью основной архитектуры, а не слоем поверх. Модель реализации, модель данных и способ, которым работает конфигурация, все это разработано с ИИ как первоклассным участником. Это компаундовое преимущество, где каждый развертывание делает систему лучше, и агенты становятся более способными с каждым новым клиентом. Такой цикл улучшения не существует в системе, где реализация все еще является человеческим консалтинговым взаимодействием.
Оглядываясь вперед, как вы представляете себе преобразование ИИ “операционной системы” бизнеса в течение следующих пяти-десяти лет, особенно в таких областях, как видимость цепочки поставок, принятие решений в реальном времени и автоматизированные операции?
Мы основали DOSS на убеждении, что корпоративные системы смогут строить себя. Три года спустя мы вошли в фазу 2 Doss: агентскую самоходную реализацию. Платформа уже может генерировать, проверять и развивать систему клиента, а не полагаться на ручную конфигурацию консультантов, и она становится лучше с каждым развертыванием.
Направление, в котором это движется, – это система, которая всегда находится в ладе с бизнесом. Сегодня разрыв между тем, как работает бизнес, и тем, что знает о нем программное обеспечение, составляет месяцы или годы. Система была сконфигурирована в определенный момент времени и не изменилась с тех пор. То, что становится возможным, когда этот разрыв закрывается, когда система адаптируется в реальном времени, как меняется бизнес, – это другая категория операционной возможности. Видимость в реальном времени не только более быстрое отчетность; это способность поймать сбои в поставках до того, как они станут провалом выполнения. Автоматизированные операции не только вопрос эффективности; это способность управлять более сложным бизнесом с той же командой. Это та версия программного обеспечения для операций, которую мы строим.
Спасибо за ваши подробные ответы, читатели, которые хотят узнать больше, должны посетить Doss.
