האמת הלא נוחה על מידע: הבנת תהליכי BIM דרך נקסוס

מידע תמיד מחבר

בספרו נקסוס טוען יובל נח הררי שהתכונה הבסיסית של מידע אינה ייצוג המציאות, אלא חיבור. לפעמים המידע מתאר את העולם בדיוק ולפעמים לא, אבל הוא תמיד יוצר רשת בין אנשים.

מכאן הוא מסיק מסקנה לא נוחה: יותר מידע, ובקצב מהיר יותר, אינו מייצר כשלעצמו יותר אמת. מידע אמיתי הוא נדיר ויקר; ללא מאמץ מכוון להעדיף אותו, הוא נקבר תחת מידע זול ושופע.

רעיון זה מתאר בדיוק רב את מה שקורה בפרויקט BIM. המודל הוא קודם כול רשת שמתאמת עשרות גורמים. העובדה שהוא גם מייצג נאמנה את הבניין היא הישג שיש לבנות ולאמת.

מודל ה-BIM הוא רשת לפני שהוא העתק

נהוג לדבר על מודל ה-BIM כ”תאום” של הבניין, כלומר כייצוג. אבל תפקידו האמיתי בפרויקט הוא לחבר: אדריכלים, מהנדסים, קבלנים, פיקוח, המזמין ובסופו של דבר מחלקת התחזוקה והתפעול - כולם עובדים על אותו מידע.

תקן ISO 19650 מכיר בכך באופן מובלע. סביבת הנתונים המשותפת (CDE), מצבי המידע (בעבודה, משותף, מפורסם, בארכיון) ומטריצת האחריות אינם עוסקים בגאומטריה: הם מתארים מי מעביר מה למי, ומתי. אלה כללים של רשת.

מנקודת מבט זו, כל פרמטר במודל הוא קשר בין אנשים:

נתון במודל	מי מייצר אותו	מי תלוי בו
עמידות אש של דלת	אדריכל / יועץ בטיחות	כבאות, קבלן, תחזוקה
יצרן ודגם של ציוד	קבלן	רכש, תחזוקה, אחריות
קוד נכס	יועץ או קבלן, לפי המפרט	מערכת ניהול התחזוקה
מיקום (מפלס, חלל)	צוות התכנון	תפעול, מצאי, הזמנות עבודה

המודל יכול לחבר היטב את כל הגורמים האלה גם כאשר חלק מהנתונים שגויים. זה בדיוק הסיכון שהררי מצביע עליו.

לאמת יש מחיר: יותר נתונים אינם נתונים טובים יותר

הררי מבקר את “התפיסה התמימה” שלפיה טכנולוגיית מידע חזקה יותר מובילה בהכרח להבנה טובה יותר של העולם. ב-BIM לתפיסה התמימה הזו יש גרסה מוכרת: “אם הכול ממודל, הכול מתועד”.

ניסיון המסירה מלמד אחרת. מודל יכול להכיל אלפי אלמנטים ומאות פרמטרים לכל אלמנט, ובאותו זמן להשאיר ריקים את השדות שהתחזוקה צריכה, למלא אותם בערכים גנריים (“TBD”, “Default”, “0”) או לתת להם שמות שונים מאלה שהוגדרו במפרט. המידע הזול (העתקת משפחות, השארת ערכי ברירת מחדל, ייצוא של הכול) שכיח הרבה יותר מהמידע היקר (בדיקת הציוד שהותקן בפועל ורישום הנתון האמיתי שלו).

לא פעם נתקלתי במפרטים שדורשים להגדיר את כל הפרמטרים לפי רשימה גנרית של איגוד מהנדסים: כ-1,000 פרמטרים שאף אחד לא ביקש ואף אחד לא צריך. זו הצורה הטהורה ביותר של מידע זול: הרבה נפח, אין משתמש ואין קריטריון לאימות.

פלטפורמות הענן מגבירות את שני הצדדים. Forma, Trimble Connect וסביבות CDE אחרות גורמות למידע לזרום מהר יותר בין יותר אנשים, אבל אינן הופכות אותו לנכון יותר. ללא בקרות, הן מאיצות גם את התפשטות הטעות.

להטות את הכף לטובת האמת

בהמשך לקו המחשבה של הררי, דחיית התפיסה התמימה אין פירושה ויתור על האמת. פירושה הוא הכרה בכך שהאמת דורשת “צעדים נוספים” שמטים את הכף לטובתה. בניהול מידע BIM לצעדים האלה יש שמות:

1. להגדיר איזה מידע נדרש. דרישות המידע (OIR, AIR, EIR) ורמת המידע הנדרשת (LOIN) קובעות איזה נתון, באיזה אלמנט, באיזה פורמט ובאיזה שלב. בלעדיהן אין מול מה למדוד את האמת.
2. להשתמש בשמות משותפים. העדפת פרמטרים מקובלים בענף (IFC, COBie, פרמטרים משותפים מוכרים) מצמצמת עמימות: אותו שם מחבר את כולם עם אותה משמעות.
3. להטיל אחריות על מישהו. מטריצת האחריות משייכת כל תוצר לגורם מסוים. מידע ללא בעלים נוטה להישאר בגרסתו הזולה.
4. לאמת לפני קבלה. הבקרה הפורמלית לפני העברת המידע למצב “מפורסם” היא מנגנון התיקון העצמי של התהליך.

שלושת הצעדים הראשונים מגדירים מה נכון עבור הפרויקט. הצעד הרביעי, יסודי כמו הראשונים, הוא שמבטיח שמה שנמסר אכן נכון.

לאמת לפני שיתוף ולפני שימוש

אם מידע אמיתי הוא יקר, הפרויקט צריך להחליט היכן הוא משלם את המחיר. ניהול המידע משיב: לאמת לפני שהמידע משותף ולפני שאחרים מאמצים אותו כבסיס לעבודתם. טעות שמתגלה במקור עולה תיקון אחד; טעות שמתגלה בהמשך הדרך עולה את כל מה שנבנה עליה.

לכן כדאי לתכנן את הפרויקט עם נקודות אימות ביניים, ולא רק עם בקרה סופית במסירה:

1. במעבר מ”בעבודה” ל”משותף”. המחבר בודק את המידע שלו מול הדרישות לפני שהוא חושף אותו לדיסציפלינות אחרות.
2. בשלב האיחוד והתיאום. נבדקת העקביות בין המודלים לפני שדיסציפלינה אחת לוקחת נתונים מאחרת.
3. בכל אבן דרך חוזית. בקרה פורמלית מול רמת המידע הנדרשת לאותו שלב, לפני אישור ההתקדמות.
4. במסירה הסופית. אימות הנתונים שהתפעול והתחזוקה ישתמשו בהם, לפני שהם נכנסים למערכות שלהם.

כל נקודה כזו פועלת כמנגנון התיקון העצמי שהררי מוצא חסר ברוב רשתות המידע: היא עוצרת את התפשטות הטעות לפני שהרשת מגבירה אותה.

הכלכלה של המידע הנדרש

הצד השני של האימות הוא משמעת במה שמבקשים. אם הפרויקט מייצר רק את המידע שנדרש ושעתיד להיות מאומת, מחיר האמת הופך לנסבל: לכל נתון יש משתמש, פורמט ובקרה. דרישה של “הכול”, לעומת זאת, מכפילה את המידע הזול והופכת את האימות לבלתי אפשרי.

כלי אימות אוטומטיים, כמו בדיקת מודלים ישירות בענן, מוזילים את הבקרה. אבל הכלכלה מתחילה מוקדם יותר: במפרט שמבקש מעט (או ליתר דיוק, רק את מה שנחוץ), מבקש בבירור ומגדיר כיצד יאומת.

כשכולם צועדים בתיאום אל הטעות

הררי מציין שרשת יכולה להיות יעילה מאוד ובו בזמן מאורגנת סביב רעיונות שגויים; השקר אינו מחליש אותה בהכרח. בקנה מידה צנוע בהרבה, פרויקטי בנייה מכירים היטב את התופעה.

מודל מאוחד ומתואם היטב מיישר את כל הצוותים. אם נתון בסיסי שגוי (מפלס, מערכת קואורדינטות, סיווג חללים, קוד נכס שהוגדר לא נכון במפרט), הטעות אינה נשארת במקום אחד: היא מתפשטת ברשת באותה יעילות שבה מתפשט הנתון הנכון. כולם עובדים בסנכרון, ובסנכרון טועים.

כמה סימנים לכך שפרויקט פועל על בסיס “אשליה משותפת”:

• דוחות ההתקדמות מודדים כמות אלמנטים שמודלו, ולא עמידה בדרישות.
• אף אחד לא יכול לומר מי אימת נתון ומול איזה מקור.
• המסירה הסופית לתחזוקה מתקבלת כי “המודל שלם”, ללא אימות נתונים.
• הטעויות מתגלות רק בשלב התפעול, כשתיקונן יקר יותר.

שתי שאלות לכל נתון

לסיכום, הררי מציע שבחקר המידע אין די בשאלה “האם הוא נכון?”; יש לשאול גם “את מי הוא מחבר ואיזו רשת הוא יוצר?”. בניהול מידע BIM כדאי לשאול את שתי השאלות על כל דרישה:

• מה הנתון הזה מחבר? מי מייצר אותו, מי משתמש בו ואיזו החלטה תלויה בו. אם אף אחד לא משתמש בו, כנראה שאין לו מקום במפרט.
• מי מבטיח שהוא נכון? מול מה הוא נבדק, באיזה שלב ומה ההשלכה אם הבדיקה נכשלת. אם אף אחד לא מאמת אותו, כנראה שהוא יגיע בגרסתו הזולה.

תפקידו של יועץ ה-BIM נמצא בדיוק בצומת הזה. חצי אחד מהעבודה הוא תכנון הרשת (מי מעביר מה למי), והחצי השני הוא בניית המנגנונים שמבטיחים שמה שזורם ברשת הזו נכון.

מקור

• יובל נח הררי, Nexus: A Brief History of Information Networks from the Stone Age to AI (2024).
• תקן BIM ISO 19650