روی پرونده مشتری نوشته شده «فروش قطعی»؛ کنار درِ خروجی انبار هنوز چیزی برای بارگیری نیست. این دو وضعیت می‌توانند هم‌زمان درست باشند. اولی از نتیجه مذاکره خبر می‌دهد و دومی از توان اجرای تعهد. برای فهم تفاوت CRM و ERP، از همین فاصله شروع می‌کنیم و یک سفارش را از انتهای مسیر، یعنی تحویل، به سمت تصمیم‌های قبلی دنبال می‌کنیم.
CRM یا مدیریت ارتباط با مشتری، بر شناخت مشتری و اداره تعاملات فروش و خدمات تمرکز دارد. ERP یا برنامه‌ریزی منابع سازمان، معمولاً فرایندهایی مانند تأمین، موجودی، تولید و امور مالی را به هم متصل می‌کند. توضیح SAP درباره تفاوت ERP و CRM این تفاوت تمرکز را بیان می‌کند و می‌گوید این دو می‌توانند روی یک بستر باشند یا جدا تهیه و یکپارچه شوند. این یک تقسیم کار کلی است؛ نام محصول به‌تنهایی مشخص نمی‌کند هر قابلیت دقیقاً کجا وجود دارد.
برای بررسی، یک سازنده فرضی مبلمان اداری را در نظر می‌گیریم. مشتری مدل صندلی، پارچه و موعد موردنظرش را تأیید کرده است. این نمونه، گزارش تجربه یک شرکت واقعی نیست. منابع فنی مقاله نیز رفتار محصولات مشخص را توضیح می‌دهند؛ از آن‌ها وعده افزایش فروش یا تأیید امکانات مدیرم استخراج نمی‌کنیم.
از بارگیری به عقب: چه چیزی هنوز باید آماده شود؟
در انتهای مسیر، مسئول ارسال باید بداند کدام صندلی‌ها برای کدام سفارش آماده‌اند، بسته‌بندی شده‌اند یا نه و به چه نشانی می‌روند. وجود یک گفت‌وگوی موفق با مشتری پاسخ این پرسش‌ها را کامل نمی‌کند. ممکن است محصول هنوز در تولید باشد، بخشی از سفارش آماده شده باشد یا مشتری نشانی تحویل را تغییر داده باشد. هرکدام از این وضعیت‌ها، تصمیم اجرایی متفاوتی می‌خواهد.
یک قدم عقب‌تر، مسئول تولید باید بداند چه چیزی را با کدام مشخصات بسازد. عنوان «صندلی جلسه» برای گفت‌وگوی اولیه قابل فهم است، اما ممکن است برای تولید کافی نباشد. نوع پایه، رنگ پارچه و تعداد باید به مشخصات قابل اجرا تبدیل شوند. اگر گزینه توافق‌شده هنوز کد یا تعریف روشنی ندارد، انتقال خودکار همان عنوان مبهم فقط ابهام را سریع‌تر به واحد بعدی می‌رساند.
در این مثال، «تاریخ درخواستی مشتری» با «تاریخ تأییدشده تحویل» دو داده متفاوت‌اند. نخستین تاریخ بیان نیاز مشتری است؛ دومی باید بر مبنای بررسی ظرفیت و شرایط اجرای سفارش تعیین شود. پیشنهاد ما این است که این دو عنوان جدا بمانند و مسئول تأیید تاریخ دوم معلوم باشد. این پیشنهاد طراحی برای سناریوی فرضی است، نه قاعده‌ای که همه محصولات به شکل یکسان اجرا کنند.
یک قدم دیگر به عقب می‌رویم و به فروش می‌رسیم: مشتری با چه چیزی موافقت کرده بود؟ اگر پرونده فقط عبارت «موافق است» داشته باشد، واحد اجرایی ناچار می‌شود جزئیات را از فروشنده بپرسد. پیشنهاد، نسخه تأییدشده مشخصات و تغییرهای بعدی باید قابل تشخیص باشند. مدیر لازم نیست جزئیات همه سفارش‌ها را بداند؛ باید مطمئن شود مسئول بعدی می‌تواند تعهد دقیق را بدون بازسازی مکالمه پیدا کند.
دو سامانه می‌توانند یک سفارش را ببینند، با اختیارهای متفاوت
یکپارچه‌سازی به معنی مجازبودن تغییر همه اطلاعات در هر دو طرف نیست. در مستند Microsoft درباره مسیر پیشنهاد تا وصول، به‌روزرسانی ۱۰ مارس ۲۰۲۶، پیشنهادها و سفارش‌ها میان Dynamics 365 Sales و Supply Chain Management در دسترس قرار می‌گیرند. در همان سازوکار، صورتحساب در Supply Chain Management ساخته و به Sales منتقل می‌شود و صفحه آن در Sales قابل ویرایش نیست. این نمونه نشان می‌دهد دیده‌شدن یک سند و اختیار تغییر آن می‌توانند از هم جدا باشند.
برای شرکت فرضی، کاربرد مدیریتی این تفکیک آن است که فروشنده بتواند وضعیت اجرای سفارش را ببیند و به مشتری پاسخ بدهد، بی‌آنکه برای اطلاع از برنامه تولید، اختیار تغییر آن را هم به او بدهیم. در مقابل، مسئول تولید به مشخصات تأییدشده نیاز دارد، اما لازم نیست مالک همه یادداشت‌های مذاکره شود. تعیین این مرزها به مسئولیت هر نقش و امکانات تأییدشده سامانه‌ها وابسته است.
همان مستند Microsoft یک گزینه برای مرجع‌بودن Supply Chain Management در محاسبه قیمت معرفی می‌کند. چنین گزینه‌ای یادآور یک پرسش مهم است: اگر قیمت در دو محیط دیده می‌شود، کدام طرف آن را محاسبه و تأیید می‌کند؟ این پرسش باید پیش از اتصال پاسخ داده شود. دو محل نمایش، لزوماً نباید دو مرجع مستقل برای یک تصمیم باشند.
در مثال مبلمان، ممکن است فروشنده درباره درخواست تخفیف مذاکره کند، ولی تأیید آن تابع قاعده داخلی دیگری باشد. بنابراین بهتر است «تخفیف درخواستی» با «تخفیف تأییدشده» مخلوط نشود. این تفکیک، سیاست قیمت‌گذاری یا حسابداری پیشنهاد نمی‌کند؛ فقط کمک می‌کند داده مربوط به یک درخواست، به‌اشتباه نتیجه یک تصمیم معرفی نشود.
هم‌نام‌بودن اطلاعات کافی نیست؛ باید هم‌معنا باشند
فرض کنیم فروشنده تعداد را به صورت «بسته» ثبت می‌کند، ولی انبار با «عدد» کار می‌کند. اگر هر بسته شامل چند صندلی باشد، کپی‌کردن مقدار تعداد بدون واحد، سفارش را روشن نمی‌کند. همین مسئله درباره نام مشتری و کد محصول هم وجود دارد: تشابه نوشته روی صفحه، برای اثبات اینکه دو پرونده به یک موجودیت اشاره دارند کافی نیست.
راهنمای اتصال Business Central و Dynamics 365 Sales، به‌روزرسانی ۲۲ اکتبر ۲۰۲۵، برای یکپارچه‌سازی سفارش‌ها، تطبیق مشتریان، واحدهای اندازه‌گیری، ارزها، گروه‌های قیمت و کالاها یا منابع را لازم می‌داند. منظور از تطبیق، مشخص‌کردن ارتباط پرونده‌های متناظر در دو سامانه است. این فهرست مربوط به همان محصولات است؛ در پروژه دیگر باید داده‌های وابسته همان پروژه بررسی شوند.
پیشنهاد عملی برای مدیر شرکت فرضی این است که مسئول فروش و مسئول عملیات، یک ردیف واقعی سفارش خودشان را کنار هم بخوانند: این مشتری کدام شرکت است؟ این کد به کدام ترکیب محصول اشاره می‌کند؟ تعداد با چه واحدی ثبت شده؟ هدف، طراحی یک فرم طولانی‌تر نیست؛ پیدا کردن تفاوت معنایی پیش از آن است که سفارش مبنای اجرا قرار بگیرد. اگر هر دو طرف برداشت یکسانی ندارند، مسئله هنوز با نوشتن کد اتصال حل نمی‌شود.
این تفاوت معنا در گزارش‌ها هم ظاهر می‌شود. «فروش قطعی»، «سفارش قابل اجرا» و «ارسال‌شده» می‌توانند سه گروه متفاوت باشند. مدیر نباید با دیدن افزایش گروه اول، افزایش همان‌اندازه در گروه سوم را فرض کند. برای تعریف دقیق عددهایی که از این وضعیت‌ها ساخته می‌شوند، مقاله مرتبط زیر موضوع گزارش و تاریخ مبنای آن را جداگانه بررسی کرده است.
پاسخ مشتری باید از وضعیت واقعی سفارش بیاید
اکنون مسیر را دوباره رو به جلو می‌خوانیم. فروش، توافق روشن را تحویل می‌دهد؛ مسئول اجرایی امکان انجام و موعد را بررسی می‌کند؛ وضعیت اجرا به جایی برمی‌گردد که پاسخ مشتری داده می‌شود. لازم نیست برای شروع، همه فرایندهای شرکت در یک پروژه بزرگ ادغام شوند. در پیشنهاد این مقاله، یک مسیر مشخص را انتخاب می‌کنیم و برای هر انتقال، ورودی لازم، مسئول دریافت و معنای پاسخ را روشن می‌نویسیم.
در سازنده فرضی مبلمان، پاسخ به مشتری می‌تواند دقیق باشد: مدل و پارچه تأیید شده‌اند، سفارش در انتظار تأیید موعد تولید است و مسئول مشخصی آن را پیگیری می‌کند. این پاسخ از عبارت کلی «در سیستم ثبت شده» اطلاعات بیشتری دارد. ثبت‌شدن، محل نگهداری داده را می‌گوید؛ مشتری می‌خواهد بداند سفارش او در چه وضعیتی است و پاسخ بعدی را چه زمانی می‌گیرد.
وقتی چنین تقسیم کاری روشن شد، می‌توان بررسی کرد کدام قابلیت باید در CRM، کدام در ERP و کدام در اتصال میان آن‌ها پیاده شود. ممکن است ابزار موجود بخشی از مسیر را پوشش دهد و برای بخش دیگر نیاز به تنظیم یا توسعه باشد؛ پیش از بررسی واقعی، نتیجه را قطعی نمی‌دانیم. نقطه پایان این طراحی، یکی‌شدن نام سامانه‌ها نیست: فروش و عملیات باید بتوانند درباره همان سفارش، دو بخش سازگار از یک واقعیت را توضیح دهند.
هر دو تصویر با هوش مصنوعی تولید شده‌اند و تصویرسازی مفهومی‌اند؛ نمای واقعی شرکت، سفارش مشتری یا رابط کاربری نرم‌افزار نیستند.
نظر شما چیست؟