Kaveh Forge — پلتفرم یکپارچه عملیات صنعتی و سازمانی

از AutomationOffice تا Kaveh Forge

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

نتیجه‌ی این تکامل Kaveh Forge است: یک پلتفرم یکپارچه برای عملیات صنعتی و سازمانی که AutomationOffice هسته‌ی اولیه‌ی آن بوده است. پس از حدود ۹ ماه توسعه‌ی فعال، پروژه در وضعیت ۸۵٪ قرار دارد؛ بخش عمده‌ی domainهای اصلی عملیاتی شده‌اند و ۱۵٪ باقی‌مانده بیشتر مربوط به تکمیل آخرین جریان‌ها، تست پذیرش بین‌ماژولی، polish تجربه کاربری و production hardening است.

این Case Study عمداً پروژه را «تمام‌شده» معرفی نمی‌کند. ارزش مهندسی آن دقیقاً در این است که یک سیستم در حال تکامل را از چند CRUD جدا به یک Operational Platform با مرزهای domain، lifecycle، کنترل دسترسی و traceability واقعی تبدیل کرده است.

مسئله کسب‌وکار

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

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

مشکل فقط «تکرار ورود اطلاعات» نیست. مشکل اصلی این است که هر بخش برداشت متفاوتی از حقیقت عملیاتی دارد. Kaveh Forge تلاش می‌کند این شکاف را با یک زنجیره‌ی داده‌ی قابل ردگیری از استاندارد مهندسی تا واقعیت تولید و هزینه‌ی دوره ببندد.

معماری پلتفرم

هسته‌ی backend یک Django/DRF ماژولار روی PostgreSQL است. Redis برای cache، state عملیاتی و صف استفاده می‌شود؛ Celery و Celery Beat کارهای background و زمان‌بندی را انجام می‌دهند؛ Channels و Daphne ارتباط real-time را برای Inbox/Chat فراهم می‌کنند؛ و فایل‌های خصوصی می‌توانند روی storage سازگار با S3 نگهداری شوند.

Frontend با Next.js و React ساخته شده و به‌جای تبدیل شدن به مجموعه‌ای از صفحه‌های مستقل، از workspaceهای permission-aware استفاده می‌کند. navigation و actionها بر اساس capabilityهای واقعی کاربر ساخته می‌شوند. طراحی فارسی، تقویم جلالی، انتخابگرهای searchable، modalهای استاندارد و راهنمای تعاملی بخشی از design system مشترک پلتفرم هستند.

استقرار برای dev، stage و production با Docker Compose تفکیک شده است و سرویس‌ها پشت Nginx/Gunicorn/Daphne اجرا می‌شوند.

۱. هویت، کاربران و RBAC مرکزی

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

مدل جدید RBAC سه مفهوم را جدا می‌کند:

• Role: بسته‌ای از مسئولیت‌های نرم‌افزاری
• Capability: مجوز دقیق و action-oriented مثل inventory.post یا backup.restore
• UserRoleAssignment: تخصیص قابل ممیزی نقش به کاربر با بازه زمانی و ثبت تخصیص‌دهنده

موقعیت سازمانی و permission عمداً از هم جدا هستند. اینکه فرد «سرپرست تولید» است به‌تنهایی نباید به شکل پنهان مجوز امنیتی ایجاد کند. Backend و frontend هر دو از capabilityهای مؤثر استفاده می‌کنند و superuser فقط یک bypass کنترل‌شده است.

این طراحی امکان نقش‌های چندگانه، دسترسی read-only مدیریتی، نقش‌های موقت و اضافه شدن ماژول‌های جدید بدون بازنویسی شرط‌های عددی را فراهم می‌کند.

۲. ساختار سازمانی و پرسنلی

پلتفرم سازمان را فقط فهرست userها نمی‌بیند. Company، location، department، position و assignment به‌عنوان مفاهیم جدا مدل می‌شوند تا بتوان تاریخچه‌ی جابه‌جایی افراد و ساختار واقعی شرکت را حفظ کرد.

این لایه پایه‌ی مشترک مکاتبات، دسترسی‌ها و گزارش‌های سازمانی است و در فاز فعلی همچنان یکی از بخش‌هایی است که برای تکمیل نهایی و polish جریان‌های HR/Personnel توسعه روی آن ادامه دارد.

۳. مکاتبات و دبیرخانه

AutomationOffice از همین ماژول متولد شد. جریان مکاتبات رسمی شامل شرکت، واحد، دفتر، دبیرخانه، نامه‌ی وارده/صادره، گیرندگان، موضوع، متن، امضا، وضعیت و بایگانی است.

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

این ماژول در نسخه‌ی جدید در کنار Inbox و notificationهای پلتفرمی قرار گرفته تا «مکاتبه رسمی» و «همکاری روزمره» دو ابزار مجزا ولی متصل باشند.

۴. اطلاعات پایه و مهندسی تولید

Master Data از مهم‌ترین نقاط تغییر پروژه است. موجودیت‌هایی مانند Item، UOM، Operation، Work Center، Machine، Fixture، BOM و Routing به‌عنوان داده‌ی مرجع صنعتی مدل شده‌اند.

BOM و Routing revision lifecycle دارند. revision فعال با تغییر عادی CRUD دستکاری نمی‌شود؛ activation یک workflow کنترل‌شده است و revision فعال برای مصرف downstream معنی مشخص دارد.

Routing شامل عملیات مرحله‌ای، مرکز کار، ماشین، زمان setup/cycle، تعداد اپراتور و fixture است. سازگاری Fixture ↔ Machine و محدودیت ظرفیت قبل از release دوباره بررسی می‌شود تا «فعال بودن master data» به‌تنهایی تضمین کافی محسوب نشود.

این کنترل‌ها مانع آن می‌شوند که Work Order جدید روی یک استاندارد مهندسی منقضی یا از نظر فیزیکی نامعتبر آزاد شود.

۵. MES و اجرای واقعی تولید

MES صرفاً وضعیت یک سفارش را از Draft به Done تغییر نمی‌دهد. در زمان release، استاندارد مهندسی به snapshot عملیاتی تبدیل می‌شود:

• عملیات Routing با sequence، Work Center، Machine و Fixture freeze می‌شوند؛
• نیازمندی مواد از BOM به WorkOrderMaterialRequirement تبدیل می‌شود؛
• تغییر بعدی BOM یا Routing روی Work Order آزادشده اثر نمی‌گذارد.

در اجرا، actualهای واقعی ثبت می‌شوند: ماشین استفاده‌شده، زمان، مصرف ماده، خروجی سالم و scrap. مصرف ماده می‌تواند به requirement استاندارد خودش bind شود و تفاوت مقدار واقعی با مقدار استاندارد به‌عنوان variance حفظ می‌شود، نه اینکه به زور برابر شود.

اتمام عملیات و Work Order به postingهای واقعی و کنترل consistency وابسته است. هدف این طراحی این است که گزارش مدیریتی بتواند بگوید «چه چیزی باید اتفاق می‌افتاد» و «واقعاً چه اتفاقی افتاد».

۶. انبار و رهگیری موجودی

Inventory یک دفتر موجودی ساده نیست. سندهای انبار lifecycle و posting دارند؛ موجودی از روی movementهای ثبت‌شده ساخته می‌شود و lot/cardex امکان traceability را ایجاد می‌کند.

کاربر می‌تواند اسناد و گردش کالا را جست‌وجو کند، گزارش بگیرد و خروجی PDF/Excel بسازد. MES برای مصرف مواد و خروجی تولید از همین مدل posting استفاده می‌کند تا تولید و انبار دو حقیقت متفاوت ایجاد نکنند.

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

۷. بهای تمام‌شده

Costing به داده‌ی واقعی domainهای دیگر متصل شده است. برای یک دوره‌ی شمسی، نرخ مواد، حقوق، هزینه‌ی مراکز/سربار و actualهای MES وارد محاسبه می‌شوند و نتیجه‌ی هزینه‌ی دوره برای محصول ساخته می‌شود.

Workspace بهای تمام‌شده منابع Master Data را دوباره ایجاد نمی‌کند؛ کالا و Cost Center را از مرجع مشترک می‌خواند. این تصمیم از ایجاد «نسخه مالی» و «نسخه تولید» از یک موجودیت جلوگیری می‌کند.

هدف ماژول، ایجاد مبنای قابل ممیزی برای هزینه‌ی تولید است؛ نه جایگزین کردن حسابداری مالی یا COGS کامل.

۸. گزارش‌ها و مرکز تحلیل مدیریتی

Platform API یک لایه aggregate permission-aware برای گزارش‌ها دارد. گزارش‌های تولید، انبار، هزینه و مدیریت بر اساس capability کاربر در دسترس قرار می‌گیرند و frontend آن‌ها را در یک مرکز تحلیل مشترک نمایش می‌دهد.

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

۹. Ticketing، Chat و Inbox بلادرنگ

پلتفرم Ticket، participant، گروه چت، عضویت، پیام، reply، attachment و Inbox notification را دارد. ارتباط‌های realtime از WebSocket و Channels عبور می‌کنند و authorization گروه/کاربر در backend enforce می‌شود.

در UI، avatar، unread count، reply/forward، emoji، فایل و chat گروهی/خصوصی در یک تجربه مشترک قرار گرفته‌اند. این ماژول برای حذف وابستگی به پیام‌رسان‌های بیرون از سازمان طراحی شده، مخصوصاً وقتی گفتگو باید به هویت سازمانی و permissionهای پلتفرم متصل باشد.

۱۰. Backup / Restore عملیاتی

Backup در Kaveh Forge یک دکمه‌ی «دانلود دیتابیس» نیست. مدل مستقل Schedule و Job وجود دارد، backup می‌تواند database یا media باشد، artifact اندازه و checksum SHA-256 دارد و retention/scheduling از مسیر Celery پشتیبانی می‌شود.

Restore به‌عنوان عملیات حساس از CRUD عادی جدا شده است: تأیید تایپی، بررسی artifact/checksum، lock سراسری، maintenance mode، بستن connectionهای دیتابیس و کنترل بازگشت سرویس جزو طراحی آن هستند. permission بازیابی هم از backup.create جداست.

Media backup علاوه بر فایل‌های local می‌تواند snapshot manifest-backed از private object storage را پوشش دهد. این موضوع برای Ticket/Chat attachment و فایل‌های سازمانی مهم است؛ چون backup باید واقعاً داده‌ی کاربر را پوشش دهد، نه فقط جداول PostgreSQL را.

۱۱. Object Storage خصوصی

فایل‌های attachment و media به‌گونه‌ای طراحی شده‌اند که backend به MinIO/S3 خاصی قفل نشود. abstraction سازگار با S3 اجازه می‌دهد محیط‌های مختلف storage متفاوت داشته باشند بدون اینکه domain code تغییر کند.

فایل خصوصی از URL عمومی دائمی استفاده نمی‌کند؛ دسترسی باید با authorization یا URL زمان‌دار انجام شود. این مسئله در یک پلتفرم سازمانی، بخشی از مدل امنیت است نه صرفاً تصمیم زیرساختی.

۱۲. System Settings و عملیات پلتفرم

مدیر سیستم از داخل پنل می‌تواند بخشی از تنظیمات عملیاتی مانند SMTP را مدیریت و تست کند و وضعیت CPU، RAM، Disk و اطلاعات سرویس را ببیند. branding و version contract نیز به backend/frontend منتقل شده‌اند تا محیط development/stage/production و build جاری قابل تشخیص باشد.

در UI، About page، footer version، favicon/logoهای Kaveh Forge و branding گزارش/PDF/Excel یک هویت مشترک برای محصول ایجاد می‌کنند.

۱۳. API Facade و BFF

با بزرگ شدن تعداد endpointها، frontend مستقیماً به هر URL داخلی backend وابسته نمانده است. facadeهای صریح و allowlist‌شده برای domainها استفاده می‌شوند و mutationهای cross-origin رد می‌شوند.

ورود frontend از session HttpOnly در BFF استفاده می‌کند تا credential احراز هویت در JavaScript مرورگر به شکل ساده در دسترس نباشد. این لایه همچنین migration تدریجی APIها به namespace مشترک /api/v1/ را امکان‌پذیر کرده است.

۱۴. تجربه کاربری صنعتی فارسی

در نرم‌افزار سازمانی، UX فقط رنگ و animation نیست. پلتفرم به‌صورت سراسری روی چند اصل کار کرده است:

• تاریخ شمسی و date picker مشترک
• Searchable Select برای داده‌های مرجع حجیم
• modal استاندارد به‌جای alertهای مرورگر
• navigation بر اساس permission واقعی
• responsive workspace و دسترسی سریع موبایل
• dark/light theme
• counterهای realtime برای Inbox/Ticket/Chat
• راهنمای تعاملی «آموزش» برای توضیح workflow هر ماژول
• نمایش وضعیت lifecycle، خطا و empty-state به‌صورت قابل فهم

وجود راهنمای workflow در خود workspace برای سیستم صنعتی مهم است؛ چون آموزش کاربر باید کنار عملیات قرار بگیرد، نه در یک PDF جدا که بعداً فراموش شود.

نقاط قوت مهندسی

مرز روشن بین Standard و Actual

BOM/Routing استاندارد مهندسی‌اند؛ Work Order snapshot قرارداد اجرای تولید است؛ MES actual واقعیت کارخانه را ثبت می‌کند. مخلوط نکردن این سه لایه، امکان variance و audit واقعی را می‌دهد.

قانون کسب‌وکار در backend

activation، release، posting، permission و restore safety به UI اعتماد نمی‌کنند. حتی اگر client دستکاری شود، backend باید invariantهای domain را حفظ کند.

Single Source of Truth بین ماژول‌ها

Costing کالا و Cost Center را دوباره تعریف نمی‌کند؛ MES موجودی خودش را جدا نگه نمی‌دارد؛ Reports داده را از domainهای مرجع aggregate می‌کند. این تصمیم جلوی divergence بین واحدها را می‌گیرد.

Authorization قابل رشد

Role/Capability به‌جای role IDهای ترکیبی، رشد تعداد ماژول‌ها را مدیریت‌پذیر کرده است. کاربر read-only، manager یا مسئول چند حوزه را می‌توان بدون ساخت user type جدید تعریف کرد.

قابلیت بازیابی و عملیات واقعی

Backup، object storage، maintenance mode، logging، health و Docker environmentها بخشی از محصول‌اند. هدف فقط «build شدن feature» نیست؛ هدف قابل اداره بودن سرویس در production است.

ارزش برای شرکت‌های صنعتی

چرا این پروژه برای من مهم است

Kaveh Forge حاصل توسعه‌ی یک feature منفرد نیست؛ نتیجه‌ی چند بار بازطراحی معماری در برابر مسئله‌های واقعی است. پروژه از مکاتبات شروع کرد، بعد به ساختار سازمانی، مهندسی، انبار، MES، costing، گزارش، RBAC، realtime collaboration و عملیات production رسید.

بخش قابل توجهی از کار نه در ساختن فرم، بلکه در پاسخ به سؤال‌های سخت بود: اگر BOM بعد از release عوض شود چه می‌شود؟ اگر دسترسی یک مدیر موقت باشد چه؟ اگر restore دیتابیس وسط عملیات fail کند؟ اگر فایل private روی object storage باشد؟ اگر مصرف واقعی ماده با استاندارد برابر نباشد؟ اگر دو ماژول یک مفهوم مشترک را دوباره تعریف کنند؟

این سؤال‌ها Kaveh Forge را از یک «پنل مدیریتی» به یک پروژه‌ی مهندسی نرم‌افزار صنعتی تبدیل کرده‌اند.

وضعیت فعلی — ۸۵٪

پروژه پس از حدود ۹ ماه توسعه فعال در وضعیت ۸۵٪ است. هسته‌های Master Data/Engineering، Production/MES، Inventory، Costing، RBAC، Backup/Restore، Ticketing/Chat، مکاتبات و Reporting پیاده‌سازی شده‌اند و بخش بزرگی از آن‌ها در محیط production/stage تست شده‌اند.

۱۵٪ باقی‌مانده به معنی نبودن هسته‌ی محصول نیست؛ تمرکز آن روی تکمیل آخرین جریان‌های سازمانی/پرسنلی، تست پذیرش end-to-end بین domainها، hardening نهایی deployment/observability، polish تجربه کاربری و بستن موارد باقیمانده‌ی rollout سازمانی است.