הכנת מכרז

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

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

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

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