اینجا برای کسی نوشته میشود که دورهٔ تخصیصِ مهمانسرا، ویلا یا سهمیهٔ هتل را میبندد و فردا باید به معترض، به مدیرعامل و به بازرسی جواب بدهد. هر مقاله یک مسئلهٔ مشخصِ واحدِ رفاه را حل میکند و بدونِ خریدِ هیچ نرمافزاری قابلِ استفاده است. هیچ آمار و رقمِ بیمنبعی در آن نیست؛ نمونهها فرضیاند و صریح گفته میشود.
امتیاز اولویت میسازد، نه ضمانتِ نوبت. چهار معیارِ رایج با وزنهای نمونه، محاسبهٔ یک متقاضیِ فرضی، تکلیفِ امتیازِ مساوی، و معیاری که تقریباً همه فراموش میکنند: سوابقِ استفادهٔ دورههای گذشته.
اکسل انتخابِ منطقیِ اولِ هر واحدِ رفاه است و برای بسیاری همانجا هم باید بماند. مسئله سه شکستِ پنهان است که فقط در جلسهٔ بازرسی پیدا میشوند. ساختارِ فایل، چکلیستِ ماندن، و آنچه هنگامِ انتقال حتماً باید منتقل شود.
در نوروز و تابستان تقاضا چند برابرِ ظرفیت است و هر روزی که دیر شود، به اعتراض تبدیل میشود. تقویمِ معکوس از روزِ اعلامِ نتیجه، تقسیمِ ظرفیت به بازهها، سهمیهٔ هتل با همان قاعده، و اشتباههای تقویمی که هر سال تکرار میشوند.
سهمیه کجا مشروع است و کجا بهانه؟ انواعِ رایج، شرطِ مشروعیت، دو مدلِ اجرا (سهمِ قطعی و کفِ حداقلی)، گزارشی که سهمِ قطعی را از سهمِ قرعه جدا نشان میدهد، و دو کاری که هیچوقت نمیشود از آن دفاع کرد.
آییننامههای موجود اغلب کپیِ آییننامهٔ سازمانِ دیگریاند و در نقطههایی که اعتراض از آنها بیرون میآید ساکتاند: مهلتِ اعتراض، روشِ قرعه، ترتیبِ ذخیره، تغییرِ دستی. راهنمای دهبندی با نمونهٔ متن و چکلیستِ بازنگری.
دستورالعملِ مهمانسرا جایی است که آییننامه به جزئیات میرسد: چه کسی میتواند درخواست بدهد، چند شب، با چه همراهانی، با چه هزینهای، و اگر انصراف داد چه میشود. دوازده بند با نمونهٔ جمله و خطای رایج، فیلدهای فرمِ درخواست، و بندهایی که با نرمافزار خودکار میشوند.
«نرم افزار امور رفاهی» در بازار سه چیزِ متفاوت است و پیش از مقایسهٔ برندها باید معلوم باشد مسئلهٔ شما کدام است. سه راه، ده معیار در یک جدول، اینکه هر راه چه وقت کافی است، جای سرای سازمانی با ضعفهایش، و بازیگرانِ بازار به تفکیکِ دسته، بدونِ رتبهبندی.
زائرسرا سه چیز دارد که مهمانسرا ندارد: هفتههای خاصی که همه میخواهند، همراهانِ بیشتر، و اتاقهایی که به نامِ مأموریت گم میشوند. بازهبندی، سهمیهٔ ایامِ خاص، قرعهٔ وزندار با ذخیرهٔ همزمان، و چکلیستِ فراخوان؛ با یک نمونهٔ فرضی.
مسئلهٔ مشترکِ بانک، شهرداری و دانشگاه یکی است: ظرفیت در چند شهر، متقاضی در چند استان، و ستادی که همه را میگیرد. چهار تصمیمِ پیش از فراخوان، اعتراض از راهِ دور، و سه بخشِ جدا برای سه صنعت: مهمانسراهای متعددِ بانک، آییننامهٔ مصوبِ شورا در شهرداری، و دو جمعیتِ دانشگاه.
ظرفیت را نمیشود زیاد کرد، تقاضا را نمیشود کم کرد؛ آنچه دستِ مدیرِ رفاه است، اهرم است. نسبتِ تقاضا به ظرفیت در سه باند، چهار اهرم با شرطِ کاربرد و شکلِ خرابی، لیستِ انتظار در برابرِ فهرستِ ذخیره، و چهار تصمیمِ سالِ بعد که از یک عدد درمیآید.
سازمانی که مهمانسرا ندارد و با هتل قرارداد میبندد، همان مسئلهٔ تقسیم را دارد بهعلاوهٔ سه چیز: هر شب پول دارد، هتل تا تاریخِ مشخصی نام میخواهد، و انصراف جریمه دارد. سه شکلِ قرارداد، تقسیم با امتیاز و قرعه و ذخیره، مرز با بازارچههای سفر، و چکلیستِ قرارداد.
صورتجلسه را همان روز کسی نمیخواند؛ شش ماه بعد، وقتی معترض یا بازرس پرونده را میخواهد، تنها چیزی است که روی میز مانده. شش بندِ واجب، چهار بندی که نبودشان گران تمام میشود، و یک نمونهٔ پرشدهٔ فرضی.
اعلامِ نتیجهٔ قرعه اعتمادِ کارکنان را برنمیگرداند، چون سه سؤال را بیپاسخ میگذارد: ورودی چه بود، عدد از کجا آمد، چطور به خروجی رسیدیم. چهار تغییرِ مشخص که این سه را میبندند، و آنچه هیچ روشی ثابت نمیکند.
اعتراضِ «امتیازم اشتباه است» و اعتراضِ «قرعه واقعی نبود» دو مسئلهٔ متفاوتاند و با یک جواب حل نمیشوند. مهلتِ رسمی پیش از قفل، اجرای دوباره پس از اعلام، رویهٔ توقف اگر اجرای دوباره نخواند، دو متنِ نمونهٔ پاسخ، و نقشِ نمایندهٔ کارکنان و بازرسی.
فهرستِ برندگان گزارش نیست. سه خوانندهٔ گزارش و سؤالِ هرکدام، هشت جدولی که به آن سؤالها جواب میدهد (با نمونهٔ فرضی)، نسبتِ تقاضا به ظرفیت که تصمیمِ سالِ بعد را میسازد، و شناسنامهای که گزارش را به صورتجلسه و پروندهٔ راستیآزمایی گره میزند.
بازرس چه چیزی را میتواند بدونِ اعتماد به واحدِ رفاه بسنجد؟ پانزده پرسش در پنج گروه (پیش از دوره، فهرست، قرعه، پس از اعلام، داده و بایگانی)، هر کدام با «چه سندی بخواهید» و «چه پاسخی نشانهٔ خطر است»، و نقشِ ناظر با دسترسیِ فقطخواندنی.
چرا Math.random مسئله نیست و «اعتماد به تولیدکنندهٔ عدد» مسئله است. چهار قطعهٔ یک قرعهٔ اثباتپذیر با شبهکدِ هر کدام، چهار بررسیای که در مرورگر انجام میشود، و فهرستِ صریحِ چیزهایی که این روش ثابت نمیکند. برای برنامهنویسِ سازمان، حسابرسِ فنی و مدیرِ آیتی.
دو یکپارچگیِ جدا که با هم اشتباه گرفته میشوند: هویت (چه کسی وارد میشود) و داده (دربارهٔ او چه میدانیم). LDAP و Active Directory برای اولی، API یا فایلِ زمانبندیشده برای دومی، فیلدهای لازم و ممنوع، مسیرِ شبکه وقتی سامانه روی سرورِ فروشنده است، و ده پرسشِ بررسیِ فنیِ پیش از قرارداد.
دادهٔ سامانهٔ رفاهی حساستر از چیزی است که به نظر میرسد: عائله، ایثارگری، سوابق، و اینکه چه کسی کِی در شهر نیست. ده پرسش با پاسخِ خوب و بد، انتشارِ نتیجه با کدِ مستعار، خروجی در پایانِ قرارداد، و پاسخِ خودِ ما به همان ده پرسش با لینک به سندِ حقوقی.
مقالهها روش را میگویند؛ سامانه همان روش را اجرا میکند
هر راهنمای این صفحه بدونِ نرمافزار هم قابلِ اجراست. سرای سازمانی همان مراحل را — از فراخوان تا صورتجلسه — با قرعهکشیِ قابلِ راستیآزمایی انجام میدهد.