گزارش فنی و حرفه‌ای هوش مصنوعی از بررسی سیستم Excel متره و برآورد همایون ریاضتی
اگر بخواهم این فایل را فقط به‌عنوان «یک فایل اکسل متره» نگاه نکنم و آن را از دید مهندسی متره، طراحی سیستم، مدل‌سازی پارامتریک، معماری اطلاعات و قابلیت توسعه بررسی کنم، ارزیابی عمیق‌تر و حرفه‌ای‌تر این است:
گزارش فنی و حرفه‌ای بررسی سیستم Excel متره و برآورد همایون ریاضتی
فایل مرجع مورد بررسی Riz-01-Frzb-Schedule.xlsm است. این فایل فقط مجموعه‌ای از جداول پراکنده نیست؛ در آن چندین خانواده ابزار و فرم وجود دارد که هرکدام بخشی از یک زنجیره بزرگ‌تر متره را تشکیل میدهند.
نکته مهم در این ارزیابی این است که شرکت پیرراز محل استفاده و فعالیت حرفه‌ای بوده است؛ اما طراحی فرم‌ها، روابط محاسباتی و روشهای مطرح‌شده در این تحلیل به کار و روش همایون ریاضتی نسبت داده میشود.
1. اولین نتیجه: این فایل «Excel Sheet» نیست؛ یک سیستم متشکل از چند Subsystem است
در نگاه سطحی، فایل دارای تعداد زیادی Sheet است.
اما وقتی روابط بین Sheetها بررسی میشود، ساختار واقعی متفاوت است.
می‌توان آن را به این صورت دید:
اطلاعات پروژه
│
▼
┌────────────────────┐
│ نقشه / AutoCAD │
│ اطلاعات هندسی │
└─────────┬──────────┘
│
▼
TEXTWINDOW
│
▼
TEXTWINDOWLEN
│
┌─────────────┴─────────────┐
│ │
▼ ▼
LEGEND اطلاعات هندسی
│ │
└─────────────┬─────────────┘
▼
جدول نازک کاری
│
▼
RIZ-SCHEDULE
│
┌──────────┴──────────┐
▼ ▼
Schedule Sheet Schedule Sheet (2)و در کنار این زنجیره، چند سیستم تخصصی مستقل یا نیمه‌مستقل وجود دارد:
RIZdoor ADAMRO منهول سپتیک تانک چربی‌گیر درز انبساط آسانسور نردبان قائم نردبان شیب‌دار کارهای برقی محوطه پایه چراغ و شیر شیلنگی ZPQ قالب زرب ...
بنابراین معماری واقعی فایل چیزی شبیه یک Estimating System است، نه یک Workbook ساده.
2. تعداد زیاد Sheetها در واقع نشان‌دهنده تنوع موضوعات متره است
در نسخه بررسی‌شده 53 Sheet وجود دارد.
اما 53 Sheet را نباید 53 ابزار مستقل فرض کرد.
آنها را می‌توان به حدود 8 خانواده اصلی تقسیم کرد.
خانوادهنمونه Sheetهانقش
ابزارهای عمومیzarb، قالب، FORMA Riz Dataمحاسبات پایه
ورودی/استخراج اطلاعاتTEXTWINDOW، textwindowLENورود و پردازش اطلاعات
نازک‌کاریLEGEND، جدول نازک کاری، RIZ-scheduleمتره نازک‌کاری
در و پنجرهRIZdoor، samen door، doorzarbشمارش، مساحت، نعل درگاه
کانال تأسیساتRIZ-ADAMROمتره پارامتریک کانال
سازه‌های خاصمنهول، سپتیک، چربی‌گیرمتره سازه‌های تکرارشونده
تجهیزات/فلزکاریآسانسور، نردبان‌ها، درز انبساطمتره آیتم‌های تخصصی
گزارش و Scheduleschedule sheetتجمیع و ارائه خروجی
این طبقه‌بندی یک نکته مهم را نشان میدهد:
Sheetها بر اساس موضوع اجرایی سازماندهی شده‌اند، ولی داخل هر موضوع، منطق پارامتریک وجود دارد.
3. مهمترین ویژگی سیستم: «پارامتر» به جای ورود مستقیم مقدار
این به نظر من یکی از مهمترین جنبه‌های روش شماست.
در متره معمولی ممکن است مترور بنویسد:
بتن کف = 7.9 مترمکعب
ولی در سیستم شما، مقدار نهایی حاصل از پارامترهاست.
مثلاً در منهول:
n = تعداد منهول a = ارتفاع h = ارتفاع محاسباتی L = طول کانال
سپس:
حجم حفاری = 2.94 × 2.94 × h × n
بنابراین:
پارامتر ↓ هندسه ↓ فرمول ↓ مقدار ↓ ردیف فهرست‌بها
این تفاوت بسیار مهم است.
زیرا سیستم شما Quantity را ذخیره نمی‌کند؛ Quantity را تولید می‌کند.
4. این موضوع در ADAMRO بسیار واضح‌تر دیده میشود
در Sheetهای مربوط به:
RIZ-ADAMRO-round
یک پارامتر اصلی مانند طول کانال وارد میشود.
مثلاً:
L = 118
و سپس همین پارامتر در چندین عملیات استفاده میشود:
تسطیح = L × 3.4 خاکبرداری = L × 3.4 × 3.65 بتن مگر = L × 0.1 × 3.4 بتن کف = L × 0.3 × 3.1 آرماتور = L × ضرایب هندسی و وزنی دیوار = L × 2 × 3.4 اندود = L × 2.2
این یعنی:
یک پارامتر مهندسی → چندین عملیات اجرایی
این دقیقاً یک مدل پارامتریک است.
در نتیجه اگر طول کانال از:
118 m
به:
150 m
تغییر کند، مترور مجبور نیست تمام ردیف‌ها را دوباره متره کند.
سیستم باید مقادیر مشتق‌شده را مجدداً تولید کند.
این ویژگی، یکی از قوی‌ترین نقاط روش شماست.
5. RIZdoor حتی یک مرحله جلوتر است
در RIZdoor فقط تعداد درها محاسبه نمی‌شود.
ساختار تقریباً چنین است:
تیپ در ↓ طبقه ↓ تعداد ↓ عرض ↓ ارتفاع ↓ مساحت ↓ دیوار ↓ نعل درگاه ↓ عرض بازشو + 0.4 ↓ انتخاب پروفیل ↓ وزن نعل درگاه
مثلاً سیستم می‌تواند بر اساس عرض بازشو انتخاب کند:
1.6 m → 2L ... 2.0 m → 2L ... 2.3 m → 2 INP ... 3.0 m → 2 INP ...
یعنی Lookup فقط برای نمایش اطلاعات نیست.
در اینجا Lookup در واقع یک قاعده مهندسی را در خود ذخیره کرده است.
این نکته بسیار مهم است.
6. بنابراین Lookup در سیستم شما نقش «Rule Engine ساده» دارد
در نگاه معمولی:
LOOKUP(...)
یک تابع اکسل است.
اما از دید معماری سیستم:
Input ↓ Parameter ↓ Rule Table ↓ Selected Engineering Solution ↓ Quantity
مثلاً:
عرض بازشو
↓
جدول نعل درگاه
↓
پروفیل مناسب
↓
وزناین یعنی جدول‌های استاندارد شما فقط Database نیستند؛ بخشی از Knowledge Base سیستم هستند.
این موضوع در:
- RIZdoor
- LEGEND
- جداول سپتیک
- نردبان‌ها
- درز انبساط
قابل مشاهده است.
7. LEGEND یک نقطه بسیار مهم در معماری سیستم است
Sheet:
LEGEND
در نگاه اول فقط یک جدول کد و شرح نازک‌کاری است.
اما نقش واقعی آن:
Master Data / Dictionary
است.
مثلاً:
FLR 02
↓
سرامیک ...یا:
BASE 03
↓
سنگ مرمریت ...و:
WALL ... CLG ...
در داده‌های واقعی نیز کدهایی مانند FLR 02، WALL 08 و CLG 05 به اطلاعات اجرایی متصل میشوند.
این طراحی بسیار ارزشمند است، زیرا شما شرح مصالح را در همه جا تکرار نکرده‌اید.
به جای:
اتاق A10 سرامیک درجه یک...
کد نگهداری میشود:
FLR 02
و سیستم شرح را از Master Table میگیرد.
8. این یعنی Code از Description جدا شده است
یکی از اصول خوب طراحی اطلاعات همین است:
CODE ≠ DESCRIPTION
مثلاً:
FLR 02
هویت آیتم است.
و:
سرامیک درجه 1 ...
شرح آن است.
این جداسازی اجازه میدهد که اگر شرح تغییر کرد، تمام پروژه‌ها الزاماً نیاز به اصلاح دستی نداشته باشند.
در داده‌های نازک‌کاری نمونه، این تفکیک کاملاً دیده میشود؛ برای مثال FLR 02 تا FLR 05 به مصالح مختلف کف متصل هستند.
9. TEXTWINDOW از نظر معماری، شاید مهمترین بخش کل سیستم باشد
من TEXTWINDOW را یک Sheet معمولی نمی‌دانم.
این Sheet نقش Data Acquisition Layer را دارد.
یعنی:
AutoCAD / Drawing
↓
Text Window
↓
Excelاطلاعاتی مانند:
طبقه بلوک فضا ارتفاع نازک‌کاری نام فضا شرح مقدار نوع
و اطلاعات هندسی مانند:
Area Perimeter Length
وارد سیستم میشوند.
این مرحله اهمیت زیادی دارد، چون سیستم را از:
«متره دستی در Excel»
به سمت:
استخراج اطلاعات پروژه و تبدیل آن به داده قابل پردازش
می‌برد.
10. textwindowLEN نقش ETL دارد
اگر با زبان امروزی Data Engineering صحبت کنیم، Sheet:
textwindowLEN
تقریباً نقش یک ETL ساده را دارد:
Extract ↓ Transform ↓ Load
یعنی اطلاعات خام Text Window را میگیرد و:
- متن را جدا می‌کند
- نوع داده را تشخیص میدهد
- Area را از Perimeter جدا می‌کند
- Length را تشخیص میدهد
- داده‌ها را کنترل می‌کند
- ساختار مناسب برای مرحله بعد تولید می‌کند
حتی کنترل‌هایی مانند:
IF(OR(...),"OK","W")
در آن دیده میشود.
این یعنی سیستم فقط محاسبه نمی‌کند؛ Validation نیز دارد.
11. زنجیره نازک‌کاری، قوی‌ترین معماری فایل است
به نظر من از میان همه بخشهای Workbook، زنجیره نازک‌کاری یکی از حرفه‌ای‌ترین نمونه‌هاست:
AutoCAD ↓ TEXTWINDOW ↓ textwindowLEN ↓ LEGEND ↓ جدول نازک کاری ↓ RIZ-schedule ↓ schedule sheet ↓ گزارش
این یک Pipeline واقعی است.
در آن:
مرحله 1
اطلاعات خام گرفته میشود.
مرحله 2
اطلاعات Parse میشود.
مرحله 3
کدهای نازک‌کاری به شرح تبدیل میشوند.
مرحله 4
Area / Perimeter / Height استخراج میشود.
مرحله 5
مساحت‌های مورد نیاز محاسبه میشوند.
مرحله 6
اطلاعات بر اساس طبقه، بلوک و نوع نازک‌کاری تجمیع میشوند.
مرحله 7
گزارش نهایی ساخته میشود.
این دیگر «فرمول‌نویسی اکسل» به معنای محدود آن نیست.
12. RIZ-schedule نقش Calculation Engine دارد
در RIZ-schedule فرمول‌هایی از جنس:
LOOKUP SUMIF SUMIFS VALUE ROUND
به کار گرفته شده‌اند.
ولی اهمیت واقعی این توابع در ارتباط آنهاست.
مثلاً:
کد نازک‌کاری
↓
نوع کف
↓
نوع قرنیز
↓
نوع دیوار
↓
نوع سقفو همزمان:
شماره فضا طبقه بلوک مساحت محیط ارتفاع
از داده‌های دیگر بازیابی میشود.
بنابراین یک رکورد نهایی ترکیبی از چند منبع اطلاعاتی است.
13. یک نکته بسیار مهم: سیستم شما چند Dimension را همزمان مدل می‌کند
در یک متره ساده ممکن است فقط:
مقدار
وجود داشته باشد.
اما سیستم شما همزمان با چند Dimension کار می‌کند:
Project Building Block Level Room Type Code Geometry Material BOQ Item Quantity
این موضوع بسیار مهم است.
چون بعداً می‌توان پرسید:
کل کف FLR 02 در طبقه اول چقدر است؟
یا:
کل دیوار WALL 08 در بلوک A چقدر است؟
یا:
مقدار یک نوع نازک‌کاری در تمام طبقات چقدر است؟
این همان چیزی است که یک سیستم متره را به یک Information System نزدیک می‌کند.
14. سیستم شما «یک مقدار» تولید نمی‌کند؛ چند خروجی از یک داده تولید می‌کند
این یکی از شاخص‌های مهم روش شماست.
مثلاً در RIZdoor:
تعداد ↓ مساحت ↓ کسر از سطح دیوار ↓ نعل درگاه ↓ وزن نعل درگاه
در ADAMRO:
طول ↓ خاکبرداری ↓ بتن ↓ قالب ↓ آرماتور ↓ دیوار ↓ اندود
در منهول:
n + h + geometry
↓
حفاری
↓
بتن
↓
قالب
↓
آجر
↓
اندود
↓
درب
↓
نردبانبنابراین یک پارامتر اولیه تبدیل به یک درخت محاسباتی میشود.
15. این ویژگی را می‌توان «Dependency Model» نامید
مثلاً:
L │ ├── Excavation ├── Concrete ├── Formwork ├── Reinforcement ├── Brickwork └── Plaster
و در RIZdoor:
Door Type
│
├── Count
├── Area
├── Wall deduction
└── Lintel
│
├── Opening
├── Profile
└── Weightاین ساختار نشان میدهد که سیستم شما بر اساس وابستگی پارامترها طراحی شده است.
16. یکی از نقاط قوت بسیار مهم: «Detail → BOQ»
در بسیاری از متره‌ها دو دنیا از هم جدا هستند:
محاسبات مهندسی
و
فهرست‌بها
اما در سیستم شما ارتباط برقرار شده است:
شرح عملیات
↓
پارامتر
↓
فرمول
↓
مقدار
↓
شماره ردیف فهرستبهااین برای Quantity Surveying بسیار مهم است.
زیرا متره فقط محاسبه حجم نیست.
متره حرفه‌ای باید بتواند بگوید:
این مقدار مربوط به کدام عملیات اجرایی و کدام ردیف فهرست‌بهاست؟
17. بنابراین روش شما سه سطح را به هم متصل می‌کند
من این را یکی از مهمترین نتایج تحلیل می‌دانم:
سطح اول ـ Engineering
هندسه ابعاد جزئیات نوع سازه نوع مصالح
سطح دوم ـ Quantity
طول مساحت حجم وزن تعداد
سطح سوم ـ Cost / BOQ
کد فهرست‌بها شرح عملیات واحد قیمت جمع
و ارتباط:
Engineering
↓
Quantity
↓
BOQ
↓
Costایجاد شده است.
این همان چیزی است که یک سیستم برآورد حرفه‌ای باید انجام دهد.
18. درز انبساط نمونه خوبی از «مدل‌سازی هندسی» است
در Sheet درز انبساط، پارامترهای:
A = Floor Joint B = Ceiling C = Wall
وارد میشوند.
سپس برای مواد مختلف:
Box Section Painting Bronze Cover Copper Sheet Styrofoam
فرمول‌های جداگانه‌ای وجود دارد.
مثلاً:
A+B+C
در چند فرمول مختلف استفاده میشود.
یعنی سیستم ابتدا هندسه مشترک را تعریف کرده و بعد عملیات مختلف را بر اساس آن تولید می‌کند.
این بسیار بهتر از آن است که هر ردیف مستقل و بدون ارتباط متره شود.
19. منهول نیز یک مدل پارامتریک واقعی است
در منهول:
a n L h
پارامترهای اصلی هستند.
و سپس:
Excavation Concrete Brickwork Plaster Formwork Cast Iron Cover Ladder Channel Sand Fill
از آنها مشتق میشوند.
نکته مهم‌تر اینکه در محاسبات منهول، گاهی مقدار بزرگ اولیه با احجام منفی تعدیل میشود:
Gross Volume
-
Subtracted Volume
=
Net Volumeاین نشان‌دهنده تفکر هندسی واقعی در متره است، نه صرفاً ضرب چند ضریب.
20. جداول استاندارد سپتیک و چربی‌گیر یک مفهوم مهم دیگر دارند
در این بخش شما از یک جدول تیپ/استاندارد استفاده کرده‌اید.
مثلاً:
Capacity L W D F H Rebar
سپس پروژه فقط تیپ مورد نظر را انتخاب می‌کند.
بنابراین:
Standard Type
↓
Geometric Parameters
↓
Takeoffاین معماری برای آیتم‌های تکرارشونده بسیار مناسب است.
در واقع شما Engineering Standardization را وارد متره کرده‌اید.
21. تفاوت روش شما با متره سنتی
اگر بخواهیم مقایسه کنیم:
روش سنتی
نقشه ↓ اندازهگیری ↓ محاسبه ↓ نوشتن مقدار ↓ جمع کردن
اما روش موجود در فایل شما:
نقشه ↓ استخراج اطلاعات ↓ پارامتر ↓ قواعد هندسی ↓ فرمول ↓ مقدار ↓ کد فهرست‌بها ↓ تجمیع ↓ Schedule ↓ برآورد
بنابراین از نظر مفهومی، روش دوم بسیار ساختاریافته‌تر است.
22. نکته‌ای که به نظر من درباره روش شما بسیار مهم است
در این سیستم:
Excel جایگزین مهندس مترور نشده است.
بلکه:
تفکر مهندس مترور داخل Excel مدل‌سازی شده است.
این دو کاملاً متفاوت‌اند.
اگر کسی فقط Excel بلد باشد، نمی‌تواند لزوماً چنین سیستمی بسازد.
چون ابتدا باید بداند:
- چه پارامتری مهم است؟
- چه ابعادی از Detail باید استخراج شود؟
- چه عملیاتی از آن ناشی میشود؟
- کدام قسمت باید کسر شود؟
- کدام ردیف فهرست‌بها مربوط است؟
- کدام ضریب مهندسی باید اعمال شود؟
- چه آیتم‌هایی به یکدیگر وابسته‌اند؟
سپس این دانش در Formula پیاده شده است.
23. بنابراین ارزش اصلی سیستم در «فرمول» نیست
این نکته را تأکید میکنم.
ارزش اصلی:
=SUMIF(...)
یا:
=LOOKUP(...)
نیست.
ارزش اصلی در این است که:
چرا SUMIF اینجا استفاده شده؟
و:
چرا این پارامتر به این فرمول وصل شده؟
و:
چرا نتیجه به این ردیف فهرست‌بها منتقل شده؟
و:
چرا تغییر یک پارامتر باید چندین مقدار را تغییر دهد؟
اینها دانش اصلی سیستم هستند.
24. از دید مهندسی نرمافزار، معماری فعلی چند لایه دارد
من ساختار را این‌گونه تعریف میکنم:
Layer 1 — Source
Drawing AutoCAD Specification Engineering Detail
Layer 2 — Acquisition
TEXTWINDOW
Layer 3 — Parsing / Transformation
textwindowLEN
Layer 4 — Master Data
LEGEND Standard Tables Type Tables
Layer 5 — Parametric Calculation
RIZdoor ADAMRO منهول سپتیک چربی‌گیر ...
Layer 6 — Quantity Takeoff
RIZ-schedule RIZmetreh
Layer 7 — Reporting
schedule sheet schedule sheet (2) List Summary
این معماری بسیار قابل دفاع است.
25. اگر DWG → EST → TEXTWINDOW را کامل اثبات کنیم، ارزش سیستم بیشتر میشود
در حال حاضر بخش Excel را می‌توانیم با اطمینان تحلیل کنیم.
اما مرحله AutoCAD را هنوز باید با نمونه DWG بررسی کنیم.
اگر مشخص شود که:
EST Layers
↓
Polygon
↓
Area / Perimeter
↓
Code
↓
TEXTWINDOWبه صورت سیستماتیک انجام میشود، آنگاه تعریف سیستم یک مرحله مهم جلوتر می‌رود:
CAD ↓ Data Extraction ↓ Excel ↓ Quantity Takeoff ↓ BOQ
و در آن حالت دیگر به‌سختی می‌توان کل کار را صرفاً «فایل اکسل متره» نامید.
بلکه می‌توان آن را یک:
CAD-to-Quantity-Takeoff Workflow
دانست.
26. نقطه قوت دیگر: قابلیت تغییر سریع پروژه
فرض کنیم در ADAMRO:
L = 118
باشد.
اگر طول به:
L = 135
تغییر کند، ده‌ها عملیات وابسته باید تغییر کنند.
در سیستم شما این تغییر در نقطه پایه انجام میشود.
این ویژگی در پروژه‌های بزرگ اهمیت بسیار زیادی دارد.
زیرا یکی از مشکلات متره دستی این است که:
یک تغییر کوچک در Detail می‌تواند باعث تغییر تعداد زیادی از مقادیر شود.
در مدل پارامتریک، تغییر از بالا به پایین منتشر میشود.
27. اما سیستم یک ضعف جدی هم دارد: وابستگی زیاد به Cell/Range
این را باید صریح گفت.
بخش‌هایی از سیستم به محدوده‌های ثابت مانند:
$D$16:$D$145 $BM$11:$BM$76 $R$5:$R$374
وابسته‌اند.
این روش در زمان طراحی کاملاً عملی است، ولی اگر ساختار داده تغییر کند، احتمال خرابی زیاد میشود.
مثلاً:
ردیف جدید ستون جدید جابجایی جدول حذف ردیف
ممکن است باعث شود Formula دیگر محدوده صحیح را نبیند.
بنابراین:
Robustness فعلی
متوسط
ولی:
Logic Architecture
قوی
این دو را باید از هم جدا کنیم.
28. ضعف دوم: بعضی قواعد مهندسی به صورت Implicit هستند
مثلاً اگر در فرمولی نوشته شود:
Width + 0.4
فرمول می‌گوید چه کاری انجام شده، اما الزاماً نمی‌گوید:
چرا 0.4؟
این دانش احتمالاً در تجربه مترور وجود دارد.
اما اگر هدف تبدیل سیستم به یک روش مستند و قابل انتقال باشد، باید نوشته شود:
Lintel Bearing Allowance = 0.20 m each side Total = Opening + 0.40 m
در این حالت Formula تبدیل به یک Rule مستند میشود.
29. این موضوع برای ضرایب نیز صدق می‌کند
مثلاً:
1.03
یا:
7.85
یا:
8.9
یا ضرایب هندسی مختلف.
اکسل می‌داند عدد چیست، اما سیستم حرفه‌ای باید بداند:
1.03 = ضریب پرت/وصله/... 7.85 = وزن مخصوص فولاد 8.9 = وزن مخصوص مس
البته فقط در مواردی که مبنای واقعی آن از فرم/مدرک مشخص است؛ نباید برای اعداد مبهم حدس بزنیم.
30. ضعف سوم: Documentation پایین‌تر از سطح Logic است
به نظر می‌رسد:
Logic ████████████████████ Documentation ██████████
یعنی منطق سیستم از مستندسازی آن قوی‌تر است.
این در سیستم‌هایی که توسط طراح اصلی ساخته شده‌اند کاملاً طبیعی است.
طراح می‌داند:
این سلول چرا این فرمول را دارد.
اما نفر دوم ممکن است نداند.
اگر بخواهیم این سیستم را به یک Methodology تبدیل کنیم، این بخش باید تقویت شود.
31. نکته بسیار مهم درباره VBA
نسخه فعلی با پسوند:
.xlsm
است، اما در بررسی Package فایل، VBA Project فعال (vbaProject.bin) مشاهده نشد.
بنابراین در نسخه بررسی‌شده، منطق اصلی سیستم عمدتاً Formula-driven است.
این موضوع اتفاقاً از نظر روش‌شناسی جالب است.
زیرا نشان میدهد بخش بزرگی از اتوماسیون با:
Formula Lookup SUMIF SUMIFS Reference Data Structure
انجام شده است، نه الزاماً با Macro.
این با رویکردی که شما در گذشته درباره کاهش وابستگی به VBA مطرح کرده‌اید نیز همخوان است.
32. از دید Quantity Surveying، سیستم شما سه نوع متره را پوشش میدهد
نوع اول ـ Area Based
مثل:
نازک‌کاری رنگ اندود کف دیوار سقف
نوع دوم ـ Count Based
مثل:
در پنجره چراغ شیر شیلنگی منهول
نوع سوم ـ Parametric Engineering
مثل:
کانال منهول سپتیک چربی‌گیر نردبان درز انبساط
این پوشش موضوعی گسترده یکی از ویژگی‌های مهم سیستم است.
33. حتی در موارد تخصصی‌تر، یک الگوی مشترک وجود دارد
مثلاً:
درز انبساط
Length ↓ Geometry ↓ Material Quantity
نردبان
Height ↓ Length/Profile ↓ Weight
منهول
Height + Count ↓ Geometry ↓ Volume/Area
ADAMRO
Length ↓ Cross Section ↓ Construction Quantities
RIZdoor
Count + Width + Height ↓ Area + Lintel
بنابراین با وجود تفاوت موضوعات، موتور فکری مشترک وجود دارد.
34. موتور فکری مشترک چیست؟
من آن را این‌گونه خلاصه میکنم:
TYPE ↓ PARAMETERS ↓ GEOMETRY ↓ OPERATIONS ↓ QUANTITY ↓ BOQ CODE ↓ AGGREGATION ↓ REPORT
این مهمترین کشف معماری در بررسی فایل است.
35. در نتیجه «روش کار همایون ریاضتی» را می‌توان دقیق‌تر تعریف کرد
تعریف قبلی را می‌توان حرفه‌ای‌تر کرد:
روش کار همایون ریاضتی، یک روش پارامتریک و سیستماتیک برای تبدیل اطلاعات مهندسی، هندسی و اجرایی پروژه به مقادیر متره و اقلام فهرست‌بهاست که در آن پارامترهای پایه، روابط هندسی، عملیات اجرایی، جداول مرجع و کدهای فهرست‌بها به یکدیگر متصل شده و از طریق Excel و در بخش ورودی، اطلاعات استخراج‌شده از AutoCAD، خروجی‌های قابل ردیابی برای متره، تجمیع و برآورد تولید میشوند.
این تعریف نسبت به عبارت «متره با Excel» بسیار دقیق‌تر است.
36. آیا می‌توان گفت این یک «روش» است؟
پاسخ من: بله، با یک شرط.
در وضعیت فعلی، شواهد کافی برای اینکه بگوییم:
یک الگوی روش‌شناختی منسجم وجود دارد
قوی است.
اما برای اینکه رسماً آن را به عنوان یک Methodology مستقل ارائه کنیم، باید قواعد آن را از داخل فایل استخراج و مستند کنیم.
یعنی باید مشخص کنیم:
Input چیست؟ ↓ Parameter چیست؟ ↓ Rule چیست؟ ↓ Formula چیست؟ ↓ Output چیست؟ ↓ Validation چگونه است؟ ↓ Traceability چگونه است؟
در حال حاضر اینها در فایل وجود دارند، اما بخش زیادی از آنها به صورت ضمنی هستند.
37. ارزیابی حرفه‌ای من از سیستم
اگر بخواهم امتیاز تقریبی بدهم:
معیارارزیابی
دانش متره و QS9.5/10
مدل‌سازی پارامتریک9/10
ارتباط هندسه و متره9/10
ارتباط با فهرست‌بها9/10
استفاده حرفه‌ای از Excel9/10
طراحی Master Data8.5/10
Traceability8.5/10
کنترل خطا7.5/10
Maintainability7/10
Documentation6/10
Robustness در برابر تغییر ساختار7/10
قابلیت آموزش به شخص دیگر6.5/10
پتانسیل تبدیل به نرمافزار9/10
این امتیازها ارزیابی تحلیلی من از معماری مشاهده‌شده هستند، نه یک استاندارد رسمی.
38. مهمترین نتیجه تاریخی/حرفه‌ای
اگر این فایل را فقط به عنوان یک فایل Excel معرفی کنیم، ارزش واقعی آن کم‌رنگ میشود.
به نظر من باید آن را در سه سطح معرفی کرد:
سطح 1
Excel Estimating Workbook
که ساده‌ترین تعریف است.
سطح 2
Parametric Quantity Takeoff System
که تعریف فنی‌تر و دقیق‌تری است.
سطح 3
یک روش عملی برای تبدیل دانش متره و مهندسی به سیستم محاسباتی قابل تکرار
که از نظر روش‌شناسی، عمیق‌ترین تعریف است.
39. نقطه‌ای که باید در ادامه روی آن تمرکز کنیم
من پیشنهاد میکنم از اینجا به بعد، فایل را صرفاً Sheet به Sheet توصیف نکنیم.
بلکه برای هر سیستم، یک Dependency Map بسازیم.
مثلاً برای RIZdoor:
Door Type
│
┌───────────┴───────────┐
▼ ▼
Door Count Dimensions
│ │
└───────────┬───────────┘
▼
Area
│
┌────────┴────────┐
▼ ▼
Wall Deduction Lintel
│
Opening + 0.4
│
Lookup Table
│
Profile Type
│
Weightو برای ADAMRO:
L
│
┌──────────┼──────────┐
▼ ▼ ▼
Excavation Concrete Masonry
│ │ │
▼ ▼ ▼
BOQ BOQ BOQو برای نازک‌کاری:
AutoCAD
│
▼
TEXTWINDOW
│
▼
textwindowLEN
│
├───────────────┐
▼ ▼
Geometry Room Data
│ │
└───────┬───────┘
▼
LEGEND
│
▼
Finish Schedule
│
▼
RIZ-schedule
│
▼
Reportingاین Dependency Mapها در واقع نقشه مغز سیستم شما خواهند بود.
40. جمعبندی نهایی من
پس از بررسی دقیق‌تر فایل، برداشت من این است:
این کار در سطح «فرمول‌نویسی اکسل» متوقف نشده است.
هسته اصلی آن عبارت است از:
شناخت ساختار اجرایی پروژه → انتخاب پارامترهای مؤثر → مدل‌سازی هندسه → تبدیل هندسه به عملیات → اتصال عملیات به فهرست‌بها → تولید مقدار → تجمیع → گزارش.
و این الگو در چند حوزه متفاوت تکرار شده است:
نازک‌کاری در و پنجره نعل درگاه کانال آدم‌رو منهول سپتیک چربی‌گیر درز انبساط نردبان آسانسور کارهای برقی محوطه
وقتی یک الگوی فکری واحد در چنین موضوعات متفاوتی تکرار میشود، دیگر با چند فرمول تصادفی مواجه نیستیم.
با یک روش کار مواجهیم.
و به نظر من، ارزش اصلی کار شما دقیقاً در همین قسمت است:
تبدیل تجربه چندین‌ساله متره و برآورد به روابط پارامتریک و سپس پیاده‌سازی آن روابط در یک محیط محاسباتی قابل استفاده مجدد.
اگر مرحله AutoCAD → لایه‌های EST → Polygon → اطلاعات هندسی → TEXTWINDOW را نیز با فایل DWG نمونه اثبات کنیم، می‌توانیم یک نتیجه حتی قوی‌تر بگیریم:
DRAWING ↓ CAD DATA ↓ TEXTWINDOW ↓ PARAMETER EXTRACTION ↓ ENGINEERING RULES ↓ PARAMETRIC TAKEOFF ↓ BOQ ↓ ESTIMATE
در آن صورت، عنوان مناسب دیگر صرفاً «سیستم اکسل متره» نیست؛ بلکه چیزی در حد:
«سیستم پارامتریک استخراج اطلاعات، متره و برآورد مبتنی بر AutoCAD و Excel»
خواهد بود.
و برای پروژه‌ای که داریم انجام می‌دهیم، قدم بعدی بسیار مهم این است که هر 53 Sheet را در یک ماتریس معماری بررسی کنیم: «ورودی | پارامتر | فرمول/Rule | خروجی | Sheet وابسته | ردیف فهرست‌بها | سطح اتوماسیون | نقاط ضعف». این کار از گزارش فعلی یک مستند فنی واقعی از روش کار همایون ریاضتی خواهد ساخت.
