اتصال فروشگاه به ERP: الگوها و دامها
در پروژههای فروش سازمانی، برآوردی که از دست میرود تقریباً همیشه برآورد اتصالهاست، نه ساخت سبد خرید و پنل. دلیلش هم روشن است: بخشی از کار به سامانهای وابسته است که شما ننوشتهاید، مستنداتش را ندیدهاید، و تیم پشتیبانیاش مال شما نیست.
اول: منبع حقیقت را مشخص کنید
پیش از هر بحث فنی، برای هر نوع داده یک سؤال جواب بدهد: کدام سامانه صاحب این داده است؟
پاسخ متعارف:
| داده | صاحب | جهت |
|---|---|---|
| کالا و مشخصات پایه | ERP | ERP ← فروشگاه |
| محتوای فروش، عکس، توضیح | فروشگاه | داخلی |
| قیمت پایه | ERP | ERP ← فروشگاه |
| قیمت و تخفیف آنلاین | فروشگاه | داخلی |
| موجودی | انبار / ERP | ERP ← فروشگاه |
| مشتری و مانده اعتبار | ERP | ERP ← فروشگاه |
| سفارش | فروشگاه | فروشگاه ← ERP |
| فاکتور و سند مالی | ERP | ERP ← فروشگاه |
قاعدهای که از این جدول بیرون میآید و باید رعایت شود: هر داده فقط یک صاحب دارد. اگر قیمت هم در ERP و هم در فروشگاه قابل ویرایش باشد، دیر یا زود دو عدد متفاوت خواهید داشت و هیچ قاعدهای نمیگوید کدام درست است.
استثنای رایج و قابل قبول: قیمت پایه از ERP میآید ولی تخفیفهای کمپینی در فروشگاه تعریف میشوند. این کار میکند چون دو چیز متفاوتند، نه دو نسخه از یک چیز.
سه الگوی همگامسازی
فراخوانی لحظهای. فروشگاه در همان لحظه از ERP میپرسد. دقیقترین، و وابسته به اینکه آن سرویس همیشه در دسترس و سریع باشد. برای مانده اعتبار مناسب است، برای کاتالوگ نه.
نکتهای که باید از قبل تصمیم گرفته شود: اگر پاسخی نیامد چه میشود؟ سفارش رد میشود، یا با آخرین داده شناختهشده ثبت و علامتدار میشود؟ در عمل، حالت دوم تقریباً همیشه بهتر است — از دست دادن یک سفارش بهخاطر کندی یک سرویس داخلی، گرانتر از بررسی بعدی آن است.
همگامسازی دورهای. هر چند دقیقه یا ساعت. مقاومتر و ناهمگامتر. برای کاتالوگ و موجودی معمولاً کافی است. برای اینکه سنگین نشود، فقط تغییرات را منتقل کنید نه کل داده — که یعنی ERP باید بتواند بگوید از فلان زمان چه چیزی عوض شده. اگر نمیتواند، مجبورید کل کاتالوگ را بخوانید و مقایسه کنید، و این را باید در برآورد ببینید.
رویدادمحور. هر طرف تغییرات را اعلام میکند. بهترین ترکیب تازگی و کارایی، و نیازمند اینکه هر دو طرف از رویداد پشتیبانی کنند. ERPهای قدیمی معمولاً نمیکنند. دو مسئلهای که همراهش میآید — تحویل تکراری و ترتیب — در معماری API-first توضیح داده شده.
در عمل بیشتر پروژهها ترکیبی از هر سه را دارند: اعتبار لحظهای، کاتالوگ دورهای، سفارش رویدادمحور.
دامهای تکرارشونده
فرض اینکه ERP همیشه در دسترس است. نیست. هر تماسی باید مهلت، تلاش مجدد و رفتار جایگزین داشته باشد.
نداشتن صف. اگر سفارش مستقیم به ERP فرستاده شود و ERP بالا نباشد، سفارش گم میشود. صف بین دو سامانه یعنی سفارش نگه داشته میشود تا وقتی طرف مقابل برگردد.
نبود شناسه یکتای مشترک. کد کالا در فروشگاه و در ERP باید قابل نگاشت باشد. اگر نگاشت دستی است، هر کالای جدید یک کار دستی است — و همان جایی است که خطا تولید میشود.
نداشتن گزارش تطبیق. باید بشود پرسید «کدام سفارشهای امروز به ERP نرفتهاند؟» بدون این گزارش، شکافها را وقتی میفهمید که مشتری تماس بگیرد.
ورود دستی بهعنوان راهحل موقت. موقت نمیماند. اگر برای حالتی راه دستی بگذارید، آن حالت هرگز خودکار نمیشود.
تست فقط با داده تمیز. داده واقعی ERP کدهای تکراری، فیلدهای خالی و کاراکترهای عجیب دارد. با یک نمونه واقعی از تولید تست کنید، نه با ده رکورد ساختگی.
اگر ERP شما API ندارد
این حالت در بازار ایران رایج است. سه مسیر وجود دارد و هر سه محدودیت دارند:
خواندن مستقیم از پایگاه داده. برای خواندن گاهی قابل قبول است. برای نوشتن تقریباً هرگز، چون منطق کسبوکار ERP را دور میزنید و به داده ناسازگار میرسید.
فایل واسط. ERP فایل تولید میکند و شما میخوانید، یا برعکس. کند و قابل اتکا، و باید بپذیرید که همگامسازی تقریبی است.
لایه واسط. یک سرویس کوچک که کنار ERP مینشیند و آن را به API تبدیل میکند. تمیزترین گزینه در بلندمدت و یک پروژه مستقل با برآورد جدا.
هر کدام را انتخاب کردید، آن را در برآورد بهعنوان یک قلم مستقل ببینید، نه بهعنوان جزئیات پیادهسازی.
سؤالهایی که پیش از شروع جواب میخواهند
نام و نسخه دقیق ERP چیست و API دارد یا نه؟
برای هر نوع داده، صاحبش کدام سامانه است؟
هر داده با چه تأخیری قابل قبول است؟ موجودی با پنج دقیقه تأخیر مشکلی ندارد؛ مانده اعتبار شاید داشته باشد.
اگر یک طرف در دسترس نبود، چه اتفاقی میافتد؟
و چه کسی مسئول سمت ERP است؟ اگر جوابی برای این سؤال ندارید، ریسک اصلی پروژه همین است — نه پیچیدگی فنی.
اتصال به سامانه حسابداری و مؤدیان، حالت خاصی از همین بحث است که در اتصال به حسابداری و سامانه مؤدیان جدا نوشتهایم.