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

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

לפני שבונים משהו — מתי לוח בקשות מתאים למשרד ייעוץ ומתי לא

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

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

שכבה ראשונה — לוח שנפתח מטופס, בלי שאף אחד מקליד

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

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

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

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

שכבה שנייה — לחבר כל בקשה לפרויקט שלה עם Mirror

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

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

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

שכבה שלישית — אוטומציה אחת ליום הראשון, ולא עשר

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

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

• מרוויחים: אף בקשה לא נשארת בלי בעלים יותר משתי דקות.
• מרוויחים: המהנדס מקבל התראה על משהו ששייך לו, ולא מנטר לוח.
• מרוויחים: אין ויכוח "חשבתי שאתה לקחת" — יש שורה עם שם.
• לא מקבלים: איזון עומסים. את זה ראש הצוות ממשיך לעשות בעיניים, ובצדק.

מה משנה את היום בפועל — תצוגת Table מסוננת לפי אדם

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

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

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

איפה זה נשבר במשרד — בקשה שנכנסה בלי לציין לאיזה פרויקט היא שייכת

זו נקודת הכשל השכיחה, והיא לא טכנית. אדריכל ממהר, ממלא את הטופס, מדלג על שדה הפרויקט או בוחר את הפרויקט הלא נכון מרשימה של אחד-עשר שמות דומים ("רוטשילד 12" ו"רוטשילד 12 — שלב ב'"). מה שקורה אחר כך: הבקשה נכנסת ללוח בלי חיבור, ולכן עמודת Mirror ריקה, ולכן אין לה מועד יעד, ולכן היא לא מופיעה בשום מיון לפי תאריך. היא קיימת ובלתי-נראית בו-זמנית.

שלוש הגנות מעשיות, לפי סדר עלות:

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

לפני שמשלמים — אילו שאלות משרד כזה צריך לשאול על התוכנית

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

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

מה זה אומר עליך — שלושה צעדים לשבוע הקרוב

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

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

רוצה לראות איך אותו מבנה נראה אצל שכנים בשרשרת התכנון? מאנדיי למשרד אדריכלים מסתכל על אותה עבודה מצד שלבי התכנון וההיתרים, ואילו מאנדיי לחברת בנייה ויזם מראה מה קורה לבקשה כשהיא מגיעה לאתר. לחזרה לתמונה המלאה: מאנדיי לפי סוג עסק — 43 הדגמות לעסק ישראלי.

מקורות

1. Available column types on monday.com — מרכז העזרה הרשמי
2. Get started with monday automations — מרכז העזרה הרשמי
3. The board views — מרכז העזרה הרשמי
4. Plans and pricing for monday.com — מרכז העזרה הרשמי
5. Getting started with workspaces — מרכז העזרה הרשמי

נכון ל-28/08/2026. פרטי ממשק, שמות רכיבים ותנאי מנוי משתנים מעת לעת; המקור הקובע הוא תיעוד הספק.