پیاده سازی عملی MCP و استفاده عملیاتی از Claud در یک شرکت تولیدی پوشاک در صنعت نساجی
وقتی Claude داشت زیادی کنجکاو میشد!
چند وقت پیش با یک شرکت نساجی تولیدکننده پوشاک در ایران وارد همکاری شدم.
شرکتی باسابقه، با چند خط تولید فعال، انبار مواد اولیه، سفارشهای عمده، بخش فروش، مالی، کنترل کیفیت و یک ERP نسبتاً کامل که سالها با اون کار کرده بودند.
مدیرعامل شرکت در جلسه اول گفت:
«ما میخوایم هوش مصنوعی بیاد کنار تیمهامون. نه برای نمایش، واقعاً برای کمک. مدیر تولید بتونه بپرسه سفارشهای عقبافتاده چیه، انباردار بفهمه کدوم پارچهها رو باید زودتر شارژ کنه، فروش بتونه وضعیت سفارش مشتری رو سریع ببینه.»
ایده عالی بود.
تیم IT شرکت هم از قبل مسیر را شروع کرده بود. یک تیم نرمافزاری خوب و پرانرژی داشتند.
توی جلسه فنی، آقای رضایی، سرپرست IT، با ذوق گفت:
«ما داریم MCP Server راه میندازیم که Claude بتونه به ERP وصل بشه. چندتا API هم آماده کردیم.»
خانم موسوی، یکی از دولوپرهای تیم، لپتاپش رو چرخوند سمت من و گفت:
«اینا هم Tool هایی هست که تعریف کردیم. مثلاً گرفتن موجودی انبار، وضعیت سفارشها، گزارش تولید و…»
من نگاه کردم.
از نظر فنی مسیر بدی نبود. حتی تمیز هم بود.
ولی یه سؤال پرسیدم: «Claude دقیقاً به چه دادههایی دسترسی داره؟»
چند ثانیه سکوت شد.
آقای رضایی گفت: «خب… به API ها. API ها هم از دیتابیس ERP میخونن.»
گفتم:
«یعنی اگر مدیر فروش بپرسه وضعیت سفارش فلان مشتری چیه، Claude میتونه فقط همون سفارش رو ببینه یا کل دیتابیس سفارشها رو؟»
خانم موسوی خندید و گفت:
«فعلاً که… بستگی داره چقدر فضول باشه!» 😄
همه خندیدن، ولی دقیقاً همانجا مسئله اصلی مشخص شد.
مشکل این نبود که MCP پیادهسازی نمیشد.
مشکل این بود که MCP بدون Privacy معماری نشده بود.
در ظاهر همهچیز جذاب بود:
- اتصال Claude به ERP ✅
- تعریف Tool برای موجودی، تولید، فروش ✅
- اجرای Query از طریق API ✅
- پاسخهای هوشمند برای مدیران ✅
اما زیر پوست ماجرا، چند ریسک جدی وجود داشت:
ریسکهای پنهان پروژه ⚠️
- دسترسی بیش از حد Claude به دادهها
- نبود Role-Based Access Control
- ارسال داده خام به مدل
- نبود Data Masking
- نبود لاگ و Audit Trail
اینجا به تیم گفتم:
«بچهها، MCP یعنی درگاه قدرت. ولی اگر درست طراحی نشه، میشه درگاه نشت اطلاعات!»
آقای رضایی گفت:
«یعنی باید کل مسیر رو از اول بریم؟»
گفتم:
«نه، اتفاقاً کارتون خوب شروع شده. فقط الان باید از حالت “وصلش کنیم ببینیم چی میشه” برسیم به “کنترلشده وصلش کنیم که خیالمون راحت باشه”.»
خانم موسوی گفت:
«پس باید Claude رو رژیم اطلاعاتی بدیم؟» 😄
گفتم:
«دقیقاً! Claude نباید بوفه آزاد دیتابیس داشته باشه. باید منوی محدود، مجاز و قابل ثبت داشته باشه.» 🍽️
معماری پیشنهادی من برای ادامه مسیر 🧩
به جای اینکه Claude مستقیم یا نیمهمستقیم به دادههای ERP نزدیک بشه، پیشنهاد دادم یه لایه امن بین Claude و ERP طراحی بشه:
User
↓
Claude
↓
MCP Server
↓
Policy / Permission Layer
↓
Business Tools
↓
ERP APIs / Database
اما نکته مهم این بود:
MCP Server فقط یک پل فنی نبود؛ باید تبدیل میشد به یک لایه کنترل، امنیت و حاکمیت داده.
برای همین نقشه راه رو به تیم دادم:
مرحله ۱: تعریف Use Case های واقعی 🎯
به جای اینکه بگیم «Claude به ERP وصل بشه»، اول پرسیدیم:
- مدیر تولید دقیقاً چه سؤالهایی داره؟
- انباردار چه دادهای لازم داره؟
- مدیر فروش چه گزارشی میخواد؟
- مدیرعامل چه داشبوردی نیاز داره؟
- کدام دادهها نباید هیچوقت از ERP خارج بشن؟
مثلاً یک Use Case خوب:
«بررسی سفارشهایی که احتمال تأخیر در تحویل دارن، بدون نمایش قیمت قرارداد و اطلاعات محرمانه مشتری.»
مرحله ۲: طراحی Tool های محدود و هدفمند 🔧
به تیم گفتم Tool نباید مثل این باشه:
getAllOrders
چون این یعنی:
«بفرمایید کل انبار اطلاعات شرکت!» 😅
به جاش باید Tool ها دقیق، محدود و قابل کنترل باشن:
getDelayedProductionOrders(userId, dateRange)
getInventoryRiskItems(userId, materialCategory)
getOrderStatusSummary(userId, orderCode)
getProductionCapacitySummary(userId, weekNumber)
یعنی هر Tool:
- ورودی کنترلشده داشته باشه
- خروجی محدود داشته باشه
- سطح دسترسی کاربر را بررسی کنه
- داده حساس را حذف یا ماسک کنه
- لاگ کامل داشته باشه
مرحله ۳: Privacy by Design 🔐
اینجا برای مدیران شرکت توضیح دادم:
«Privacy چیزی نیست که آخر پروژه اضافه کنیم. مثل دکمه چاپ گزارش نیست! باید از اول داخل معماری باشه.»
قرار شد این موارد حتماً رعایت بشه:
- عدم ارسال داده خام و غیرضروری به Claude
- Mask کردن اطلاعات مشتریان
- حذف قیمت خرید و حاشیه سود از پاسخهای عمومی
- سطحبندی دسترسی بر اساس نقش سازمانی
- ثبت کامل درخواستها و پاسخها
- محدود کردن حجم داده برگشتی
- تعریف سیاست نگهداری لاگها
- جلوگیری از اجرای Query آزاد توسط مدل
یکی از مدیران پرسید:
«یعنی Claude نمیتونه خودش هر گزارشی خواست بسازه؟»
گفتم:
«میتونه کمک کنه گزارش بسازیم، ولی نباید خودش بیاجازه بره سراغ هر کشویی از کمد اطلاعات شرکت.» 🗄️
جلسه که تموم شد، تیم IT نگاهش به MCP عوض شده بود.
دیگه موضوع فقط اتصال Claude به ERP نبود.
موضوع این بود:
چطور میشه هوش مصنوعی رو وارد کارخانه کرد، بدون اینکه امنیت، حریم خصوصی و کنترل مدیریتی قربانی هیجان تکنولوژی بشه؟
خانم موسوی آخر جلسه گفت:
«پس فعلاً Claude رو از دیتابیس دور نگه میداریم تا تربیتش کنیم!» 😄
گفتم:
«دقیقاً. اول قوانین بازی، بعد اتصال.»
اما ماجرا تازه شروع شده بود…
چون در مرحله بعد، وقتی اولین نسخه MCP Server را پیادهسازی کردن، یه اتفاق جالب افتاد:
Claude به یه سؤال ساده مدیر تولید، پاسخی داد که از نظر فنی درست بود؛
اما از نظر مدیریتی میتونست دردسرساز بشه…
وقتی پاسخ درست، کافی نبود!
بعد از چند روز، نسخه اول MCP Server آماده شد.
آقای رضایی پیام داد:
«مهندس، بیاید تست کنیم. این دفعه Claude رو رژیمی کردیم!» 😄
رفتم جلسه.
خانم موسوی با لبخند گفت:
«این بار دیگه خبری از getAllOrders نیست. قول میدم Claude فقط با قاشق مرباخوری دیتا میخوره!» 🥄
نسخه جدید خیلی بهتر شده بود:
- Tool ها کوچکتر و هدفمندتر شده بودن
- سطح دسترسی اولیه اضافه شده بود
- بعضی دادهها ماسک شده بودن
- لاگ درخواستها ثبت میشد
- خروجیها خلاصهتر شده بودن
همهچیز خوب به نظر میرسید.
تا اینکه جناب مدیر تولید وارد جلسه شد و گفت:
«یه سؤال واقعی بپرسیم ببینیم چی میگه.»
پرسید:
«کدوم سفارشها این هفته احتمال تأخیر دارن و دلیلش چیه؟»
Claude از طریق MCP چندتا Tool رو صدا زد:
getProductionSchedule()
getInventoryRiskItems()
getDelayedProductionOrders()
و جواب داد:
«سه سفارش احتمال تأخیر دارند. دلیل اصلی کمبود پارچه فاستونی کد W-۲۱۴ و تأخیر در تکمیل مرحله دوخت است.»
تا اینجا عالی بود.
اما در ادامه اضافه کرد:
«یکی از این سفارشها مربوط به مشتری A است که در سفارشهای قبلی هم تأخیر پرداخت داشته و بهتر است در اولویت پایینتری قرار گیرد.»
جلسه ساکت شد.
مدیر فروش گفت:
«صبر کن ببینم! این اطلاعات تأخیر پرداخت رو چرا آورد وسط؟ مدیر تولید که نباید اینو ببینه.»
دقیقاً اینجا یک نکته مهم روشن شد:
گاهی پاسخ از نظر دادهای درسته ، اما از نظر سازمانی مجاز نیست.
مشکل دوم: فقط امنیت دیتابیس کافی نیست ⚠️
خیلیها فکر میکنند اگر جلوی دسترسی مستقیم به دیتابیس رو بگیرن، مسئله حل شده.
اما در سیستمهای Agentic و MCP، مسئله فقط «دسترسی به جدول» نیست.
مسئله اینهاست:
- چه کسی سؤال میپرسه؟
- برای چه هدفی سؤال میپرسه؟
- مدل از کدوم Tool استفاده میکنه؟
- پاسخ نهایی شامل چه نتیجهگیریهایی میشه؟
- آیا ترکیب چند تا داده مجاز، یه اطلاعات غیرمجاز تولید میکنه؟
به تیم گفتم:
«اینجا مشکل SQL Injection نیست. مشکل Business Context Injection ـه!» 😄
یعنی ممکنه هر Tool بهتنهایی مجاز باشه،
اما ترکیب خروجی چند Tool، اطلاعاتی بسازه که برای اون کاربر نباید نمایش داده بشه.
راهکار: Context-Aware Access Control 🧠🔐
در مرحله دوم، معماری رو یه لایه جلوتر بردیم.
دیگه فقط Role کاربر مهم نبود.
Context هم مهم شد.
یعنی سیستم باید بفهمه:
- کاربر از کدوم واحد سازمانیه؟
- هدف سؤال چیه؟
- داده برای تصمیم تولیدی لازم هست یا مالی؟
- پاسخ نهایی چه اطلاعاتی رو افشا میکنه؟
- آیا مدل داره از محدوده مأموریتش خارج میشه؟
معماری جدید اینطوری شد:
User
↓
Claude
↓
MCP Server
↓
Policy Engine
↓
Tool Router
↓
Business Tools
↓
ERP
↓
Response Filter
↓
Claude / User
دو بخش مهم اضافه شد:
۱. Policy Engine 🧱
قبل از اجرای Tool بررسی میکرد:
- آیا این کاربر اجازه اجرای این Tool رو داره؟
- آیا پارامترهای ورودی مجاز هستن؟
- آیا بازه زمانی درخواستشده منطقیه؟
- آیا درخواست با نقش سازمانی کاربر تناسب داره؟
۲. Response Filter 🧼
بعد از گرفتن داده از ERP، خروجی رو پاکسازی میکرد:
- حذف دادههای مالی برای کاربران غیرمالی
- ماسک کردن نام مشتری در گزارشهای تولیدی
- حذف حاشیه سود و قیمت خرید
- تبدیل داده خام به Summary
- جلوگیری از نمایش توضیحات داخلی حساس
مثلاً به جای اینکه پاسخ این باشه:
«مشتری A تأخیر پرداخت دارد و بهتر است اولویت پایینتری بگیرد.»
پاسخ مجاز برای مدیر تولید شد:
«سه سفارش احتمال تأخیر دارند. دلیل عملیاتی: کمبود ماده اولیه و تراکم ظرفیت دوخت. پیشنهاد: بازبینی برنامه تولید و تأمین پارچه موردنیاز.»
یعنی پاسخ همچنان مفید بود،
اما دیگه وارد محدوده مالی و محرمانه نمیشد.
نکات مدیریتی که در پروژه جا افتاد 📌
در جلسه با مدیران شرکت تأکید کردم:
هوش مصنوعی در سازمان فقط پروژه IT نیست.
اگر قراره AI به ERP، تولید، فروش و انبار وصل بشه، باید چند گروه کنار هم باشند:
- مدیریت ارشد
- واحد IT
- تیم نرمافزار
- مدیران فرآیند
- مسئول امنیت اطلاعات
- نماینده واحدهای عملیاتی
چون Claude فقط یه چتبات نیست؛
وقتی از طریق MCP به ERP وصل میشه، عملاً به بخشی از جریان تصمیمسازی سازمان تبدیل میشه.
پس باید مشخص باشه:
- چه کسی مالک داده است؟
- چه کسی مجوز دسترسی میده؟
- چه چیزی لاگ میشه؟
- چه دادهای هرگز نباید به مدل ارسال بشه؟
- چه پاسخهایی باید قبل از نمایش فیلتر بشن؟
- چه سناریوهایی نیاز به تأیید انسانی دارن؟
نتیجه فنی پروژه 🚀
در پایان، MCP Server شرکت به این شکل طراحی شد:
- Tool های محدود و قابل تست
- عدم دسترسی مستقیم Claude به دیتابیس
- احراز هویت کاربران با اتصال به ERP
- RBAC برای نقشهای سازمانی
- Context-Aware Policy برای کنترل هوشمندتر
- Data Masking و Data Minimization
- Audit Log کامل
- Rate Limit برای جلوگیری از استخراج حجمی داده
- Response Filtering قبل از نمایش خروجی
- Human-in-the-loop برای تصمیمهای حساس
خانم موسوی آخر جلسه گفت:
«الان Claude دیگه فقط با اجازهنامه میره انبار!» 😄
آقای رضایی هم گفت:
«قبلاً فکر میکردیم MCP یعنی فقط اتصال. الان فهمیدیم یعنی اتصال کنترلشده.»
و این دقیقاً اصل ماجراست.
جمعبندی برای مدیران و تیمهای فنی 🧠
اگه در سازمان ERP دارید و میخواهید Claude یا هر مدل هوش مصنوعی دیگه ای رو از طریق MCP به سیستمهای داخلی وصل کنید، از این سؤال شروع نکنید:
«چطور وصلش کنیم؟»
از این سؤال شروع کنید:
«چه چیزهایی رو نباید ببیند؟»
چون در پروژههای AI سازمانی، موفقیت فقط به این نیست که مدل جواب بده.
موفقیت یعنی مدل، جواب درست، مجاز، قابل ردیابی و امن بده.
MCP اگه درست طراحی بشه، میتونه یه پل قدرتمند بین AI و ERP باشه.
اما اگه بدون Privacy و Governance جلو بره، ممکنه تبدیل بشه به یه تونل مستقیم به اطلاعات حساس سازمان.
و همونطور که در اون جلسه گفتم:
«هوش مصنوعی خوبه؛ ولی نه اونقدر صمیمی که رمز گاوصندوق شرکت رو هم بدونه!» 😄🔐
