نرم‌افزار چندشعبه‌ای فقط یک برنامه با فیلتر «شعبه» نیست. مدیر شعبه باید کارهای همان واحد را ببیند، ستاد باید تصویر تجمیعی و قابل اتکا داشته باشد، و جابه‌جایی یک کارمند نباید دسترسی قدیمی او را باز بگذارد. اگر این مرزها پس از ساخت فرم‌ها و گزارش‌ها تعریف شوند، اصلاح آن‌ها پرهزینه و پرخطر می‌شود. طراحی درست از پاسخ به سه سؤال شروع می‌شود: هر داده متعلق به کدام واحد است، چه کسی حق تغییر آن را دارد، و ستاد چگونه بدون مخلوط کردن رکوردها گزارش مشترک می‌گیرد؟
این راهنما برای سازمانی است که چند شعبه، نمایندگی یا مرکز عملیاتی دارد و می‌خواهد نرم‌افزار سفارشی بسازد یا سامانهٔ فعلی را توسعه دهد. موضوع، انتخاب یک معماری جادویی نیست؛ تبدیل قواعد کسب‌وکار به مرزهای روشن داده و دسترسی است. شعبه‌های یک شرکت لزوماً «مستأجران مستقل» در معنای فنی SaaS نیستند. بااین‌حال، اصل جداسازی داده و کنترل دسترسی در بسیاری از مسیرهای طراحی مشترک است و باید متناسب با مالکیت حقوقی و عملیاتی همان سازمان پیاده شود.
پیش از طراحی، مدل شعبه را روشن کنید
در یک سازمان، شعبه فقط محل فیزیکی است و مالک پرونده ستاد است. در سازمانی دیگر، هر شعبه بودجه، موجودی، مسئول تأیید و مشتریان خود را دارد. گاهی نیز مشتری در چند شعبه خدمت می‌گیرد، اما پروندهٔ خدمت باید در شعبهٔ ایجادکننده بماند. یک جدول «کد شعبه» این تفاوت‌ها را توضیح نمی‌دهد.
برای هر موجودیت اصلی مانند مشتری، سفارش، قرارداد، موجودی یا درخواست خدمت، چهار پاسخ بنویسید: ایجادکننده کیست؟ مالک عملیاتی کیست؟ کدام شعبه‌ها مجاز به مشاهده‌اند؟ انتقال مالکیت چگونه ثبت می‌شود؟ این پاسخ‌ها ممکن است برای هر نوع داده فرق کنند. مشتری می‌تواند سراسری باشد ولی درخواست خدمت او شعبه‌ای؛ کالا می‌تواند شناسهٔ مشترک داشته باشد ولی موجودی هر شعبه مستقل باشد. چنین تمایزی باید پیش از طراحی صفحه‌ها و APIها در واژه‌نامهٔ دادهٔ نرم‌افزار سفارشی ثبت شود.
«شعبهٔ فعال» با «مالک رکورد» یکی نیست
کاربر ممکن است در رابط کاربری شعبهٔ الف را انتخاب کند، اما این انتخاب به‌تنهایی مجوز دیدن رکوردهای آن شعبه نیست. شعبهٔ فعال، زمینهٔ کار است؛ مالک رکورد، ویژگی داده؛ و مجوز کاربر، تصمیمی مستقل. اگر این سه مفهوم در یک فیلد ادغام شوند، جابه‌جایی کارمند یا انتقال پرونده به‌راحتی باعث نمایش نادرست اطلاعات می‌شود.
برای نمونه، کارشناس ستاد ممکن است مجاز به مشاهدهٔ همهٔ شعبه‌ها باشد اما فقط در شعبهٔ مأموریت‌داده‌شده امکان ثبت تغییر داشته باشد. مدیر شعبه ممکن است گزارش همان شعبه را ببیند، ولی به پروندهٔ مشترکی که در شعبهٔ دیگر آغاز شده فقط دسترسی محدود داشته باشد. این حالت‌ها را با مثال واقعی، نه عنوان شغلی کلی، تعریف کنید.
دسترسی را در سرور و برای هر عملیات اعمال کنید
پنهان کردن یک گزینه در منو، حفاظت از داده نیست. هر مسیر خواندن، ویرایش، دانلود فایل، خروجی اکسل، جست‌وجو، گزارش و کار پس‌زمینه باید زمینهٔ شعبه و مجوز کاربر را بررسی کند. راهنمای امنیت چندمستاجری OWASP بر اعمال مجوز در مرزی تأکید می‌کند که تمام مسیرهای دسترسی به داده از آن عبور می‌کنند. این اصل را برای شعبه‌ها نیز می‌توان به‌عنوان الگوی طراحی به کار گرفت؛ البته شعبه و مستأجر حقوقی یکسان نیستند.
قواعد باید صریح باشند: «کارشناس شعبهٔ الف می‌تواند درخواست‌های همان شعبه را ببیند»، «مدیر منطقه می‌تواند گزارش چند شعبهٔ مشخص را ببیند»، «ستاد می‌تواند مالک پرونده را با ثبت دلیل تغییر دهد». نقش به‌تنهایی کافی نیست؛ دامنهٔ شعبه و نوع عملیات نیز اهمیت دارد. راهنمای طراحی نقش و سطح دسترسی برای تعریف نقش‌ها، مجوزها و استثناهای موقت مکمل این بحث است.
وقتی کارمند از یک شعبه به شعبهٔ دیگر منتقل می‌شود، تاریخ شروع و پایان اختیار باید معلوم باشد. دسترسی قدیمی را بر اساس وضعیت فعلی غیرفعال کنید، اما سابقهٔ اینکه او در زمان مجاز چه کاری کرده حذف نکنید. برای جانشینی موقت یا مأموریت بین‌شعبه‌ای، دسترسی با دامنه و انقضای روشن بدهید؛ نه نقش دائمی و گسترده.
طراحی داده: مشترک، شعبه‌ای یا منطقه‌ای؟
همهٔ داده‌ها نباید یک شکل جداسازی داشته باشند. فهرست نوع کالا، کد خدمت و قواعد پایه ممکن است مشترک باشند. موجودی، شیفت کاری یا صندوق معمولاً به واحد اجرا وابسته است. بعضی داده‌ها نیز در سطح منطقه یا شرکت تعریف می‌شوند. برای هر جدول، فایل و رخداد، دامنهٔ مالکیت و قواعد انتقال را مشخص کنید؛ افزودن یک ستون `branch_id` به چند جدول، بدون بررسی مسیرهای مرتبط، کافی نیست.
مثلاً اگر سفارش در شعبهٔ الف ثبت و کالا از شعبهٔ ب ارسال شود، «شعبهٔ سفارش»، «شعبهٔ تأمین» و «شعبهٔ پاسخ‌گو» سه مفهوم متفاوت‌اند. تحمیل یک فیلد شعبه بر هر سه، گزارش‌ها و دسترسی‌ها را مبهم می‌کند. قرارداد داده باید این روابط را نام‌گذاری کند. همچنین مشخص کنید اگر شعبه‌ای ادغام یا تعطیل شد، رکوردهای تاریخی چگونه در گزارش باقی می‌مانند؛ تغییر نام شعبه نباید گذشته را بازنویسی کند.
این انتخاب به معنی الزام به پایگاه دادهٔ جداگانه برای هر شعبه نیست. مدل ذخیره‌سازی به اندازهٔ سازمان، الزامات جداسازی، بار سیستم و هزینهٔ عملیات بستگی دارد. راهنمای معماری دادهٔ چندمستاجری Microsoft گزینه‌های جداسازی را با مزایا و هزینه‌های متفاوت شرح می‌دهد. برای سازمان چندشعبه‌ای، آن راهنما منبع تصمیم‌گیری فنی است، نه نسخهٔ واحدی که بدون تحلیل کسب‌وکار کپی شود.
گزارش تجمیعی نباید مرز داده را دور بزند
مدیرعامل ممکن است فروش و عملکرد همهٔ شعبه‌ها را یک‌جا بخواهد. این نیاز واقعی است، اما دلیل نمی‌شود هر کاربر گزارش‌گیر به تمام ردیف‌های خام دسترسی پیدا کند. گزارش تجمیعی را از نمایی بسازید که دامنهٔ مجاز، تعریف شاخص و زمان به‌روزرسانی آن مشخص است. اگر در گزارش امکان رفتن از عدد کل به ریز پرونده‌ها وجود دارد، همان‌جا مجوز ریزداده را دوباره بررسی کنید.
شاخص‌ها را یکسان تعریف کنید. «درخواست بسته‌شده» در شعبه‌ای شاید شامل پروندهٔ لغوشده باشد و در شعبهٔ دیگر نباشد. قبل از مقایسه، قواعد وضعیت، دورهٔ زمانی و منطقهٔ زمانی را استاندارد کنید. اگر شعبه‌ها در زمان‌های مختلف داده وارد می‌کنند، زمان ثبت، زمان رخداد و زمان همگام‌سازی را از هم جدا نگه دارید. گزارشی که اعداد آن قابل توضیح نیست، حتی با نمودار زیبا به تصمیم بهتر کمک نمی‌کند.
در خروجی‌های اکسل و فایل نیز همان محدودیت‌ها باید برقرار باشد. بسیاری از نشت‌های ناخواسته از صفحهٔ اصلی رخ نمی‌دهند؛ از یک دانلود، فایل ضمیمه، ایمیل خودکار یا API گزارش آغاز می‌شوند. قبل از انتشار هر مسیر خروجی، یک کاربر شعبه را با شناسهٔ رکورد شعبهٔ دیگر امتحان کنید و انتظار رد دسترسی داشته باشید.
مثال عملی: شبکهٔ مراکز خدمات
فرض کنید یک شرکت سه مرکز خدمات دارد. مشتری می‌تواند در هر مرکز درخواست جدید ثبت کند؛ هر درخواست یک مرکز مسئول دارد؛ و ستاد برای نظارت، گزارش همهٔ مراکز را می‌بیند. این سناریو صرفاً برای توضیح طراحی است و ادعایی دربارهٔ مشتریان یا محصول فعلی ایزی‌ساز نیست.
در نسخهٔ اولیه، تیم تصمیم می‌گیرد «پروندهٔ مشتری» را سراسری نگه دارد تا تاریخچهٔ ارتباط گم نشود، ولی «درخواست خدمت» و ضمیمه‌های عملیاتی را به مرکز مسئول وصل کند. کارشناس مرکز ب فقط در صورت ارجاع رسمی می‌تواند درخواست مرکز الف را ببیند. ارجاع، دلیل، فرستنده، گیرنده و زمان انقضا دارد. ستاد می‌تواند گزارش تجمیعی بگیرد، اما ویرایش پروندهٔ مرکز را فقط با اختیار تعریف‌شده انجام می‌دهد.
اکنون یک مورد دشوار را آزمایش کنید: مشتری در مرکز الف درخواست می‌دهد، سپس برای ادامهٔ کار به مرکز ب می‌رود. آیا مالکیت درخواست منتقل می‌شود یا مرکز ب فقط به آن کمک می‌کند؟ چه کسی پاسخ نهایی را ثبت می‌کند؟ اگر هر دو مرکز هم‌زمان یک تغییر بزنند چه می‌شود؟ پاسخ باید در قاعدهٔ کار و تاریخچهٔ تغییر ثبت شود. یک دکمهٔ «انتقال» بدون تعریف مسئولیت، فقط اختلاف را به نرم‌افزار منتقل می‌کند.
برای پذیرش، چند نقش آزمایشی بسازید: کارشناس الف، مدیر ب، مدیر منطقه و ناظر ستاد. هر کدام باید هم عملیات مجاز را با موفقیت انجام دهند و هم در تلاش برای خواندن یا تغییر دادهٔ خارج از دامنه رد شوند. آزمون فقط روی صفحهٔ فهرست کافی نیست؛ لینک مستقیم، جست‌وجو، API، فایل و خروجی گزارش را هم دربر بگیرید.
اتصال شعبه‌ها و کار در زمان اختلال
نرم‌افزار چندشعبه‌ای اغلب با سامانه‌های مالی، انبار، پیامک یا سخت‌افزار محلی ارتباط دارد. برای هر اتصال مشخص کنید شناسهٔ شعبه از کجا می‌آید و آیا سامانهٔ مقصد همان مفهوم را دارد یا نه. فرض نکنید کد شعبه در دو سیستم یک معنا دارد. نگاشت کدها و مالک آن را مستند کنید و هنگام تغییر ساختار شعبه، اثرش بر اتصال‌ها را بررسی کنید.
اگر اینترنت یک شعبه قطع شود، همهٔ فرایندها لزوماً نباید آفلاین ادامه یابند. اول عملیات حیاتی را مشخص کنید: ثبت درخواست، مشاهدهٔ سابقه، دریافت وجه یا تحویل کالا هرکدام خطر متفاوتی دارند. سپس تصمیم بگیرید کدام عملیات باید متوقف، کدام فقط خواندنی و کدام با ثبت محلی کنترل‌شده انجام شود. همگام‌سازی پس از وصل شدن، حل تعارض و جلوگیری از ثبت تکراری به طراحی جدا نیاز دارد. وعدهٔ «آفلاین کامل» بدون این قرارداد، خطر مغایرت داده را پنهان می‌کند.
چه چیزی را در سفارش ساخت نرم‌افزار بنویسیم؟
در شرح نیاز، فهرست شعبه‌ها کافی نیست. مدل مالکیت داده، ماتریس دسترسی، مسیر ارجاع بین‌شعبه‌ای، قواعد گزارش تجمیعی، رفتار هنگام قطع ارتباط و نمونهٔ پرونده‌های مرزی را بنویسید. برای هر مورد معیار پذیرش مشخص کنید: چه کسی با چه نقشی، در کدام شعبه، چه داده‌ای را می‌بیند یا نمی‌بیند. چند سناریوی ممنوع را نیز مانند سناریوی موفق ثبت کنید.
تحویل را مرحله‌ای تعریف کنید. ابتدا یک یا دو شعبه و چند فرایند اصلی را با دادهٔ نمونه یا مجاز راه‌اندازی کنید؛ سپس دامنه را گسترش دهید. از ابتدا برنامهٔ مهاجرت داده و آموزش مدیران شعبه را در نظر بگیرید. اگر هر شعبه روش خود را دارد، روشن کنید کدام تفاوت واقعاً باید در نرم‌افزار پشتیبانی شود و کدام ناشی از رویهٔ نامنسجم است. سفارشی‌سازی بی‌مرز، نگهداری محصول مشترک را دشوار می‌کند.
برای بررسی فنی و برآورد دامنه، صفحهٔ طراحی نرم‌افزار سفارشی ایزی‌ساز مسیر خدمت را توضیح می‌دهد. پیشنهاد اجرایی خوب باید پس از دیدن نمونهٔ فرایند و مرز داده ارائه شود؛ قیمت یا زمان قطعی بدون آن‌ها قابل اتکا نیست.
جمع‌بندی
نرم‌افزار چندشعبه‌ای زمانی مفید است که استقلال عملیاتی شعبه با دید تجمیعی ستاد در تعارض نباشد. این نتیجه با یک فیلتر نمایشی به دست نمی‌آید؛ باید مالکیت داده، مجوز هر عملیات، انتقال پرونده، گزارش و رفتار هنگام اختلال از ابتدا تعریف و آزمون شوند. تفاوت میان «شعبهٔ انتخاب‌شده»، «مالک رکورد» و «دامنهٔ مجوز» مهم‌ترین نقطهٔ شروع است.
اگر قصد ساخت یا بازطراحی سامانهٔ چندشعبه‌ای دارید، شرح یک فرایند واقعی و چند سناریوی دسترسی را برای ایزی‌ساز بفرستید. با دادهٔ نمونهٔ بدون اطلاعات حساس و فهرست تصمیم‌های باز، می‌توان دامنهٔ پایلوت و معیارهای پذیرش را دقیق‌تر تعیین کرد.