איך לבחור מערכת לניהול פרויקטים

איך לבחור מערכת לניהול פרויקטים בתחום התשתיות והבניה

אסף מורג וארז פייגנברג - פברואר 2021

מה החשיבות של מערכת לניהול פרויקטים?

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

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

מטרתו של מאמר זה לפרט את השיקולים שאותם יש לשקול כאשר מבצעים את הבחירה במערכת כזו.

איך מטפלים בפרויקטים מורכבים ?

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

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

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

ריבוי הגורמים העובדים בפרויקט והשפעתם

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

אחד התנאים לפתרונה של בעיית ניגוד האינטרסים הוגדר על ידי מקינזי כמערכת מידע שתהווה Singe source of truth, כלומר – מערכת שתמנע מחלוקות עובדתיות כיוון שתתעד בצורה אמינה ומפורטת את כל מה שחשוב לדעת על אודות הפרויקט. הגדרה זו של מקינזי נעשתה למוסכמה בענף ואנו סבורים שיש לאמצה ולראות בה מטרה מהותית של מערכת המידע שתיבחר.

איך יוצרים מציאות מוסכמת?

המושג מציאות מוסכמת נובע מקיומו של Single source of truth והוא מתייחס למצב בו כל המשתתפים מסכימים על העובדות שקרו במציאות. זה אולי נשמע טריוויאלי, אבל רוב הקונפליקטים מתחילים מאי הסכמה לגבי השאלה הפשוטה - מה באמת קרה?

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

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

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

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

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

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

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

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

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

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

את מי צריכה המערכת לשרת?

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

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

באיזה פרויקטים צריכה המערכת לטפל?

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

אספקת מידע למנהלים ולגורמי ממשל

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

תמיכה בתהליכי עבודה

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

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

נוחות העבודה והתועלת למשתמשים

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

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

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

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

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

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

חבילה ראשונה - ניהולו היומיומי של הפרויקט

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

לוח הזמנים (גאנט)

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

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

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

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

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

חשוב לשים לב שיומן "Stand alone" שאינו מקושר ללו"ז ולמערכת המשימות, יוצר בעיות דומות לאלו שיוצר לו"ז שאינו מקושר. הוא מאפשר, ואפילו מעודד, יצירה של "עובדות אלטרנטיביות" ומפחית מיכולתה של המערכת להיות Single source of truth.

ניהול סיכונים

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

בקשות מידע

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

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

ניהול מסמכים ותוכניות

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

סיכומי פגישות ומשימות

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

התראות ודירוג משימות

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

ניהול שלבי התכנון

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

מערכת ניהול התכנון היא חשובה ביותר.

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

ניהול דו"חות שטח

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

ניתוח פורנזי

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

סגירת פרויקט

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

חבילה שניה - הטיפול בחשבונות ובשינויים

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

ניהול כמויות וחשבונות

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

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

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

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

ניהול בקשות לשינוי חוזה

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

ניהול תקציבים

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

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

רצוי מאוד לאפשר גם ניהול תקציבי בצ"מ ("באפר תקציבי") מה שיאפשר הצגה של התקדמות הביצוע אל מול "אכילת" הבאפר התקציבי.

ניהול מכרזים

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

ניהול שלב התפעול והאחזקה

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

חבילה שלישית - שדרוג יכולות המזמין ותהליכי על

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

ניהול קטלוגים ומחירונים

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

דרוג איכות הביצוע של המשתתפים השונים

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

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

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

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

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

יכולות למידת מכונה ובינה עיסקית

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

איך לנהל את תהליך הבחירה

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

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

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

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

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

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

הפרמטרים המוצעים להשוואה בין מערכות שונות

א - חבילת ביצוע הפרויקט (סה"כ 100 נקודות)

1. יכולת המערכת להיות Single source of truth (סה"כ 11 נקודות)

1.1. את מי משרתת המערכת? (קבלנים? קבלני משנה? מנהלי פרויקטים? מתכננים? צדדי ג'? המזמין?) (4 נק')

1.2. האם המערכת בעלת בסיס נתונים אחוד שבו סוגי הנתונים השונים מקושרים זה אל זה, מעדכנים זה את זה, וכך שומרים על Data Inegrity? (המצב ההפוך הוא מערכת המציגה בתוך דאשבורד אחד מספר מערכות נפרדות). (7 נק') (חברות מסוימות עשויות להציג דרישה זו כדרישת סף שבלעדיה כלל אין לבחון את שאר היבטי המערכת)

2. ספק הענן (סה"כ 2 נק')

2.1. מה איכותו של ספק שרותי הענן מבחינת אמינות, רוחב פס, בטיחות, מניעת סיכוני סייבר, מהירות תגובה, גיבוי אוטומטי והתאוששות אוטומטית? (2 נק')

3. יכולות ניהוליות (סה"כ 6 נק')

3.1. האם קיימת יכולת ניהול Work flows של תהליכים מורכבים - ניהול בקשות מידע, ניהול משימות, ניהול שינויים, ניהול חשבונות וכדומה, או שקיימת רק יכולת איחסון קבצים. (3 נק')

3.2. האם קיימת מערכת התראות פנימית המאפשרת משלוח הודעות באמצעות המייל על מידע חדש המחייב התייחסות? (1 נק')

3.3. האם יש מערכת הרשאות גמישה המאפשרת הגדרת והרשאות גישה למסכים, רשומות, קבצים, ושדות בודדים, על בסיס תפקידם של המשתמשים.? (1 נק')

3.4. האם יש למערכת אפשרות למתן הרשאות עצמאיות למשתתפים השונים? (לדוגמה – האם היא יכולה לאפשר מצבים בהם סיום פרויקט או סילוק יד של משתתף מפרויקט יאפשרו לו צפייה במידע שנוצר טרם הסיום או סילוק היד שלו – זה הכרחי על מנת לחסוך מהמשתתפים את הצורך בשמירת מידע כפולה). (1 נק')

4. ידידותיות למשתמשים ומתן ערך להם (סה"כ 8 נק')

4.1. האם המערכת נוחה לשימוש? האם היא אינה מוסיפה עבודה לגורמים שונים בפרויקט? (2 נק')

4.2. האם המערכת מעודדת את הגורמים השונים לעשות את המשימות שלהם בזמן? (1 נק')

4.3. האם המערכת יכולה לתמוך בתהליך קבלת ההחלטות של הגורמים המשמעותיים של הפרויקט ? (1 נק')

4.4. האם המערכת עוזרת למשתתפי הפרויקט להבין את המשימות שלהם? (0.5 נק')

4.5. האם המערכת מאפשרת לקטלג משימות לפי חשוב ודחוף? (0.5 נק')

4.6. האם למערכת יש אפשרות לתת עדכונים והתראות לכל אחד מהגורמים המשתתפים בפרויקט? (1 נק')

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

5. השתלבות המערכת בארגון (5 נק')

5.1. האם יש אפשרות לשלב מידע עם מערכות אחרות בארגון? (2 נק')

5.2. האם המערכת יודעת לתמוך ולהשתלב בתהליכי העבודה הארגוניים? (1 נק')

5.3. האם למערכת יש מודולריות המאפשרת בחירת המודולים הרלוונטיים לארגון? (1 נק')

5.4. האם יש אפשרות התאמה אישית לצרכי הארגון? (1 נק')

6. אספקת מידע למנהלים ולרשויות (7 נק')

6.1. האם המידע למנהלים נוצר באופן אוטומטי מהמידע המפורט ברמת הפרויקט או שיש צורך ביצירת דיווח ידני מיוחד עבור המנהלים, שאינו נובע באופן אוטומטי מהמידע המצטבר במערכת? (3 נק')

6.2. האם דו"חות המנהלים מתעדכנים באופן אוטומטי מתוך המידע שנוצר בשטח בו ביום? (1 נק')

6.3. האם למערכת יש אפשרות לספק מבט על - על כל הפרויקטים המתנהלים בחברה? (3 נק'

7. מודולים נדרשים במערכת

7.1. לו"ז, יומן עבודה, בקשות מידע (22 נק')

7.1.1. האם המערכת כוללת מודול פנימי לניהול לו"ז הפרויקט או מאפשרת הצגה בלבד של לו"ז ממקור אחר או אינה כוללת לו"ז כלל? (7 נק')

7.1.2. האם המערכת כוללת מודול יומן עבודה ? (5 נק')

7.1.3. האם המידע היומי המוקלד ביומני העבודה, מעדכן את לוח הזמנים מדי יום באופן אוטומטי וללא צורך ביועץ לו"ז? (3 נק')

7.1.4. האם המערכת מנהלת בקשות מידע? (3 נק')

7.1.5. האם המערכת מעדכנת את הלו"ז גם באמצעות בקשות המידע? (שוב – ללא צורך ביועץ לו"ז.) (1 נק')

7.1.6. האם פעילויות לוח הזמנים ניתנות לתחקור? האם ניתן לראות לא רק תאריכי התחלה וסיום אלא גם את כל יומני העבודה שבהם דווח על ביצוע הפעילות, ומה נאמר בהם לגביה, וכן את אזכוריה בסיכומי פגישות ובבקשות מידע? (2 נק')

7.1.7. האם המערכת מאפשרת לנהל סיכונים על גבי לו"ז הפרויקט?(1 נק')

7.2. ניהול משימות וסיכומי פגישות (7 נק')

7.2.1. האם המערכת מאפשרת לקבוע ולנהל משימות? (2 נק')

7.2.2. האם המערכת מאפשרת להוראות ביומני העבודה להצטרף לרשימת המשימות הפתוחות וממנה לסיכומי הפגישות? (1 נק')

7.2.3. האם סיכומי הפגישות ניתנים לניהול הן כפרוטוקולים והן כמשימות נפרדות? (3 נק')

7.2.4. האם כל משימה ניתנת לניהול ולמעקב? (אפשר לדווח ביצוע, להעביר מאחראי אחד לאחר, ולקבל דו"ח מעקב אחר כל ההיסטוריה של המשימה). (1 נק')

7.3. ניהול דו"חות שטח (4 נק')

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

7.3.2. האם כל אחת מההערות בדו"ח ניתנת לניהול בנפרד? האם ניתן לעקוב אחר כל ההערות הפתוחות בכל הדו"חות השונים לפי חתכים שייקבעו? (2 נק')

7.4. מסמכים ותכניות (7 נק')

7.4.1. האם המערכת מאפשרת העלאה, ניהול, חיפוש ועדכון קבצים ותוכניות? (4 נק')

7.4.2. האם יש מנגנון המבטיח שכל המשתתפים מקבלים את התוכניות הכי מעודכנות? (1 נק')

7.4.3. האם ניהול מסמכים ותכניות במערכת מבוסס על מסרים או על מערכת תיקיות בלבד? (רצוי שמסמכים ותכניות יתווספו למערכת באמצעות מסר שיש לו לכל הפחות שולח ותאריך.) (1 נק')

7.4.4. האם המערכת מאפשרת קיטלוג וחיפוש אינטואיטיביים ונוחים? (1 נק')

7.5. ניהול שינויים חוזיים (4 נק')

7.5.1. האם המערכת תומכת בניהול שינויים חוזיים? (1 נק')

7.5.2. האם קיים בה תהליך מובנה לניהול השינויים? (1 נק')

7.5.3. האם התהליך כולל את כל השלבים – מבקשת הקבלן, דרך המלצת מנה"פ, חוות דעת יועצים, החלטת ועדת שינויים ועד הטמעה בכתב הכמויות? (1 נק')

7.5.4. האם התהליך גמיש ויכול להתאים את עצמו לכללי החברה? (1 נק')

7.6. ניתוח פורנזי של עיכובים (5 נק')

7.6.1. האם המערכת מספקת רשימה של כל הפעילויות ששינוי משך הביצוע שלהן השפיע על הנתיב הקריטי? (2 נק')

7.6.2. האם המערכת מאפשרת להציג עבור כל פעילות כזו את יומני העבודה, בקשות המידע והמשימות הקשורים אליה? (2 נק')

7.6.3. האם המערכת מספקת מנגנון של חלוקת אחריות לעיכובים בין המעכבים השונים? (1 נק')

7.7. סגירת פרויקט (2 נק')

7.7.1. האם המערכת מכילה מודול המטפל בסגירת פרויקט? (1 נק')

7.7.2. האם הוא ניתן להתאמה לצרכי ונהלי החברה? (1 נק')

7.8. ניהול שלבי התכנון (10 נק')

7.8.1. האם קיים מודול לניהול שלבי התכנון? (3 נק')

7.8.2. האם יש הבחנה בין תכנון ראשוני, תכנון מוקדם ותכנון מפורט? (1 נק')

7.8.3. האם מערכת ניהול התכנון הינה מבוססת גאנט? (3 נק')

7.8.4. האם המערכת כוללת מנגנון ניהול משימות תכנון? (1 נק')

7.8.5. האם גאנט התכנון מתעדכן באמצעות משימות התכנון? (1 נק')

7.8.6. האם המערכת כוללת מנגנון יעיל לניהול וורסיות של תכניות? (1 נק')

ב - חבילת הכמויות והחשבונות (100 נק')

7.9. ניהול כמויות וחשבונות (40 נק')

7.9.1. האם קיים מודול להגשת חשבונות? (12 נק')

7.9.2. האם אפשר להגיש חשבונות המבוססים על חישובי הכמויות, או שיש בה מודול הגשת חשבונות בלבד? (6 נק')

7.9.3. האם המערכת תומכת בניהול כמויות? (ניהול אסמכתאות לחישוב ודפי חישוב כמויות). (4נק')

7.9.4. האם המערכת תומכת בתהליך בדיקה ואישור חישובי הכמויות? (3 נק')

7.9.5. האם היא מאפשרת אישור כמות שבוצעה בנפרד מאישור החישוב עצמו? (1 נק')

7.9.6. האם היא מאפשרת ניהול כתבי כמויות של קבלני משנה? (2 נק')

7.9.7. האם היא מאפשרת ניהול חשבונות של קבלני משנה על בסיס חישובי הכמויות של הקבלן הראשי? (1 נק')

7.9.8. האם ניתן לשמור את כל חשבונות הביניים בצורתם המפורטת (האם כל דף חישוב כמויות בפרויקט ניתן לקישור לחשבון הספציפי במסגרתו הוגש?). (4 נק')

7.9.9. האם קיימת אפשרות לניהול הצמדות והתיקרויות? (4 נק')

7.9.10. האם קיימת אפשרות לניהול מקדמות והפחתתן לאורך הפרויקט? (3 נק')

7.10. ניהול תקציבים (18 נק')

7.10.1. האם ניתן לבנות ולנהל כתבי כמויות המבוססים על קטלוג הסעיפים? (6 נק')

7.10.2. האם ניתן ליצור אומדן תקציבי לפרויקט באמצעות יישום מחירי המחירון לכתב הכמויות של הפרויקט? (2 נק')

7.10.3. האם ניתן להוסיף סעיפים מחוץ לקטלוג? (2 נק')

7.10.4. האם יש אפשרות להשוות בין תקציב מתוכנן, תקציב עדכני (כולל שינויים) וצריכת תקציב בפועל (בחשבונות המצטברים)? (4 נק')

7.10.5. האם ניתן לנהל ולעקוב אחר תקציבי בצ"מ ("באפר תקציבי") והשימוש בהם בפועל, הן ברמת הפרויקט והן ברמה אגרגטיבית? (4 נק')

7.11. שימוש בקטלוגים ומחירונים (22 נק')

7.11.1. האם קיים מודול לתחזוקת קטלוגים ומחירונים? (10 נק')

7.11.2. האם הוא יכול לקלוט קטלוגים קיימים בשוק? (7 נק')

7.11.3. האם ניתן לנהל מחירים תקופתיים שונים לסעיפי הקטלוג?(5 נק')

7.12. ניהול מכרזים (20 נק')

7.12.1. האם קיים מודול לניהול מכרזים? (5 נק')

7.12.2. האם הוא כולל "לוח מודעות" עם אפשרות להצגת כל קבצי המכרז בפומבי? (3 נק')

7.12.3. האם יש אפשרות למשלוח שאלות הבהרה ישירות לתיקיית המכרז? (2 נק')

7.12.4. האם יש אפשרות קליטה של הצעות "נעולות" אשר יפתחו לעיון רק כשיגיע המועד האחרון להגשת המכרז. (3 נק')

7.12.5. האם יש מנגנון מובנה להשוואת הצעות? (3 נק')

7.12.6. האם ישנן תבניות מוכנות מראש לניהול פרוטוקול ועדת מכרזים, לפסילת קבלן, ולהכרזה על זוכה? (4 נק')

ג - חבילת ניהול הפורטפוליו (100 נק')

8. כלים מתקדמים

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

8.1. ניהול קטלוגים מפרטים ומחירונים (25 נק')

8.1.1. האם יש תמיכה בניהול קטלוג סעיפים? (7 נק')

8.1.2. האם יש תמיכה בניהול מפרטים? (7 נק')

8.1.3. האם יש קישור בין מערכת המפרטים למערכת הסעיפים? (5 נק')

8.1.4. האם יש תמיכה באיסוף תוצאות מכרזים והשוואתן למחירון לשם בניית המחירון הבא? (5 נק')

8.1.5. האם ניתן לנהל מחירים תקופתיים שונים לסעיפי הקטלוג?(1 נק')

8.2. דירוגי איכות משתתפים ומניעת תביעות סרק (25 נק')

8.2.1. האם למערכת יש יכולת לדרג את איכות הביצוע של המשתתפים על בסיס הנתונים הנאספים בה מתוך התנהלותו היומיומית של הפרויקט? (13 נק')

8.2.2. האם למערכת יש יכולת להשוות את האיכות הזו בין משתתפים שונים? (6 נק')

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

8.3. ניהול שלב התפעול והאחזקה (50 נק') (במקרים מסויימים מודול זה יכול להוות חבילה שלמה נפרדת)

8.3.1. האם קיים מודול לניהול שלב התפעול? (20 נק')

8.3.2. האם קיים מנגנון לתזמון עבודות אחזקה מתוכננת ובקרה תקופתית? (15 נק')

8.3.3. האם קיים מנגנון למעקב אחר עבודות אחזקה (מתוכננת ואחזקת שבר גם יחד)? (15 נק')

[1] Reinventing construction – a route to higher productivity, McKinsey global institute, February 2017