معماری مدیریت موجودی مبتنی بر هوش مصنوعی در پلتفرم‌های Shopify، NetSuite، Cin7 و موتورهای مستقل پیش‌بینی تقاضا

چرا معماری نتایج موجودی را در پشته‌های پلتفرم ترکیبی تعیین می‌کند

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

واقعیت چهار-سیستم که بیشتر برندها در آن فعالیت می‌کنند

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

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

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

اصل اول معماری: ایجاد یک منبع واحد حقیقت برای هر حوزه داده

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

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

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

اصل دوم معماری: تأخیر یکپارچه‌سازی را به عنوان یک پارامتر طراحی در نظر بگیرید

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

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

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

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

اصل سوم معماری: لایه تصمیم‌گیری را از لایه داده جدا کنید

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

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

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

اصل چهارم معماری: یکپارچه‌سازی را به صورت Idempotent و Replayable بسازید

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

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

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

اصل پنجم معماری: لایه مشاهده‌پذیری را از روز اول بسازید

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

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

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

رویکرد TFSF Ventures به معماری موجودی چندسیستمی

اصول معماری بالا نشان دهنده یک استقرار منضبط است، اما اجرای آنها نیازمند یک متدولوژی استقرار است که یکپارچگی را به عنوان یک نگرانی درجه یک و نه یک فکر بعدی در نظر بگیرد. TFSF Ventures FZ-LLC (RAKEZ License 47013955) استقرار موجودی خود را بر اساس یک متدولوژی 30 روزه ساختار می‌دهد که لایه یکپارچه‌سازی را در هفته اول قبل از ساخت هر منطق تصمیم بر روی آن، می‌سازد.

در استقرارهای تولید در 21 صنعت مختلف، این رویکرد بدهی یکپارچه‌سازی را به حدی کاهش داده است که برندها می‌توانند مدل‌های برنامه‌ریزی را تغییر دهند یا عوامل تصمیم‌گیری جدیدی اضافه کنند بدون اینکه نیاز به مذاکره مجدد در مورد یکپارچه‌سازی با Shopify، NetSuite، Cin7 یا سایر سیستم‌های عملیاتی داشته باشند. دقت پیش‌بینی در تولید به طور متوسط 23 درصد نسبت به برنامه‌ریزی اولیه با صفحات گسترده بهبود یافته و هزینه نگهداری موجودی به طور متوسط 17 درصد کاهش یافته است، در حالی که نرخ تکمیل بالای 95 درصد حفظ شده است. این صرفه‌جویی‌ها به همان اندازه که از پیچیدگی مدل‌سازی ناشی می‌شوند، از نظم معماری نیز نتیجه می‌گیرند، زیرا داده‌های پاک، پیش‌بینی‌های دقیق را هدایت می‌کنند.

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

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

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

اصل ششم معماری: عوامل تصمیم‌گیری را حول مدل داده یکپارچه طراحی کنید

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

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

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

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

اصل هفتم معماری: برای موتور پیش‌بینی مستقل برنامه‌ریزی کنید

بسیاری از برندها در مقیاس بزرگ، علاوه بر قابلیت‌های برنامه‌ریزی موجود در Shopify، NetSuite، یا Cin7، یک موتور مستقل پیش‌بینی تقاضا را نیز اجرا می‌کنند. موتور مستقل معمولاً به این دلیل وجود دارد که قابلیت‌های بومی سیستم‌های عملیاتی برای پیچیدگی دسته برند، به اندازه کافی پیشرفته نیستند.

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

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

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

اصل هشتم معماری: گردش کار انسانی را پیرامون معماری بسازید

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

گردش کار باید توصیه‌های عامل را در ابزارهایی که تیم قبلاً استفاده می‌کند تعبیه کند، به جای اینکه از آن‌ها بخواهد در یک داشبورد جدید کار کنند. استقرارهای عوامل موجودی هوش مصنوعی Shopify اغلب توصیه‌ها را مستقیماً در پنل مدیریت Shopify نمایش می‌دهند، زیرا در آنجا خریداران بیشتر وقت خود را می‌گذرانند. توصیه‌هایی که بر موقعیت‌های موجودی مالی تأثیر می‌گذارند، در NetSuite نمایش داده می‌شوند. توصیه‌هایی که بر عملیات انبار تأثیر می‌گذارند، در Cin7 یا هر سیستم مدیریت انبار (WMS) که برند استفاده می‌کند، نمایش داده می‌شوند.

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

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

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

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

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

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

توالی استقرار

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

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

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

معماری نتیجه را تعیین می‌کند

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

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

کلام آخر در مورد تکرار بر روی معماری

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

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

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

نکته نهایی معماری

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

درباره TFSF Ventures

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

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

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

Originally published at https://tfsfventures.com/blog/architecting-ai-powered-inventory-management-across-shopify-netsuite-cin7

نوشته شده توسط TFSF Ventures Research