طراحی داشبورد مدیریتی برای شرکت‌های ساختمانی، از تصمیم تا داده

گزارش خوانده می‌شود، اما داشبورد بارها و بارها بررسی می‌شود. گزارش ماهانه یک وضعیت را توضیح می‌دهد، در حالی که داشبورد باید در چند ثانیه نشان دهد کجا به توجه نیاز است. شرکت‌های ساختمانی معمولاً به سه سطح داشبورد نیاز دارند که هرکدام مخاطب و دوره‌ی زمانی خاص خود را دارد:

• سطح مدیریت ارشد: همه‌ی پروژه‌ها در یک صفحه، برای تصمیم درباره‌ی اینکه کدام پروژه این هفته به توجه مدیریت نیاز دارد.
• سطح پروژه: داشبورد مدیریت پروژه ساختمانی، شامل هزینه، برنامه‌ی زمانی، مدارک و ریسک‌های یک پروژه، برای مدیر همان پروژه.
• سطح عملیات: کارهای امروز و این هفته، مانند درخواست‌های در انتظار تأیید، مدارک ارسال‌نشده و گزارش‌های روزانه‌ی کارگاه.

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

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

چند نمونه از تصمیم‌هایی که در شرکت‌های ساختمانی تکرار می‌شوند:

• کدام پروژه این هفته به حضور مدیریت نیاز دارد؟
• آیا با نیروی فعلی می‌توان مناقصه‌ی بعدی را پذیرفت؟
• پیگیری کدام صورت‌وضعیت‌ها در اولویت است؟
• کدام تأییدها کار کارگاه را متوقف کرده‌اند؟

برای هر تصمیم سه مورد را مشخص کنید: عددی که تصمیم را پشتیبانی می‌کند، آستانه‌ای که از آن به بعد اقدام لازم است و فردی که تصمیم می‌گیرد. CIFE دانشگاه استنفورد، بر پایه‌ی پایگاه داده‌ی شاخص‌های عملکرد CII از ۱۰۰۰ پروژه، مجموعه‌ای از ۱۸ شاخص کلیدی عملکرد را برای صنعت ساختمان پیشنهاد کرده است. ۱۸ شاخص یک مجموعه‌ی پژوهشی برای کل صنعت است؛ اولین داشبورد یک شرکت به همان چند عددی نیاز دارد که مدیرانش واقعاً بر اساس آن‌ها اقدام می‌کنند.

پس از مشخص‌شدن تصمیم‌ها، شاخص‌ها معمولاً در این گروه‌ها قرار می‌گیرند:

• هزینه: هزینه‌ی تعهدشده و انجام‌شده در برابر بودجه، دستورکارها و تغییرات تأییدشده.
• برنامه‌ی زمانی: پیشرفت برنامه‌ریزی‌شده در برابر پیشرفت واقعی و نقاط کنترلی در معرض تأخیر.
• نقدینگی: صورت‌وضعیت‌های ارسال‌شده، مبالغ دریافت‌شده و مطالبات معوق.
• منابع انسانی: تخصیص نیروها به پروژه‌ها و حجم کار هر تیم.
• کنترل مدارک: RFIهای باز، مدارک در انتظار تأیید و نقشه‌هایی که با تأخیر ارسال شده‌اند.
• ایمنی و کیفیت: حوادث ثبت‌شده و موارد عدم انطباق باز.

بیشتر این شاخص‌ها پس‌نگر هستند و آنچه را پیش از این رخ داده گزارش می‌کنند. تعداد کمی از آن‌ها پیش‌نگرند. مدارکی که امروز در انتظار تأیید هستند، تأخیر ماه آینده‌ی کارگاه را پیش‌بینی می‌کنند و RFIای که از موعد پاسخ آن گذشته، احتمال یک دستورکار تغییر را نشان می‌دهد. در هر صفحه دست‌کم یک شاخص پیش‌نگر قرار دهید، چون تنها نوع شاخصی است که مدیر هنوز می‌تواند بر اساس آن اقدام کند.

دفاتر مهندسی و طراحی با پیمانکاران تفاوت دارند و راهنماهای عمومی کمتر به این تفاوت اشاره می‌کنند. برای یک دفتر طراحی، مهم‌ترین عدد معمولاً ساعت‌های کارکرد در برابر حق‌الزحمه‌ی هر مرحله است و پس از آن، مدارکی که طبق برنامه ارسال شده‌اند. داشبوردی که برای یک پیمانکار طراحی شده، این دو عدد را نشان نمی‌دهد.

بیشتر پروژه‌های داشبورد در این مرحله با مشکل روبه‌رو می‌شوند، نه در مرحله‌ی طراحی نمودارها. در یک شرکت ساختمانی، داده‌ها معمولاً در این منابع پراکنده‌اند:

• نرم‌افزار حسابداری: هزینه‌ها، صورت‌حساب‌ها و دریافتی‌ها.
• سامانه‌ی کارکرد: ساعت کار هر فرد برای هر پروژه.
• نرم‌افزار برنامه‌ریزی: فایل‌های MSP یا Primavera با برنامه‌ی زمانی و پیشرفت.
• فایل‌های Excel: جدول‌های پیگیری که هرکدام را یک نفر نگهداری می‌کند.
• کنترل مدارک: فهرست مدارک ارسالی، RFIها و وضعیت تأییدها.
• گزارش‌های کارگاه: گزارش روزانه روی کاغذ، در پیام‌رسان یا در یک فرم.
• مدل‌های BIM: مقادیر و اسکجوال‌هایی که از مدل‌های Revit استخراج می‌شوند.

مطالعه‌ی Autodesk و FMI که بیش از ۳۹۰۰ متخصص صنعت ساختمان را بررسی کرد، هزینه‌ی داده‌ی نامناسب، یعنی داده‌ی نادرست، ناقص، غیرقابل‌دسترس، ناسازگار یا دیرهنگام، را برای صنعت ساختمان جهان در سال ۲۰۲۰، ۱٫۸۵ تریلیون دلار برآورد کرد. در همان مطالعه، ۳۰ درصد از پاسخ‌دهندگان گفتند بیش از نیمی از داده‌های پروژه‌هایشان نامناسب است.

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

داشبوردی که برای پروژه‌ای در مرحله‌ی فونداسیون پیشرفت ۱۰۴ درصد نشان دهد، فقط در یک جلسه مورد توجه قرار می‌گیرد. پس از آن، به یک تصویر پس‌زمینه تبدیل می‌شود.

اعتماد به داشبورد از جزئیاتی ساخته می‌شود که در نگاه اول کم‌اهمیت به نظر می‌رسند:

• تعریف مکتوب هر شاخص: «پیشرفت» می‌تواند درصد ساعت‌های صرف‌شده، درصد مدارک ارسال‌شده یا پیشرفت فیزیکی باشد. تعریف باید یکی باشد و در کنار عدد نمایش داده شود.
• واژگان ثابت برای وضعیت‌ها: فهرست کشویی به‌جای متن آزاد، تا «متوقف» و «توقف» دو وضعیت متفاوت ثبت نشوند.
• یکسانی تاریخ‌ها و واحدها: یک تقویم، یک قالب تاریخ و یک واحد پول در تمام منابع.
• زمان آخرین به‌روزرسانی: کنار هر عدد، تا مشخص باشد عدد امروز است یا مربوط به ماه گذشته.
• امکان ردیابی تا منبع: هر عدد با یک کلیک به سطرهایی برسد که از آن‌ها محاسبه شده است.

مورد آخر از همه مهم‌تر است. وقتی مدیری عددی را باور نمی‌کند و می‌تواند منبع آن را ببیند، یا عدد تأیید می‌شود یا خطای منبع پیدا و اصلاح می‌شود. بدون این امکان، بحث به جلسه‌ی بعد موکول می‌شود و کسی دوباره فایل Excel خود را باز می‌کند.

«هم‌زمان» یکی از رایج‌ترین درخواست‌ها درباره‌ی داشبوردهاست و همیشه ضروری نیست. دوره‌ی به‌روزرسانی هر عدد باید با دوره‌ی تصمیمی که به آن وابسته است متناسب باشد. تأییدهای در انتظار و گزارش‌های کارگاه ارزش به‌روزرسانی روزانه یا هم‌زمان را دارند. هزینه‌ی پروژه معمولاً هفتگی یا ماهانه بررسی می‌شود و به‌روزرسانی لحظه‌ای آن تصمیمی را تغییر نمی‌دهد.

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

بیشتر ابزارهای آماده‌ی هوش تجاری برای زبان‌های چپ‌به‌راست و تقویم میلادی ساخته شده‌اند. برای یک شرکت ایرانی، این موضوع جزئیات ظاهری نیست و بر درستی خود اعداد اثر می‌گذارد:

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

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

انتخاب ابزار پس از مشخص‌شدن تصمیم‌ها و منابع انجام می‌شود و هر گزینه جایگاه خود را دارد:

• قالب Excel: برای یک شرکت کوچک با چند پروژه و یک نفر که داده‌ها را نگهداری می‌کند، کافی است.
• Power BI یا Looker Studio: زمانی مناسب است که داده‌ها در سامانه‌هایی قرار دارند که این ابزارها به آن‌ها متصل می‌شوند و محدودیت‌های راست‌به‌چپ و تقویم شمسی برای شرکت قابل‌قبول است.
• داشبورد داخلی نرم‌افزار مدیریت پروژه: اگر همه‌ی اعداد از پیش در یک نرم‌افزار مدیریت پروژه ثبت می‌شوند، از داشبورد همان نرم‌افزار استفاده کنید. برای این کار به ما یا شرکت مشابهی نیاز ندارید.
• توسعه‌ی داشبورد اختصاصی: زمانی ارزش هزینه‌ی خود را دارد که داده‌ها میان ابزارهای داخلی پراکنده‌اند، راست‌به‌چپ و تقویم شمسی الزامی است، دسترسی‌ها برای هر پروژه متفاوت است، یا کارکنان باید وضعیت‌ها را در همان داشبورد ثبت کنند و فقط بیننده‌ی آن نباشند.

مورد آخر معمولاً عامل تعیین‌کننده است. داشبوردی که فقط نمایش می‌دهد، به ورود داده در جای دیگری وابسته است. داشبوردی که محل ثبت وضعیت‌ها نیز هست، منبع مرجع همان داده‌ها می‌شود و در نتیجه، یک فایل Excel و یک مرحله‌ی دستی حذف می‌شود.

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

1. یک تصمیم و یک صفحه، برای مدیری که آن تصمیم را می‌گیرد.
2. اتصال منابع همان اعداد، همراه با تعریف مکتوب و مالک هرکدام.
3. اجرای موازی با گزارش دستی فعلی به مدت چند هفته و مقایسه‌ی اعداد.
4. کنار گذاشتن گزارش دستی، پس از آنکه اعداد چند هفته پیاپی با آن یکسان بودند.
5. افزودن صفحه‌ی بعدی برای تصمیم بعدی.

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

داشبورد را در همان جلسه‌ای به کار ببرید که اعداد در آن بررسی می‌شوند. اگر جلسه هنوز با فایل Excel برگزار می‌شود، داشبورد هنوز جایگزین آن نشده است.

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

سه نقش درستی داشبورد را حفظ می‌کنند:

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

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