پروژههای بزرگ با فرایندهای سنتی مدیریت نمیشوند از اجرای فیزیکی تا صورتوضعیت، وصول مطالبات و کنترل مالی پروژه
دانشنامه تاج | مقاله مدیریتی و اجرایی
مسئله از نگاه TAJ
در بسیاری از پروژههای پیمانکاری، مشکل فقط این نیست که پروژه سود دارد یا ندارد. پروژه ممکن است از نظر اجرا جلو برود، اما اگر صورتجلسه، دستورکار، مکاتبات، ثبت هزینه و صورتوضعیت همزمان با اجرا پیش نروند«، کار انجامشده» به «مطالبه قابلوصول» تبدیل نمیشود و نقدینگی تحت فشار قرار میگیرد.
پروژه جلو میرود؛ چرا پول عقب میماند؟
در یک پروژه پیمانکاری، پیشرفت فیزیکی فقط یکی از واقعیتهاست. واقعیت دوم این است که چه مقدار از کار انجامشده، مستند، قابلاندازهگیری و از نظر قراردادی قابل مطالبه است. واقعیت سوم هم این است که چه مقدار از مطالبه تأیید شده و چه زمانی به وجه نقد تبدیل میشود. فاصله میان این سه واقعیت، یکی از مهمترین منابع فشار مالی در شرکتهای پیمانکاری است.
از نگاه TAJ مدیریت پروژه وقتی بالغ است که عملیات، قرارداد و مالی در یک زنجیره اطلاعاتی واحد حرکت کنند. اگر کارگاه یک عدد، دفتر فنی عدد دیگر، کنترل پروژه عدد سوم و حسابداری تصویر متفاوتی داشته باشد، مدیر پروژه دیر یا زود با صورتوضعیت برگشتی، مطالبات معوق، اختلاف قراردادی یا گزارش سودآوری غیرقابلاتکا روبهرو میشود.
سه جریان که باید همزمان مدیریت شوند
اگر این سه جریان از یکدیگر فاصله بگیرند، پروژه ممکن است ظاهراً پیشرفت کند اما توان مالی شرکت ضعیف شود. مدیریت حرفهای پروژه دقیقاً برای کمکردن همین فاصله طراحی میشود.
پیمانکاری را فقط از زاویه اجرا نبینیم
پیمانکاری توافقی قراردادی برای انجام کار یا ارائه خدمت در برابر شرایط مالی مشخص است، اما از نگاه مدیریتی، هر پروژه پیمانکاری یک سیستم چندلایه است: اجرا، زمانبندی، تأمین، قرارداد، مستندسازی، هزینه، مطالبات و نقدینگی باید به یکدیگر متصل باشند.
پنج سؤال پایهای که مدیر پروژه باید همزمان پاسخ دهد
- چه مقدار کار واقعاً انجام شده و چه مقدار آن قابل اثبات است؟
- این کار طبق قرارداد، دستورکار یا تغییرات مصوب، قابل مطالبه هست یا نه؟
- هزینه واقعی انجام این کار چقدر بوده و با بودجه چه انحرافی دارد؟
- چه مبلغی صورتوضعیت شده، چه مبلغی تأیید شده و چه مبلغی هنوز وصول نشده است؟
- کدام تأخیر یا مغایرت امروز میتواند در ماههای بعد به Claim کسری نقدینگی یا اختلاف تبدیل شود؟
۲. چرا فرایندهای سنتی در پروژههای بزرگ فرسوده میشوند؟
منظور از «فرایند سنتی» صرفاً استفاده نکردن از نرمافزار نیست. مسئله اصلی، اتکا به حافظه افراد، گزارشهای پراکنده، فایلهای شخصی، تصمیمهای شفاهی، نبود مالک داده و کنترل پس از وقوع است. این روش ممکن است در پروژهای کوچک و کمریسک جواب دهد، اما با افزایش حجم کار، تعداد ذینفعان و پیچیدگی قرارداد، ظرفیت آن محدود میشود.
| اطلاعات پروژه | مرجع داده مشخص و کدینگ مشترک | فایلهای پراکنده و ثبت چندباره |
|---|---|---|
| تصمیمگیری | هشدار زودهنگام بر اساس شاخص و انحراف | واکنش پس از بروز مشکل |
| مستندسازی | همزمان با اجرا و قابلردیابی | پس از اجرا یا هنگام نیاز |
| کنترل هزینه | متصل به WBS/CBS و پیشرفت واقعی | تجمیعی و دیرهنگام |
| تغییرات | گردش کار ثبت، ارزیابی و تصویب | شفاهی یا پراکنده |
| صورتوضعیت | فرایند ماهانه با تقویم و مسئول مشخص | فشار کاری پایان ماه |
| دانش پروژه | تبدیلشده به فرایند و سابقه سازمانی | وابسته به افراد کلیدی |
بنابراین گذار از روش سنتی، پیش از آنکه پروژه خرید نرمافزار باشد، پروژه طراحی فرایند، مسئولیت، داده و کنترل است.
پروژه مدرن یعنی پروژه قابلکنترل؛ نه پروژه پرنرمافزار
ابزارهایی مانند Primavera، Microsoft Project، PMIS، ERP و داشبوردهای مدیریتی میتوانند کیفیت کنترل پروژه را افزایش دهند، اما فقط وقتی که ساختار اطلاعات و فرایند پیش از آن روشن باشد. نرمافزار آشفتگی را اصلاح نمیکند؛ اگر داده مبهم باشد، فقط آن را سریعتر تکثیر میکند.
زیرساختهای اصلی کنترل یک پروژه متوسط یا بزرگ
- ساختار شکست کار (WBS و کدینگ مشترک فعالیتها، هزینهها و مدارک
- برنامه مبنا و روش مشخص اندازهگیری پیشرفت
- بودجه و ساختار هزینه قابل تطبیق با فعالیتها و مراکز پروژه
- کنترل تغییرات، دستورکارها، الحاقیهها و ادعاهای قراردادی
- سیستم کنترل اسناد و مکاتبات رسمی
- ثبت ریسک و تصمیمهای اصلاحی
- اتصال گزارش فنی، کنترل پروژه و حسابداری پروژه
- تقویم بستن کارکرد و تهیه صورتوضعیت
- داشبورد مطالبات، کسورات و جریان نقدی پروژه
صورتوضعیت؛ نقطه تبدیل اجرای پروژه به مطالبه
صورتوضعیت فقط یک جدول مالی نیست. این سند، محل اتصال اجرای فیزیکی پروژه، متره و مستندات فنی، مفاد قرارداد، تغییرات و آثار مالی است. اگر یکی از این لایهها ناقص باشد، مبلغ قابل مطالبه یا زمان تأیید میتواند تحت تأثیر قرار گیرد.
در برخی قراردادهای عمرانی مشمول شرایط عمومی پیمان، سازوکار تهیه و رسیدگی صورتوضعیت در اسناد پیمان مشخص میشود. با این حال، قرارداد، شرایط خصوصی و سایر اسناد پیمان مرجع نهایی هر پروژه هستند و زمانبندی یا الزامات باید بر اساس همان قرارداد کنترل شوند.
| لایه | ریسک در صورت ضعف | مدرک /داده موردنیاز | سؤال اصلی |
|---|---|---|---|
| فنی | کاهش یا رد مقدار کار | متره، نقشه، صورتجلسه، گزارش اجرا | چه کاری واقعاً انجام شده؟ |
قرارداد، دستورکار، الحاقیه، تغییر مقادیر وصورت
وضعیت
اصل اجرایی TAJ
هر آیتمی که قرار است در صورتوضعیت مطالبه شود باید صاحب داده، مدرک پشتیبان، تاریخ ثبت و مسیر تأیید مشخص داشته باشد. اگر این زنجیره فقط در پایان ماه ساخته شود، تأخیر تقریباً اجتنابناپذیر میشود.
۵. چرا «آخر ماه» برای صورتوضعیت خیلی دیر است؟
یکی از خطاهای رایج این است که تهیه صورتوضعیت به فعالیت پایان ماه تبدیل شود. در حالی که صورتوضعیت باید محصول جمعشدن روزانه و هفتگی اطلاعات باشد: متره، صورتجلسه، دستورکار، اسناد مصالح، پیشرفت، تغییرات و مکاتبات باید در طول دوره تکمیل شوند.
تقویم بستن کارکرد ماهانه
ثبت روزانه اجرای واقعی
کارگاه مقدار و وضعیت اجرای کار را با مرجع فعالیت ثبت میکند.
تکمیل مستند فنی
دفتر فنی متره، صورتجلسه، نقشه و دستورکار مرتبط را کنترل میکند.
کنترل پیشرفت
کنترل پروژه پیشرفت واقعی را با برنامه و WBS تطبیق میدهد.
کنترل تغییرات
قراردادها تغییرات، دستورکارها و مبانی قابل مطالبه را نهایی میکند.
تطبیق مصالح و انبار
رسیدها، حوالهها و مصالح پای کار در صورت شمول کنترل میشوند.
تطبیق مالی
هزینه، کارکرد، کسورات و ثبتهای پروژه با اطلاعات فنی تطبیق داده میشوند.
جلسه رفع مغایرت
اختلاف بین واحدها پیش از تهیه نسخه نهایی حل میشود.
ارسال رسمی و پیگیری
صورتوضعیت با مسیر مکاتبات رسمی ارسال و تا تأیید و وصول پیگیری میشود.
در این مدل، پایان ماه نقطه «جمعبندی» است؛ نه زمان شروع جمعآوری اطلاعات.
صورتوضعیت محصول یک واحد نیست
اگر صورتوضعیت را صرفاً مسئولیت دفتر فنی یا مالی بدانیم، یک حلقه مهم از واقعیت پروژه حذف میشود. هر واحد بخشی از داده مورد نیاز را تولید میکند و کیفیت خروجی نهایی به هماهنگی بین این واحدها وابسته است.
| واحد | خروجی موردنیاز | مسئولیت اصلی |
|---|---|---|
| کارگاه و اجرا | گزارش اجرا، تأیید کار، داده متره اولیه | ثبت اجرای واقعی و پیشرفت |
| دفتر فنی | کارکرد قابل استناد و مستندات فنی | متره، نقشه، دستورکار و صورتجلسه |
| کنترل پروژه | پیشرفت، انحراف و تحلیل زمان | مقایسه برنامه و واقعیت |
| قراردادها /امور پیمان | سابقه قراردادی، الحاقیه و مکاتبات | کنترل مفاد، تغییرات و Claims |
| تدارکات و انبار | اسناد خرید، رسید، حواله و مصالح پای کار | تأمین، ورود/خروج و موجودی |
| مالی پروژه | دفتر پروژه، مطالبات و جریان نقدی | ثبت هزینه، مطالبه، کسورات و وصول |
| کنترل اسناد | شماره، تاریخ، پیوست و رسید تحویل | ثبت و ردیابی مکاتبات |
| مدیریت پروژه | تأییدات و تصمیمات بینواحدی | حل تعارض و تصمیم نهایی |
نامهنگاری و کنترل اسناد؛ زیرساخت مالی پنهان پروژه
در پروژه پیمانکاری، نامهنگاری فقط کار اداری نیست. درخواست اطلاعات، دستورکار، اعلام تأخیر، تغییرات، اعتراض، تمدید مدت، ارسال صورتوضعیت و پاسخ به ایرادات، بخشی از زنجیره اثبات حق قراردادی هستند.
برای هر مکاتبه مهم، حداقل موضوع، شماره و تاریخ، فرستنده، گیرنده، مرجع مرتبط، پیوستها، مهلت پاسخ، مسئول اقدام و وضعیت نهایی باید قابلردیابی باشد. وقتی نسخه معتبر سند یا تاریخ تحویل نامشخص باشد، حتی کار واقعی انجامشده میتواند در رسیدگی قراردادی کمقدرت شود.
حداقل کنترلهایی که باید وجود داشته باشد
- شماره یکتا برای نامه، صورتجلسه، دستورکار و مدارک کلیدی
- ثبت نسخه معتبر و جلوگیری از استفاده از نسخه منسوخ
- رسید تحویل یا سابقه ارسال قابل اثبات
- مسئول اقدام و مهلت پاسخ برای هر مکاتبه
- اتصال سند به WBS، آیتم قرارداد یا موضوع Claim در صورت نیاز
- جستوجوی سریع سابقه تصمیم و تغییرات
۸. یک خطای کوچک چگونه به فشار نقدینگی تبدیل میشود؟
در پروژههای پیمانکاری، هزینه بسیاری از خطاها فقط مبلغ اصلاحشده نیست. اختلاف در مقدار، تاریخ، شماره سند، شرح فعالیت یا مبنای قراردادی میتواند باعث بررسی مجدد، مکاتبات اضافی، برگشت صورتوضعیت و افزایش مدت وصول شود.
هزینه فرصت نقدینگی، زمان کارکنان برای رفع مغایرت، تأخیر در پرداخت تأمینکنندگان و فشار روی پروژههای دیگر نیز بخشی از اثر اقتصادی این خطا هستند. به همین دلیل TAJ خطای اطلاعاتی را یک ریسک عملیاتی و مالی میبیند، نه صرفاً یک اشکال اداری.
| ناهماهنگی | پیامد محتمل | نمونه |
|---|---|---|
| پیشرفت و دفتر فنی | برگشت بخشی از کارکرد و گزارش مدیریتی متناقض | گزارش پیشرفت با کار مستندشده همخوان نیست |
| دفتر فنی و قرارداد | ریسک عدم پذیرش یا Claim | کار اجرا شده اما دستورکار/تغییر ثبت نشده |
| انبار و صورتوضعیت | تعلیق یا حذف مبلغ | مصالح درج شده اما مدارک تحویل کامل نیست |
| مالی و دفتر فنی | مطالبات و سود پروژه نادرست | کارکرد تأییدشده با ثبت مالی تطبیق ندارد |
| نامهنگاری و قرارداد | ضعف در پیگیری حقوق قراردادی | اعتراض بدون ثبت رسمی و قابلردیابی |
۹. ریشه ناهماهنگی اطلاعات کجاست؟
- هر واحد از کد، فایل یا تعریف متفاوتی برای یک فعالیت استفاده میکند.
- اطلاعات چندبار در Excel و فرمها مستقل وارد میشوند.
- دوره گزارشگیری واحدها یکسان نیست.
- تغییرات قرارداد و دستورکار دیر به واحدهای مرتبط میرسد.
- مالکیت داده مشخص نیست و معلوم نیست مرجع نهایی هر عدد کدام واحد است.
- مدارک در پوشهها و کانالهای پراکنده نگهداری میشوند.
- گزارش مالی با ساختار WBS و کنترل پروژه کد مشترک ندارد.
- صورتوضعیت، هزینه و جریان نقدی در جلسات مدیریتی جدا از هم دیده میشوند.
مرجع واحد اطلاعات پروژه؛ هسته راهکار یکپارچهسازی
هدف از مرجع واحد اطلاعات این نیست که همه واحدها الزاماً در یک نرمافزار کار کنند. هدف این است که برای هر داده کلیدی، تعریف، مالک، منبع معتبر و مسیر تغییر مشخص باشد و گزارشهای مختلف از یک واقعیت مشترک تغذیه شوند.
اقدامهای اجرایی پیشنهادی
- ایجاد WBS و کدینگ مشترک برای فعالیت، هزینه، قرارداد و مدارک
- تعریف Data Owner برای پیشرفت، متره، هزینه، تغییرات، مطالبات و اسناد
- تعریف تقویم رسمی بستن کارکرد ماهانه
- چکلیست کنترل صورتوضعیت پیش از ارسال
- گردش کار ثبت و تصویب تغییرات و دستورکارها
- گردش رسمی مکاتبات با شماره، تاریخ و مسئول اقدام
- تطبیق دورهای پیشرفت فیزیکی، کارکرد قابل صورتوضعیت و هزینه ثبتشده
- جلسه کوتاه رفع مغایرت پیش از ارسال صورتوضعیت
- اتصال PMIS/ERP در صورت توجیه، بعد از تثبیت منطق فرایند
کنترل مالی پروژه فقط بودجه در برابر هزینه نیست
مدیر مالی پروژه باید بین چهار تصویر تمایز قائل شود: هزینهای که واقعاً ایجاد شده، کارکردی که انجام شده، مبلغی که قابل صورتوضعیت است و مبلغی که وصول شده است. اختلاف این چهار عدد، اطلاعات مدیریتی مهمی درباره سلامت پروژه ایجاد میکند.
| لایه | کاربرد مدیریتی | سؤال |
|---|---|---|
| هزینه واقعی | کنترل هزینه و پیشبینی نهایی | چه مقدار منابع مصرف شده؟ |
| پیشرفت فیزیکی | تحلیل برنامه و ظرفیت اجرا | چه مقدار کار انجام شده؟ |
| کارکرد قابل مطالبه | کنترل فاصله اجرا تا مطالبه | چه مقدار مستند و قراردادی قابل صورتوضعیت است؟ |
| مطالبات /وصول | کنترل سرمایه در گردش و نقدینگی | چه مبلغی تأیید و چه مبلغی دریافت شده؟ |
مدیریت ارزش کسبشده؛ ابزار مفید، نه جایگزین کیفیت داده
مدیریت ارزش کسبشده (EVM میتواند زمان و هزینه را در یک چارچوب تحلیلی کنار هم قرار دهد و به تشخیص انحراف کمک کند. اما خروجی آن فقط به اندازه دادههای برنامه، پیشرفت و هزینه قابلاعتماد است. اگر پیشرفت فیزیکی با مبنای مشخص اندازهگیری نشود یا هزینهها به ساختار پروژه متصل نباشند، شاخص پیشرفته هم تصمیم خوب تولید نمیکند.
در رویکرد TAJ پیش از اضافهکردن شاخصهای پیچیده، کیفیت دادههای پایه و سازگاری، WBS ثبت هزینه و روش اندازهگیری پیشرفت بررسی میشود.
شاخصهایی که سلامت فرایند صورتوضعیت را نشان میدهند
| شاخص | هدف مدیریتی | تعریف |
|---|---|---|
| زمان چرخه صورتوضعیت | کاهش زمان آمادهسازی | از پایان دوره کارکرد تا ارسال رسمی |
| درصد برگشت /اصلاح | کاهش خطای مستندات | تعداد صورتوضعیتهای برگشتی یا دارای اصلاح جدی |
| درصد مغایرت بین واحدها | افزایش یکپارچگی اطلاعات | موارد اختلاف دفتر فنی، کنترل پروژه و مالی |
| فاصله اجرا تا مطالبه | کاهش کارکرد گیرکرده | کار انجامشدهای که هنوز قابل صورتوضعیت نشده |
| مدت تأیید | تشخیص گلوگاه رسیدگی | فاصله ارسال تا تأیید |
| مدت وصول مطالبات | کنترل نقدینگی | فاصله تأیید /سررسید تا دریافت وجه |
| درصد کارکرد بدون سند کامل | کاهش ریسک عدم پذیرش | مبلغ کارکردی که مدارک کافی ندارد |
| مطالبات معوق | تمرکز بر وصول | مبالغ تأییدشده اما وصولنشده پس از موعد |
نقشه راه TAJ برای اصلاح فرایند پروژه پیمانکاری
شناخت قرارداد و مدل اقتصادی پروژه
روش پرداخت، ساختار هزینه، نقاط حساس نقدینگی، الزامات مدارک و مسئولیت واحدها بررسی میشود.
ترسیم جریان واقعی کار و داده
مسیر اجرا، متره، صورتجلسه، تغییرات، صورتوضعیت، ثبت مالی و وصول وضعیت موجود (As-Is) مستند میشود.
شناسایی گلوگاهها و ریسکها
تأخیر مدارک، دوبارهکاری، مغایرت داده، وابستگی فردی و نقاط بدون کنترل اولویتبندی میشوند.
، WBS کدینگ، مالک داده، نقشها، نقاط تأیید و مرجع رسمی هر اطلاعات تعریف میشود.
طراحی Workflow و تقویم پروژه
گردش صورتوضعیت، مکاتبات، تغییرات و بستن کارکرد با مسئول و مهلت مشخص طراحی میشود.
هماهنگی سیستم و ابزار
تنظیم PMIS، ERP یا ابزار موجود متناسب با فرایند انجام میشود؛ نه برعکس.
استقرار، آموزش و سنجش
فرایند در پروژه واقعی اجرا و KPIها پایش میشوند تا اصلاحات به رویه پایدار تبدیل شوند.
بسته به نیاز سازمان، نقش TAJ میتواند اجرایی یا مشاوره/استقرار باشد: از طراحی و نظارت تا آموزش، انتقال دانش و همراهی در اجرای فرایندهای توافقشده.
نمونهای از تجربه حرفهای: وقتی تأخیر وصول فقط تقصیر کارفرما نیست
در تجربه حرفهای اعضای تیم TAJ در فضای پیمانکاری، یکی از الگوهای پرتکرار این بوده است که فشار نقدینگی صرفاً از تأخیر کارفرما در تأیید یا پرداخت صورتوضعیت ناشی نمیشود. بخشی از زمان وصول، داخل خود شرکت پیمانکار از دست میرود: آمادهسازی دیرهنگام صورتوضعیت، جابهجایی و جمعآوری مدارک، تکمیل ناقص صورتجلسهها، نامهنگاری با تأخیر و نبود پیگیری ساختاریافته.
وقتی این مراحل استاندارد و زمانبندی شوند، کارکرد زودتر بهصورتوضعیت قابل دفاع تبدیل میشود، رفتوبرگشت مدارک کاهش مییابد و فاصله اجرای کار تا وصول وجه کوتاهتر میشود. اثر این اصلاح فقط مالی نیست؛ سازمان ظرفیت مدیریت پروژههای بیشتر و بزرگتر را نیز پیدا میکند، چون گردش مستندات و تصمیمها کمتر به حافظه و پیگیری فردی وابسته میشود.
توضیح شفافیت این بخش برگرفته از تجربه حرفهای اعضای تیم تاج است و بهمعنای ادعای اجرای پروژه تحت قرارداد رسمی TAJ نیست. جزئیات اختصاصی مشتریان نیز در این مقاله ارائه نشده است.
خطاهای پرتکرار و اصلاح پیشنهادی
| خطای رایج | اصلاح TAJ | پیامد |
|---|---|---|
| خرید نرمافزار قبل از طراحی فرایند | ابتدا فرایند و مالکیت داده، سپس ابزار | ثبت سریعتر همان آشفتگی |
| تهیه صورتوضعیت از روزهای آخر ماه | ثبت و تکمیل مستندات در طول ماه | فشار، نقص مدرک و برگشت |
| کدینگ متفاوت بین فنی و مالی | WBS/CBS و کد مشترک | گزارشهای غیرقابل تطبیق |
| تغییرات شفاهی | Workflow رسمی ثبت و تصویب تغییر | Claim ضعیف و ریسک عدم پرداخت |
| اتکا به مدیر پروژه برای همه تصمیمها | نقش، سطح اختیار و فرایند تصمیم | گلوگاه و وابستگی فردی |
| فقط گزارش درصد پیشرفت | کنار هم دیدن پیشرفت، کارکرد، هزینه و وصول | پنهانشدن نقدینگی و مطالبات |
چکلیست مدیریتی برای یک پروژه قابلکنترل
- ۱. WBS و کدینگ فعالیتها بین اجرا، کنترل پروژه و مالی مشترک است.
- ۲. برای هر نوع داده کلیدی، واحد مالک و منبع رسمی مشخص است.
- ۳. گزارش اجرای واقعی و متره بهصورت مستمر ثبت میشود.
- ۴. دستورکارها و تغییرات قبل از اثرگذاری مالی در مسیر رسمی قرار میگیرند.
- ۵. صورتجلسهها، نقشهها و مکاتبات نسخه معتبر و قابلردیابی دارند.
- ۶. تقویم ماهانه بستن کارکرد برای همه واحدها مشخص است.
- ۷. پیشرفت فیزیکی، کارکرد قابل صورتوضعیت و هزینه ثبتشده ماهانه تطبیق داده میشوند.
- ۸. مطالبات تأییدشده، سررسید و مدت وصول در داشبورد پروژه دیده میشود.
- ۹. علت برگشت یا اصلاح صورتوضعیت ثبت و تحلیل میشود.
- ۱۰. شاخصهای زمان چرخه، مغایرت و وصول صاحب گزارش مشخص دارند.
- ۱۱. ابزار نرمافزاری با فرایند پروژه هماهنگ شده است.
- ۱۲. درسآموختهها و اصلاحات فرایندی به پروژه بعدی منتقل میشوند.
روش استفاده از چکلیست
هر پاسخ «خیر» یک نقطه برای عارضهیابی است. همه موارد اهمیت یکسان ندارند؛ اولویت اصلاح باید بر اساس اثر بر نقدینگی، مبلغ صورتوضعیت، ریسک قراردادی و تکرار خطا تعیین شود.
جمعبندی؛ بلوغ پیمانکار در فاصله میان کارگاه و پول دیده میشود
پروژه بزرگ فقط با تجربه مدیر پروژه یا نصب نرمافزار کنترل نمیشود. بلوغ واقعی وقتی شکل میگیرد که کارگاه، دفتر فنی، کنترل پروژه، قراردادها، انبار، تدارکات، کنترل اسناد و مالی روی یک جریان داده قابلاتکا کار کنند.
صورتوضعیت یکی از روشنترین نقاطی است که کیفیت این هماهنگی را نشان میدهد. اگر اجرای واقعی بهموقع مستند شود، تغییرات مسیر رسمی داشته باشند، اطلاعات واحدها قابل تطبیق باشند و مطالبات تا وصول پیگیری شوند، پروژه فقط «اجرا» نمیشود؛ مدیریت میشود.
از نگاه TAJ هدف نهایی از فرایندسازی پیمانکاری ساختن سازمانی است که بتواند کار انجامشده را با اصطکاک کمتر به مطالبه قابل دفاع و سپس نقد تبدیل کند؛ همزمان سودآوری، ریسک و ظرفیت رشد خود را نیز بهتر بشناسد.
برای شروع اگر پروژههای شما اجرا میشوند اما صورتوضعیت، مستندات یا وصول مطالبات همیشه عقبتر از کارگاه حرکت میکنند، نقطه شروع الزاماً تعویض نرمافزار نیست. یک بررسی کوتاه از مسیر «اجرا تا وصول» میتواند نشان دهد بیشترین زمان و نقدینگی دقیقاً در کدام حلقه از زنجیره از دست میرود.