سامانه نیکوکاری: شفافیت به‌عنوان یک الزام فنی

تیم آرادتیم مهندسی

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

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

این واقعیت باید در معماری نشسته باشد، نه در صفحهٔ «دربارهٔ ما».

زنجیرهٔ ردیابی

سؤالی که سامانه باید بتواند جواب بدهد: این مبلغ مشخص، در نهایت صرف چه شد؟

برای پاسخ به این، هر کمک باید در طول مسیر قابل ردیابی بماند:

دریافت. از چه کسی، چقدر، از چه کانالی، با چه نیت مشخصی — اگر برای کمپین خاصی داده شده.

تخصیص. به کدام پرونده، کدام کمپین، کدام قلم هزینه.

مصرف. چه چیزی خریداری یا پرداخت شد، با سند.

گزارش. به کمک‌کننده، به هیئت امنا، به نهاد ناظر.

نکتهٔ فنی که همه‌چیز به آن برمی‌گردد: کمک هدف‌دار باید تا آخر هدف‌دار بماند. اگر کسی برای «تحصیل کودکان» کمک کرده، سامانه نباید اجازه دهد آن مبلغ صرف هزینهٔ اداری شود — و باید بتواند این را اثبات کند.

این یعنی مدل داده‌ای که کمک را به‌عنوان مبلغی در یک استخر مشترک نمی‌بیند، بلکه هویت و محدودیت خودش را نگه می‌دارد. افزودن این به سامانه‌ای که از ابتدا این‌طور طراحی نشده، عملاً بازنویسی است.

گزارش به کمک‌کننده

آنچه واقعاً اعتماد می‌سازد، گزارش سالانهٔ کلی نیست. اینهاست:

رسید فوری با مشخصات کامل — و اگر مجوز مالیاتی دارید، اطلاعات لازم برای کسر مالیاتی.

گزارش اختصاصی همان کمک. «کمک شما به این مورد رسید و این اتفاق افتاد.» حتی اگر ساده و کوتاه باشد، از هر گزارش تجمیعی مؤثرتر است.

نمای کلی سازمان، با نسبت هزینهٔ اداری به کمک مستقیم. سازمانی که این عدد را خودش منتشر می‌کند، اعتماد بیشتری می‌گیرد از سازمانی که پنهانش می‌کند.

سابقهٔ کمک‌های شخص، قابل دسترس در حساب کاربری.

کرامت مددجو، که تصمیم فنی است

اینجا مسئله‌ای هست که فراتر از فناوری است و در مدل داده اثر می‌گذارد.

داستان‌ها و تصاویر مددجویان ابزار قدرتمند جذب کمک‌اند و به‌سادگی به نمایش فقر تبدیل می‌شوند. سامانه باید این را کنترل‌پذیر کند:

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

پروندهٔ مددجو، دادهٔ به‌شدت حساس است: وضعیت مالی، سلامت، خانواده، گاهی سوابق قضایی. سطح حفاظتش باید همان باشد که برای دادهٔ بیمار گفتیم — دسترسی به‌ازای رکورد، لاگ کامل، کمینه‌سازی داده، و ناشناس‌سازی پیش از انتقال به محیط آزمایش.

و همان‌طور که آنجا گفتیم، حذف نام کافی نیست: در شهر کوچک، ترکیب چند فیلد عادی یک خانواده را مشخص می‌کند.

کمک‌های غیرنقدی، بخشی که همیشه جا می‌ماند

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

  • کالا: پوشاک، مواد غذایی، لوازم خانگی، تجهیزات.
  • خدمت: ویزیت پزشکی، آموزش، مشاوره، حمل‌ونقل.
  • زمان داوطلبان.

اینها انبار و ارزش‌گذاری و توزیع و — مهم‌تر — گزارش‌دهی خودشان را می‌خواهند. سامانه‌ای که فقط ریال حساب می‌کند، بخش زیادی از کار خیریه را نامرئی می‌گذارد و در گزارش سالانه، تصویر ناقصی از سازمان می‌دهد.

آنچه در بازار ایران خاص است

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

کمک مستمر و پرداخت خودکار. ستون فقرات مالی هر خیریه‌ای، کمک ماهانهٔ ثابت است نه کمک موردی. سازوکار پرداخت دوره‌ای و مدیریت آن باید از نسخهٔ اول باشد، همراه با اطلاع‌رسانی پیش از هر برداشت — بی‌خبری، لغو می‌سازد.

فصلی بودن شدید. ماه رمضان، محرم، اعیاد و بازگشایی مدارس، قله‌های ترافیکی می‌سازند که چند برابر روزهای عادی است. سامانه باید برای همان قله‌ها آزمایش بار شده باشد، نه برای میانگین.

سازوکارهای سنتی: نذر، صدقه، قربانی، زکات، کفاره — هرکدام قواعد تخصیص خاص خودشان را دارند و در محصولات خارجی معادلی ندارند. اینها را نمی‌شود با یک فیلد «نوع کمک» پوشش داد؛ هرکدام منطق تخصیص متفاوتی دارند.

گزارش به نهادهای نظارتی، با قالب‌های مشخص.

نمونهٔ اجراشدهٔ این الزامات را در سنا می‌بینید — سامانه‌ای در مقیاس سازمانی که همین زنجیرهٔ دریافت تا مصرف را پوشش می‌دهد.

معماری، به‌طور خلاصه

اگر چنین سامانه‌ای می‌سازید، این چهار تصمیم را از روز اول بگیرید:

۱. کمک، موجودیت مستقل با محدودیت و هویت خودش است — نه ردیفی در حساب.

۲. هر تخصیص و هر مصرف، به کمک برمی‌گردد. زنجیره نباید در هیچ نقطه‌ای شکسته شود.

۳. تفکیک دادهٔ داخلی از دادهٔ قابل انتشار، در سطح مدل نه در سطح رابط کاربری.

۴. لاگ تغییرات مالی، غیرقابل تغییر. در سازمانی که با پول مردم کار می‌کند، تاریخچهٔ قابل ویرایش یعنی گزارش غیرقابل دفاع.

سه مورد اول را نمی‌شود بعداً اضافه کرد. چهارمی را می‌شود و تا آن موقع، هر گزارشی که داده‌اید قابل مناقشه است.

پروژه یا ایده‌ای دارید؟

متخصصین ما آماده برگزاری یک جلسه مشاوره رایگان هستند.

مشاوره رایگان

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

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

چطور با شما تماس بگیریم؟

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

راه دوم برای رساندن پاسخ — اگر تلفن در دسترس نبود، ایمیل می‌زنیم.

در حال ارسال…

درخواست شما ثبت شد.

همکاران ما پیام شما را می‌بینند و با شما تماس می‌گیرند.