هزینه‌یابی پروژه؛ نشت حاشیه سود در کسب‌وکار پروژه‌ای
هزینه‌یابی پروژه یعنی ثبت دقیق هر ریال هزینه، روی همان پروژه‌ای که آن را ایجاد کرده است. در بسیاری از شرکت‌های پروژه‌ای، تیم شلوغ است، فروش رشد می‌کند و با این حال در پایان سال معلوم می‌شود کارهایی که سودده فکر می‌شدند، زیان داده‌اند. علت معمولاً خطای محاسبه نیست؛ هزینه‌ها اصلاً به پروژه نرسیده‌اند.
نشت حاشیه سود از کجا شروع می‌شود؟
حاشیه سود پروژه همان تفاوت قیمت قرارداد و هزینه‌ی واقعی است. اگر بخشی از هزینه در جای دیگری ثبت شود، حاشیه‌ی گزارش‌شده بیش از واقعیت به نظر می‌رسد. سه منشأ رایج نشت وجود دارد:
- کار پیش از قرارداد که به هیچ پروژه‌ای وصل نیست.
- بودجه‌ای که در چند فایل و نسخه‌ی متفاوت پراکنده است.
- درس‌هایی که فقط بعد از بسته‌شدن پروژه، آن هم اگر وقتی باقی بماند، گرفته می‌شود.
کار پیش از قرارداد خانه ندارد
بیشتر شرکت‌ها اندازه‌گیری پروژه را از لحظه‌ی امضای قرارداد شروع می‌کنند، در حالی که کار چند هفته زودتر آغاز شده است: مهندس نقشه می‌کشد، برآوردکننده چند بار قیمت را بازنگری می‌کند، مدیر پروژه به پرسش‌های مشتری جواب می‌دهد و شاید هزینه‌ی چاپ نقشه هم پرداخت می‌شود. چون هنوز کد پروژه وجود ندارد، این ساعت‌ها یا ثبت نمی‌شوند یا به سربار می‌روند.
راه‌حل این است که کد پروژه را همان لحظه‌ای که فرصت جدی می‌شود باز کنید و هزینه‌ها را روی آن بنویسید. اگر فرصت از دست رفت، مجموع هزینه‌ها را به حساب «هزینه‌ی برآورد و پیشنهاد» منتقل کنید. نتیجه دو فایده دارد:
- می‌دانید برای بردن کار چقدر خرج کرده‌اید.
- این هزینه در سربار گم نمی‌شود.
باز کردن زودهنگام کد، انضباط دیگری هم می‌خواهد: فرصت‌های مرده باید تمیز بسته شوند. بدون فرایند بستن، فهرست پروژه‌ها پر از کدهایی می‌شود که هرگز کاری رویشان ثبت نشده است و تشخیص پروژه‌ی واقعی از استعلام بی‌نتیجه سخت می‌شود.
یک بودجه‌ی تأییدشده، نه سه فایل اکسل
وقتی حسابدار برای فهمیدن «برنامه‌ی فعلی» باید پوشه‌ها را بگردد، گفت‌وگو درباره‌ی حاشیه سود از همان ابتدا ناقص است. اگر سه فایل فرض‌های متفاوتی برای نیروی کار و مصالح دارند، گزارش هرقدر هم درست محاسبه شود، پاسخ سؤال «پروژه سالم است یا نه» روشن نیست.
برآورد را به‌عنوان سند ورودی پروژه در نظر بگیرید و فقط یک نسخه‌ی تأییدشده نگه دارید. این نسخه باید شامل این موارد باشد:
- مبلغ قرارداد
- بودجه‌ی نیروی کار
- بودجه‌ی مصالح
- بودجه‌ی تجهیزات
- بودجه‌ی پیمانکاران فرعی
اگر دامنه‌ی کار تغییر کرد، تغییر را جداگانه ثبت کنید و فرض اولیه را بی‌صدا جایگزین نکنید. این همان منطق تحلیل بودجه در برابر عملکرد است: بدون مبنای ثابت، انحراف معنایی ندارد.
درس‌ها بعد از بسته‌شدن پروژه می‌رسد
فروش می‌خواهد کار را ببرد، اجرا می‌خواهد آن را تحویل دهد و مالی می‌خواهد بفهمد چه شد. هر سه هدف منطقی است و حاشیه سود می‌تواند میان آن‌ها گم شود. اگر قیمت‌گذاری چند تحویل اشتباه بوده و خطا دیر کشف شود، شرکت زیان را می‌پذیرد و همان اشتباه دوباره تکرار می‌شود.
برای پروژه‌های بزرگ یا غیرمعمول، یک بازبینی کوتاه ماهانه کافی است. چهار مقدار را کنار هم بگذارید: برآورد، هزینه‌ی واقعی، دستور تغییرها و حاشیه‌ی نهایی. بعد بپرسید دفعه‌ی بعد چه چیزی را باید متفاوت قیمت زد.
ریتم عملی: هفتگی و ماهانه
دو گزارش با دو هدف متفاوت لازم دارید.
| گزارش | تناوب | هدف | محتوا |
|---|---|---|---|
| هزینه‌ی واقعی در برابر بودجه | هفتگی | اقدام در حین اجرا | نیروی کار، مصالح، تجهیزات، پیمانکار فرعی |
| وضعیت کار در جریان (WIP) | ماهانه | ربط پیشرفت به درآمد و نقد | پیشرفت، صورت‌حساب، وصول |
گزارش هفتگی برای اقدام است. مدیر پروژه می‌بیند مصالح از برنامه جلو زده، ساعت‌ها بیرون از دامنه‌ی کار مصرف می‌شود یا صورت‌حساب پیمانکار دیر آمده و تصویر را عوض کرده است. گزارش ماهانه توضیح می‌دهد چه اتفاقی افتاده، اما گزارش هفتگی فرصت می‌دهد آینده را تغییر دهید.
برای حفظ حریم فیش حقوقی، می‌توانید نیروی کار را در گزارش هفتگی به‌صورت یک عدد کل نشان دهید و درآمد را حذف کنید. مدیر پروژه برای کنترل هزینه همین مقدار را لازم دارد.
یک مثال عددی ساده
فرض کنید قرارداد ۱٬۰۰۰ واحد پولی است و بودجه‌ی هزینه ۸۰۰ واحد: نیروی کار ۳۰۰، مصالح ۳۰۰، تجهیزات ۱۰۰ و پیمانکار فرعی ۱۰۰. حاشیه‌ی برنامه‌ریزی‌شده ۲۰۰ واحد، یعنی ۲۰ درصد است.
در هفته‌ی هشتم هزینه‌ی مصالح به ۳۵۰ رسیده در حالی که کار هنوز کامل نیست. اگر ۴۰ واحد ساعت مهندسی پیش از قرارداد هم هرگز روی پروژه ثبت نشده باشد، هزینه‌ی واقعی دست‌کم ۸۹۰ است و حاشیه از ۲۰ درصد به ۱۱ درصد می‌رسد. اگر گزارش هفتگی وجود داشت، مدیر در هفته‌ی هشتم هشدار می‌گرفت، نه در ماه ششم پس از پایان کار.
قدم بعدی: پنج پروژه‌ی اخیر
پنج پروژه‌ی تمام‌شده‌ی اخیر را بردارید. برای هر کدام برآورد، هزینه‌ی واقعی، دستور تغییرها و حاشیه‌ی نهایی را کنار هم بگذارید و بزرگ‌ترین شکاف توضیح‌داده‌نشده را پیدا کنید. بعد بپرسید شکاف اول کجا دیده شد: کار پیش از قرارداد؟ تغییر بودجه در فایلی دیگر؟ هزینه‌ای که بعد از اطمینان مدیر آمد؟ یا فرض قیمتی که کسی بازبینی نکرد؟
با همین یک پروژه اولین تغییر را طراحی کنید: قاعده‌ی باز کردن کد، یک سند برآورد تمیز یا گزارش هفتگی. نیازی نیست سیستم کامل داشته باشید. به یک مسئول مشخص و یک ریتم نیاز دارید. برای ارتباط این ریتم با نقدینگی، کنترل جریان نقد در کسب‌وکار را هم ببینید.
پرسش‌های متداول
کد پروژه را چه زمانی باید باز کرد؟
وقتی کار واقعی شروع می‌شود؛ یعنی مهندسی، برآورد یا برنامه‌ریزی جدی آغاز شده است. صرف یک گفت‌وگوی اولیه لازم نیست کد بگیرد.
اگر فرصت از دست برود، هزینه‌های ثبت‌شده چه می‌شوند؟
به حساب هزینه‌ی برآورد و پیشنهاد منتقل می‌شوند تا بدانید برای جذب کار چقدر هزینه کرده‌اید.
بازبینی پس از پروژه برای همه‌ی پروژه‌ها لازم است؟
در ابتدا برای همه انجام دهید، اما خیلی زود آستانه‌ای تعیین کنید تا فقط پروژه‌های پیچیده یا بزرگ بررسی شوند و وقت تیم تلف نشود.
تفاوت گزارش هفتگی و بازبینی WIP چیست؟
گزارش هفتگی هزینه را با بودجه می‌سنجد تا مدیر اقدام کند. بازبینی ماهانه‌ی WIP پیشرفت، صورت‌حساب و وصول را بررسی می‌کند.
جمع‌بندی
هزینه‌یابی پروژه فقط یک سیستم نرم‌افزاری نیست؛ ترکیبی از مسئول مشخص، یک بودجه‌ی تأییدشده و ریتم گزارش‌دهی است. کد را زود باز کنید، هزینه‌ی پیش از قرارداد را ثبت کنید، هر هفته هزینه‌ی واقعی را با بودجه مقایسه کنید و پروژه‌های بزرگ را پس از پایان بازبینی کنید. حاشیه سود وقتی بهبود می‌یابد که کسب‌وکار پیش از پروژه‌ی بعدی یاد بگیرد، نه پس از بستن دفاتر.