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