في 15 سبتمبر 2026، أعلنت DoorDash وواوندر عن إبرام تعاون استراتيجي.
- وفقًا لإعلان الطرفين، وافقت DoorDash على الاستحواذ على أعمال Grubhub Campus Dining التابعة لواوندر مقابل USD 300,000,000، وفي الوقت نفسه استثمرت USD 125,000,000 في واوندر. من المتوقع إتمام صفقة Campus Dining في النصف الأول من 2027، ولا يزال يتعين الحصول على الموافقات التنظيمية ذات الصلة.
- كانت واوندر قد أكملت سابقًا تمويل Series D بقيمة USD 650,000,000 حتى تاريخ إعلان الصفقة، وكان لديها حوالي 157 فرعًا مملوكًا مباشرة، وتستمر في توجيه الأموال إلى الذكاء الاصطناعي، الروبوتات، أتمتة المطابخ، وتوسيع الشبكة الفعلية.
من منظور رأس المال، يمكن فهم هذه الصفقة كإعادة هيكلة أصول وتركيز استراتيجي: تسلم واوندر أعمال Campus Dining وغيرها من خدمات الطعام المؤسسية إلى DoorDash، وتوجه المزيد من الموارد نحو إنتاج الطعام، أتمتة المطابخ، والبنية التحتية للطبخ الذكي.
ما يستحق المتابعة حقًا هو أن واوندر داخلها تُنشئ نظام عمل قريب جدًا من Forward Deployed Engineering، المختصر بـ FDE.
أولاً، تقوم شركة Wonder بتحويل خبرة المطاعم إلى نظام يمكن للآلات تنفيذه
تقدم Wonder وصفًا حاسمًا لنظامها التقني:
تحويل خبرة الطهاة وعلامات تجارية في مجال الطعام إلى عملية قابلة للتكرار وقابلة للقراءة من قبل الآلة، أي “عملية يمكن تكرارها وقراءتها آليًا”.
هذا يعني أن الطبق لم يعد مجرد وصفة تقليدية.
يتم تفكيكه الآن إلى سلسلة من المعلمات التي يمكن للبرمجيات والأجهزة والروبوتات قراءتها:
مواصفات المكونات → الوزن بالجرام → ترتيب الإضافة → الوقت → الحرارة → طريقة الخلط → قوة النار → منحنى الطهي → عملية تقديم الوجبة → عملية التنظيف → حركات الجهاز
المطاعم التقليدية تعتمد على خبرة الطهاة لإكمال هذه الإجراءات.
تسعى شركة Wonder إلى تحويل هذه الخبرة إلى هندسة.
في النهاية يتشكل:
خبرة الطهي البشرية → هندسة الوصفة → وصفة قابلة للقراءة آليًا → تحكم برمجي → تنفيذ الروبوت → التحقق في المتجر
هذا يجعل الوصفة للمرة الأولى تمتلك خصائص مشابهة لبرنامج برمجي.
ثانيًا، ظهرت ميزات FDE أولاً في فريق نشر الروبوتات.
فريق الروبوتات في Wonder قد أنشأ بالفعل وظائف هندسية ميدانية نموذجية.
إحدى هذه الوظائف هي:
Deployment & Applications Engineer
تشمل مسؤولياته:
- نشر Infinite Kitchen على مستوى الدولة؛
- قضاء وقت كبير في المتاجر ومواقع المشاريع؛
- تولي دور المسؤول التقني في الموقع؛
- تنسيق فريق الهندسة، المقاولين وموردي المعدات؛
- حل المشكلات التي تظهر أثناء النشر الفعلي؛
- العودة إلى فريق البحث والتطوير للمشاركة في تحسينات الأجهزة والبرمجيات والاختبارات؛
- تحويل خبرة النشر الفردية إلى عمليات نشر وصيانة موحدة؛
يمكن تلخيص مسار عمله كالتالي:
Lab → Field → Problem → Engineering → Product → Next Deployment
هذا قريب جدًا من دور مهندس تطوير الأجهزة (FDE) في صناعة البرمجيات؛
المهندسون لا يقتصرون على تطوير المنتجات فقط، بل يدخلون مباشرةً إلى مواقع الأعمال الحقيقية ويعيدون المشكلات التي يواجهونها في الموقع إلى نظام المنتج.
3. بدأت شركة Wonder في تنفيذ “نشر القوائم” للعملاء الخارجيين.
التغيير الأكثر أهمية يأتي من فريق الروبوتات B2B في شركة Wonder.
دور Commercialization الطهي في Wonder مسؤول بوضوح عن العملاء المؤسسين الخارجيين، أي العملاء الشركات الخارجية.
إحدى المهام الأساسية هي:
مساعدة العملاء على تحويل قوائمهم المخصصة إلى منصة الأجهزة الروبوتية الخاصة بـ Wonder.
بمصطلحات الضيافة، يعني ذلك:
الطبق الأصلي للعميل → فريق Wonder يدخل الموقع → فهم المكونات وطريقة التحضير → تعديل الوصفة → تعديل المعلمات → تكييف الروبوت → الاختبار → التدريب → الإطلاق → التعديل المستمر
هنا تظهر سلسلة عمل FDE النموذجية:
أعمال العميل → الفهم في الموقع → التحويل الهندسي → تكييف المنتج → الإطلاق → تغذية البيانات الراجعة → ترسيخ المنصة
في صناعة البرمجيات، عادةً ما يكون FDE هو تحويل عمليات أعمال العميل إلى برامج وأنظمة بيانات.
ما تقوم به Wonder هو:
تحويل قوائم طعام العميل وعمليات المطبخ إلى برامج روبوتية.
لذلك يمكن فهم ذلك كنوع من:
Forward-Deployed Culinary Engineering
أو:
Forward-Deployed Robotics
رابعًا، FDE في Wonder ليست وظيفة بل فريق متعدد التخصصات
عادةً ما يتحمل مهندسو البرمجيات مسؤولية FDE التقليدي.
سيناريوهات المطاعم أكثر تعقيدًا بكثير.
لإدخال طبق فعليًا إلى نظام المطبخ الآلي، يجب حل جميع ما يلي في آن واحد:
- قائمة الطعام؛
- المكونات؛
- سلسلة التوريد؛
- المعالجة المسبقة؛
- الطبخ；
- الروبوت؛
- البرمجيات؛
- KDS；
- سلامة الغذاء؛
- إيقاع تقديم الطعام؛
- تشغيل الموظفين؛
- صيانة المعدات.
لذلك فإن FDE في Wonder يتم إنجازه فعليًا من قبل عدة مناصب مشتركة:
Culinary Engineer ＋ Food Scientist ＋ Robotics Engineer ＋ Deployment Engineer ＋ Software Engineer ＋ Operations
الدور الأساسي هنا ليس منصبًا واحدًا يُدعى "FDE".
الجوهر هو هيكل تنظيمي:
فريق الهندسة وبين المطبخ الحقيقي يوجد حلقة مستمرة ذات اتجاهين.
عند حدوث مشكلة في الموقع، لا يتم حلها فقط عبر التدريب أو SOP.
يتم إرجاع المشكلة مرة أخرى:
تصميم الروبوتات، البرمجيات، واجهة المستخدم، هندسة الوصفات، هيكل المعدات وعمليات التشغيل.
ثم يتم تشكيل الجيل التالي من المنتجات.
خمسة، الحلقة الأساسية هي الميدان → الهندسة → المنتج → الميدان
فريق عمليات الطهي في وندر لديه وصف مسؤولية مميز للغاية:
ربط مبتكري الهندسة ومشغلي الميدان.
أي:
البحث والتطوير الهندسي ↔ عمليات الخط الأمامي
هذا الفريق مسؤول عن مراقبة كيفية دخول الروبوتات إلى المطابخ الحقيقية، بما في ذلك:
- هل تؤثر على معدل الإنتاجية؛
- هل يسهل على الموظفين تشغيلها؛
- كيف يتعاون نظام عرض الطلبات (KDS) مع الروبوت؛
- كيف يتم توجيه تنفيذ الوصفات؛
- هل إنتاجية المنتج مستقرة؟
- هل واجهة المستخدم مناسبة لبيئة المطبخ؟
- هل الهندسة البشرية معقولة؟
- كيف تؤثر أعطال المعدات على التشغيل؟
تُعاد هذه المعلومات لاحقًا إلى نظام البحث والتطوير.
في النهاية يتشكل:
Field → Data → Engineering → Product → Deployment → Field
هذه هي القيمة الأهم لـ FDE.
الموقع لم يعد مجرد “نقطة تسليم”.
الموقع يصبح جزءًا من البحث والتطوير.
6. تقوم Wonder ببناء نوع من Food Runtime
إذا استمر التجريد، فإن ما تقوم به Wonder يتجاوز “روبوت القلي”.
يتشكل النظام بأكمله تدريجياً:
Restaurant Knowledge → Recipe Engineering → Machine Representation → Kitchen Software → Robotic Execution → Field Validation → Reusable Platform
أهم ما يستحق المتابعة هنا هو تمثيل الآلة (Machine Representation).
الوصفات التقليدية تستهدف البشر أساساً.
ستحتاج الوصفات المستقبلية إلى استهداف عدة جهات في آن واحد:
البشر + الذكاء الاصطناعي + البرمجيات + معدات المطبخ + الروبوتات
وبالتالي سيتحول الوصف من نص إلى أصل تشغيل في الوقت الفعلي.
يمكن تجريده أكثر إلى:
Recipe → Cooking Program → Kitchen Runtime → Robot Execution
إذا استمر هذا الاتجاه في التطور، قد تظهر طبقات في صناعة الضيافة تشبه تلك في قطاع البرمجيات:
طبقة التطبيق: علامات تجارية للمطاعم، القوائم، تجربة المستهلك
طبقة التشغيل: بيئة تشغيل المطبخ (Kitchen Runtime)
طبقة البروتوكول: وصفة قابلة للقراءة آليًا
طبقة الأجهزة: الروبوتات، الأفران، المستشعرات، المعدات الآلية
طبقة البيانات: الحرارة، الوزن، الوقت، الصور، حالة الجهاز، نتائج المبيعات
تعمل شركة Wonder حاليًا على التركيز في بناء Kitchen Runtime وRobotics Execution في الوسط.
7. العلاقة مع OPENFOOD
تشير هذه التغيّر أيضًا إلى أن أهم مسألة في الطهي الذكي المستقبلي قد لا تكون من يصنع المزيد من الروبوتات.
المسألة الأساسية هي:
كيف يمكن للطبق أن يصبح أصلاً رقمياً قابلاً للتنفيذ عبر الأجهزة، والمتاجر، والآلات.
من الطبيعي أن تُنشئ شركات الروبوتات تنسيق وصفاتها الخاص.
كما ستنشئ شركات الأجهزة نظامها الخاص من المعلمات.
إذا امتلكت كل شركة أجهزة مجموعة مستقلة من Recipe Runtime، سيظهر في قطاع الضيافة عدد كبير من “أنظمة تشغيل الوصفات” غير المتوافقة.
لذلك فإن طبقة البروتوكول لها قيمة مستقلة.
يمكن تشكيل:
OPENFOOD Recipe Protocol → Machine-readable Recipe → Kitchen Runtime → Robot / Equipment → Dish Execution → Proof of Dish Sold
من بينها، OPENFOOD أكثر ملاءمة لتولي:
بنية الوصفة + تعريف الحقول + تجريد الجهاز + إدارة الإصدارات + المعايرة عبر الأجهزة + سجلات التنفيذ + قبول النتائج
يتولى مصنعو الأجهزة التنفيذ.
طبقة البروتوكول مسؤولة عن الوصف.
بهذه الطريقة يمكن أن تتحول الوصفة من “برنامج الجهاز” على جهاز معين إلى أصل رقمي قابل للنقل فعليًا.
ثامناً، لا تُعد DoorDash × Wonder نفسها جزءًا من صفقة FDEPE (دليل من الطرف المعارض).
يجب التمييز بين مستويين.
الصفقة بين DoorDash و Wonder، وفقًا للمعلومات المتاحة حاليًا، هي:
DoorDash → USD 300,000,000 لشراء Campus Dining → USD 125,000,000 للاستثمار في Wonder
تستمر Wonder في التركيز على:
AI ＋ Robotics ＋ Kitchen Infrastructure ＋ Food Production
لا توجد أدلة عامة حالياً تُظهر:
- قامت DoorDash بإرسال فريق FDE إلى Wonder؛
- أنشأت الطرفان فريق هندسة تحويل مشترك؛
- شاركت DoorDash مباشرة في تحويل نظام مطبخ Wonder؛
- ربط عائد الاستثمار بنتائج التحويل التشغيلي المحددة؛
- هناك آلية تحويل FDE ما بعد الاستثمار النموذجية على طريقة PE.
لذلك، يُعَدّ هذا الصفقة أكثر ملاءمة لتُعرّف كـ:
استثمار استراتيجي + إعادة هيكلة أصول + تنسيق صناعي.
تتواجد خصائص FDE أساساً في نظام الروبوتات والتسويق التجاري B2B الخاص بـ Wonder.
9. لماذا تستحق Wonder أن تكون حالة “FDE للغذاء”
القيمة البحثية الأكبر لـ Wonder هي أنها تعيد هندسة المعرفة التي يعتمد عليها قطاع الطعام بشدة على البشر.
عادةً ما يكون مسار توسيع المطاعم التقليدية:
الخبير → التدريب → SOP → مدير المتجر → المشرف → النسخ
تحاول Wonder مسارًا آخر:
خبرة الخبراء → الرقمنة → الهندسة → البرمجيات → تنفيذ الآلة → ملاحظات الموقع → ترقية المنصة → النسخ مرة أخرى
يتحول نسخ المنظمة تدريجيًا إلى نسخ نظامي.
يتحول نسخ الخبرة تدريجيًا إلى نسخ معلمات.
يتحول التدريب البشري تدريجيًا إلى نشر البرامج.
يتحول توسيع المتاجر تدريجيًا إلى نشر وقت التشغيل (Runtime Deployment).
هذا هو التغيير الأكثر جدارة بالملاحظة عندما تدخل فكرة FDE الصناعة المادية.
إذا عُرِّف ذلك بجملة واحدة:
تُنشئ Wonder نظامًا للروبوتات الموزعة مسبقًا (Forward-Deployed Robotics) / الهندسة الطهوية في قطاع المطاعم: يدخل فريق الهندسة إلى مطبخ حقيقي، يحول وصفات البشر وخبرات التشغيل إلى نظام يمكن للآلة تنفيذه، ثم يدمج الخبرات الميدانية باستمرار في المنصة وينسخها إلى المتجر التالي.
من هذا المنظور، ما يستحق الدراسة حقًا في Wonder ليس الروبوتات فقط.
إنها تحاول تحويل عملية إنتاج الطعام بأكملها إلى بنية تحتية برمجية يمكن نشرها وتشغيلها وتعلمها وتكرارها.
مصادر مرجعية ومنهجية البحث
نظام الهندسة على نمط FDE، وFood Runtime، والطبقات الصناعية المذكورة في النص هي استنتاجات بحثية وليست تسميات رسمية من Wonder. يمكن أن توضح مسؤوليات التوظيف العامة تصميم الوظيفة، لكنها لا تثبت بمفردها حجم نشر الفريق أو أداء الأعمال أو تغطية جميع المتاجر.