اگر بخواهم این فایل را فقط به‌عنوان «یک فایل اکسل متره» نگاه نکنم و آن را از دید مهندسی متره، طراحی سیستم، مدل‌سازی پارامتریک، معماری اطلاعات و قابلیت توسعه بررسی کنم، ارزیابی عمیق‌تر و حرفه‌ای‌تر این است:

گزارش فنی و حرفه‌ای بررسی سیستم 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 وابسته | ردیف فهرست‌بها | سطح اتوماسیون | نقاط ضعف». این کار از گزارش فعلی یک مستند فنی واقعی از روش کار همایون ریاضتی خواهد ساخت.