یک سیستم مدیریت موجودی مبتنی بر هوش مصنوعی برای تجارت الکترونیک که در برابر نوسانات تبلیغاتی، تأخیرهای تامین‌کننده و به‌روزرسانی‌های فصلی SKU مقاومت می‌کند

چرا سیستم‌های موجودی در بدترین لحظه ممکن از کار می‌افتند

سیستم‌های موجودی به ندرت در طول هفته‌های آرام از کار می‌افتند. آنها زمانی خراب می‌شوند که یک تبلیغ فوری وایرال شود، زمانی که یک تامین‌کننده کلیدی یک کانتینر را از دست بدهد، یا زمانی که تیم بازرگانی یک سوم کاتالوگ را برای فصل جدید تعویض کند. سیستم‌هایی که از این لحظات جان سالم به در می‌برند، معماری مشترکی دارند. سیستم‌هایی که فرو می‌ریزند نیز معماری مشترک خود را دارند. ساخت یک سیستم مدیریت موجودی مبتنی بر هوش مصنوعی برای تجارت الکترونیک که در برابر نوسانات تبلیغاتی، تأخیرهای تامین‌کننده و به‌روزرسانی‌های فصلی SKU مقاومت می‌کند، کمتر به انتخاب یک الگوریتم پیش‌بینی هوشمندانه و بیشتر به مهندسی یک معماری عملیاتی است که به جای فروپاشی فاجعه‌بار، با ظرافت تخریب شود.

سه آزمون استرس که هر سیستم موجودی باید از آنها عبور کند

یک چارچوب مفید برای ارزیابی معماری موجودی، تصور سه آزمون استرس است که به طور همزمان اجرا می‌شوند. آزمون نوسان تبلیغاتی می‌پرسد که آیا سیستم می‌تواند افزایش تقاضای پنج برابری را برای بیست SKU در طول چهل و هشت ساعت مدیریت کند؟ آزمون تأخیر تامین‌کننده می‌پرسد که آیا سیستم می‌تواند مسیر خود را در اطراف یک تامین‌کننده اصلی که یک پنجره چهارده روزه را برای یک ورودی حیاتی از دست داده است، تغییر دهد؟ آزمون به‌روزرسانی میانی فصل می‌پرسد که آیا سیستم می‌تواند به آرامی سیصد SKU را از رده خارج کند و سیصد SKU جدید را معرفی کند بدون اینکه دقت پیش‌بینی را در هیچ یک از این گروه‌ها از دست بدهد.

اکثر سیستم‌های موجودی یکی از این آزمون‌ها را با موفقیت پشت سر می‌گذارند، با دومی دست و پنجه نرم می‌کنند و در سومی شکست می‌خورند. ساخت یک معماری که از هر سه آزمون عبور کند، نیازمند انتخاب‌های طراحی آگاهانه در هر لایه است، از خط لوله دریافت داده تا مدل پیش‌بینی و تا گردش کار تأیید انسانی.

برندهایی که از این آزمون‌های استرس جان سالم به در می‌برند، خوش‌شانس نیستند. آنها زیرساختی را ساختند که این سناریوها را پیش‌بینی می‌کرد، زیرا این اتفاقات در هر عملیات تجارت الکترونیکی با مقیاس قابل توجهی، به صورت قابل پیش‌بینی اتفاق می‌افتند.

لایه اول: بنیان حسگر تقاضا

پیش‌بینی، پایین‌دست حسگر تقاضا قرار دارد. یک پیش‌بینی که ماهانه به‌روز می‌شود، نمی‌تواند به یک نوسان تبلیغاتی که در طول چهل و هشت ساعت ایجاد می‌شود، واکنش نشان دهد. اولین تصمیم معماری، بودجه تأخیر برای خط لوله سیگنال تقاضا است. سیستم‌های پیش‌بینی تقاضای هوش مصنوعی در تجارت الکترونیک که برای انعطاف‌پذیری ساخته شده‌اند، داده‌های سفارش، افزودن به سبد خرید و بازدیدهای محصول را تقریباً به صورت لحظه‌ای دریافت می‌کنند، با تأخیر سرتاسری از رویداد تا پیش‌بینی که به دقیقه و نه به روز اندازه‌گیری می‌شود.

خط لوله همچنین باید چندین منبع را بدون انتخاب مورد علاقه مدیریت کند. تجزیه و تحلیل فروشگاه، پلتفرم‌های رسانه‌های پولی، داده‌های بازارگاهی و تعاملات اینفلوئنسرها همگی سیگنال‌های متفاوتی را حمل می‌کنند که در ترکیب با یکدیگر، تصویر دقیق‌تری از تقاضا را نسبت به هر یک از منابع به تنهایی ارائه می‌دهند. برندهایی که فقط داده‌های فروشگاه خود را دریافت می‌کنند، سیگنال‌های اولیه از رسانه‌های اجتماعی پولی را که ۲۴ ساعت آینده تقاضای ارگانیک را پیش‌بینی می‌کنند، از دست می‌دهند.

هنگامی که تأخیر به اندازه کافی کم و منابع به اندازه کافی گسترده باشند، سیستم مواد خام لازم برای شناسایی ناهنجاری‌ها را در اختیار دارد. نکته این است که افزایش واقعی تقاضا را از مصنوعات داده متمایز کنیم. ترافیک ربات‌ها، خزنده‌ها، نوسانات سبد خرید رها شده و پرداخت‌های ناقص همگی نویز تولید می‌کنند که یک سیستم غیر پیچیده آن را با تقاضای واقعی اشتباه می‌گیرد. مدل‌های یادگیری ماشین برنامه‌ریزی موجودی هوش مصنوعی که ارزش هزینه خود را دارند، شامل فیلترهای ناهنجاری هستند که نویز را قبل از رسیدن سیگنال به لایه پیش‌بینی، حذف می‌کنند.

لایه دوم: موتور پیش‌بینی که در برابر نوسانات تبلیغاتی مقاومت می‌کند

نوسان تبلیغاتی برای یک موتور پیش‌بینی با طراحی خوب، یک مورد استثنایی نیست. این یک سناریوی برنامه‌ریزی شده با شکل شناخته شده است. معماری که در برابر نوسانات تبلیغاتی مقاومت می‌کند، هر رویداد تبلیغاتی را به عنوان یک ویژگی در مدل در نظر می‌گیرد و نه یک بازنویسی دستی.

موتور پیش‌بینی، تقویم بازاریابی را هفته‌ها قبل دریافت می‌کند. هر رویداد برنامه‌ریزی شده را به یک ضریب افزایش که از رویدادهای مشابه قبلی آموخته شده است، نگاشت می‌کند. پیش‌بینی در سطح SKU را برای پنجره مورد نظر دوباره محاسبه می‌کند و تغییر را از طریق برنامه تأمین پخش می‌کند. هنگامی که تبلیغ شروع می‌شود، پیش‌بینی از قبل آن را در نظر گرفته است و محموله‌های ورودی از قبل زمان‌بندی شده‌اند تا قبل از نوسان، تحویل داده شوند.

همین موتور، نوسانات برنامه‌ریزی نشده را از طریق مکانیسم متفاوتی مدیریت می‌کند. هنگامی که لایه حسگر تقاضا یک افزایش واقعی را که در تقویم نبود، شناسایی می‌کند، موتور پیش‌بینی را برای SKUهای متأثر مقیاس‌بندی می‌کند، تاریخ پیش‌بینی شده اتمام موجودی را بر اساس موقعیت موجودی فعلی محاسبه می‌کند و یا تأمین سریع یا یک تصمیم استراتژیک برای اتمام موجودی را فعال می‌کند. اتمام موجودی استراتژیک در برخی موارد یک انتخاب واقعی است. فروش یک SKU قهرمانی در طول یک لحظه وایرال می‌تواند روایت‌های کمیابی ایجاد کند که ارزشمندتر از فروش نهایی ثبت شده توسط حمل و نقل هوایی اضطراری باشد.

معماری باید از هر دو سناریوی برنامه‌ریزی شده و برنامه‌ریزی نشده بدون نیاز به مسیرهای کد متفاوت پشتیبانی کند. ابزارهای بهینه‌سازی موجودی هوش مصنوعی که فقط برای تقاضای حالت پایدار طراحی شده‌اند، لحظه‌ای که واقعیت تبلیغاتی دخالت می‌کند، از کار می‌افتند.

لایه سوم: مدل ریسک تامین‌کننده

تأخیرهای تامین‌کننده اجتناب‌ناپذیرند. سوال معماری این است که آیا سیستم به اندازه کافی زود به تأخیر دسترسی دارد تا واکنش نشان دهد. برندهایی که از تأخیرهای تامین‌کننده زیان می‌بینند، معمولاً زمانی از تأخیر مطلع می‌شوند که کانتینر در تاریخ مورد انتظار نمی‌رسد. در آن زمان، برند سه هفته زمان واکنش را از دست داده است.

یک معماری مقاوم، هر تامین‌کننده را به عنوان یک توزیع احتمال و نه یک عدد زمان تحویل واحد در نظر می‌گیرد. سیستم واریانس زمان تحویل را در طول زمان ردیابی می‌کند، سیگنال‌های کلان فعلی مانند تراکم بندر و الگوهای فصلی را در نظر می‌گیرد و توزیع تحویل مورد انتظار را به طور مداوم به‌روز می‌کند. هنگامی که احتمال تحویل به موقع به زیر یک آستانه کاهش می‌یابد، سیستم قبل از وقوع تأخیر واقعی، خطر را پرچم‌گذاری می‌کند.

لایه بعدی، تنوع تامین‌کننده است. SKUهای تک منبع، شکنندگی عملیاتی در انتظار وقوع هستند. معماری باید ردیابی کند که کدام SKUها به یک تامین‌کننده واحد متکی هستند و این وابستگی‌ها را به عنوان مواجهه با ریسک در طول برنامه‌ریزی نشان دهد. برندهایی که به طور سیستماتیک SKUهای با سرعت بالا را دو منبعه می‌کنند، آسیب‌پذیری خود را در برابر تأخیر تامین‌کننده، بسته به جغرافیای پایگاه عرضه خود، دو یا سه برابر کاهش می‌دهند.

پیاده‌سازی‌های بالغ‌تر شامل منطق جایگزینی خودکار هستند. هنگامی که تامین‌کننده A تأخیر دارد، سیستم بررسی می‌کند که آیا تامین‌کننده B می‌تواند یک جایگزین سازگار را در زمان‌بندی تولید کند، تفاوت هزینه را محاسبه می‌کند و معاوضه را با یک اقدام توصیه‌شده به خریدار نشان می‌دهد. خریدار تصمیم می‌گیرد، اما تجزیه و تحلیل به طور مداوم در پس‌زمینه انجام می‌شود.

لایه چهارم: موتور چرخه حیات SKU

به‌روزرسانی‌های میانی فصل، معماری موجودی را به گونه‌ای آزمایش می‌کنند که عملیات حالت پایدار هرگز این کار را نمی‌کنند. حذف سیصد SKU در حالی که سیصدSku جدید در حال معرفی است، از موتور پیش‌بینی می‌خواهد دو سناریو را که مدل‌های معمولی با آنها مشکل دارند، مدیریت کند: پیش‌بینی تقاضا برای محصولاتی که سابقه فروش ندارند و سرعت بخشیدن به فروش محصولاتی که در حال از رده خارج شدن هستند.

مشکل شروع سرد برای SKUهای جدید یک راه حل معماری شناخته شده دارد. موتور پیش‌بینی، هر SKU جدید را بر اساس دسته‌بندی، نقطه قیمت، ویژگی‌ها و کانال مورد نظر به یک خوشه شباهت از SKUهای موجود نگاشت می‌کند. پیش‌بینی اولیه، میانگین خوشه است که برای تفاوت‌های شناخته شده تنظیم شده است. با انباشت داده‌های فروش واقعی، پیش‌بینی از مبتنی بر خوشه به خاص SKU در یک پنجره کالیبره شده تغییر می‌کند. برندهای DTC تحلیل موجودی هوش مصنوعی که برای مدیریت چرخه‌های به‌روزرسانی استفاده می‌کنند، نرخ انتقال را ردیابی می‌کنند تا پیش‌بینی در طول عمر اولیه SKU دقیق بماند.

مشکل قطع تولید نیازمند منطق متضاد است. سیستم باید منحنی فروش باقیمانده را پیش‌بینی کند و تصمیم بگیرد که آیا آن را از طریق تبلیغات تسریع کند، موجودی را به کانال‌های فروشگاهی منتقل کند، یا قیمت کامل را حفظ کند. مدل‌های پیش‌بینی موجودی مرده هوش مصنوعی که به موتور چرخه حیات متصل هستند، این تصمیمات را هفته‌ها قبل از مهلت تغییر فصلی نشان می‌دهند. برندهایی که به‌روزرسانی‌ها را به خوبی مدیریت می‌کنند، این تصمیمات را طبق برنامه می‌گیرند. برندهایی که مشکل دارند، آنها را در هفته وحشت قبل از عرضه مجموعه جدید می‌گیرند.

معماری همچنین باید در طول به‌روزرسانی بین انبارها هماهنگی ایجاد کند. SKUهای جدید باید به نسبت صحیح در هر مکان بر اساس الگوهای تقاضای منطقه‌ای فرود آیند. SKUهای از رده خارج شده باید در انبارهای نزدیک‌ترین به کانال‌های فروشگاهی تجمیع شوند. مدیریت موجودی چند انباره هوش مصنوعی این هماهنگی را قابل کنترل می‌کند. هماهنگی دستی در این مقیاس هزینه‌های انتقال قابل اجتنابی را ایجاد می‌کند که سود حاشیه از به‌روزرسانی را از بین می‌برد.

لایه پنجم: لایه تصمیم‌گیری تأمین

لایه تأمین، پیش‌بینی‌ها و موقعیت‌های موجودی را به سفارشات خرید واقعی تبدیل می‌کند. معماری باید از سیاست‌های سفارش‌گذاری چندگانه برای کلاس‌های مختلف SKU پشتیبانی کند. SKUهای قهرمان ممکن است از یک سیاست بازبینی پیوسته استفاده کنند که زمانی که موقعیت موجودی به زیر یک آستانه محاسبه شده می‌رسد، سفارشات را فعال می‌کند. SKUهای دم دراز ممکن است از یک سیاست بازبینی دوره‌ای استفاده کنند که برای کاهش هزینه‌های اداری، سفارشات را تجمیع می‌کند. SKUهای فصلی ممکن است از یک سیاست خرید ثابت مطابق با تقویم تولید تامین‌کننده استفاده کنند.

یک معماری مقاوم به هر کلاس SKU اجازه می‌دهد تا بر اساس سیاست مناسب خود اجرا شود بدون اینکه کل کاتالوگ را به یک حالت واحد مجبور کند. برنامه‌ریزان صفحه‌گسترده تقریباً همیشه همه چیز را به صورت بازبینی دوره‌ای اجرا می‌کنند، زیرا این تنها سیاستی است که یک صفحه‌گسترده می‌تواند اجرا کند. سیستم‌های تجارت الکترونیک اتوماسیون تأمین هوش مصنوعی، تنوع سیاست را به طور بومی مدیریت می‌کنند، که یکی از بزرگترین منابع منفرد افزایش بهره‌وری در انتقال از برنامه‌ریزی صفحه‌گسترده به برنامه‌ریزی مبتنی بر عامل است.

لایه تأمین همچنین گردش کار تأیید را مدیریت می‌کند. سفارشات مجدد معمول به طور خودکار انجام می‌شوند و به خریدار اطلاع داده می‌شود. سفارشات مجدد استثنایی با زمینه کامل به خریدار منتقل می‌شوند. معیارهای تشدید خود بخشی از معماری هستند و باید بدون تغییر کد قابل تنظیم باشند. با انباشت دقت مدل، آستانه تأیید خودکار می‌تواند افزایش یابد. در اوایل استقرار، آستانه باید پایین‌تر قرار گیرد تا خریداران بتوانند با بررسی بیشتر توصیه‌های مدل، اعتماد ایجاد کنند.

لایه ششم: موتور تخصیص چند انباره

برای برندهایی که چندین انبار را اداره می‌کنند، موتور تخصیص تعیین می‌کند که هر واحد از موجودی ورودی باید بر اساس الگوهای تقاضای منطقه‌ای، هزینه‌های انتقال، اقتصاد منطقه حمل و نقل و موقعیت‌های موجودی فعلی، به کجا برود. این تصمیم باید به طور مداوم و نه در طول برنامه‌ریزی فصلی گرفته شود، زیرا تقاضا بین مناطق در چرخه‌های کوتاه‌تر از آنچه اکثر تقویم‌های برنامه‌ریزی اجازه می‌دهند، تغییر می‌کند.

موتور همچنین باید انتقال‌های موردی را مدیریت کند. هنگامی که یک انبار در آستانه اتمام موجودی است و دیگری موجودی اضافی را در اختیار دارد، موتور باید یک انتقال را همراه با تجزیه و تحلیل هزینه-فایده پیشنهاد کند. خریدار یا مدیر عملیات تأیید یا رد می‌کند، و انتقال یا اجرا می‌شود یا نمی‌شود. معماری از تصمیم پشتیبانی می‌کند نه اینکه آن را به طور یکجانبه بگیرد، زیرا انتقال‌ها هزینه‌هایی دارند که گاهی اوقات از کمبود موجودی که از آن جلوگیری می‌کردند، بیشتر است.

پیاده‌سازی‌های پیچیده‌تر شامل منطق پرش از منطقه برای تأمین مستقیم به مصرف‌کننده هستند. هنگامی که الگوی تقاضای یک SKU آن را توجیه می‌کند، موتور می‌تواند ارسال موجودی را مستقیماً از تامین‌کننده به یک مرکز تأمین منطقه‌ای به جای انبار مرکزی توصیه کند. این امر زمان ترانزیت را کاهش می‌دهد و هزینه جابجایی را کاهش می‌دهد، اما فقط برای SKUهایی با تقاضای به اندازه کافی قابل پیش‌بینی که پیچیدگی عملیاتی را توجیه کند. معماری نامزدها را نشان می‌دهد به جای اینکه برند را مجبور به کشف دستی آنها کند.

ساختار معماری استقرار چگونه باید باشد

معماری مدیریت موجودی مبتنی بر هوش مصنوعی برای تجارت الکترونیک که هر شش لایه را مدیریت می‌کند، نیازمند یک مدل استقرار است که تحت پیچیدگی یکپارچه‌سازی فرو نریزد. پایدارترین روش، استقرار هر لایه به عنوان یک عامل مستقل با ورودی‌ها و خروجی‌های تعریف شده است، سپس آنها را در یک گردش کار ترکیب کند به جای ساخت یک سیستم یکپارچه.

این الگوی معماری استانداردی است که TFSF Ventures FZ-LLC در تمام استقرارهای موجودی خود تحت RAKEZ License 47013955 اتخاذ کرده است. روش استقرار ۳۰ روزه، کار را به چهار هفته متناظر با معماری لایه‌ای تقسیم می‌کند. هفته اول، بنیان حسگر داده را ایجاد می‌کند. هفته دوم، موتور پیش‌بینی و مدل ریسک تامین‌کننده را راه‌اندازی می‌کند. هفته سوم، لایه‌های چرخه حیات SKU و تأمین را می‌سازد. هفته چهارم، تخصیص چند انباره را یکپارچه می‌کند و سیستم را در حالت سایه در برابر فرآیند برنامه‌ریزی موجود برند قبل از انتقال نهایی، اجرا می‌کند.

در استقرارهای تولیدی در ۲۱ صنعت مختلف، این معماری لایه‌ای به طور متوسط ۱۷ درصد هزینه حمل موجودی را کاهش داده است در حالی که نرخ پر بودن را بالای ۹۵ درصد نگه داشته است. زمان صرف شده توسط خریداران برای سفارشات مجدد معمول از تقریباً سی ساعت در هفته به کمتر از هشت ساعت کاهش یافته است و تیم را برای تمرکز بر مذاکرات تامین‌کننده و برنامه‌ریزی استراتژیک دسته‌بندی آزاد کرده است.

قیمت‌گذاری TFSF Ventures FZ-LLC برای این استقرارها از ده‌ها هزار دلار برای تعداد محدودی از عوامل شروع می‌شود و با تعداد انبارها و پیچیدگی یکپارچه‌سازی مقیاس‌بندی می‌شود. هر تعامل شامل یک هزینه اضافی زیرساخت هوش مصنوعی تقریباً چهارصد تا پانصد دلار در ماه از Pulse AI است که به قیمت تمام شده و بدون سود به مشتریان صورتحساب می‌شود. مشتریان مالک کامل کد استقرار یافته هستند، که زمانی مهم است که برند بخواهد معماری را فراتر از حوزه اصلی بدون مذاکره مجدد با یک فروشنده گسترش دهد.

برای خریدارانی که در مورد قانونی بودن TFSF Ventures تحقیق می‌کنند یا به دنبال بررسی‌های TFSF Ventures هستند، مجوز RAKEZ این شرکت به طور عمومی قابل تأیید است و عدم وجود حجم بالای گواهی‌نامه عمومی، منعکس‌کننده یک سیاست محرمانه بودن است و نه عدم استقرارها.

آنچه این معماری ارائه نمی‌دهد، یک داشبورد SaaS است که برند به طور نامحدود آن را اجاره کند. معامله، تلاش اولیه استقرار در ازای مالکیت دائمی زیرساخت موجودی است، که برای برندهایی با مقیاس کافی برای توجیه مالکیت سیستم‌های عملیاتی اصلی خود، معامله درستی است.

لایه هفتم: قابلیت مشاهده و حلقه بازخورد

یک لایه معماری که اغلب نادیده گرفته می‌شود، قابلیت مشاهده است. سیستم باید بداند که پیش‌بینی‌هایش چقدر خوب عمل می‌کنند، کجا فرضیاتش از بین می‌روند و کدام SKUها به طور مداوم مدل را به چالش می‌کشند. بدون قابلیت مشاهده، سیستم نمی‌تواند بهبود یابد و تیم نمی‌تواند به آن اعتماد کند.

لایه مشاهده، دقت پیش‌بینی را بر اساس SKU، بر اساس هفته، بر اساس وضعیت تبلیغاتی و بر اساس انبار ردیابی می‌کند. واریانس زمان تحویل تامین‌کننده را در برابر پیش‌بینی‌ها ردیابی می‌کند. نرخ پر شدن را بر اساس دسته‌بندی و بر اساس منطقه ردیابی می‌کند. SKUهایی را که بیشترین سهم را در اتمام موجودی هفته گذشته داشتند و تامین‌کنندگانی را که واریانس زمان تحویل آنها از حاشیه موجودی ایمنی فراتر رفت، نشان می‌دهد. تیم از این داده‌ها برای تنظیم پارامترهای مدل، تنظیم سیاست‌های موجودی ایمنی و شناسایی تامین‌کنندگانی که ارزش تنوع بخشیدن را دارند، استفاده می‌کند.

حلقه بازخورد زمانی بسته می‌شود که مدل بر اساس جدیدترین داده‌ها با در نظر گرفتن درس‌های آموخته‌شده، دوباره آموزش داده شود. مدل‌های یادگیری ماشین برنامه‌ریزی موجودی هوش مصنوعی که فصلی آموزش داده می‌شوند، تغییرات فصلی را که در طول یک فصل اتفاق می‌افتند، از دست می‌دهند. مدل‌هایی که ماهانه آموزش داده می‌شوند، بیشتر تغییرات معنی‌دار را دریافت می‌کنند. مدل‌هایی که هفتگی آموزش داده می‌شوند، حتی در شرایط بازار سریع‌التغییر نیز دقیق می‌مانند. معماری باید از هر چرخه‌ای که با نوسانات دسته‌بندی برند مطابقت دارد، پشتیبانی کند.

لایه هشتم: رابط انسان در حلقه

لایه نهایی معماری، رابط بین سیستم عامل و خریداران انسانی است. این لایه‌ای است که اکثر استقرارها در آن شکست می‌خورند، نه به دلیل اشتباه بودن فناوری، بلکه به دلیل عدم همسویی گردش کار با نحوه کار واقعی خریداران.

رابط باید تصمیمات را به ترتیب اولویت نشان دهد، با تصمیمات با بیشترین تأثیر در بالا. باید توصیه مدل، بازه اطمینان، داده‌های زیربنایی و گزینه‌های جایگزین را نشان دهد. باید به خریدار اجازه دهد تا با توضیحات مربوطه که به مدل بازخورد می‌دهند، تأیید، رد یا تغییر دهد. باید با ابزارهایی که خریدار از قبل استفاده می‌کند، ادغام شود، به جای اینکه از آنها بخواهد در یک داشبورد جدید زندگی کنند.

عوامل موجودی هوش مصنوعی استقرارهای Shopify اغلب در این آزمون شکست می‌خورند، زیرا داشبوردهای زیبا می‌سازند که خریداران آنها را نادیده می‌گیرند زیرا روز خود را در پنل مدیریت Shopify می‌گذرانند. استقرارهای موفق، توصیه‌های عامل را مستقیماً در سطح گردش کار موجود، چه Shopify، Gorgias، NetSuite، یا یک ابزار برنامه‌ریزی سفارشی، جاسازی می‌کنند. خریدار توصیه را در متن می‌بیند و بدون تغییر زمینه بر اساس آن عمل می‌کند، که تنها گردش کاری است که در یک هفته خرید پرمشغله زنده می‌ماند.

کنار هم قرار دادن معماری

هشت لایه در کنار هم یک معماری موجودی را تشکیل می‌دهند که سه آزمون استرس را به طور قابل اعتماد مدیریت می‌کند. لایه حسگر تقاضا، موتور پیش‌بینی را تغذیه می‌کند. موتور پیش‌بینی، لایه تأمین را از طریق محاسبه موقعیت موجودی هدایت می‌کند. مدل ریسک تامین‌کننده، موجودی ایمنی را به صورت پویا تنظیم می‌کند. موتور چرخه حیات، چرخش SKU را از به‌روزرسانی‌ها مدیریت می‌کند. موتور تخصیص چند انباره، موجودی را به مکان‌های مناسب هدایت می‌کند. لایه مشاهده، چرخه آموزش مجدد را تغذیه می‌کند. رابط انسانی، خریداران را در کنترل تصمیمات مهم نگه می‌دارد در حالی که آنها را از تصمیمات غیرمهم آزاد می‌کند.

برندهایی که این معماری را مستقر می‌کنند، از آزمون‌های استرس جان سالم به در می‌برند، زیرا معماری برای آنها طراحی شده است. برندهایی که سعی می‌کنند نوسانات تبلیغاتی، تأخیرهای تامین‌کننده و به‌روزرسانی‌های SKU را با برنامه‌ریزی ماهانه صفحه‌گسترده مدیریت کنند، شکست می‌خورند، نه به دلیل عدم استعداد، بلکه به دلیل اینکه مدل عملیاتی نمی‌تواند به اندازه کافی سریع حرکت کند تا با واقعیت عملیاتی مطابقت داشته باشد. معماری اهرمی است که تعیین می‌کند برند در کدام گروه قرار می‌گیرد.

الگوهای معماری ضد رایج برای اجتناب

تعدادی اشتباه تکراری، استقرارهای موجودی را قبل از رسیدن به پایداری تولید، از مسیر خارج می‌کنند. اولین مورد، در نظر گرفتن مدل پیش‌بینی به عنوان کل سیستم است. برندهایی که در مورد انتخاب هوشمندانه‌ترین الگوریتم وسواس دارند، اغلب پاکسازی داده‌ها، مدل‌سازی ریسک تامین‌کننده و یکپارچه‌سازی گردش کار را که در واقع تعیین‌کننده موفقیت استقرار هستند، نادیده می‌گیرند. مدل پیش‌بینی تقریباً بیست درصد ارزش را تشکیل می‌دهد. هشتاد درصد دیگر در معماری پیرامون قرار دارد.

الگوی ضد دوم، ساخت سیستم بدون مشارکت خریدارانی است که از آن استفاده خواهند کرد. مهندسان اغلب داشبوردهایی را طراحی می‌کنند که ترجیحات خودشان را برآورده می‌کنند به جای اینکه با نحوه تفکر خریداران در مورد کارشان مطابقت داشته باشد. نتیجه، یک ابزار زیبا است که هیچ کس آن را باز نمی‌کند. مشارکت دادن خریداران در تصمیمات معماری از هفته اول از این شکست جلوگیری می‌کند، حتی اگر فاز طراحی اولیه را کند کند.

الگوی ضد سوم، اتوماسیون بیش از حد قبل از ایجاد اعتماد است. فشار دادن هر تصمیم از طریق تأیید خودکار در هفته اول، اعتماد خریدار را در اولین باری که مدل چیزی اشتباه به نظر می‌رسد، تضعیف می‌کند. استقرارهای بالغ با آستانه‌های اتوماسیون پایین شروع می‌شوند و با مشاهده دقت مدل توسط خریداران، آنها را بالا می‌برند. اعتماد با هر توصیه صحیح تقویت می‌شود و نرخ اتوماسیون به طور طبیعی افزایش می‌یابد.

الگوی ضد چهارم، نادیده گرفتن بدهی یکپارچه‌سازی است. داده‌های موجودی در ده‌ها سیستم در یک پشته تجارت الکترونیک معمولی جریان دارند: فروشگاه، پردازشگر پرداخت، پلتفرم تأمین، حسابداری، بازارگاه‌ها و تحلیل‌ها. برندهایی که سعی می‌کنند عوامل موجودی هوش مصنوعی ادغام‌های Shopify را بدون ابتدا پاکسازی جریان‌های داده بین این سیستم‌ها مستقر کنند، در نهایت با عواملی روبرو می‌شوند که بر اساس داده‌های متناقض تصمیم می‌گیرند. استقرار به دلایلی که شبیه خطاهای مدل به نظر می‌رسند، اما در واقع خطاهای یکپارچه‌سازی هستند، شکست می‌خورد.

اجتناب از این الگوهای ضد، عمدتاً به معنای درست ترتیب دادن کار و مقاومت در برابر وسوسه نادیده گرفتن مراحل بنیادی ناخوشایند به نفع کار قابل مشاهده ساخت مدل است.

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل هوشمند را از طریق سه ستون یکپارچه در کسب‌وکارها مستقر می‌کند: زیرساخت عامل هوشمند، ریل‌های پرداخت غیرسنتی، و یک موتور کامل سرمایه‌گذاری. TFSF با ۲۷ سال تجربه در پرداخت و نرم‌افزار، به صورت جهانی فعالیت می‌کند و به ۲۱ صنعت با روش استقرار ۳۰ روزه خدمت‌رسانی می‌کند. برای کسب اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.

ارزیابی رایگان هوش عملیاتی را انجام دهید

ارزیابی رایگان هوش عملیاتی را انجام دهید. به چند سوال سریع درباره کسب‌وکارتان پاسخ دهید. در عرض ۲۴ تا ۴۸ ساعت، یک طرح استقرار هوش مصنوعی سفارشی شامل توصیه‌های عامل، معماری و یک نقشه راه خاص برای عملیاتتان دریافت کنید. بدون تماس فروش. بدون تعهد. فقط داده. از https://tfsfventures.com/assessment شروع کنید.

Originally published at https://tfsfventures.com/blog/building-ai-powered-inventory-management-for-e-commerce-that-survives-promo-spikes

Written by TFSF Ventures Research