בקשה להצעות RFP

בקשה להצעות - RFP

בקשה להצעות - RFP

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

שלב בקשה להצעות נחלק למספר תתי שלבים ברורים:

1. כל הפעילויות עד להוצאת המפרט (RFP) לספקים.

2. כל הפעילויות הכרוכות בהכנת ההצעות ע"י הספקים.

3. כל הפעילויות מקבלת ההצעות ועד לסיכום וקבלת החלטה.

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

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

מבוא – מנהלה

הגדרות ועקרונות

בקשה להצעות – Request For Proposals

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

 ·         כל הפעילויות עד הוצאת מפרט לספקים (וכתיבת מפ"ל)

 ·         מהוצאת המפרט ועד הגשת ההצעות ופתיחתן הרשמית.

 ·         מקבלת ההצעות ועד סיכום וקבלת החלטה

 ·         בניית מסמך SOW כתשתית לפרויקט

 ·         התקשרות עם הספק שהצעתו התקבלה וחתימת חוזה.

מסמך בקשה להצעות

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

מפ"ל – מסמך פנימי לבדיקה

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

מענה הספק

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

SOW, מסמך קונסולידציה

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

גורמים מעורבים

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

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

תקנות חוק המכרזים

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

עקרונות

בבקשה להצעות נערכת ונארזת הגדרת המערכת הידועה ברגע נתון (תיק אפיון!) במבנה מיוחד הנקרא מפרט ומוגשת לספקים. הספק מצדו מגיש מסמך תשובה. יש כאן מפגש בין שני עצי מערכת. עץ המערכת של הארגון (המזמין) ועץ המערכת של הספק (המציע). ככל שעץ המערכת של הארגון (המפרט) ברור יותר ומוגדר היטב, יהיה גם עץ המערכת של הספק (ההצעה) ברור ומעשי יותר. המפרט יתאר ברכיב 1 את יעדי המערכת (כך שהספק ידע מהן מטרות המערכת), יתמקד ברכיבים 2, 3 ו- 4 בהתאם לסוג המערכת הנדונה ויכין טבלאות למילוי ברכיב 5 (עלות). הצעת הספק תתמקד ברכיבים 2, 3, 4 ו- 5– כפוף לסיווגים של המפרט – ויהיה גם ברור ממנה שהיא עונה ליעדים שתוארו ברכיב 1. (רכיב מיוחד 0 - מנהלה מתווסף לעץ המערכת בשלב בקשה להצעות ומשתתף במפגש הנ"ל כפי שמוסבר בהמשך). הקפדה על ההתאמה במבנה של שני עצים אלה (רכיב מול רכיב) מקלה מאד על ההשוואה בין ההצעות, על בדיקתן מול המפרט ועל ההחלטה במי לבחור. בשיטה זו, הצעת הספק מחייבת יותר וניתנת לשליטה ובקרה נוחים בשלב העיצוב והבנייה.

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

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

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

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

קלט-תהליך-פלט

קלט

כללי:

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

 ·         ידע כללי על התחום הרלוונטי ועל מצב השוק

 ·         דוגמאות של בקשות להצעות קודמות (שבוצעו לפי מפת"ח!).

 

לתת-שלב א': הכנת המפרט

 ·         מסמך אפיון

 ·         גלופת מפרט (בקשה להצעות) או גלופת פרק המנהלה (להלן)

 ·         גלופת מפ"ל (להלן)

 ·         מפרטים קודמים (כולל של משרדים וארגונים אחרים).

 

לתת-שלב ב': הכנת ההצעות

 ·         המפרט (RFP)

 ·         שאלות תשובות והבהרות: סיכומי כנסי ספקים

 

לתת-שלב ג': בדיקת ההצעות

 ·         מפ"ל (כולל טפסי הבדיקה, תבחינים, משקלות וכו')

 ·         המפרט (RFP)

 ·         הצעות הספקים (כולל תמצית מנהלים)

 

לתת-שלב ד': התקשרות

 ·         דוגמת חוזה (ראה קיט חוזים והיבטים משפטיים בכרך נושאים תומכים)

 ·         המפרט והמפ"ל הממולא

 ·         ההצעה שנבחרה

התהליך

ראה פעילויות - תכנית עבודה להלן. ראה גם סעיף 4.3  במסמך האפיון.

פלט

סופי, מתת-שלב ד': התקשרות

 ·         חוזה התקשרות + SOW, תיק מערכת (תיק עיצוב ראשוני)

 ·         תוכנית עבודה לפרויקט (4.2 בתיק המערכת)

 

מתת-שלב ג': סיכום הבדיקה

 ·         מסמך מסכם והמלצות (מפ"ל ממולא)

 ·         טפסי בדיקה והערכה

 ·         פרוטוקולים וסיכומי ביניים (מעבר בתנאי סף, למשל).

 

מתת-שלב ב': הגשת ההצעות

 ·         הצעות ספקים בפורמט הנדרש

 

מתת-שלב א': הכנת המפרט

 ·         מפרט סופי ומפ"ל.

לו"ז ומשאבים

לו"ז

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

 ·         חסם תחתון:  שלושה חודשים

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

 

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

משאבים

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

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

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

 

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

גורמים מעורבים

גורם מאשר ביצוע השלב

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

גורם מבצע

הצוות המקצועי שמונה לשלב זה

גורם אחראי

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

גורם מחליט

בשלב בקשה להצעות יש לקבל שתי החלטות ראשיות:

 ·         אישור יציאה למכרז (החלטה סופית ואישור המפרט והמפ"ל)

 ·         בחירת ההצעה העדיפה, המשך הפרויקט והתקשרות.

 

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

החלטה -המשך

ההחלטה

אלטרנטיבות להמשך:

 ·         התקשרות והמשך ביצוע.

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

 ·         אין המשך: הקפאת המערכת וסגירה מסודרת של הפרויקט.

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

 

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

תנאים לאי-ביצוע

שלב בקשה להצעות לא יבוצע במקרים הבאים:

 ·         בניית המערכת ע"י הארגון (יחידת המחשוב).

 ·         פטור ממכרז ע"י הגורמים המוסמכים (גורם מחליט לעיל).

 

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

פעילויות - תכנית עבודה

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

פירוט הפעילויות וסיווגן:

להלן פירוט פעילויות (תכנית עבודה) לביצוע שלב בקשה להצעות בחלוקה לארבע קבוצות פעילויות:

 ·         תת-שלב א: הכנות והוצאת המפרט ע"י הארגון,

 ·         תת-שלב ב: הכנת ההצעות (המענה) ע"י הספק/המציע,

 ·         תת-שלב ג: בדיקה וסיכום ע"י הארגון.

 ·         תת-שלב ד: התקשרות בין המציע לבין הארגון.

 

פעילויות המסומנות ב- [n] הן פעילויות צומת, אבני דרך או סקרים.

תת-שלב א: הכנות והוצאת המפרט

1 בדיקת תיק האפיון

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

[2] גיבוש וציוות כל הגורמים המעורבים

בחירת הצוות המקצועי

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

 

גיבוש ועדת ההיגוי \ הצוות המנהלי

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

[3] בניית תוכנית עבודה

תכנית העבודה עוברת למעשה מספר סבבים:

 ·         תכנית ראשונית נכתבת בשלב האפיון (רכיב 4.3 במסמך האפיון).

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

 ·         תכנית העבודה נבנית סופית ועוברת אישור סופי כאן.

 

פעילות זו בונה את תוכנית העבודה לשלב בקשה-להצעות עצמו!

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

יש לבצע את סבב האישורים ליציאה למכרז ולפנייה לספקים! (ראה מבוא – מנהלה לעיל).

[4] החלטה על צורת הפנייה לספקים

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

5 קביעת שיטת המכרז

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

 ·         החלטה על אפשרות לשילוב ספקים וקבלני משנה.

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

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

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

6 כתיבת המפרט - RFP

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

7 הכנת המסמכים הפנימיים לבדיקה - מפ"ל

במקביל לכתיבת המפרט, לאחר השלמת טיוטה מסודרת ראשונה, יש לכתוב את המסמך הפנימי המגדיר את תהליך הבדיקה (מפ"ל).

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

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

 

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

[8] החלטה סופית על יציאה למכרז

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

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

9 הוצאת המפרט

 ·         הדפסות ואריזה, כולל פרסום אלקטרוני באתר אינטרנט/אינטראנט

 ·         פרסום ברשומות/בעיתונות/באתר מתאים

 ·         חלוקה והפצה

 ·         ניהול רשימת הספקים שקבלו/רכשו את המפרט: תאריך, נציג, חתימה

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

תת-שלב ב: הכנת ההצעות

10 קריאת ההצעה ובחינתה

 ·         אם בידי הספק יש רק את פרק המנהלה, האם כדאי לו לרכוש את המפרט המלא?

 ·         קריאה מהירה של ההצעה ובחינה כללית האם הספק יכול לענות על מכרז זה?

 ·         פרק המנהלה – האם יש לספק בעיה עקרונית?

 ·         ריכוז סעיפי M – יש לספק מענה?

 ·         ריכוז סעיפי S – יש לספק יתרון?

 

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

11 עריכה \ השתתפות כנס ספקים

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

לכנס ספקים יש שתי מטרות (בלבד!):

 ·         לוודא שהספקים מבינים היטב מה מבוקש.

 ·         להביא את כל הספקים למכנה משותף ואחיד.

 

סדר הפעולות המומלץ הוא כדלקמן (וכמוגדר בסעיף 0.3 בפרק המנהלה של הבקשה להצעות):

 ·         ריכוז שאלות הספקים (יוגשו בכתב/פקס/דוא"ל, מספר ימים לפני הכנס)

 ·         עריכת המפגש, הצגת השאלות, מתן תשובות לשאלות

 ·         פרסום פרוטוקול הפגישה, כולל הבהרות שניתנו וכו'. הבהרות אלה מחייבות את משתתפי המכרז !!!

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

12 כתיבת ההצעות

 ·         הספקים מכינים את הצעותיהם

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

 ·         ניתן להיעזר בגלופת הצעת ספק. ראה סעיף הכנת ההצעות להלן.

 ·          

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

 

תת-שלב ג: בדיקה וסיכום

13 קבלת ההצעות ופתיחתן

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

 ·         רישום כל הצעה שהתקבלה/נפתחה

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

14 בדיקה I של ההצעות - סינון ראשוני

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

 ·         קריאה ראשונה (הבדיקה בשלב זה היא ע"ס קריאת ההצעות בלבד)

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

 ·         סינון ראשוני לפי רכיבי סף שהוגדרו במפ"ל:

             ·         רכיבי סף של פרק המנהלה

             ·         רכיבי סף דרגה 1- על פני המפרט כולו (ראה הסבר במפ"ל).

[15] כינוס הגורם המחליט לאישור הסינון הראשוני

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

 

לאורך כל הבדיקה - זכור! - הבדיקה מתנהלת על פי המפ"ל!

 

16 בדיקה II של ההצעות

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

 ·         סינון רכיבי סף מדרגה 2 - (אם הוגדרו)

 ·         הבהרות ומצגות

 

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

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

 

17 הערכות, מתן ציונים וסיכומים

סיכום רכיבי התועלת: רכיבים 2, 3 ו- 4 במפרט

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

 

סיכום רכיב העלות (רכיב 5)

ריכוז עלויות ההצעות.

 

סיכומים והערכות סופיות (עלות/תועלת).

18 עריכת חקר ישימות מחודש

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

 ·         הצעות הספקים אינן ריאליות (מוטות למעלה או למטה).

 ·         אמידת העלויות שבוצעה בשלב האפיון, אינה ריאלית.

 

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

[19] החלטה

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

בסיכום ההצעות מומלץ לנקוט בשיטה של דירוג ההצעות לפי מיקומן ביחס עלות\תועלת יורד: הצעה עדיפה מס' 1 (ההצעה הזוכה), עדיפה מס' 2, עדיפה 3 וכו'. שיטת ה- First refusal.

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

 

או החלטה חלופית:

 

[20] החלטה II – Best & Final

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

[21] יידוע גורמים נוספים

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

תת-שלב ד: התקשרות

[22] הכנת ההתקשרות עם הספק(ים)

 ·         מינוי צוות לקיום פגישות וסיכום ההתקשרות עם הספק

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

 ·         תכנית עבודה: קביעת לוח פגישות קצר וצפוף. 

[23] פגישות עם הספק

סגירת החוזה ותיק המערכת

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

 ·         לוחות זמנים

 ·         אבני דרך ופריסת עלויות

 ·         צוותים ואנשי קשר

 ·         מקום וסביבת הפיתוח

 ·         נהלי עבודה

 

ראה פירוט פעולה זו בסעיף התקשרות בסוף מדריך זה.

 

תיקונים ושינויים - שיפור ההצעה

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

[24] אישור ההתקשרות והמשך הפרויקט

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

[25] ביצוע התקשרות עם הספק/ים

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

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

סיכום: תת שלבים קלטים ותוצרים

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

 

תת שלב

קלט

פלט

זיהוי הקלט

מקור הקלט

זיהוי הפלט

יעד הפלט

א': הכנת המפרט – הארגון/המשרד מפרסם המכרז

מסמך אפיון

תיקיית הפרויקט

מפרט סופי ומפ"ל

ועדת מכרזים

הפצה/מכירה לספקים מיועדים

גלופת מפרט בקשה להצעות או גלופת פרק המנהלה

קיט בקשה להצעות

גלופת מפ"ל

קיט בקשה להצעות

מפרטים קודמים/דומים

מהארגון וממשרדים/ארגונים אחרים

ב': הכנת ההצעות – ספקים פוטנציאליים

המפרט (RFP)

תת-שלב א'

מענה הספקים בפורמט הנדרש

הארגון מפרסם המכרז

שאלות תשובות והבהרות

סיכומי כנסי ספקים

ג': בדיקת ההצעות – ועדת מכרזים בארגון/משרד

מפ"ל כולל טפסי הבדיקה, תבחינים, משקלות וכו'

תת-שלב א'

מסמך מסכם והמלצות (מפ"ל ממולא)

ועדת מכרזים

המפרט (RFP)

תת-שלב א'

טפסי בדיקה והערכה

הצעות הספקים כולל תמצית מנהלים

תיבת המכרזים

פרוטוקולים וסיכומי ביניים (מעבר בתנאי סף, למשל).

ד': התקשרות הארגון/משרד עם הספק הזוכה

דוגמת חוזה

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

חוזה התקשרות + תיק מערכת SOW (תיק עיצוב ראשוני)

ועדת מכרזים

תיקיית הפרויקט

המפרט והמפ"ל הממולא

תת-שלב ג'

תוכנית עבודה לפרויקט (4.2 בתיק המערכת)

תיקיית הפרויקט

ההצעה שנבחרה

תת-שלב ג'

 

 

סיווג סעיפי המפרט

הגדרות הסיווג

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

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

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

I – (Information)

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

G – (General)

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

S – (Specific)

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

M – (Mandatory)

רכיב סף (Go/NoGo), נקרא גם סעיף חובה (Mandatory). (ה"חובה" היא בתוכן הסעיף, לא בעצם הצורך לענות. הצורך לענות חל על כל סעיפי המפרט כמוסבר ב"סעיף 0.9 בפרק המנהלה" להלן). תשובת הספק תהיה מסוג "קראנו והבנו - מקובל עלינו, הצעתנו עונה על דרישות סעיף זה", או תשובה עניינית ומלאה בדומה לסיווג S, או קיום דרישה (המצאת אישור למשל) או התחייבות לקיום דרישה. הכל בהתאם לעניינו ותוכנו של הסעיף. חוסר תשובה, תשובה שאיננה עונה לדרישה, חוסר מענה לדרישה, או תשובה לא ברורה ולא חד משמעית, בסעיף מסוג זה, תפסול את ההצעה על הסף

N – (Not relevant)

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

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

קשיים ביישום הסיווג

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

סעיפי I (Information)

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

סעיף 0.9 בפרק המנהלה

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

סעיפי M (Mandatory)

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

המלצות מפת"ח

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

פרק המנהלה

פרק 0 מנהלה של המפרט, זכה למעמד מיוחד משום שהוא מכתיב את "כללי המשחק" של המכרז, מציג תנאים מנהליים בסיסיים, מזין במיוחד את הפרסום בעיתונות, יש לו זיקה מיוחדת לאנשי הרכש והייעוץ המשפטי וכו'. מעמד מיוחד זה, בא לידי ביטוי בסיווגו באופן כולל וגורף כ- M. זאת, כמוגדר בסעיף 0.5.2 בפרק המנהלה עצמו. במחשבה שנייה, כתוצאה מהניסיון שנרכש ולאור ההגדרות המחודשות לעיל, נראה לנו שמומלץ לשנות הגדרה כוללת זו, היינו למחוק את סעיף 0.5.2 ולסווג כל סעיף במנהלה בפני עצמו ובהתאם לכללים הנ"ל: I, S, G וכמובן M לאותם סעיפים שהם אכן מנדטוריים (אישורים וכו').

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

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

סעיפי I חוזרים לכוונתם המקורית

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

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

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

חידוד השימוש בסעיפי S

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

שימוש בסעיפי G

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

סעיפים מנדטוריים M – Go / No-Go

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

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

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

 ·         דרישות להצגת יכולות, כגון: ניסיון, כוח אדם ומיומנויות, פרויקטים דומים, רשימת ממליצים והתקנות, הסמכה לתקן או רגולציה, היקף עסקי וכו'. לדעתנו, חוות דעת שלילית ברורה של הממליצים יכולה לפסול ב- Go / No-Go.

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

 

דרישות שניתן לאמת רק בשלב הביצוע, לא יכולות להיות מסומנות כמנדטוריות. לדוגמא, מומלץ מאד לא לסמן כ- M את סעיף 4.2 תכנית עבודה משום שהיא איננה ניתנת לבדיקה ואימות בשלב בדיקת המענים. סעיף 4.2 יסווג S או G בהתאם לאילוצים ולדרישות תאריכי יעד של מוציא המפרט, כפי שמוסבר לעיל. המציעים יפרטו את תכנית העבודה שנראית להם תוך התחשבות באילוצים ובדרישות המסגרת של תכנית העבודה. בבדיקת ההצעה יתחשב הבודק גם בניסיון המציע בעבודות דומות ובחוות דעת הממליצים על האופן בו הוא עמד בלוחות הזמנים בפרויקטים דומים. דוגמא נוספת, אין לסמן כ- M דרישה שהתוכנה שתסופק (תפותח) תכיל תכונות כאלה ואחרות. הבטחה זו של הספק, כמו העמידה בלוחות הזמנים הנ"ל, יעוגנו בחוזה ובמפרט הטכני שיצורף לו (SOW) ואי עמידה בהם כמוה כאי עמידה בחוזה. באופן דומה יסווגו וייבדקו דרישות לזמני תגובה וביצועים, דרישות לאמינות וכו'. בכל הדוגמאות שהובאו, נכון לרגע המכרז ובדיקת ההצעות, ניתן לבדוק רק הסתייגות מהדרישות הספציפיות שהוזכרו בסעיפים אלה ולתת להם ציון כפונקציה של התרשמות צוות הבדיקה מהתייחסות המציע, מתכונות מוצרים קיימים ומניסיון קודם (ממליצים). פסילה של מציעים שלגביהם יש חשש ברור שהבטחותיהם בסעיפים אלה אינן ריאליות ושעמדו בכל הדרישות הפורמאליות, לא תיתכן אלא בסעיפי סף של טכנולוגיות ויכולות (סעיפים 2,3 לעיל), או בציון איכות ו\או עלות מינימאליים.

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

ציון סף לאיכות ("סיווג L")

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

המשמעות החוזית של הסיווג

יש להבחין בין שתי נקודות זמן:

 ·         לפני חתימת ההסכם עם הספק – המכרז,

 ·         אחרי חתימת ההסכם עם הספק – תקופת ההתקשרות / העבודה.

 

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

סיווג (M) משמש לפסילת הצעה על הסף, לפני חתימת ההסכם.

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

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

יש להבחין בין שני סוגי רכיבים:

 ·         רכיבים המחייבים את הספק,

 ·         רכיבים שאינם מחייבים את הספק.

 

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

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

תוצרים

תיקיית הפרויקט

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

 ·         תוצרי תיעוד לסוגיהם השונים, קלטים ופלטים.

 ·         תוצרי מערכת מוחשיים.

 

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

תיקיית הפרויקט משקפת את מצבו של הפרויקט בהיבט העיקרי לפיו הוא נמדד, לאמור: מה הופק והושג כבר ומה עדיין לא, מה הם ה- Deliverables שהושלמו נכון לרגע נתון ואילו Deliverables יש עוד להשלים!

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

 

תוצרי תיעוד

התוצרים המרכזיים של שלב בקשה להצעות הם:

 ·         מסמך בקשה להצעות - מפרט

 ·         מסמך פנימי לבדיקה - מפ"ל

 ·         הצעות ספקים (מועמדים) – תשובות למפרט

 ·         מסמכי סיכום הבדיקות והמלצה (מפ"ל ממולא)

 ·         חוזה התקשרות

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

 

התוצר

באחריות

קשור לתת שלב

מסמך בקשה להצעות - מפרט

מוציא המפרט

א.       הכנת המפרט

ב.       בדיקת ההצעות

ג.        התקשרות

מסמך פנימי לבדיקה – מפ"ל

מוציא המפרט

א.       הכנת המפרט

ב.       בדיקת ההצעות

הצעות ספקים (מועמדים) – תשובות למפרט

ספק – מציע

א.       הכנת ההצעות

ב.       בדיקת ההצעות

ג.        התקשרות (ההצעה שנבחרה)

מסמכי סיכום הבדיקות והמלצה (מפ"ל ממולא)

מוציא המפרט

א.       בדיקת ההצעות

חוזה התקשרות

משותפת

א.       הכנת המפרט (נספח למפרט)

ב.       הכנת ההצעות (הסכמה\חתימה)

ג.        בדיקת ההצעות

ד.       התקשרות

 

 

מסמך בקשה להצעות

מפרט (RFP) המוגש לספקים לצורך קבלת הצעות מורכב משני חלקים:

 ·         חלק מנהלי אדמיניסטרטיבי

 ·         חלק טכני מקצועי.

 

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

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

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

הנחיות כלליות לכתיבת המפרט

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

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

3.       יש לשים לב לרכיבים המיוחדים הבאים:

             ·         0.X – הבהקים

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

             ·         97.X - אחר, הערות והרחבות

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

             ·         98.X - נקודות פתוחות וחלופות

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

             ·         99.X- דרישות עתידיות

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

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

בתשובה לסעיף זה נא לציין: …

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

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

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

 

פרק המנהלה במפרט

פרק המנהלה (פרק 0) מכיל את התנאים הכלליים והנוהליים של הבקשה להצעות. בדומה למנהלה של מסמכים אחרים במפת"ח, תפקידו הוא לנהל את השלב הנוכחי. ועם זאת, יש למנהלה של המפרט מבנה ותפקיד ייחודיים. יש לבנותו באמצעות גלופת העבודה שבקיט זה, שהיא גלופה עירומה, שלדית, תוך התבססות על גלופת הלימוד המקבילה. יש להיצמד לטקסט הבסיסי עד כמה שניתן. הפרק כתוב בנטייה למשרדי ממשלה והוא תואם את תקנות חוק המכרזים והוראות החשב הכללי במשרד האוצר (הוראות תכ"ם). ארגונים אחרים, יתאמו פרק זה עם הנחיות רכש וכספים המקובלים אצלם וכן עם היועץ המשפטי בארגון (ראה למשל סעיפים 0.3, 0.6, 0.7, 0.8 וכו').

החלק הטכני של המפרט

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

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

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

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

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

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

הקשר בין המפרט ומסמך (תיק) האפיון

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

 

הפרק במסמך האפיון

סיווג במפרט

שיכתוב והערות

0. מנהלה

M

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

1. יעדים

I

בדרך כלל אין סיבה לשכתוב. יעדי המערכת צריכים להיות ידועים ומוסכמים על כולם.

2. יישום

G או S

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

S או G

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

2.21 נפחים ועומסים

S

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

3. טכנולוגיה

S, M או G

סיווג מדויק יקבע בכל תת-רכיב (X.3). יש להרבות בחסמים ובאילוצים, במטרה לצמצם את מרחב ההצעות. תת-רכיבים שאינם נדרשים לא יושמטו אלא יסומנו N. לדוגמא: 3.30  LAN (N), אין דרישות לרשת LAN.

4. מימוש

S או M

פרק זה דורש שיכתוב רב, כמוסבר בגלופת הלימוד.

4.1.4 פרטי הספק

S  (M חלקי)

סעיף מרכזי במפרט. ראה הסבר בגלופת הלימוד.

5. עלות

S

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

5.4 מחירון

S

יש להוסיף רכיב זה למפרט.

 

 

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

מפ"ל - מסמכים פנימיים לבדיקה

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

 ·         תנאי סף

 ·         סולם הציונים

 ·         משקלות

 ·         תבחינים

 ·         אופן סיכום והצגת התוצאות לפני הגורם המחליט

 

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

 ·         מה בעצם רוצים

 ·         מה חשוב יותר ומה פחות

 ·         אילו דרישות במפרט הן פתוחות ואילו סגורות

 

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

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

גלופת מפ"ל

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

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

1. כללי - מנהלה

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

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

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

2. תנאי סף

תנאי סף להכללת הצעת הספק בהשוואה הסופית של עלות\תועלת ההצעות השונות, הם משלושה סוגים:

 ·         דרישות \ סעיפי סף

 ·         תועלות (איכויות) סף

 ·         עלויות מינימום ו\או מקסימום.

 

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

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

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

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

 

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

 ·         אפס הצעות. שום הצעה לא עברה את תנאי הסף.

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

 

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

2.1 סעיפי סף במפרט – דרישות סף

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

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

אפשר לדרג את סעיפי הסף לשתי דרגות:

 ·         אי-עמידה בסעיף אחד מדרגה זו (ציון 0 או 1) פירושה פסילת ההצעה.

 ·         אי-עמידה ב- X סעיפים מדרגה זו (ציון 0 או 1) על פני ההצעה כולה, פירושה פסילת ההצעה. המלצת מפת"ח: X = 3.

 ·          

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

 

2.2 תועלות (איכויות) סף

תועלות סף הן ציונים מינימליים לרכיבי צד התועלת (האיכות) במפרט: יישום ו\או טכנולוגיה ו\או מימוש (לא עלות ולא יעדים). הציון המינימלי יהיה בד"כ (אם בכלל משתמשים בטכניקה זו) לרכיב אב, למשל, לרכיב 2 יישום בכללותו, לרכיב 3 טכנולוגיה בכללותו וכו'. לדוגמא, ציון נמוך מ-60% ברכיב היישום יפסול את ההצעה. שימוש בטכניקה זו אינו שכיח כמו סעיפי סף לעיל ויש לשקול כל מפרט \ מכרז לגופו.

2.3 עלויות סף

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

3. ציונים, משקלות ותבחינים

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

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

 ·         רכיבים המסומנים I או N.

 ·         רכיב העלות.

 

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

4. סיכום תועלות

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

5. סיכום עלויות

גלופת המפ"ל מכילה טבלה פשוטה של ריכוז עלויות.

6. סיכום כולל: עלות/תועלת

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

הכנת המענה לבקשה להצעות

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

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

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

טיפים והמלצות לספק

להלן רשימת פעולות ונקודות מומלצות:

לימוד והכנות

1.       אל תמעיט בערך ההתארגנות וההכנה. אל תכתוב את המענה ברגע האחרון.

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

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

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

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

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

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

כתיבת המענה

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

2.       תן מענה גם לסעיפי "I". ראה דוגמא בגלופה הנ"ל.

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

4.      הפרד בהצעתך בין:

             ·         תמצית מנהלים (כתוב כזו, גם אם לא נדרש במכרז)

             ·         גוף המענה (השתדל שלא יעלה על 70 עמודים)

             ·         נספחים (הרחבות לסעיפים במענה). זה המקום להוסיף חומר טכני\פרסומי  וכדומה.

5.      הקדש זמן לעריכה נאותה:

             ·         כותרות, מספרי עמוד (X מתוך Y),

             ·         פסקאות, מרווח בין שורות

 

זכור הצעתך היא חלון הראווה שלך!

 

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

 

בדיקה וסיכום

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

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

הקשר בין המפרט להצעת הספק

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

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

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

 

הפרק במפרט וסיווגו השכיח

תכולה במפרט

תכולה במענה הספק

0. מנהלה - M

במבנה הגלופה של מפת"ח, בשינויים והתאמות מזעריים.

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

1. יעדים - I

הגדרה ברורה של היעדים. דגש על 1.6 ישימות ועלות/תועלת.

סיווג שונה מ-I ?

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

2. יישום - G או S

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

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

3. טכנולוגיה - S או G, חלקי גםM

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

בהתאם לנדרש במפרט ובהסכמה ברורה שההצעה בסעיף זה מתאימה להגדרת היישום בסעיף 2

4. מימוש - S וגם M, G, I

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

סעיף מרכזי בתשובת הספק! הצעה ברורה למימוש המערכת המכסה את סעיפים 2 ו- 5 ואשר יחד עם רכיב 5 עלות, נותנת הצעה כוללת:turnkey & fixed price.

5. עלות - S

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

עיקר תשובת הספק! מילוי  כל הטבלאות כנדרש. ההצעה ברכיב זה מתאימה לתשובה בסעיף 4 מימוש ומכסה את כל הדרישות ברכיבים 2, 3 ו- 4.

 

 

טכניקות וכלים

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

במידה שמשתמשים בכלי ממוחשב לבדיקת הצעות יש לשים לב לנקודות הבאות:

 ·         מהי השיטה לסכום עלות/תועלת שמציע הכלי, כיצד היא משתלבת עם שיטת הסיכום הנדרשת במפ"ל (סעיף 5 לעיל) וכיצד היא מסייעת להצגת הסיכומים הסופיים והמלצות לפני הגורם המחליט.

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

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

 ·         מה דרישות הסביבה הממוחשבת של הכלי?

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

 ·         האם יש תמיכה בעברית?

הצגת הסיכומים

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

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

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

התקשרות עם הספק

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

 ·         חוזה התקשרות

 ·         תיק המערכת SOW (נספח טכני)

 

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

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

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

 

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

 

כיצד מתחזקים SOW?

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

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

ניהול הפגישות עם הספק

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

 ·         לוחות זמנים

 ·         אבני דרך ופריסת עלויות

 ·         צוותים ואנשי קשר

 ·         מקום וסביבת הפיתוח

 ·         נהלי עבודה

 ·         ועדת היגוי

 ·         פוסק וטיפול בחריגים

 

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

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

סיכום

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

זכותו (אף חובתו) של מוציא המפרט להגיע להתקשרות המיטבית שתבטיח ביצוע מוצלח של הפרויקט. מהעבר השני, זו גם זכותו\חובתו של הספק להגיע לעסקה הטובה ביותר מבחינתו. ובסה"כ, צריך להגיע למצב שזו עסקת Win/Win שהיא טובה לשני הצדדים. יש לזכור שלדו-שיח עם הספק בתת-שלב זה יש מטרה אחת בלבד: כריתת התקשרות על בסיס המפרט וההצעה שהוגשה ונתקבלה. פתיחת נושאים וכניסה למו"מ רחב, עלולה לגרום לבעיות משפטיות, מקצועיות וניהוליות שימנעו בסופו של דבר את ביצוע ההתקשרות. מו"מ כזה הוא, להלכה ולמעשה, פתיחה מחדש של תנאי המכרז!

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

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

 

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

 

מכרזים מיוחדים (ספציפיים)

מכרזי ייעוץ

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

 ·         ביצוע שלב אפיון, עיצוב ובניה, בדיקות או תפעול של מערכת מידע או תשתית

 ·         בניית תכנית עבודה לאבטחת איכות

 ·         בניית עץ מערכת תשתית (כולל) לאבטחת מידע

 ·         תכנון והקמה של תשתית מחשוב חדשה

 ·         הכנת מכרז גדול/מסובך

 

התייחסות ספציפית למכרזי יעוץ ניתן למצוא בקיטים הבאים בכרך יסודות/מחזור חיים:

 ·         בחירת יועץ לביצוע אפיון – קיט אפיון מערכת

 ·         בחירת יועץ לביצוע בדיקות – קיט בדיקות מערכת

 

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

בכל מקום בו פונקציה חיצונית למערכת משתמשת גם היא בעץ המערכת להגדרת תכניה כמו במקרה של בחירת גורם חיצוני לאפיון או בדיקות, יש בעיה של דו-משמעיות (רקורסיביות) של עץ המערכת. האם הסרגל של מפת"ח: 1. יעדים, 2. יישום, 3. טכנולוגיה וכו', הוא של המערכת עצמה או של הצעת היועץ לאפיון/בדיקה (פרויקט הייעוץ). האם, למשל, בסעיף 5. עלות הכוונה לעלות המערכת והאופן בו היועץ מציע לאפיין (לאמוד) אותה, או שהכוונה לעלות היועץ עצמו (עלות ביצוע שלב האפיון). דוגמא אחרת: האם בסעיף 3.13 כלי פיתוח הכוונה לכלים בהם תפותח המערכת שהגדרתם היא חלק מתוצאת שלב האפיון (רכיב 3.13 בתיק האפיון הסופי שיגיש היועץ), או שהכוונה לכלים שהיועץ מציע (בהצעתו כעת) להיעזר בהם לצורך ביצוע שלב האפיון או הבדיקות עצמם. בעיה דומה קיימת בסעיף 4.2 תכנית עבודה.

התשובה במקרה זה, כמו בכל המקרים הרקורסיביים הדומים, היא שעץ המערכת, המיוצג ע"י תיק המערכת העדכני לאותו שלב, הוא תמיד המערכת עצמה ויש להפריד בין מענה הספק לתיק המערכת (החלק המקצועי של המפרט), לבין תשובתו לפרק המנהלה שלהלן. תשובת הספק לתיק המערכת היא עם הפנים קדימה למערכת, היינו, האופן בו הוא רואה ומבין את המערכת וכיצד הוא ממליץ להתקדם בהגדרת תכני עץ המערכת (תיק אפיון!), או לבצע את הבדיקות (תיק בדיקות מערכת) שיטות ומדדים שהוא מציע ואף הערות (אם יש) למסמך. כל זאת, על סמך הידע המקצועי שלו, ניסיונו במערכות דומות וכו'. תשובה זו היא בד"כ פתוחה. תיק המערכת מסומן, בד"כ G. תשובת היועץ לפרק המנהלה, לעומת זאת, היא הצעתו לביצוע השלב/המטרה עצמם. תשובה זו היא סגורה יותר. פרק המנהלה מסומן, בד"כ,  S או M. ראה במיוחד סעיף 0.9 שם.

 

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

 

בניית המפרט

בניית מפרט ומפ"ל לבחירת יועץ מורכבת מהפעולות הבאות:

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

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

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

2.       כתיבת פרק המנהלה לפי ההנחיות להלן.

3.       כתיבת מפ"ל בהתבסס על גלופות לימוד ועבודה בקיט זה

פרק המנהלה

פרק המנהלה לבקשה להצעות לבחירת יועץ תואם את פרק המנהלה הכללי אשר מתואר בקיט זה, עם זאת, יש בו מספר התאמות וקיצורי דרך המפשטים את התהליך. אם נדרשת הרחבה של סעיף (קיום כנס ספקים, למשל), יש לחזור למנהלה הרגילה ולהרחיב את הסעיף המתאים ולא ליצור סעיף חדש. הפרק כתוב בנטייה ברורה למשרדי ממשלה והוא תואם את תקנות חוק המכרזים והוראות החשב הכללי במשרד האוצר (הוראות תכ"ם). ארגונים אחרים, יתאמו פרק זה עם הנחיות רכש וכספים המקובלים אצלם (ראה למשל סעיפים 0.6.1, 0.6.7, 0.6.8, סעיף 0.7 וכו').

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

מפ"ל ובדיקת ההצעות

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

התקשרות

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

מכרזי כוח אדם

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

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

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

חבילות תוכנה

במכרזים לחבילות תוכנה מומלץ להשתמש בנוסח מובנה ואחיד ולהשתמש יותר בטבלאות (שרבות מהן יכולות להילקח מרכיבי 0.Y.X כמו 2.5.0) בהן יש טור לדרוג הפתרון: קיים, דורש התאמות קלות, דורש התאמות יסודית, ייכתב מן היסוד וכו'.

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

מיקור חוץ – Outsourcing

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

 ·         מפרט - תנאי סף, ניסוחים ברורים מה נדרש מהספק לענות, סעיפים פתוחים/סגורים, שמירה על הקיים מול פיתוחים חדשים וכו'

 ·         מפ"ל -  משקלות, יחס עלות תועלת, תנאי סף ועוד.

 

תת שלב ההתקשרות בו נעשה שימוש בחוזה Outsourcing, הוא מטבע הדברים אחד השלבים המרכזיים ביותר בפרויקט. יש לשים לב להנחיות מפת"ח לתת-שלב זה כפי שהן מופיעות במדריך זה ולהימנע מפתיחת הנושא תחת הכותרת של מו"מ או Best & Final.

ראה התייחסות ספציפית למכרז ולהתקשרות בקיט מיקור חוץ Outsourcing בכרך ניהול/ניהול הארגון.

בקשה למידע – RFI

בקשה לקבלת מידע (RFI: Request For Information) היא פניה בלתי פורמלית לספקים לצורך קבלת מידע. במפת"ח, אין תהליך מיוחד ל- RFI. בקשה לקבלת מידע יכולה להיעשות באחד משני אופנים:

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

             ·         ראיון המשתמשים

             ·         לימוד המצב הקיים

             ·         בניית אבטיפוס

             ·         קריאת ספרות מקצועית

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

2.       ע"י שלב בקשה להצעות מלא ומסודר. במקרה זה RFP = RFI = RFQ = בקשה להצעות מסודרת. אלא שכאן הדגש הוא יותר על סעיפי היישום והטכנולוגיה (ואף הם לידיעה בלבד ואינם מחייבים) ופחות על העלות ומנהלה.

 

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

 

RFI איננו תחליף לאפיון מסודר. ברוב המקרים מומלץ לבחור באופן א לעיל, ולהימנע מפניות פורמליות לספקים.

 

בל"מ – בקשה למחיר – RFQ

בקשה להצעת מחיר (בל"מ) או בשמה באנגלית (RFQ Request For Quotation) היא סוג מיוחד של מפרט (מכרז) בו הבקשה היא להצעת מחיר בלבד. מבחינת מפת"ח זהו מקרה פרטי של בקשה להצעות (מכרז) בו הדגש הוא על המחיר וכל (רוב) שאר הסעיפים הם לידיעה בלבד (סעיפי I) למעשה, כל RFQ הוא בעצם RFP ומכרז לכל דבר.

מכרזי מסגרת

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

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

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

 

מכרזי מסגרת בשירות המדינה

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

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

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

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

פיתוח בסבבים ויחידות מסירה

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

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

 ·         כיצד לכתוב מפרט מסוג זה

 ·         כיצד לבחון ולדרג את ההצעות

 ·         איך תבוצענה ההתקשרויות

 ·         מה קורה אם רוצים להחליף את הספק בין יחידת מסירה אחת לאחרת

 

חלק מהתשובות נמצאות בקיט מיקור חוץ (Outsourcing) בכרך ניהול/ניהול הארגון.

אבטחת איכות

1.       בדיקה כללית של תכולת המסמכים המוגשים לועדת המכרזים (המשרדית או המרכזית):

             ·         מסמך ייזום (תמצית הפרויקט) או תמצית מנהלים

             ·         מפרט

             ·         מפ"ל

             ·         אישור תקציבי

2.       האם היה אפיון או שהמפרט נכתב ישירות?

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

4.       פרק מנהלה תקין? עיבוד לפי סטנדרט פנימי של המשרד? המצאה של היועץ?

5.       האם נעשה שימוש נכון ומושכל בסיווגים:

             ·         סעיפים בסיווג S: האם מוגדר בדיוק נדרש לענות? טבלאות למילוי?

             ·         ריבוי סעיפי סף?

             ·         סימול סעיפי סף בטעות בגלל דרישה למענה.

             ·         ריבוי סעיפים לידיעה בלבד?

6.       מהי תמצית הבקשה? על מה ייבחנו הספקים? מהם המשקלות? האם זה תואם את המפרט?

7.       לו אתה ספק, האם היית יודע איך בדיוק להגיש הצעה? על מה להתמקד? מה עיקר ומה טפל?

8.       גודל המפרט ומידת הפירוט: האם הוא סביר לגבי סוג המכרז?

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

             ·         אם רזה מדי: האם בכלל בוצע אפיון? האם אין כאן מפרט שנבנה ישירות?

             ·         מקרים מיוחדים: מכרזים לפתרונות מדף, חבילות תוכנה, ציוד תואם

9.       בדיקות מיוחדות לסעיפי המנהלה:

             ·         0.3: האם ניתן זמן סביר להכנת ההצעות לספקים? האם יש כנס ספקים מסודר וברור? האם יש ערוץ תקשורת ברור ומוגדר לגבי שאלות \ הבהרות?

10.   בדיקות מיוחדות לפרק 4 מימוש:

             ·         סעיף 4.2: האם המפרט מתווה אבני דרך ומסגרת כללית (נכון), או שהוא מכתיב תכנית עבודה מפורטת (לא נכון)?

             ·         סעיף 4.7: האם יש דרישות ברורות להדרכה, הטמעה, ליווי וכו'

11.   בדיקות מיוחדות לפרק 5 עלות:

             ·         האם ניתנו בסעיפים 5.1 ו- 5.2 טבלאות פשוטות וברורות למילוי

             ·         כנ"ל בסעיף 5.5: האם ברור איך יסוכמו עלויות ההצעות השונות ואיך יושוו?