תוכנה לחברות בנייה וקבלנים: לקנות, להתאים או לבנות

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

עיקרי הדברים

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

המערכת הראשונה הכי בעלת ערך היא כמעט אף פעם לא ניהול פרויקטים מלא. זה תהליך החשבונות החלקיים לקבלני משנה - הדבר שאוכל שבוע בכל חודש.

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

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

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

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

למה כלי ניהול פרויקטים גנריים לא מתאימים

Monday, Asana ו-Trello ממדלים משימה עם אחראי ותאריך יעד. בנייה לא עובדת ככה. המושגים שבאמת מניעים את העסק לא מיוצגים בכלים גנריים:

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

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

מה לקנות

אל תבנו אף אחד מאלה:

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

מה שווה לבנות

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

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

מבחן המציאות בשטח

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

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

אינטגרציה היא לא אופציונלית

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

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

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

עלות וסדר

היקף	בנייה טיפוסית
תהליך חשבונות חלקיים בלבד, אינטגרציה חשבונאית אחת	6-10 שבועות
חשבונות + תמחיר פרויקט חי + דוחות	3-5 חודשים
בתוספת קליטה מהשטח ופורטל קבלני משנה	6-9 חודשים בסך הכל

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

מתי לא לבנות

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

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

שאלות נפוצות

אפשר פשוט להשתמש ב-Monday.com או Procore לניהול בנייה?

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

כמה פרויקטים צריך לפני שתוכנה מותאמת משתלמת?

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

מה צריך להיות המודול הראשון?

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

מנהלי עבודה באמת משתמשים באפליקציות מובייל?

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

זה חייב להתחבר לפריוריטי?

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