איך כותבים מכרז IT שאפשר באמת להשוות לפיו בין ספקים?

שירותים הקשורים לנושא

• מכרזים טכנולוגיים וליווי רכש - דרישות מדידות, מנגנוני הוכחה וקבלה, SLA, מודל תמחור, מטריצת השוואה וליווי הבחירה והיישום.
• ייעוץ אסטרטגי וארכיטקטורה טכנולוגית - ארכיטקטורת יעד, מפת דרכים, ניתוח חלופות, סיכונים והצדקת השקעה לפני פרויקט משמעותי.
• ממשל, מבנה ותהליכי IT - בחינת מודל ההפעלה של מערך ה־IT לפי עקרונות COBIT ו־ITIL: אחריות, תהליכים, בקרה, שירות ומדדים.

RFP טוב מתחיל בתוצאה, לא במוצר

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

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

להפריד בין דרישות חובה, העדפות ויתרונות

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

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

לחייב מבנה תשובה אחיד

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

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

מודל התמחור חייב להיות חלק מהמכרז

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

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

SLA צריך להיות מדיד

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

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

שאלות הבהרה הן חלק מהתהליך, לא תקלה

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

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

איך בונים מודל השוואה

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

בדיקות קבלה צריכות להופיע לפני בחירת הספק

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

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

השורה התחתונה

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

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