هوشمندسازی فرآیند کاری در صنعت ساختمان از کجا شروع می‌شود؟

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

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

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

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

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

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

گزینه‌ها، فارغ از اندازه‌ی دفتر، معمولاً از چند بخش ثابت می‌آیند:

• کنترل اسناد. فرم‌های ارسال نقشه (Transmittal)، فهرست نقشه‌ها و شماره‌گذاری ویرایش‌ها، جایی که یک فهرست در چند جا کپی می‌شود.
• درخواست‌ها و تأییدها. RFIها، مدارک ارسالی برای تأیید (Submittal) و درخواست‌های تغییر که از طریق ایمیل جابه‌جا می‌شوند و در صندوق ورودی یک نفر منتظر می‌مانند.
• گزارش‌های دوره‌ای. گزارش پیشرفت هفتگی، کارکرد افراد و خلاصه‌ی هزینه‌ها که به‌صورت دستی از چند فایل جمع‌آوری می‌شوند.
• کنترل‌های سمت مدل. مقادیر پارامترها، نام‌گذاری و هشدارهای استاندارد در مدل Revit، که با یک گراف Dynamo یا یک کنترل‌کننده قابل‌پوشش است.
• انتقال میان نرم‌افزارها. خروجی یک مدل سازه‌ای که دوباره در فایل Excel یا نرم‌افزاری دیگر تایپ می‌شود.

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

اولین فرآیند را بر اساس سه معیار و به همین ترتیب انتخاب کنید:

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

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

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

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

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

بسیاری از تلاش‌ها برای خودکارسازی در همان قدم اول متوقف می‌شوند، نه به این دلیل که منطق پیچیده است، بلکه به این دلیل که داده‌های موردنیاز میان چند فایل، چند نفر و چند قالب ناسازگار پراکنده‌اند. این مشکل قدیمی است و اندازه‌گیری هم شده است: مطالعه‌ی NIST هزینه‌ی ناکافی‌بودن تبادل داده (Interoperability) در صنعت تأسیسات سرمایه‌ای آمریکا را برای سال ۲۰۰۲، ۱۵٫۸ میلیارد دلار برآورد کرده که دوسوم آن بر عهده‌ی مالکان و بهره‌برداران بوده است و خود گزارش، این عدد را احتمالاً محافظه‌کارانه می‌داند.

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

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

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

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

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

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

داشبورد زمانی ارزش هزینه‌ی خود را دارد که یک تصمیم واقعی و تکرارشونده را سریع‌تر کند، مانند اینکه کدام پروژه از برنامه عقب است یا کدام تیم بیشترین درخواست تأیید در انتظار را دارد. داشبوردی که کسی هفته‌ای یک‌بار به آن نگاه می‌کند اما بر اساس آن تصمیمی نمی‌گیرد، یک نمایشگر است، نه یک ابزار.

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

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

ابزارهایی که در بیشتر راهنماها نام برده می‌شوند، از Autodesk Construction Cloud و Procore تا Bluebeam و Dynamo، همه توانمند هستند. هیچ‌کدام از آن‌ها تعیین نمی‌کنند کدام فرآیند باید خودکار شود یا قواعد آن چیست. ابزار را پس از تعریف فرآیند و توافق بر سر منبع داده‌ها انتخاب کنید و اگر ابزاری که دفتر همین حالا برای آن هزینه می‌پردازد از عهده‌ی کار برمی‌آید، همان را انتخاب کنید.

اگر فرآیند ساده است و کسی در تیم با ابزارهای بدون کد (No-Code) آشناست، آن را داخلی بسازید؛ برای این کار به ما یا هر تیم دیگری نیاز ندارید. کمک بیرونی زمانی منطقی است که فرآیند هم‌زمان با چند سامانه سروکار دارد، داده‌های پشت آن واقعاً پراکنده است یا نتیجه باید به داشبوردی تبدیل شود که دفتر سال‌ها بتواند به منطق آن تکیه کند.

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

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