أرناف ميشرا، المؤسس المشارك والمدير التقني لشركة Doss – سلسلة المقابلات

أرناف ميشرا، المؤسس المشارك والمدير التقني لشركة Doss، هو مهندس كامل العتاد ومدير تقني مع خلفية تشمل الشركات الناشئة في المراحل الأولى وأنظمة البنية التحتية على نطاق واسع. قبل تأسيس شركة Doss، كان مهندسًا مؤسسًا في شركة Siteline، حيث بنى أنظمة أساسية بما في ذلك هندسة الأذونات، وتكاملات ERP، وأطر عمل التutomat، بالإضافة إلى المساهمة في الاستخدام، وعمليات الإيرادات، وثقافة الشركة. في وقت مبكر من مسيرته المهنية، شغل مناصب هندسية في Rubrik ومتدربًا في شركات مثل Uber و VMware، وطوّر الخبرة في بنية تحتية السحابة، وأنظمة البيانات، والautomat. إلى جانب عمله التقني، كان مشاركًا بشكل فعال في التوجيه وتطوير المواهب من خلال منظمات مثل Techquitable Futures و Contrary، مما يعكس التزامًا أوسع دعم الجيل القادم من المهندسين.

Doss هي شركة برمجيات مؤسسية حديثة تركز على إعادة اختراع الأنظمة التقليدية لبرامج تخطيط الموارد Enterprise (ERP) من خلال منصتها التكيفية للموارد (ARP)، وهي منصة عمليات مرنة ومصممة أصلاً للوحدات الذكية. تم بناؤها كبديل قابل للتركيب بدلاً من حلول ERP التقليدية، تمكن Doss الشركات من إدارة المخزون، وشراء المواد، والمالية، والشحن داخل نظام واحد يعتمد على العمليات الفعلية بدلاً من فرض عمليات صارمة. تجمع المنصة طبقة بيانات مركزية، وعمليات بدون كود، وتحليلات في الوقت الفعلي، مما يسمح للأعمال بالتوسع بسرعة، وتكامل مع أدوات موجودة، وتطوير عملياتها دون تنفيذ طويل أو استشاريين باهظين.

ما هو الدافع لإنشاء DOSS يعود إلى ويلي الذي شهد كيف قامت البرمجيات التقليدية بإعاقة أعمال والده، وكلاكما رأى مشاكل مماثلة أثناء العمل مع المصانع وسلاسل التوريد. كيف أثرت تلك الخبرات على قرارك لتأسيس DOSS وإعادة التفكير في أنظمة ERP من الصفر؟

قبل DOSS، كنت مهندسًا مؤسسًا في شركة FinTech. السبب الرئيسي الذي يجعل المشترين – CFOs، المحاسبون، إلخ – لا يختارون حلنا هو أنهم “مشغولون بتنفيذ نظام ERP”. عندما قمت بالغوص في أرض قديمة من ERP، كنت مذهولًا بنموذج التنفيذ الحالي.

ما وجدته دائمًا هو نفس الفشل الأساسي: التنفيذ يستغرق أشهر أو سنوات، ويتكلف مئات الآلاف إلى ملايين الدولارات، ويتأثر بالكامل بالاستشاريين البشريين الذين لديهم فواتير ساعية. ثم، بمجرد شحن ERP، يتوقف عن التغيير. الأعمال تستمر في التطور؛ النظام لا يتغير. هذا مشكلة معمارية، وليست مشكلة تكوين. لا يمكنك إصلاحها من خلال التصحيح.

كما بناء برمجيات، كان أقرب مقارنة يمكنني التفكير فيها هي ما يلي: تخيل عالمًا حيث الأداة الأكثر أهمية التي تستخدمها – كمطور، دعنا نقول GitHub – تم بناؤها خصيصًا لشركة واحدة فقط على مدار سنوات بواسطة وكالة استشارات طرف ثالث. ثم، بمجرد انتهاء المنتج، يغادر المستشارون بدون صيانة، ولا تحسينات للميزات، ولا دعم. سوف يثور المهندسون.

لا يمكن لأي شركة برمجيات حديثة العمل في هذا النموذج. ويلي وأنا كنا قد وصلنا إلى نفس الاستنتاج: الطريقة الوحيدة لتصحيح ذلك هي بناء من الصفر.

DOSS تضع نفسها كمنصة عمليات ذكية أصلاً مصممة لاستبدال أنظمة ERP التقليدية مثل SAP أو Oracle (ORCL ). ما هي الاختلافات المعمارية الأساسية التي تجعل منصة ERP ذكية أصلاً ممكنة اليوم وليست قابلة للتطبيق قبل عقد من الزمن؟

Oracle وSAP تم بناؤها في عصر حيث، من أجل تحقيق التوزيع الأقصى، كانوا بحاجة إلى تبسيط مستوى التكوين لنظام ERP ليكون محررًا قائمًا على واجهة المستخدم يمكن للمستشارين غير التقنيين تقديمه على نطاق واسع. من أجل الحفاظ على أفضل الممارسات، قاموا بقفل أجزاء كبيرة من الأنظمة الأساسية وسمحوا فقط بالتركيب على الحواف. ومع ذلك، في الواقع، عندما تنظر إلى طيف جميع الشركات في العالم، تحتاج تطبيقات الأعمال إلى مرونة قصوى.

ما يمكّن العالم الذكي من التحول هو تحويل هندسة البرمجيات من حرفة إلى آلة صناعية. لا نحتاج بعد الآن إلى فنانين برمجيات يدويين لإنشاء أنظمة برمجية؛ بدلاً من ذلك، نحن ننتقل إلى عالم حيث إنتاج البرمجيات هو фактор من الحوسبة والرموز.

تم تصميم Doss بالضبط مع هذا في الاعتبار.

قمنا ببناء ZSL، لغة معماريةเฉพาะ النطاق (DSL) تصف تطبيق DOSS الكامل للعميل في الكود. فكر في ما فعلته “Terraform” لجهد “البنية ككود”، ولكن بدلاً من ذلك تم تطبيقها على منطق التطبيقات التجارية. من خلال تعريف أنظمة ERP في لغة برمجة منخفضة الأبعاد نسبيًا، نحن قادرون على نشر وكلاء على نطاق واسع لتسليم حلول ERP.

بمجرد كتابة ZSL، كان الجزء الأكثر أهمية من الهندسة هو خبز أفضل الممارسات في المنصة نفسها لمنع الوكلاء من بناء تطبيقات منخفضة الجودة. قام فريقنا بتسليم نظام موزع قابل للتوسيع مع جدول زمني على مستوى النواة لتحمل حمولة عمل ERP المتقطعة. بالإضافة إلى ذلك، بنينا نظام قاعدة بيانات HTAP يدمج أجزاء معملية من قاعدة بيانات معاملات مثل Postgres والقدرات التحليلية لمخزن البيانات.

من خلال بناء المنصة لامتلاك قوة مؤسسية مبكرة، يتم تحديد النظام لتحميل التوزيع الكامل. ما كان يأخذ فرقًا من الاستشاريين أشهر أو سنوات يمكن أن يتم الآن بالتوازي على نطاق واسع باستخدام البنية التحتية الوكيلية في نظامنا المغلق.

ما هي النقاط العمياء التشغيلية الأكبر التي تظهر عندما لا يتم توحيد بيانات الأعمال الأساسية في مصدر وحيد للحقيقة؟

المشكلة الأكثر شيوعًا هي أن القرارات يتم اتخاذها بناءً على معلومات قديمة أو غير كاملة. إذا كان بيانات المخزون تعيش في مكان، وأوامر الشراء في مكان آخر، وأوامر المبيعات في مكان ثالث، فأنت دائمًا ما تقوم بمصالح يدوية، وبطريقة بطيئة، وبعد الحادث. بمجرد أن يدرك شخص ما أن المخزون غير صحيح أو أن المورد متأخر، فإنه بالفعل مشكلة في الأعمال.

Verve Coffee Roasters هو مثال جيد على كيفية تفكك هذا في الممارسة. يديرون العمليات عبر التجزئة، والجملة، والبيع المباشر، والمقاهي في الولايات المتحدة واليابان، ولكنهم كانوا يديرون كل ذلك عبر أنظمة غير متصلة بدون رؤية فعلية للمخزون. لقد نفدوا من قهوتهم الخاصة في المواقع ذات الحركة الكبيرة ووصلوا إلى نقص مخزون حرج خلال إطلاق متجر رئيسي ảnh hưởng إلى علاقة بائع رئيسية. البيانات موجودة في مكان ما؛ فقط أنها لا تعيش في طريقة تسمح لأي شخص بالعمل عليها في الوقت المناسب.

المشكلة الأكثر دقة هي أن التجزئة تخفي شكل العمليات الحقيقي. لا يمكنك رؤية العلاقة بين التأخير في مجرى النهر العلوي ومشكلة الشحن في مجرى النهر السفلي إذا كان هذان الأمرين يعيشان في أدوات منفصلة. تنتهي بهم المطاف إلى إدارة الأعراض، وتسريع الطلبات، وإنشاء مخزون أمان، وتنفيذ فحوصات يدوية بدلاً من فهم ما يحدث فعلاً. نظام موحد لا يوفر فقط وقتًا على المصالح. إنه يغير ما يمكنك رؤيته وسؤاله.

في جوهره، تخيل تشغيل أعمال بدون وصول إلى نظام تحكم بالإصدار (Git)، أو أداة مراقبة (DataDog)، أو قاعدة بيانات مركزية لاستعلام المعلومات منها.

كيف تتغير اقتصاديات وتعقيد تطبيق البرمجيات التشغيلية داخل الأعمال الحقيقية مع تغيرات الذكاء الاصطناعي؟

النموذج التقليدي للتنفيذ هو النتيجة المتأصلة لممارسات برمجيات قديمة. نحن لا نعيش بعد ذلك في هذا العالم.

هناك حافز معكوس في عمليات التنفيذ الحالية – كلما استمر التنفيذ لفترة أطول وأصبح أقل فعالية، زادت الأموال التي يتلقاها المنفذون. لن يأخذ معظم البنائين هذه الفرصة؛ ومع ذلك، فإنهم لا يتم حثهم أبدًا على التحرك بسرعة وجودة.

علاوة على ذلك، نسبة إنفاق الاستشارات إلى إنفاق البرمجيات في عقد ERP تقليدي تقارب 9:1، لذلك تنفق تسعة دولارات على استشاريين لكل دولار تنفقه على البرمجيات نفسها.对于 شركة كبيرة، هذا مؤلم للغاية.对于 أعمال السوق المتوسطة، إنه محظور. لذلك إما أن يستسلموا لبرمجيات لا تتناسب حقًا مع كيفية عملهم، أو يؤجّلون المشروع، أو يتركونه في منتصف الطريق.

يغير الذكاء الاصطناعي اقتصاديات الوحدة هذه بالكامل. بدلاً من عقد استشاري، فإن تنفيذ Doss هو قاعدة كود. مع استمرار انخفاض أوقات التنفيذ، نتمكن من محاذاة الحوافز مع نموذج “الدفع عند التسليم” بدلاً من “الدفع أثناء التنفيذ”. عندما تتغير الأعمال، يتغير النظام معها. لا يوجد حاجة إلى غرف من الاستشاريين وشرائح طويلة. النجاح في Doss يعني استبدال الإنفاق العالمي على خدمات تكنولوجيا المعلومات البالغ 1.86 تريليون دولار بالتنفيذ الوكيلية والصيانة باستخدام ZSL لغة برمجيات التطبيقات التجارية. النجاح في Doss هو توفير جميع تطبيقات الأعمال على نطاق واسع.

لقد نشرت Doss مع شركات تعمل في بيئات حقيقية مثل التصنيع، واللوجستيات، والسلع الاستهلاكية. ما هي بعض التحديات غير المتوقعة التي تظهر عندما يلتقي الذكاء الاصطناعي مع بيانات تشغيلية غير منضبطة؟

التحدي نادرًا ما يكون الذكاء الاصطناعي. إنه البيانات التي تطلب منه التفكير فيها.

كل عمل نعمل معه قد تراكمت عليه سنوات من الحلول البديلة التشغيلية. البيانات تقنيًا موجودة، فقط أنها لا تعيش في مكان يمكن لموظفيه، ناهيك عن الأنظمة الوكيلية، أن يعملوا عليه بثبات. هناك مثال رائع هو شركة ألمانية لتصنيع الأثاث التي تصنع قطع مخصصة. عندما جئنا، كان لديهم 10 سنوات من البيانات التاريخية موزعة على 8 صيغ ملفات مخصصة مع 11 كائن بيانات و 3PL متزامن يعمل على نسخ ولصق يدوي من مجلدات FTP. المنطق التجاري كان محددًا مع أبعاد مخصصة، وتفاصيل الدفع، ومواقع العرض، وكان النظام بأكمله يحتاج إلى العمل باللغة الألمانية. لا يوجد مخطط جاهز لهذا. كان عليهم دفع آلاف اليوروهات كل مرة يريدون فيها تغيير خيارات تكوين بسيطة، مثل خيارات حالة أمر الشراء.

التحدي ليس التعقيد الفني لأي قطعة واحدة. إنه أن كل عمل له نسخة مختلفة من هذه المشكلة، وأنت لا تستطيع التنبؤ بها حتى تكون داخل بياناتهم. المهمة هي الحصول على صورة دقيقة لطريقة عمل الأعمال الفعلية، وليس تخطيط بياناتهم إلى قالب عام وأمل في أن يناسب.

لبناء حلًا يعمل للعالم الحقيقي، تحتاج إلى منصة ذات مرونة قصوى. فقط بعد ذلك يمكن للذكاء الاصطناعي أن يكون مفيدًا في فهم نموذج البيانات الأساسي الذي يعمل منه، وبناء النموذج الذي يعمل لكل عميل.

هناك الكثير من المناقشات حول رفيق الذكاء الاصطناعي والوكلاء المستقلين في برمجيات الأعمال. أين ترى أن يضيف الذكاء الاصطناعي القيمة الأكبر في سلاسل العمل التشغيلية اليوم، وأين يبقى الإشراف البشري ضروريًا؟

في النطاق الواسع، يمتلك الذكاء الاصطناعي القدرة على إزعاج جميع الأعمال.

على الأفق القريب، يجب أن تكون نماذج Doss ووكلاؤه قادرون على تحويل نواة الاستشاريين التقنيين في تنفيذ تطبيقات الأعمال، بالإضافة إلى استشاريي الإدارة في تقديم توصيات إستراتيجية. سيكون لدى Doss أكبر مستودع بيانات موزعة وموحدة تمثل كل من مخططات البيانات ومعلومات التشغيل للأعمال. يمكن لوكلائنا استخدام هذه البيانات لتسليم توصيات قابلة للتوسيع.

القيمة الأكثر وضوحًا اليوم هي أكثر تحديدًا من ذلك. إنه العمل المتكرر والقائم على القواعد والذي يتم حاليًا بواسطة أشخاص لديهم أولويات إستراتيجية أخرى: معالجة أوامر الشراء، ومصالح المخزون، وتنفيذ قرارات الشحن. هذه المهام لها مدخلات ومخرجات محددة جيدًا، ويمكن للذكاء الاصطناعي التعامل معها بثبات على نطاق واسع.

لمعظم الوقت، يبقى الإشراف البشري ضروريًا في كل مكان حيث تكلفة القرار الخاطئ عالية، والنظام لا يزال يفتقر إلى السياق الكافي ليكون واثقًا. اليوم، النموذج الصحيح ليس وكلاء مستقلين ي替ون اتخاذ القرارات البشرية بالكامل؛ إنه وكلاء يتعاملون مع العمل ذي الحجم الكبير والقائم على القواعد حتى يتمكن الناس من التركيز على القرارات التي تتطلب فعلاً حكمهم.

كثير من الشركات الكبيرة تحاول وضع الذكاء الاصطناعي على رأس أنظمة برمجيات قديمة. لماذا يفشل تحديث الأنظمة القديمة بالذكاء الاصطناعي غالبًا مقارنة ببناء الذكاء الاصطناعي مباشرة في أساس المنصة؟

الأنظمة القديمة لم تكن مبنية لتكون معالجة بواسطة الذكاء الاصطناعي. نماذج البيانات، وواجهات برمجة التطبيقات، وطريقة هيكلة المعلومات، كل ذلك تم تصميمه للتفاعل مع واجهات المستخدم. عندما تحاول وضع الذكاء الاصطناعي على رأس ذلك، أنت تطلب منه العمل حول قيود لم يكن من المفترض أن يعمل حولها.

حتى إذا حاولت وضع خادم MCP على رأس ذلك، في الواقع، يحتاج خادم MCP إلى أنماط تصميم محددة جدًا. معظم خوادم MCP اليوم تقدم بloat أكبر لنافذة السياق وتفجر الأداء.

然而، المشكلة الأكثر عمقًا هي نموذج التنفيذ. في نظام ERP تقليدي، يتم تخزين تكوين النظام في النظام نفسه. إنه ليس كودًا يمكن قراءته أو اختباره أو إصدارَه. لا توجد طريقة للوكيل لفهم ما يفعله النظام، ناهيك عن تغييره بأمان. قمنا ببناء ZSL خصيصًا لكي يكون التكوين كودًا قابلًا للقراءة، واختبار، وتنفيذ في نظام مغلق.

كيف تتغير واجهات برمجيات الأعمال التقليدية مع تطور الذكاء الاصطناعي في التفاعل المباشر مع الأنظمة التشغيلية؟

سؤال الواجهة هو في الواقع من يحتاج إلى استخدام النظام. حاليًا، واجهات ERP مبنية حول مجموعة صغيرة من مستخدمي القوة، الناس الذين تم تدريبهم على النظام أثناء التنفيذ. كل شخص آخر إما لا يستطيع استخدامها أو يحصل على نسخة مخفضة منها.

ما بنيناه هو واجهة قابلة للتركيب، تعامل الواجهة مثل بناء موقع ويب. الواجهة نفسها مدعومة أيضًا بواسطة ZSL المغلق. كل شخص، من الرئيس التنفيذي إلى مدير المستودع، إلى محلل سلاسل التوريد، يحصل على لوحة تحكم وآراء بيانات موزعة حول كيفية عملهم الفعلي، وليس حول كيفية تكوين البرمجيات.

بمجرد أن يتعامل الذكاء الاصطناعي مع التنفيذ الأساسي للعمل، تصبح الواجهة أقل حول إدخال البيانات وأكثر حول الرؤية واتخاذ القرارات. تحتاج إلى رؤية ما يحدث، وفهم لماذا، واتخاذ قرارات حكمية. يجب على البرمجيات التعامل مع الباقي.

الشركات الناشئة مثل DOSS تدخل سوقًا يهيمن عليه لاعبون قدامى. ما هي المزايا التي تتمتع بها الشركات الناشئة الأصلية بالذكاء الاصطناعي عند التنافس مع منصات المؤسسات القائمة؟

اللاعبون القدامى لديهم مشكلة معاكسة للشركات الناشئة. لديهم قاعدة كبيرة من العملاء لحمايتها. كل قرار معماري يأخذه يجب أن يكون متوافقًا مع الإصدارات السابقة. يمكنهم إضافة ميزات الذكاء الاصطناعي إلى المنتجات الحالية، لكنهم لا يستطيعون إعادة بناء الأنظمة الأساسية دون كسر كل شيء يعمل عليها. هذا ليس فشلًا في الطموح؛ إنه هيكلي.

في مجال ERP على وجه الخصوص، هم أيضًا محملون بقرارات أعمال دفعتهم على طريق يجعلهم يعتمدون على خدمات استشارية احترافية. نظرًا لأن المستخدمين ينفقون تسعة دولارات على استشاريين لكل دولار ينفقونه على البرمجيات نفسها، فإن القدرة على تحويل 90% من إيراداتهم الحالية غير قابلة للتطبيق لللاعبين الكبار.

يمكن تصميم نظام أصلي بالذكاء الاصطناعي من البداية بحيث يكون الذكاء الاصطناعي جزءًا من الهندسة الأساسية، وليس طبقة على رأسها. نموذج التنفيذ، ونموذج البيانات، وطريقة التكوين كلها مصممة مع الذكاء الاصطناعي كparticipant من الدرجة الأولى. هذا هو ميزة مركبة حيث كل تنفيذ يجعل النظام أفضل، ووكلاء التنفيذ يصبحون أكثر قدرة مع كل عميل جديد. هذا النوع من حلقة التحسين لا يوجد في نظام حيث التنفيذ لا يزال عقد استشاري بشري.

ما هو رؤيتك لتحول الذكاء الاصطناعي “نظام التشغيل” للأعمال على مدى الخمس إلى عشرة سنوات القادمة، لا سيما في مجالات مثل رؤية سلاسل التوريد، وصنع القرار في الوقت الفعلي، والعمليات الآلية؟

تأسسنا DOSS على اقتناع بأن الأنظمة المؤسسية ستتمكن من بناء نفسها. بعد ثلاث سنوات، دخلنا المرحلة 2 من Doss: التنفيذ الذاتي القائم على الوكيل. المنصة يمكنها بالفعل توليد، وتنفيذ، وتطوير نظام العميل بدلاً من الاعتماد على تكوين استشاري يدوي، وهي تحسن مع كل تنفيذ.

الاتجاه الذي يتحرك نحوه هو نظام دائمًا في خطوة مع الأعمال. حاليًا، الفجوة بين كيفية عمل الأعمال وما يعرفه البرنامج هي أشهر أو سنوات. النظام تم تكوينه في نقطة زمنية ولم يتغير منذ ذلك الحين. ما يصبح ممكنًا عندما تختفي هذه الفجوة، عندما يتكيف النظام في الوقت الفعلي مع تغيير الأعمال، هو فئة مختلفة من القدرات التشغيلية. الرؤية في الوقت الفعلي ليست فقط تقارير أسرع؛ إنه القدرة على إيقاف عرقلة سلاسل التوريد قبل أن تصبح فشلًا في الشحن. العمليات الآلية ليست فقط حول الكفاءة؛ إنه القدرة على تشغيل أعمال أكثر تعقيدًا بنفس الفريق. هذا هو الإصدار من برمجيات العمليات التي نبني نحوه.

شكرًا على إجاباتك المفصلة، القراء الذين يرغبون في معرفة المزيد يجب أن يزوروا Doss.