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

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

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

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

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

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

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

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

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

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

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

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

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